Generalize Quick Replies for WhatsApp and other RICH_MESSAGING channels

[markboots]

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:

• Other input blocks (Open Response, Numeric, etc.) may want to suggest Quick Replies when useful possibilities are known.
• There is an emerging use-case where Quick Replies are loaded dynamically (at runtime) from a third-party service (e.g. via Webhook request). Using Select One block here for its existing Quick Reply capability runs counter to the goal of Select One, which is to select from discrete options that are structured within the Flow at authoring time, rather than runtime.

Proposal: To add an optional config parameter quick_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 or block.config.RICH_MESSAGING.quick_replies.resources:

{
  "blocks": [
    {
      // Example 1: Loaded dynamically from an expression
      // ...
      "config": {
        // ...
        "RICH_MESSAGING": {
          "quick_replies": {
            "expression": "@results.q3_webhook.value"
          }
        }
      }
    },
    {
      // Example 2: From an array of localized resources
      // ...
      "config": {
        // ...
        "RICH_MESSAGING": {
          "quick_replies": {
            "resources": [
              "c0eb929e-8cb0-45bd-826f-9c0a0e3b988c",
              "bd6274bf-5f22-4394-8ae7-ea3c8143a4f0",
              "78f8b5ef-7f4f-42c2-8f3a-bb2c85649609"
            ]
          }
        }
      }
    }
  ]
}

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?

[smn]

@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.