Chatbots, as they exist today, aren’t great at understanding natural human language. And this is one of the main reasons why most of the messaging apps (Messenger, Kik, etc.) are resorting to a mix of graphical and text UI in their bot platforms. Think of buttons, carousels, and image cards—not just text responses.
We at Tars are using the browser as a platform to build our own chat interface for bots to operate. And this gives us complete freedom on the components we include. If you’ve tried any of our bots (if you haven’t, first try one out here and here), you probably know that we strongly support the graphical UI + text-based approach. As a part of this thought process, we’ve created a number of custom keyboard inputs in our front-end interface to facilitate different user interactions and situations.
“Chatbots aren’t great at understanding natural human language.”
Messenger, Kik, and Telegram are huge platforms where developers deploy hundreds of bots every day. I still feel these messaging platforms haven’t done enough with front-end components to help a botmaker create enriching user interactions.
Related: The ultimate guide to chatbots
That’s why I want to talk more about how we went about creating each custom UI, why each one makes sense, and how the lack of them is screwing up user interactions right now.
Date and time scroller
Think of a scenario where you need to ask a user when they’d like to make an appointment. There can be multiple ways of giving the same information.
25th Nov, 25th November, Nov 25th, 25/11, 25–11–2016, 11/25/16—all of them essentially mean the same, but it becomes difficult for a machine to make sense of this data.
This is why we’ve incorporated a date and time scroller where users can roll the dials and select the date/time.
I haven’t seen any other messaging platform provide this UI until now, and I feel this is a must have if a bot asks for a date or time from the user.
Think of these as multiple choice options in a form where you have a limited number of things to choose from. Tapping on buttons makes the interaction quicker and also keeps the scope of the conversation limited.
A button-based approach makes sense when you have to choose between a veg and non-veg pizza, but it might not be the best UI to have if you have 100 insurance policies to choose from.
“Tapping on buttons limits the scope of chatbot conversations.”
What else can be done with vertical buttons?
- Add an image next to each option to make it more visually appealing
- Let the user either respond in a single tap or make them click on “Send” after they tap on any of the options. The latter helps in reconfirming if the user didn’t select the particular option by mistake. There’s no way to go back in a chat flow—and that’s why this customization makes sense.
- Add a quick info menu to each option to provide detailed information and improve the decision-making process
One more important thing to keep in mind when you use button UI: Frame your question the right way. As Leszek explains in his article here, it’s better to have bots ask a question in a way that limits the range of options and sets the context instead of asking a very open-ended question.
Restricting user input
This is one of the best things we’ve done to our chat interface. Whenever we provide a graphical input UI (buttons, carousels, etc.), we don’t allow the user to type in anything in text.
“Restricting user input prevents broken conversations.”
Why do that? Because a user can type in anything out there, and your bot isn’t ready for that. Until you’re there, keep user input simple and restricted so you don’t break the conversation.
What we do:
And here’s what happens when you don’t have something like this:
“Done” and “pass” buttons
These are 2 small nuances incorporated because we’ve always thought of scripted chatbots as an evolution of forms.
When you’re sending across your address or giving a detailed feedback over a chat interface, the general behavior is to press the send button after writing a few words, and the whole response is eventually spread across 3–4 statements. With a “done” button, you can keep typing and press this once you’ve given the complete response.
If you don’t have such an option, the machine’s next message would come after the first instance itself, resulting in incomplete responses.
There might also be cases where a user wants to skip the question, and for that we have a “pass” button in place of the “send” button. As soon as the user starts typing, the “pass” button turns into a “send” button.
This is like the autocomplete functionality in a Google search where you start typing and it suggests possible options. This becomes particularly useful when you have a long list of options and having vertical buttons isn’t feasible. Think of a long list of localities, cities, car models, etc.
Stars and likes
Especially useful when you’re asking for user feedback or experience and the response is more qualitative in nature. And you can even customize the icons to be stars, likes, hearts, or emoticons.
This is useful when you need to showcase multiple pieces of information about each item at one go. Could be a burger in a food ordering process or a shirt in a shopping flow. All the cards are stacked against each other and you can scroll through to look at all the options.
There are 4 parts of this UI element: image, title, description, and footer. You can utilize these differently depending on what you want to display in there.
In case you want to test out all these input UI elements, here’s a link to a chatbot that takes you through one element at a time.
Chat, being a minimalist interface with just bubbles and a text box, doesn’t give much scope. And I believe we’ll have to rethink how we can facilitate a variety of interactions by using the existing elements and adding new ones to the chat interface.