On Sat, 8 Dec 2018 at 22:29, Tedd Sterr <[email protected]> wrote: > > A few thoughts (some of which have already been touched on by others)… > > * clicking a button results in a textual message that provides no indication > that it came from a button press as opposed to being typed (I could type > "yes" for some other reason and you'd interpret it as a button press.) I > understand this is to provide a text fallback, but that doesn't mean such > information can't be inculded anyway for cases where it's understood.
I think you're viewing it wrong. The text is not a fallback, it's the baseline. The buttons are simply to provide convenient quick responses. I'm actually not very opposed to some additional element in the response with a per-button id, or even making <body> optional if we add this. However it is not the core use-case. > * there's no linkage of the reply with the buttons (if you send two messages > with buttons and I reply with "no", which set of buttons did that come from?) Yes, I agree this is frustrating. Either the buttons should only function for the last message (this is along the lines of how Telegram works), or they need some kind of per-message id (more like how Slack works). I lean towards the latter, but for that I think we would have to add the additional metadata element above. > * the buttons feel very detached - they're just appended onto the end. that's > not necessarily bad, but wrapping them in an enclosing tag would group them > and allow identification. Possibly easier for clients to pluck the buttons out of the message this way, yes. > * maybe some business rules regarding how many times buttons can be pressed > (can I press the same button twice? can I press multiple buttons? should all > buttons be disabled after the first press?) Last Message Correction ;) > * I think a few more suggestions for use cases might help people to better > see the utility. +1. > * this is limited to just buttons - which could be useful - though someone > will soon decide they also need drop-down lists, then someone else will want > checkboxes… > Obviously people will start muttering "shouldn't this just be data forms?" > Maybe it could be generalised into "Inline Data Forms" to provide a > reasonable subset of components suitable for use in chats (data forms's scope > is much wider). [And now it's too big and complex and you just wanted a > simple lightweight solution for buttons!] I'm not opposed to someone making something for forms. We've done it in the past (there was a GSoC project over 10 years ago to make a generic form designer for things like polls and surveys, etc.). The idea of sending forms inside messages is not at all new, but it has never been (widely?) adopted. I think dataforms have real-life hurdles to get over. I don't know of a single mobile client with dataform rendering for example (so they don't do custom IBR forms, they don't do ad-hoc commands, and they certainly won't do forms inside messages). But none of this belongs in this XEP, because it is not the goal. The goal is to provide (optional) quick responses to the message. To provide something like rich dataforms, you would first have to determine that the recipient can render it, or provide a fallback web link to fill out the form. This is absolutely not the goal of this XEP. Let's keep simple simple. I'm hesitant about i18n. Multiple <body> with different xml:lang is not used in reality. In reality the sender almost always already knows the appropriate language to use before sending a message. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
