Messenger Bots: Decision Trees vs Webviews
Since now we’re mostly past this obsession with natural language in bots, time to talk about another developer dilemma: message templates vs external web pages. Or put more simply, bubble chains vs webviews.
Most of you are probably familiar with the bubble chains. Here’s a bit more context on our approach to webviews. Last September, we launched Messenger Extension SDK. This JS SDK allows you to call some of the Messenger functionality within a web page if opened from the Messenger app. Two of the key features in the context of this post are 1) retrieving user identity, and 2) closing the webview container. Here’s how they can be used in practice:
- You send a message with a URL button that has the extension flag on
- A person taps the button and opens a webview without leaving Messenger
- Using the SDK, you retrieve the user ID, potentially personalize the page, capture user input
- When done, you send a message back to the thread if needed
That solves a big pain point by simplifying freeform input and enabling rich browsing experiences. I have to admit, we could’ve done a better job highlighting the benefits of this approach back then. We’ve also observed some aversion to webviews from the developer community and, as a result, bubble chains are still being used in most bots (with some great exceptions). Hence, this post.
What are decision trees? Pretend someone wants to buy a bonsai tree. They hit the “Shop” button in your bonsai bot, which triggers a message that asks what species they’re interested in. Then, your bot surfaces a bunch of quick replies to select from or asks for a freeform response. Next, the bot asks about tree size, age, and delivery location. And so on. At some point your customer changes their mind, or realizes they made a typo three steps back. Looking for a way to change it, they see a “Restart Flow” button in the menu. Ouch! Now they have to enter everything again.
This example shows the key limitation of decision trees: the cost of reentry is way too high. If the people using your bot lose their previous selections and have to start over, that negatively impacts your conversion rates and makes the overall experience subpar. It also illustrates that if a tree is longer than 2 steps and people want to revisit an earlier step in the flow, a tree may not be the best choice.
In general, even having a “Restart Flow” button in the menu is a good indicator that things will go wrong. Consider using a “Change Your Selection” button instead — a button that simply invokes a webview that displays their previous choices and gives them the opportunity to make edits.
There’s also a misconception that if the Messenger Platform supported richer UI elements like multiple choice selection, the problem would be solved. However, the root of the problem is that it’s actually a step-by-step selection for multiple data points. While multiple choice would optimize one step of the tree, it still wouldn’t allow people to go back and make changes without resetting the whole flow.
If you’re still debating between decision trees and webviews, here are two main use cases where webviews usually make more sense:
- Rich browsing experiences. Your content can be more engaging in a webview, incorporating larger images, additional scrolling, and specifically structured data.
- Entry of multiple pieces of data. Here webviews are the only feasible way, as cost of reentry and inability to change previous selections with decision trees results in a really poor UX.
To illustrate these two points further, Swelly recently shared how they migrated their iOS experience into a bot. Here’s how it looks:
Imagine how their subscription page would look in a message tree (and I see such examples a lot). Also note that some of their experiences are still using message flow, but it makes perfect sense as these are one-step actions.
Another example is Olabot which relies heavily on webviews for rich browsing:
Lastly, a message to bot developers and bot development platforms. We need better tooling for web aspects of bot creation!
A good example was set by GupShup, who recently launched the serverless webviews builder. Also check the slick set of web components built by WeChat — WeUI. It’s open-source and you can use it in your bots/platforms. To reap all the benefits of webviews, developers need to provide a quick and efficient way for businesses to create simple and beautiful web experiences.
PS: If you’ve built or know of a good example of properly used webviews for complex user input, please send it my way (tweet me your bots and screenshots). Would love to give them a shout out too!
UPDATE: Shane Mac posted a must-read article on a third way of bot flow design: random access navigation. Requires some serious grit but ultimately seems like the best from two worlds, especially when combined with webviews to allow quick review/editing.
Thanks to Elena Ontiveros and Jennifer Hakes for contributing to the post. Thanks to Andrew Yaroshevsky for inspiring me to write it with out debate.
Great bots mentioned in the article (in order of appearance): Hipmunk, Resolution Bot, Swelly, Olabot
