<div dir="ltr"><div>Hi all,</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>## What other platforms are doing<br></div><div><br></div><div>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!)</div><div><br></div><div>If you're interested, here is more info about:</div><div><br></div><div>  - Facebook Messenger Buttons: <a href="https://developers.facebook.com/docs/messenger-platform/send-messages/buttons">https://developers.facebook.com/docs/messenger-platform/send-messages/buttons</a></div><div><br></div><div>  - Telegram Keyboards: <a href="https://irazasyed.github.io/telegram-bot-sdk/usage/keyboards/">https://irazasyed.github.io/telegram-bot-sdk/usage/keyboards/</a></div><div><br></div><div>  - Slack interactive message buttons: <a href="https://api.slack.com/legacy/message-buttons">https://api.slack.com/legacy/message-buttons</a></div><div><br></div><div>## Why other platforms are doing this<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>## Responses to feedback / FAQ<br></div><div><br></div><div>### Buttons, buttons, buttons</div><div><br></div><div>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.</div><div><br></div><div>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!<br></div><div><br></div><div>### Separation of responses/actions</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>In some cases you will want a body to be included, and in other cases you won't.</div><div><br></div><div>This is literally the only difference between the two responses, and I strongly feel that they should be merged.<br></div><div><br></div><div>### Why not use data forms?</div><div><br></div><div>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.</div><div><br></div><div>They are too complex for this feature, however - at the protocol, implementation and UX levels.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>"But we would be able to show more complex forms" is basically the opposite of the UX improvement that I am aiming for.<br></div><div><br></div><div>### Responses on earlier messages</div><div><br></div><div>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.</div><div><br></div><div>I think we do need to clarify a little bit how this should behave.</div><div><br></div><div>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.<br></div><div><br></div><div>### Visibility of user responses</div><div><br></div><div>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.</div><div><br></div><div># EOF</div><div><br></div><div>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.<br></div><div><br></div><div>Regards,</div><div>Matthew<br></div></div>