Re: [Standards] On Quick Responses

[Matthew Wild]

On Tue, 21 Apr 2020 at 23:06, Dave Cridland  wrote:

>
>
> On Tue, 21 Apr 2020 at 21:24, Matthew Wild  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
implementations.

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
> available.
>

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)
https://api.slack.com/tools/block-kit-builder

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
platforms.


> ### 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...
>

Why?

Regards,
Matthew
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] On Quick Responses

[Dave Cridland]

On Tue, 21 Apr 2020 at 21:24, Matthew Wild  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  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
___

Re: [Standards] On Quick Responses

[Andrew Nenakhov]

ср, 22 апр. 2020 г. в 01:24, Matthew Wild :

> Hi all,
>

We have similar functionality on our roadmap and so far we see no reason
not to use forms. Concerns about their complexity are overblown. Most
likely, we'll need some extensions to them, true, but I see little issues
with the basic principle.

One more thing. Blindly copying telegram won't cut it, for a simple reason.
Telegram allows this only for bots, because telegram always knows 100% that
an entity is a bot, so it can tweak client accordingly to interact with it.
In XMPP, any entity can be a bot, and some users will be greatly upset if
their client would remove their favourite keyboard and replace it with some
buttons, all without their consent.

We DO have ideas about a way to provide special input mechanics to users
which are announced by an entity, but it'll likely use something like
XEP-0050 Ad Hoc commands, it won't be based on messages received from an
entity.


-- 
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] On Quick Responses

[Matthew Wild]

Hi all,

I have an attachment to Quick Responses, as I originally pushed Zash to
write the initial Buttons XEP after our discussions. I'm really grateful to
Tim for trying to give this another attempt at life.

There is (and probably will continue to be) a bunch of discussion over what
I consider to be a very easy solution to gain some ground on UX and parity
with other messaging platforms.

## What other platforms are doing

I'm aware that a significant portion of our community may not be familiar
with other messaging platforms, but a number of them have a feature similar
to this one. Always used exclusively by bots (it makes little sense for
humans to manually craft suggested responses to their messages!)

If you're interested, here is more info about:

  - Facebook Messenger Buttons:
https://developers.facebook.com/docs/messenger-platform/send-messages/buttons

  - Telegram Keyboards:
https://irazasyed.github.io/telegram-bot-sdk/usage/keyboards/

  - Slack interactive message buttons:
https://api.slack.com/legacy/message-buttons

## Why other platforms are doing this

The primary motivation behind buttons across all these platforms is to
provide shortcuts for the user based on the context of the message that has
been sent. Prior to the introduction of these features, interaction with
bots was purely through text messages.

The problems with text-based interaction are well known. They lack
discoverability (i.e. the user doesn't necessarily know what options are
available that the bot can understand), and they can be painful to type
(correctly) on a mobile keyboard.

## Responses to feedback / FAQ

### Buttons, buttons, buttons

Throughout this email I'm going to refer to these things as buttons. I 100%
recognise that buttons are not the only UI that a client might present for
this.

I think renaming the proposal was a great idea for this reason, and I think
client developers should totally have the freedom to experiment with UI.
But I'm still going to call them buttons, sorry!

### Separation of responses/actions

I confess I don't see these things as separate at all. They both concern
the same UI elements ("here is a message, here are some things you can
do"). They both concern the same action at the protocol level: send a
response to the message in question.

I voiced my opinion in the MUC yesterday - my preference is for this to be
a simple list of actions, each one with an optional body to be sent in the
response message. I feel it can be left in the hands of bot developers to
choose the right course of action depending on the context.

In some cases you will want a body to be included, and in other cases you
won't.

This is literally the only difference between the two responses, and I
strongly feel that they should be merged.

### 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
 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.

### 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.

I think we do need to clarify a little bit how this should behave.

I'm not sure whether this should be based on the type of chat, the type of
response, or possibly even some other flag under the bot's control (e.g.
select between "custom keyboard" mode or "persistent interactive buttons"
mode). Or something else.

### Visibility of user responses

In the sense that this protocol replaces "legacy" text-based interaction,
there is no change here - people who would have seen a text response will
also see a quick response (whether it includes a  or not). I don't
see that this needs fixing for