From 9e0079f41b83c699bbc40a6bdeb83d4491c628ed Mon Sep 17 00:00:00 2001 From: Evgeny Poberezkin Date: Tue, 10 Dec 2024 10:53:04 +0000 Subject: [PATCH] update --- docs/rfcs/2024-11-28-business-address.md | 2 +- docs/rfcs/2024-12-08-chat-bot-ui.md | 27 ++++++++++++++++++++++-- 2 files changed, 26 insertions(+), 3 deletions(-) diff --git a/docs/rfcs/2024-11-28-business-address.md b/docs/rfcs/2024-11-28-business-address.md index e41c904457..7cee4ed6a3 100644 --- a/docs/rfcs/2024-11-28-business-address.md +++ b/docs/rfcs/2024-11-28-business-address.md @@ -8,7 +8,7 @@ When business uses a communication system for support and other business scenari It's important for the business: - to have bot accept incoming requests. -- to be able to add other people to the coversation, as transfer and as escalation. +- to be able to add other people to the conversation, as transfer and as escalation. This is how all messaging support system works, and how WeChat business accounts work, but no messenger provides it. diff --git a/docs/rfcs/2024-12-08-chat-bot-ui.md b/docs/rfcs/2024-12-08-chat-bot-ui.md index 2582a762fb..581809ad98 100644 --- a/docs/rfcs/2024-12-08-chat-bot-ui.md +++ b/docs/rfcs/2024-12-08-chat-bot-ui.md @@ -8,14 +8,37 @@ Interacting with chat bots requires structured commands, which require entering ## Solution +### Bot commands + +As commands should be recognized based on their syntax, the same list of commands should be accepted irrespective of the conversation state. In cases commands cannot be executed, for any reason, bot would respond with the message. + +One of the options where commands can be communicated is bot profile the best place to include supported commands, in the form of a menu tree. See the schema. + +The downside of communicating commands via profile is that they may change per contact or per group. The usual place to put commands is chat preferences, which also make sense - receiving commands is "the preference" of the bot. This preference would indicate that bot supports commands, and also which commands are supported with any additional information. + +This menu will be shown to the end users in the app when they type "/" character in the first position of after several spaces. When the user chooses command from the menu, it will be inserted into the entry field for further editing. The placeholders for parameter should be inserted as "". Clients may offer some interaction for filling parameters in, but in MVP it is sufficient to let users edit them directly. + +When processing commands bots should ignore leading and trailing spaces in the user messages. + +### Interactive dialogues with buttons + A special message sent by chat bot that would show a modal UI requiring to choose one of several presented options. These options should contain the text visible to the user with an optional emoji or action icon. The clients may automatically use icons for known words. -When this message is received, the compose area is either replaced with or complemented (if message allows a free text entry in response) with one or several buttons, either located in a row, with wrapping, or in a column. +When this message is received, the compose area is either replaced with or complemented (if the context allows a free text entry in response) with one or several buttons, either located in a row, with wrapping, or in a column. -When the response is sent, the chosen text is sent, possibly as a reply to the original message, and the original message can be looked at to show which choices it offered in message information pane. There could should be slightly different design or some marker to indicate that it was a message that offered multiple choices, and it could be updated to indicate it was replied to. +When the response is sent, the chosen text is sent, possibly as a reply to the original message, and the original message can be looked at to show which choices it offered in message information pane. There could be slightly different design or some marker to indicate that it was a message that offered multiple choices, and it could be updated to indicate it was replied to. + +The clients probably should not show client messages as replies. There are 3 options here: +- show as a normal reply. This avoids any ambiguity in the conversation history, and may protect customers from misbehaving bots - the message would be visually attached to the question. +- simply do not show reply in the conversation, but use replies in the protocol. +- use some other marker in the protocol. + +I prefer sending and showing normal replies in these cases, as it avoids any ambiguity in the transcript about which question the choices were offered for. That means that bots should support replies, not only normal messages. For protocol design we could either offer a completely different message, or we could use a normal message where all information would be present in the message text so it could be correctly presented by the old clients, with additional property that would be interpreted by the new clients so that it can parse the message text to present it as a multiple choice. +I prefer using normal messages with additional data. + ### Protocol Add to message container an optional property `choice`, an object with these optional properties: