[Standards] On Quick Responses

Matthew Wild mwild1 at gmail.com
Tue Apr 21 20:23:29 UTC 2020


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
<body> 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 <body> or not). I don't
see that this needs fixing for the use cases this is trying to fill.

# EOF

That's all for now, but hopefully it sheds some clarity on where this all
grew from and why I feel strongly that we need it.

Regards,
Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200421/d92fb755/attachment-0001.html>


More information about the Standards mailing list