Article by Frank Nimphius, December 2020
While chatbots shouldn't pretend to be human, they shouldn't behave robotic either. A bot that has a single prompt for interacting with a human can only display that single prompt, which sounds like a broken record if the prompt needs to be displayed again. In Oracle Digital Assistant, there are two things you can do to make your chatbot appear more natural when prompting users. Both have to do with entities and the use of either the System.CommonResponse component or the System.ResolveEntities component to render the entity.
A reoccurring theme you find on Oracle TechExchange is model-driven conversations that use entities to prompts users for input and for holding and validating user provided input. Custom entities, and when used in composite bag entities then system entities too, expose properties developers can set. The three properties that help with the display of smart prompts are
- The prompt property
- The error message property
- The disambiguation prompt
In this article, I'm going to show you how to create alternating prompts using the prompt property that "escalate" problems after users provide invalid data entries by displaying additional information that guide users or suggest an alternative.
As an example, let's take the usecase of a chatbot selling wine. One of the entities it has defined is for shipping sizes. For simplicity, the delivery is available in three sizes: a single bottle, a box of 3 bottles and a box of 6 bottles.
The Example
In the sample below, the user is printed for providing a value for the shipment size of a wine delivery.
If the user fails to select from the list, then input validation fails and the user is re-prompted. Notice the prompt in the re-prompt that shows additional information. If then the user fails again, the bot response provides an escape option, which in this case is to suggest contacting customer support,
The images above show a sequence of messages in which each message provides more user guidances. Lets re-run the sample, pretending the order process is started over again and again look at the prompts.
Notice how the prompt is different from the first prompt, which started with "Wine. You can never have enough". This time it starts with "Ordering good wine requires two skills. Good taste and an idea of how much you need". So apparently the chatbot can select from a range of prompts for displaying the initial user input. Notice how the second and the third message too differ from the first run of the sample. So what we are seeing is
- For each prompt there are a number of prompts defined that are displayed in a random order
- Each re-prompting for a user input also has a set of prompts defined that are displayed in a random order
All in all, using different prompt messages for each prompt and also be able to show different details based on whether or not a previous first or second input has failed, makes the bot appear more human and less robotic.
How to implement
All prompts are defined on an entity. Actually they are not defined there but reference a resource bundle string.
The entity definition
The entity used in the sample is a value list entity with 3 values.
To prompt users to define the shipping size for the wine they selected, the entity has the following prompts defined
All in all, the image above shows 9 prompts. Each prompt is defined in a resource bundle. Using resource bundles for prompts is not mandatory but I consider it best practices, which is why I am promoting the use of resource bundles. The "rb" reference is the name of a variable in the dialog flow. The variable type is "resourcebundle".
Note: The order in which prompts and sequences are defined in the entity has no impact to when they are rendered. All that matters is the sequence number (if used) and the number of prompts.
Prompts and Sequences of
You can define one to many prompts for an entity. The prompts are either displayed in a sequence (if a sequence is provided) or in random order (if no sequence is provided). In the example shown in the image above, there are three prompts defined for each sequence. What this does is as follows: The first time a user gets prompted for input, one of three prompts is displayed that are configured for sequence 1. If the user failed to provide a valid data input, then one of the three prompts defined for sequence 2 is displayed. If again the user fails to provide a valid data entry, then one of the prompts in the sequence 3 range is displayed.
Given the order of sequence 1, sequence 2 and sequence 3, you can use the prompts defined for a sequence to handle "escalation" of failed user input. The prompts in sequence 1 may be defined short but friendly. The prompts in sequence 2 then still are defined friendly but with a lot more explanation in the message. The prompts in sequence 3 are friendly, expensive and also e.g. offer users to contact customer service.
The prompts you define within a sequence are displayed in random order.
Resource Bundles
I defined the prompts in resource bundles. The image below shows the resource bundle keys used in the sample. Note that there is no rule demanding for using 3 sequences or using 3 prompts. You can define as many sequences as you like and also as many prompts within. You can also have sequences with 2 prompts defined and other sequences with e.g. 10. The number of prompts you define for a sequence determines the likelihood for users to actually see different prompts.
You can imagine that the chance for a prompt to display is 50% for 2 prompts that are defined. For 10 prompts, the likelihood of a different prompt to be shown is 90%.
Use maxPrompts
Though it sounds like fun to display alternating prompts and to guide users, there should be an end defined to avoid users being locked in e.g. a validation loop. For this you can set the maxPrompts property on the System.CommonResponse and System.ResolveEntities component for regular entities or the "
The image below shows the resource bundle keys used in the sample. Note that there is no rule demanding for using 3 sequences or using 3 prompts. You can define as many sequences as you like and also as many prompts within. You can also have sequences with 2 prompts defined and other sequences with e.g. 10. The more prompts you define, the more likely it is for users to actually see different prompts.
Use maxPrompts to avoid endless validation loops
Though it sounds like fun to display alternating prompts and to guide users, there should be an end defined to avoid users being locked in e.g. a validation loop. For this you can set the maxPrompts property on the System.CommonResponse and System.ResolveEntities component for regular entities or the "Maximum User Input Attempts" property on composite bag entity items.
Dialog flow definition
For this example I used the System.ResolveEntities component. The first image shows the definition of the entity type variable.
This variable then is used with the System.ResolveEntities component to prompt the user for selecting a shipment size.
A final runtime demo
Lets look at another runtime example
About the error message property
In this sample I did not use the error message property of the entity. You can use the error message property to display a message in front of a prompt indicating that a previous data input attempt failed. However, in this sample I am using a sequence of prompts, which means that sequence 2 is displayed when a previous data input attempt failed. So there is not really a reason for me to use the error message in front of the prompt. However, only because I did not use it doesn't mean it cannot be used. You decide in your design how you compose and display prompts in case of a previously failed data input attempt.
Related content
TechExchange: Use Entities To Build Powerful, Robust And Speech-Ready Action Menus
TechExchange Quick-Tip: How-to use the maxPrompts property for input validation
