article by Grant Ronald, June 2019
One of the key factors of a successful digital assistant is to make it easy for the user to make the right choices and stay on the “happy path”. Consider the example of booking a flight. If you know the user nearly always travels to the same two or three airports then wouldn’t it make sense to present those common choices up front.
The user can simply select the correct option rather than typing in the airport name. Of course, you still want to give the flexibility that they can free-type in any possible airport, but you want to make sure it’s a valid airport!
Or another common example when inputting expenses – maybe most of the time your expense currency is EUR, USD or GBP – so those might be the options you see up front but you should still be able to select any other valid currency
In this article I’ll show you how you how to easily present a list of common entity choices to the user, but still allow a natural language input which is validated as a valid value.
Below screenshots taken from the sample you can download for this article illustrate the use case. A user starts a conversation with a bot. The bot then displays three destination it recognizes as a user preference.
Still, the user is able to follow the conversational message path by typing or selecting a value from the list or by typing a different value, which is Los Angeles in the above image.
The solution outlined in this article relies on 3 primary concepts
- An entity called Airport codes is a list of valid airports along with synonyms (e.g. LHR Heathrow, LAX Los Angeles). This defines the list of all valid entity values.
- We’ll make the assumption that the knowledge of the user’s most commonly chosen airports comes from a backend system. Ideally, it wouldn’t be the skill which is making this decision. Let’s assume that either there was a custom component which returns properties indicating the top 3 airports or that for the bot there is a hard coded top three.
- A common response component is responsible for rendering the airport choice but will also further allow free text user from which a validated against the entity
Let’s take a look at the OBotML which supports this.
Firstly, note 1, you can see a variable called mostVisited which represents the values you would have retrieved from your backend system. In this example we’ve created this as an array of objects so that we can define not only the value of the airport, but a label and the action that should be triggered when that airport is selected.
Strictly speaking we don’t need the action property because whatever airport you select it always goes to the same state in the dialog flow rather than defining separate action states to navigate to. However, you might have a use case, for example, where if you select a non European airport you might have to make a different transition because you have to check visa status first.
Note 2 shows the CommonResponse component that will allow the values of mostVisited to be “stamped out” regardless of the number of values defined in mostVisited.
Within the CommonResponse component, note 3 shows the reference to a variable called code. This is a variable which references the airport code entity. By referencing it here the CommonResponse component will ensure that any input is validated against that variable to see whether it is valid.
The reference to iResult ensures that the CommonResponse component will slot the value of code (i.e. a valid airport) should it have been mentioned in the original user input.
Note 4 shows how the CommonResponse component iterates over the mostVisited variable (the variable of the top visited airports). For each entry within that array of objects it will display the label. On selecting an item it will return the payload which will trigger the defined action and will set the variable code to the value property of the currently selected item.
Related Content
TechExchange Quick-Tip: Implement Page Ranging for Lists using the Common Response Component
