Open markboots opened 1 year ago
@markboots thanks for kick starting this, it aligns with how we're approaching this at the moment. We have a custom block that takes an expression in the config which is expected to return a list of resources.
The detail here is that for an expression, the resources and exits (depending on implementation tradeoffs) also need to be dynamically generated for the expression and this needs to happen at run time. This has the side effect that when running a flow with an expression for quick replies, the state of that flow (including any resources & exits dynamically defined) need to be stored in the flowspec JSON for the duration of that flow's session as these may vary from other session's resources & exits because the values come from a dynamic expression.
Quick Replies are an important part of effective chatbot user experience, to guide contacts on how to respond, and to accelerate interacting with flows. Many chatbot channels (WhatsApp, Facebook Messenger, Telegram, etc.) support Quick Replies. For instance, "Reply Buttons" and "List Messages" are available on the WhatsApp Business API.
Until now, the only standard Flow Block that supported Quick Replies was the Select One block: its choices could be easily presented as quick replies. However, this is limited in two ways:
Proposal: To add an optional
config
parameterquick_replies
to all blocks, scoped to the RICH_MESSAGING channel, with an array of quick replies to be presented to the user. To support dynamic loading, this can either be an expression (which is expected to return an array), or an array of resources. (Resources are necessary for content localization into the contact's language.)Parameter:
block.config.RICH_MESSAGING.quick_replies.expression
orblock.config.RICH_MESSAGING.quick_replies.resources
:The channel driver would be responsible for determining the presentation (and the viability) of how the quick replies would be implemented on a particular channel/chatbot. For example, on WhatsApp, if the number of quick_replies is up to 3, they can be presented as Reply Buttons; if up to 10, they can be presented as a List Message. If more than 10, another approach (or no display) would be the result. Quick Reply capabilities and limits vary by chatbot channel, so they should not be relied on for flow functionality, only to improve the contact's user experience.
@smn, any additions from your team?