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]> 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. 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. > 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? > > *Gesendet:* Dienstag, 21. April 2020 um 14:26 Uhr > *Von:* "Andrew Nenakhov" <[email protected]> > *An:* "XMPP Standards" <[email protected]> > *Betreff:* Re: [Standards] Proposed XMPP Extension: Quick Response > > > вт, 21 апр. 2020 г. в 16:51, <[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] > _______________________________________________ > _______________________________________________ > 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] _______________________________________________
