[Standards] On Quick Responses
mwild1 at gmail.com
Wed Apr 22 06:39:01 UTC 2020
On Tue, 21 Apr 2020 at 23:06, Dave Cridland <dave at cridland.net> wrote:
> On Tue, 21 Apr 2020 at 21:24, Matthew Wild <mwild1 at gmail.com> wrote:
>> ### Why not use data forms?
> What happens when people want to show, for example, a polling bot, or a
> ... well, anything beyond some text followed by some buttons?
Not sure why a polling bot wouldn't be possible with this?
> 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.
For the future I don't see this protocol "going" anywhere. It's a very
simple protocol with a very simple ambition. And it might actually see
Forms certainly open more possibilities, at the cost of additional
complexity in construction, parsing and the UI work required to display
them sensibly. Unless we modernize/replace XEP-0004 with the capabilities
of modern UIs, it's going to be doomed to be a UX monstrosity. I honestly
think we'd do as well to define some way of embedding (X?!)HTML widgets in
messages (XEP-0088 anyone?).
FWIW XEP-0004 itself already details the possibility to send someone a form
in a message and they will simply render it (it even includes a disco
feature for this ability). Yet it's almost our oldest protocol XEP, and no
bot or client implements it. (This is where someone tells me Psi or Gajim
support it, and pop up a form dialog - which only proves my point).
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
Ok, well I linked to what other platforms are doing. The truth is, they are
doing stuff far in advance of this current proposal. Facebook support
buttons that don't just generate a response, but also that directly open a
URL, or carry out other Facebook-specific actions.
And the Slack documentation I linked to? It's actually deprecated. While
they started with buttons, they reworked their entire "interactive
messaging" API so that you can essentially compose any kind of message,
including interactive ones, out of various "blocks". You can get a feel for
it with their design tool here: (probably requires a Slack account)
Moving an ecosystem is hard. We aren't going to get anywhere near Slack or
Facebook overnight, but it's not even clear that we need to. We have
extensibility already baked into our core. There is merit to working with
simple additions such as this one that are relatively easy for client
developers to implement, with obvious UI choices.
Other platforms have the advantage that they control the protocol, and also
control the rendering code which they write once, maybe twice, to reach all
> ### 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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards