It would be great (especially within chatbot workflows) to support interactive message buttons (like e.g. in slack https://rocket.chat/docs/developer-guides/rest-api/chat/postmessage#attachments-detail). As the slack syntax is quite straight forward, it can look analogously.
{
// some properties
"attachments": [
{
// some properties
"callback_id": "question_abc_123",
"actions": [
{
"name": "question_abc",
"text": "Yes",
"type": "button",
"value": "yes"
},
{
"name": "question_abc",
"text": "No",
"type": "button",
"value": "no"
}
]
}]
}
The answer could look like:
{
// some properties
"message": {
//some properties
"actions": [
{
"name": "question_abc",
"text": "Yes",
"type": "button",
"value": "yes"
}
],
"callback_id": "question_abc_123",
}
}
Rocket.Chat Version: 0.55.1
Running Instances:
DB Replicaset OpLog:
Node Version:
@geekgonecrazy and I was just talking about this functionality while we was at DockerCon last week, it will be something I be looking into in the next few weeks as I would love to enable this even for integrations.
We have had the start to this in for a while. Called actionlinks, its used by the video call. But they need to be expanded so they would be useful from an integration. :+1:
Hello!
I work on a chatbot project and would love to implement it to Rocket.Chat.
And of course having buttons would be a game changer. Does anyone work on this issue right now and what is the state of this project?
hey @geekgonecrazy,
couldn't we have a actionlink that implements any kind of button, by a default method that would receive these params "name": "question_abc", "text": "Yes", "type": "button", "value": "yes"
and generate a button that sends back the value as a message?
could.. could even have a message type maybe not visible on client UI that could be sent.
So you accept it and it sends a hidden message that something like a bot could listen for.
:man_shrugging:
This is now nearly a year old and for two projects a very big plus, is there some way to support this feature?
There is a current project to address this in GSOC. I will add to the bots roadmap for discussion and update topic for consistent terms.
GSOC project description is also useful context for the proposed approach:
Create UI components and develop the handling of message payloads to support new interactions for bots, like buttons, cards, images and more. Follow existing conventions to let bot developers migrate pre-built solutions to be delivered via Rocket.Chat. This opens the door for enhanced user experience and interaction flows in automated messaging, letting bots provide a much greater variety of utility; such as business apps, team workflows, even games and interactive narratives.
@timkinnane Hi Tim, we're also interested in this, especially for Android. I wonder if it would take some of the load off of the GSOC team if I created an issue in the Android repo and then put a bounty on it to get it done. My my concern then would be that we'd want to be aligned with the GSOC project. So, for instance, we'd want to use the same message schema, etc. that would be consumed by the IOS and Web clients. Thoughts on how we can align these efforts?
Need this too. Can support it with bounty too, if this will help make this feature a little faster. So @bizzbyster when issue with bounty will be ready, post info here, I'll throw a penny too.
Also I found a sort of dirty replacement, for bot buttons only, while the main thing is in progress, that may help to do fast and right now bots with buttons in answers: https://github.com/PropertyUX/rocketchat-commandwords
@slyk will sound out a simple spec soon for your (and others) comments. Question: which clients do you need? Getting support for all three might take time but we can certainly add the issues and bounty the ones we need.
Some discussion has happened on our forums related to this: https://forums.rocket.chat/t/supporting-fb-messenger-style-rich-chatbot-messages-menus/528
@slyk I actually built that dirty replacement. I don't have time to work on this right now, but I can chat with anyone who wants to follow up that piece and provide a stop-gap solution.
Following is a draft spec in a format consistent with other bot issues for the bots project roadmap...
Create UI components and develop the handling of message payloads to support new interactions for bots, like buttons, cards, images and more.
This opens the door for enhanced user experience and interaction flows in automated messaging, letting bots provide a much greater variety of utility; such as business apps, team workflows, even games and interactive narratives.
There鈥檚 two approaches to consider for buttons. The simplest is conversation prompt buttons, which just submit a basic command back to the bot and don't need to be coupled with anything on the Rocket.Chat side. This can be implemented with the click event for the button sending the button鈥檚 text as a message from the user.
The more complicated requirement is when the button needs to trigger a callback within Rocket.Chat or the bot, but should not be sent as a message, this can be achieved eventually, but we need to progress the UX standards and mobile consistent approach as well, so we should concentrate on the simpler approach first and expand the options when it鈥檚 mature and stable.
Thanks!
@timkinnane I agree with the approach you outlined in the forum link.
Our approach is to do the following:
1) Survey of rich message types across popular chat platforms so we get a sense of what is implemented and how those things overlap. Also we want to put a name next to each category of thing -- quick replies versus attachments with buttons, etc. -- with screenshots before we specify what we'd like to see added to Rocket.chat.
2) Write a short spec of what we'd like to see implemented that refers to that survey document and post here for comments. The spec will also include the payload structure which will be in keeping with your "Support payload structure from Slack and Messenger with minimal migrations".
3) Integrate feedback from @slyk and others into the spec and then post a bounty on this issue for the work required to implement it in the Web client.
4) Create seperate issues in Android and IOS repos pointing to this issue and post bounties for each of those implementations as well.
5) Work with implementors to get this feature in across the three platforms.
Let me know if anyone has any comments/enhancements to this approach.
That is an amazing plan @bizzbyster! Thanks for your proactive approach to this.
@timkinnane @slyk Here is a draft of the survey of rich message types that is number 1 in @bizzbyster 's plan of action just above: https://github.com/WideChat/Rocket.Chat.Android/wiki/A-Survey-of-Rich-Messaging-in-Chatbots
Thanks @jaytat0 !
Please send comments and feedback to the forum thread on this topic, which can be found here: https://forums.rocket.chat/t/supporting-rich-chatbot-messages-menus/528/12.
Wondering if this will cover everything RCS could provide...
This may be a little late, but make sure to consider the Rasa framework and how it implements buttons when you do this, as many developers use Rasa as their open source Chatbot core framework!
https://rasa.com/docs/core/slots/#slots-set-by-clicking-buttons
Most helpful comment
@timkinnane I agree with the approach you outlined in the forum link.
Our approach is to do the following:
1) Survey of rich message types across popular chat platforms so we get a sense of what is implemented and how those things overlap. Also we want to put a name next to each category of thing -- quick replies versus attachments with buttons, etc. -- with screenshots before we specify what we'd like to see added to Rocket.chat.
2) Write a short spec of what we'd like to see implemented that refers to that survey document and post here for comments. The spec will also include the payload structure which will be in keeping with your "Support payload structure from Slack and Messenger with minimal migrations".
3) Integrate feedback from @slyk and others into the spec and then post a bounty on this issue for the work required to implement it in the Web client.
4) Create seperate issues in Android and IOS repos pointing to this issue and post bounties for each of those implementations as well.
5) Work with implementors to get this feature in across the three platforms.
Let me know if anyone has any comments/enhancements to this approach.