Creating universal commands

Voice applications benefit from having a small number of universal commands that work throughout the application—for example, “help”.

Such universal commands can be associated with VoiceXML events that are thrown whenever the related command is recognized. The application must then include event handlers that contain the appropriate instructions for the command. For example, the “help” command may play different prompts at different stages of the application, to let the user know what to say next.

There are two main methods for implementing universal commands:

  • The universals property—NVP supports a standard universals property that throws events for exit, cancel, help, and operator commands. NVP also offers default handlers that react to these commands if no other instructions are supplied in the application.

  • Custom universal grammars and links—An application may support universal commands with a series of <link> elements with grammars that recognize each command. Such links may throw an event that has a matching <catch> handler, or transition to another part of the dialog using the next attribute of the <link> element. If no action or event handler is supplied, the event is simply ignored.

These methods are generally best used in the application root document, giving them an application-wide scope.

The table below lists recommendations for some standard universal commands, and describes how the application should respond when they are recognized.

Universal command Related event Recommended handling
Help help

The application responds with detailed instructions about the current dialog state, explaining where in the application the caller is and what choices are available. It may also list all universal commands.
Cancel, Go Back cancel

The system returns to the previous step in the dialog or previous menu. Callers might get confused about where they end up after such a command, so always explicitly state where they are going.

Exit, Goodbye

exit

The system responds to the caller’s request to end the call, but takes precautions to avoid unintentional hang-ups caused by false recognitions. Some strategies include confirming that the caller wants to hang up if the confidence score is below a threshold (such as 0.6), or stating that the caller can hang up at any time.
Operator operator

The system responds by transferring the call to a human operator (if the application has access to operators). Before the transfer, a system message explains that the transfer will take place. If no operator is available, the system tells the caller and provides details about how the caller can get help. Sometimes a follow-up dialog is required to learn where the caller should be transferred (for example, a billing specialist, or general representative).
Repeat repeat

The system responds by simply repeating the last meaningful item spoken to the caller.

Main Menu/Start Over

 mainmenu

The system responds by playing an earcon for the main menu (if appropriate) and re-entering the main menu. If there is no main menu, it plays the first prompt that follows any login process.

The universals property

The universals property can be used to enable several universal commands automatically. The supported commands are “exit”, “help”, “cancel”, and “operator”. To activate these commands, simply use the <property> element:

<property name="universals" value="all"/>

You can also activate only a subset of the commands by listing them one by one in a space-separated list. For example, to enable only the help and cancel commands:

<property name="universals" value="help cancel"/>

To disable universals, supply a value of none:

<property name="universals" value="none"/>

This allows you to disable some universal commands locally. For example, you can enable all universals in your application root, but disable the exit command within a specific field by setting the value to “help cancel operator” (leaving out “exit”).

When recognized, each command throws an event with the corresponding name (cancel, exit, help, or operator) which must then be caught and handled.

NVP provides default handlers for the four property-based universal commands, but these handlers are not terribly useful—each plays a simple error message, and then exits the application (except for the help handler, which simply plays a different message and continues). It is therefore recommended that the application include separate handlers in order to ensure that the commands result in an appropriate action.

Custom universals

If your application requires additional universal commands, you can add custom universal commands by creating your own grammars for them and using the <link> element to perform an action when the command is recognized.

For example, instead of using the universals property, the pizza.vxml root document for Pizza Talk links the universal commands “help” and “repeat” with specific events to be thrown whenever the appropriate command word is recognized:

<link event="help">
  <grammar src="../grammars/universals.grxml#Help" weight="0.01" />
</link>
<link event="repeat">
  <grammar src="../grammars/universals.grxml#Repeat" weight="0.01" />
</link>

The next section specifies the actions to take whenever these events are thrown:

<catch event="help">
  <assign name="entry" expr="'help'" />
  <reprompt/>
</catch>
<catch event="repeat">
  <throw event="help"/>
</catch>

Both these handlers assign the ‘help’ value to the entry variable. This value is then used in other PizzaTalk documents to select the appropriate message to use as a reprompt, depending on where the caller is in the application when the command is invoked.

Instead of throwing an event, a <link> can use the next attribute to move to another part of the dialog. See Links for an example.

Universal commands are not limited to the recommendations provided above. You can use a link to generate events for other universal commands specific to your application.

For example, suppose your application places orders and you want to include a universal “total” command to play back the current total money that the order costs at any point in the application. In this case, in the root document you might include the following:

<link event="total">
  <grammar src="../grammars/universals.grxml#Total" />
</link>
<catch event="total">
  <prompt>Your current total spent is <value expr="current_total" />. </prompt>
</catch>

This example assumes that the universals.grxml#Total grammar rule catches the word “total”, and that the current_total is a global variable that keeps track of how much the caller has spent so far. Whenever the caller says the word “total”, the caller hears “Your current total spent is”, followed by the current total.