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, <[email protected] <mailto:[email protected]>>
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" <[email protected]
<mailto:[email protected]>>
*An:* "XMPP Standards" <[email protected]
<mailto:[email protected]>>
*Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response
вт, 21 апр. 2020 г. в 16:51, <[email protected] <mailto:[email protected]>>:
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: [email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
