1. Using Oracle Digital Assistant
  2. Digital Assistant Development Blueprint
  3. Channel-Specific Considerations

12 Channel-Specific Considerations

Here are some channel-related things you should think about and plan for when designing your digital assistant.

The term "channel" encompasses the messaging platform and the messenger client a bot uses to interact with users. Channel considerations should be made during the planning phase of a digital assistant project and when implementing the digital assistant.

Oracle Digital Assistant has native support for a number of channels including Facebook, MS Teams, Slack, Web, iOS, Android, and SMS. For natively-supported channels, Digital Assistant handles the message transformation of incoming message payloads into the format used in the digital assistant and vice versa. As a developer, all you have to do is create a channel configuration in Digital Assistant and provide the required channel-specific information.

Channels that don’t have native support in Digital Assistant can be connected to a digital assistant via a webhook. This is a generic configuration that you use with custom code that you need to write to convert and queue messages.


Description of second-language.png follows
Description of the illustration second-language.png

Consider Channel Limitations When Designing Your Chatbot

Although all channels generally do the same thing, each has channel-specific features and limitations. Typical limitations include the number of actionable items that can appear in a list of values or on cards in a carousel, or the layout of cards. For example, Slack only supports for vertical card layouts.

Other differences are in the support of message formatting and highlighting. The web channel, for example, allows you to use HTML markup and stylesheet to format messages while others don't.

Note:

Depending on the channels that you are targeting and the extent of the formatting that you need, it may be possible for you to use HTML markup in your messages. If you use that approach, the markup will be automatically converted to the channel-specific format when the message is transmitted to each channel. See Rich Text Formatting in Channels.

As a strategy you can choose between:

  • Designing your bot for a single channel.

  • Designing your bot for the highest common denominator.

  • Designing your bot for all channels and optimizing it for a few.

Design Your Bot for a Single Channel

The least sustainable solution is to design your digital assistant for only one channel and ignore the others, even those that may be options in the future. In addition to being the least sustainable, this solution is also the least recommended since you are designing a single-use product.

There might be use cases for such an approach, like a proof of concept that you need to create quickly. But for any bots that you want to release into production you should consider one of the other two approaches.

Design your Bot for the Highest Common Denominator

If you know the channels you need to support with your bot and agree on an implementation that each of the channels can support, you can create a digital assistant that works the same on multiple channels with little development effort and therefore without much delay. The downside of this is that, for some channels, it will feel like driving a sports car but only using the first of six gears.

This option makes sense if the goals you have outlined for your chatbot don’t require an optimized channel experience.

Design Your Bot for All Channels and Optimize for a Few

Another term we use for this option is “adaptive design” or “adaptive bot response design”. Much like the same paradigm in web application development, you build your chatbot to work for all channels and then apply changes for some that optimize the user experience. Adaptive bot response design will take longer for you to implement but ensures the best user experience possible, plus the ability to leverage channel specific features like adaptive cards on the MS Teams channel.

To implement this design strategies, you have the following tools available:

  • Resource bundles that use the ICU message format to display channel specific messages.

  • The Switch component to branch to channel specific conversation flows.

  • The visible property on the Common Response component to show or hide response items based on the channel type that is used.

  • The ${system.channelType} expression in dialog flows on entities and for built-in dialogs to display channel specific messages. If you use custom components to render bot responses, then the channel type is also available as a function on the context object.

  • The Common Response component and custom components, which support channel custom properties, which you can use to send channel specific properties, like adaptive card payloads for the MS Teams channel.

  • Optimization built into Oracle Digital Assistant that automatically uses the best replacement for functionality that is not available on a platform. For example, the horizontal card layout in Slack is automatically changed to vertical cards.

Implementing Channel-Specific Bot Responses

One implementation that we observe frequently but which we don’t recommend is to write text messages directly into the UI components instead of using resource bundle references.

A second pattern we see is developers adding HTML markup to messages that they either add directly to the text message property in UI components or that they store in resource bundles. Using HTML markup limits channel support for a bot to those channels that support markup.

You can use markup, but we suggest that you use it in a way that does not lock you in. Here is an example that uses the ICU message format for resource bundles in Oracle Digital Assistant to avoid a channel lock-in:

{channelType, select,
  web {<b>This message uses HTML markup to display in bold</b>}
  slack {*This message uses markdown to display in bold*}
  other {This message is for all other channels}
}

To reference the message in the resource bundle, you would use the following expression in your dialog flow, entity, or skill configuration:

${rb('the_key_name','channelType',system.channelType)}

Checklist for Channel Considerations

  • ☑ Design for all, optimize for a few.
  • ☑ Consider adaptive design when supporting multiple channels.
  • ☑ Use resource bundle strings for all your bot messages.
  • ☑ Leverage the ICU message format to build resource bundles that adapt to the message to a channel.

Learn More