[Standards] Proposed XMPP Extension: Quick Response

Tim Henkes syndace at web.de
Tue Apr 21 14:00:25 UTC 2020


On 4/21/20 3:40 PM, Dave Cridland wrote:
> Not blocking comments, but I'd like to explore the forms thing a bit more:
>
> On Tue, 21 Apr 2020 at 13:40, <syndace at web.de <mailto:syndace at web.de>>
> wrote:
>
>     I agree that forms are a better fit for more complicated use-cases
>     with multiple fields and options. And I can see that the benifit
>     of a single-click "yes" vs. a manually typed "yes" isn't super high.
>
>
> There's a disadvantage in responses which is that there's no
> indication that a response is a response. But maybe that's OK - for
> bots that are essentially text-driven, this would allow for pre-canned
> responses. On the other hand, a bot could handle something more
> structured just as well, in parallel.
>
"Something more structured" would probably mean something that requires
additional client support to work, right? To reiterate, the idea for
quick responses is that they are 100% equivalent to manually typing the
message. So that e.g. memberbot can just add indicators that "yes" and
"no" are possible responses, without having to do/change anything else.
I think the simplicity and non-structuredness is the key here.

> So I can see that these are useful, but I'm worried they'll end up
> baking in a data-as-text-body construction which is less than ideal,
> and tricky to move away from.

Maybe the protoXEP should hint at forms for anything more complex than
just a plain text response.

>     But I think you are missing the second half of the protoXEP, which
>     is actions. Actions have a lot more potential under the hood,
>     examples are:
>     - a "merge now" action for a Git bot that notifies a about a new
>     merge request
>     - a bot that does polls/votes in MUCs
>     I think that this can't easily be mapped to forms and that Actions
>     are a super simple extension that allow for a variety of different
>     interesting bots.
>
>
> I think any single action can be mapped to a form (I mean, it's an
> XSLT transform, let alone a semantic equivalence).
>
> For multiple actions, we cannot exactly duplicate the UX because we
> want multiple submit buttons, and forms provide only one (essentially).
>
> We could, instead, create a new field type in forms that would act as
> a submission button. Or we could just use multiple forms - ugly, but
> still.
>
> So what does <action/> offer that a form cannot/does not, that we want
> to go this route?

You could define multiple actions as a single form that may only contain
instances of the new submission button and that has to be rendered
inline together with the message by clients. But that would mean that

a) only the subset of forms is used which doesn't even exist yet

b) possibly (not sure about that one) a set of rather complicated rules
that try hard to make forms fit in, where the proposed solution is a
single super compact XML element with clear semantics.

And clients obviously couldn't support Quick Response without supporting
forms, though from what I've heard support for forms is rather
wide-spread in clients so that's probably not a big issue.

>     *Gesendet:* Dienstag, 21. April 2020 um 14:26 Uhr
>     *Von:* "Andrew Nenakhov" <andrew.nenakhov at redsolution.com
>     <mailto:andrew.nenakhov at redsolution.com>>
>     *An:* "XMPP Standards" <standards at xmpp.org
>     <mailto:standards at xmpp.org>>
>     *Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
>     вт, 21 апр. 2020 г. в 16:51, <syndace at web.de <mailto:syndace at web.de>>:
>
>         One example use-case for Quick Response is the memberbot,
>         which asks yes/no multiple times during membership voting.
>         Memberbot does not use a form to ask for yes/no, but a
>         plaintext message. The idea of Quick Response is to enable
>         memberbot to tell clients that "yes" and "no" are possible
>         answers, so that clients can offer convenient UI to quickly
>         select one of these possibilities. I think forms would be
>         helplessly overkill here.
>
>     Well, forms are a good standard way of presenting a user with
>     different buttons and options. It can be used for any kind of bots
>     in a fairly straightforward way.
>     I think that bloating a number of XEPs that are to be supported by
>     various application developers is wrong way to go.
>     In short, we are unlikely to support this.
>
>     --
>     Andrew Nenakhov
>     CEO, redsolution, OÜ
>     https://redsolution.com <http://www.redsolution.com>
>     _______________________________________________ Standards mailing
>     list Info: https://mail.jabber.org/mailman/listinfo/standards
>     Unsubscribe: Standards-unsubscribe at xmpp.org
>     <mailto:Standards-unsubscribe at xmpp.org>
>     _______________________________________________
>     _______________________________________________
>     Standards mailing list
>     Info: https://mail.jabber.org/mailman/listinfo/standards
>     Unsubscribe: Standards-unsubscribe at xmpp.org
>     <mailto:Standards-unsubscribe at xmpp.org>
>     _______________________________________________
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200421/12f4dfac/attachment-0001.html>


More information about the Standards mailing list