Dear Facebook Messenger, we need fallbacks.
Dear Facebook Messenger team,
I love your product. At F8, I enjoyed hearing how much Facebook is investing in chatbots, AI, and messenger ‘bots. All of this is crucial to make people like us invest time and a non-inconsiderable amount of money in developing rich conversational interfaces for our users to enjoy.
I do have a couple of grievances that I would like to highlight.
Browser feature segmentation, but for chatbots.
When you are browsing the web, your browser sends an identification string that the server can use to send content customized to the browser. While not a perfect solution, it hugely improves the end user’s experience, because they don’t suffer broken HTML and non-functioning websites.
We are running into the same challenge with the Facebook Messenger platform. It is very hard to create chatbots if you don’t know what the capabilities of the client are.
For example, Facebook Messenger on the desktop has a different feature set than Facebook Messenger on iOS. Within the mobile app, you can use a sharing intent to share the bot with people via Messenger. On the desktop, that button is just grayed out. Not a great user experience.
You’re forcing chatbot developers to avoid your advanced features.
The native Messenger experience is different than the feature set for Messenger within Safari on mobile. That experience is different again within third-party clients like the Disa messenger app. And the Android Facebook Messenger app. And the Amazon Fire Facebook Messenger app. And… Well, you catch my drift.
In addition to the feature sets, there are different behaviors as well — Within the native app, you can pop up a web view to capture customer data, for example. On the desktop, the web view opens a new window. The differences in user experience are jarring and confusing. Which is OK, as long as you prepare the user for what is about to happen. We can’t: we don’t know what the user experience will be.
One proposed solution: Fallbacks.
Only the Messenger platform itself knows what clients its users are using at any given time.
Remember that the challenge is not just about the first time a user sees a message. A user can complete a conversation in the Facebook Messenger app for iOS, then switch to the pop-up messenger window on Facebook.com, before taking another look at the conversation within the native Messenger app on Android, and then revisit the same conversation on Messenger.com. Scrolling back through the timeline in a client that doesn’t support all of the features could be frustrating.
This is where the web is different from chat interfaces: A web page is generated especially for the browser, and you don’t expect to go back to the same state. People are used to a website looking slightly different if it’s loaded on mobile, a modern browser, or Internet Explorer 6.
A conversation is different. Even if Facebook passed developers a client string, it doesn’t mean that this is consistent from message to message. More importantly, if you make decisions based on a client string one minute, it doesn’t necessarily mean that those decisions are still valid 20 seconds later.
In our mind, the only sensible solution is to offer a set of fallbacks. Whenever we want to use an advanced feature, the fallbacks will make it possible to degrade the experience gracefully. At the moment, a user using the Disa messenger simply doesn’t see the prompt they need to click on, and they get stuck in the conversation. It isn’t the user’s job to know that a “solution” is to switch to the desktop or a native client. That’s a terrible user experience.
However, imagine a situation where we send an advanced behavior with a fallback. If you are using a native Messenger app, you get the full experience. If you’re on a client that doesn’t support the particular behavior we need, perhaps we could configure a fallback message. “Hey, looks like your Messenger doesn’t support web-views, would you like to talk through these questions instead?”
Again, it would be ideal if all clients supported all features, but failing that, not leaving customers to get frustrated along the way would be a far better experience than what we currently have.
Right now, developers won’t use advanced functionality
By not offering fallbacks, dear Messenger team, you’re shooting yourself in the foot. It means that you’re forcing chatbot developers like ourselves to avoid your advanced features.
That’s lose-lose: We want to make chatbots that offer rich, advanced experiences. And you want to help us do that. Your metrics will tell you that nobody is using the advanced features, which might (erroneously) lead you to conclude that none of us want them. That’s not the case.
As programmers, we can probably code around all of these edge cases, but only if there is some way of knowing which client the customer is using, or being confident that advanced behaviors degrade in a safe state, rather than resulting in a broken conversation.
Right now, we can’t. And that means that the only way to do this is to give the user an advanced feature, and then say “Hey, if that didn’t work, let me know, and we’ll do it a different way.” That’s not the experience we want for our customers. That’s not the experience Facebook wants for its users. We can be better than that.
Oh, and developer support, please.
The final piece of the puzzle is customer support. We have run into some pesky problems where we need input from Facebook. Either due to inconsistencies in documentation or behavior that was unexpected.
At F8, you encouraged people to develop for your platform. Developer relations / support is part of that puzzle, and we’d love to see that improved further. Having someone to explain challenges to would be a relief. Being able to get answers when we are stretching the limits of what Messenger is able to do would go a long way.
Haje Kamps is the CEO at LifeFolder, a company that is using chatbots to help people to plan for end-of-life healthcare.
Source: Chatbots Magazine