On Tue, 21 Apr 2020 at 21:24, Matthew Wild <mwi...@gmail.com> wrote: > ### Why not use data forms? > > Data forms have existed for a long long time. They are quite powerful, and > have been reused successfully in a bunch of places for both human and > machine interactions. > > They are too complex for this feature, however - at the protocol, > implementation and UX levels. > > From a protocol perspective, they don't even currently support what we > want - an array of buttons. We could hackily build it out of list-single, > but that will eliminate any attempt at reusing rendering code that will > want to display them as e.g. radio buttons. Also you would still need to > include a <body> in some use cases. > > Client support: next to zero in mobile clients. Look at desktop clients > and it's not hard to see why - it is hard to present data forms in a nice > user-friendly way, it is hard to integrate with UI libraries in a way that > doesn't look plain ugly. > > Which brings me to my final point: Good UX these days is not about > providing the user with a flat list of controls of a handful of limited > types that were common in 2001. > > "But we would be able to show more complex forms" is basically the > opposite of the UX improvement that I am aiming for. > > What happens when people want to show, for example, a polling bot, or a ... well, anything beyond some text followed by some buttons?
If the answer is "XEP-0004 Forms have ended up being used primarily non-interactively, especially in user-facing cases, and are unsuited to modern UX" that's absolutely fine as an opinion, but it's not an answer. I'd like to know where you see the future going. Note that I don't see a reason to block this from Experimental, but I do wonder if we could consider options that have a little more extensibility available. > ### Responses on earlier messages > > For interactive bots (especially 1:1) such as memberbot, only showing > quick responses for just the latest message makes sense (and is how > Telegram "custom keyboards" work). For notification bots, you may still > want to display buttons under each notification. E.g. in the winning > example of a Mercurial notification bot, it would be surprising if two > notifications arrived together and only the latter had a button to merge. > > It'd also be surprising if you clicked Merge, and as you did so another pull request message arrived... Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
