 |
| • | In a mixed-initiative form, put any welcoming prompt in the <initial> element, not in a separate <block> element. |
The BeVocal VoiceXML go-back facility allows the user to retract the last response or to transition back to the last location in an application.
| • | Retracting User Responses |
| • | Go-Back Stack |
| • | Go-Back Destinations |
| • | Enabling the Go-Back Facility |
| • | Controlling Go-Back Behavior |
| • | Using the Go-Back Facility |
Note: The go-back facility is an experimental extension to VoiceXML; its implementation and behavior are subject to change. The current BeVocal VoiceXML implementation contains the feature before it has been standardized so that developers may provide feedback. If this capability becomes a standard part of a future version of VoiceXML, the BeVocal VoiceXML implementation will change as necessary to match the VoiceXML standard.
If the go-back facility is enabled, the user can retract the last response to a VoiceXML application by saying "go back." After the interpreter "removes" the user's response, it prompts for the information again.
For example, the following form asks for the user's home and work phone numbers:
<form>
<field name="home" type="phone">
<prompt>
What is your home phone number?
</prompt>
</field>
<field name="work" type="phone">
<prompt>
What is your work phone number?
</prompt>
</field>
</form>
Suppose a user inadvertently gives the work number when asked for the home number. The go-back facility would allow the user to correct this mistake.
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: | |
| User: |
The go-back facility also allows users to change their minds after requesting one of several alternatives. For example, it would permit the following interaction.
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: | |
| User: |
When user says "go back," the interpreter undoes whatever actions resulted from the last response, then it prompts the user for a new response. The user can retract a sequence of responses by saying "go back" repeatedly.
Each request for user input is called a go-back destination. When the user provides the requested input, the interpreter saves information about the go-back destination as an entry on its go-back stack.
If the user says "go back," the interpreter uses the saved information for the most recent go-back destination on the stack to undo the actions that resulted from the user's response. It then goes back to that go-back destination, popping the corresponding entry off the stack.
Each entry on the go-back stack saves information about one step the interpreter performed during the execution of the application.
The entries corresponding to go-back destinations are called go-back entries; they correspond to the user-visible steps in the interaction. As the user retraces these steps, the interpreter goes back to the appropriate elements within the VoiceXML application, transparently moving between dialogs and documents as necessary. For example:
In addition to the go-back entries, the go-back stack saves internal entries, which correspond to non-user-visible steps, such as transitions between forms. When the interpreter goes back to the most recent go-back destination, it also "undoes" each non-user-visible step that occurred after the last go-back destination and pops the corresponding internal entry off the stack.
A <block> form item does not request user input and so is not a possible go-back destination. However, any block items that are executed between one input request and the next are saved as internal stack entries that can be undone when the interpreter goes back to the preceding input request.
A VoiceXML application can request user input in a menu, in the initial item of a mixed-initiative form, and in an input item. These elements, therefore, can be go-back destinations.
A <menu> element asks the user to select a choice. The <menu> element is the go-back destination for the user's response. If the user says "go back" after selecting a menu choice, the menu is executed again.
The <initial> element of a mixed-initiative form asks the user for initial input to the form. This element is the go-back destination for the user's response. If the user says "go back" after providing initial input, the initial element is executed again.
The user's answer to the initial prompt may provide values for several of the form's input variables. When the interpreter "undoes" an initial element, it clear's not only the initial form-item variable, but also any input variables that were set by the user's response.
For the purposes of the go-back facility, input items can be classified as follows:
A <field> item asks the user for the value of its input variable. A <record> item asks the user for input to be recorded. These input items are go-back destinations. If the interpreter goes back to one of these items, it clears the corresponding input variable and executes the item again. Going back to a <field> item allows the user to give a different answer; going back to a <record> item allows the user to provide different input to be recorded.
A <transfer> item transfers the user to another destination, allowing the user to carry on a conversation with a third party.
Note: Currently, the BeVocal interpreter supports bridging transfers only.
A transfer item is a go-back destination. If the interpreter goes back to a transfer item, the transfer call is repeated. Any change in the information exchanged during the original transfer and during the repeated transfer is determined by the user's conversation with the third party and does not affect the VoiceXML application. For example, the original transfer might place a call in which the user orders a pizza. After that call, the user might say "go back," and add a salad to the original order.
A <subdialog> item invokes another dialog as a subdialog of the current one. Each request for input made by the subdialog is a go-back destination. The <subdialog> element itself is also a go-back destination.
If the user says "go back" to a request for input inside the subdialog, the go-back behavior is the same as in any other form. Within the subdialog's execution context, the go-back stack is initially identical to the go-back stack in the calling dialog's execution context. As each new input is requested, another go-back destination is pushed onto the stack:
Once the subdialog returns to the calling dialog, however, the subdialog's execution context terminates. The go-back stack in the calling dialog's execution context does not contain any go-back destinations for the input requests made by the subdialog. A new go-back destination is added for the subdialog itself.
If the subdialog requests a single user input, the go-back behavior is the same as for any other single-input input item. If a subdialog requests more than one user input, however, the go-back behavior may not be what the user expects. For example, suppose a document contains the following forms:
<form id="main">
<field name="A">...</field>
<subdialog name="B" src="#sub">
...
</subdialog>
<field name="F">...</field>
</form>
<form id="sub">
<field name="C">...</field>
<field name="D">...</field>
<field name="E">...</field>
<filled>
<return namelist="A B C"/>
</filled>
</form>
A user who says "go back" when prompted for field F, might expect to provide a different answer for field E in the subdialog. However, the interpreter goes back to subdialog B. It executes the subdialog from the beginning, prompting again for fields C, D, and E.
Note: In a future release, you may be able to specify whether "go back" will go back into the subdialog (to ask for field E in the preceding example) or to the beginning of the subdialog (as currently happens).
To enable the go-back facility, you must set two properties to:
| • | Activate the goback universal grammar |
| • | Specify the minimum size of the go-back stack |
You use the <property> tag to set both properties.
The goback universal grammar recognizes the spoken "go back" request. Like all universal grammars, it is deactivated by default. See Universal Commands and Grammars. When this grammar is deactivated, the speech-recognition engine does not recognize the input "go back." If the user says "go back" to the prompt for a field, a no-match event is thrown.
You set the universals property to activate or deactivate the goback grammar, either in the entire application, or in particular documents, forms, or fields.
The go-back facility is activated in the following document, but deactivated during the execution of the first form.
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
<!-- Activate goback, help, and exit universals -->
<property name="universals" value="goback help exit"/>
...
<form>
<!-- Activate only help and exit universals -->
<property name="universals" value="help exit"/>
...
</form>
...
</vxml>
The bevocal.mingoback property specifies the minimum size of the go-back stack. The interpreter keeps at least this many entries on the stack, except at the beginning of the call when fewer steps have been executed, and after the user has said "go back" so many consecutive times that the stack has been depleted.
By default, this property is set to 0, which means that the go-back stack is always empty and the go-back facility is effectively disabled. If the user says "go back", the go-back facility responds, "I'm sorry, I don't know where to go back to".
If you want to allow the user to go back, you must set the bevocal.mingoback property to 1 or more. For example, the following application sets the minimum stack size to 20 entries.
<?xml version="1.0" ?>
<!DOCTYPE vxml PUBLIC "-//BeVocal Inc//VoiceXML 2.0//EN"
"http://cafe.bevocal.com/libraries/dtd/vxml2-0-bevocal.dtd">
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml">
<!-- Activate goback and help universal grammars -->
<property name="universals" value="goback help"/>
<!-- Save at least 20 entries on the go-back stack -->
<property name="bevocal.mingoback" value="20"/>
<form>
<field name="home" type="phone">
<prompt>
What is your home phone number?
</prompt>
</field>
<field name="work" type="phone">
<prompt>
What is your work phone number?
</prompt>
</field>
</form>
</vxml>
You can control the application's use of the go-back facility in the following ways:
You can prevent the user from retracting certain inputs by setting the bevocal.goback property. This property controls whether requests for user input are legal go-back destinations. By default, the property is set to true and each request for input is a legal go-back destination. When the user provides the requested input, the interpreter pushes a go-back entry for the request onto its go-back stack.
If the bevocal.goback property is false, however, a request for input is a not a legal go-back destination. When the user provides the requested input, the interpreter pushes an internal entry for the request onto its go-back stack. The internal stack entry enables the interpreter to undo the information request if the user returns to an earlier go-back destination; however, it prevents the user from going back to the request itself.
A user's response is called "retractable" if a corresponding go-back entry is added to the stack; if, instead, an internal entry is added to the stack, the response cannot be retracted.
If you set the bevocal.goback property to false in a field, the user's input for the field is not retractable. The user cannot go back to that field, but may skip back to retract the preceding retractable input. If you set this property to false in a form, you prevent the user from retracting any input to that form.
When several fields are treated as a single conceptual unit, you may want to suppress retraction of all but the first field. For example, the go-back facility treats the city and state fields as a unit in the following form:
<form>
<field name="city">
<prompt>Choose a city</prompt>
<grammar>...</grammar>
</field>
<field name="state">
<property name="bevocal.goback" value="false"/>
<prompt>What state?</prompt>
<grammar>...</grammar>
</field>
<field name="first" type="boolean">
<prompt>
Do you want to fly first class?
</prompt>
</field>
</form>
The user cannot retract an answer to the question about state, but can skip past it to retract the city, as illustrated in the following interaction.
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: |
When the speech-recognition engine matches the goback grammar, a goback event is thrown. The default handler undoes entries on the go-back stack until it reaches the most recent go-back entry, corresponding to the user's last retractable response. If the go-back stack is empty, the default handler plays an audio message that says "I'm sorry, I don't know where to go back to".
If you want the application to take different actions, you can add your own event handler for go-back events. For example, an application might keep information about each user's default location. If the user requests a traffic report from the main menu, the traffic form might start to fetch the report for the user's default location without requesting the user's city. The application could use the go-back facility to allow the user to provide a different location.
<form id="traffic">
<catch event="goback">
<clear/>
</catch>
<field name="city" expr="document.defaultCity">
<prompt>What city?</prompt>
<grammar>...</grammar>
</field>
<block>
<prompt>
Retrieving traffic data for
<value name="city">
Say Go Back to choose another city.
</prompt>
<!-- Retrieve and play traffic report -->
</block>
</form>
An interaction with the application might proceed as follows.
In this case, saying "go back" takes the user to a question that has never been asked before.
If the application's go-back handler needs to take some actions and then proceed as normal to undo the user's response, it can perform the appropriate actions and then rethrow the event to the default handler:
<catch event="goback"> ... <rethrow/> </catch>
This section contains guidelines for using the go-back facility
You need to ensure that go-back stack can grow large enough to enable a user to retrace as many steps as you think are likely; see Setting the Minimum Stack Size, The size of the stack limits the number of consecutive times the user can say "go back." Remember that the stack must be large enough to accommodate internal entries as well as go-back entries. When you set the stack size, you should allow for a few internal entries for each go-back entry.
You can safely put blocks between go-back destinations in a form. For example, in the following form, if the user goes back to the home field, the interpreter "undoes" the subsequent block, clearing its item variable and allowing the block to be visited again after the user provides an new answer for the home field:
<form>
<field name="home" type="phone">
<prompt>
What is your home phone number?
</prompt>
</field>
<block>
Your home number is <value expr="home"/>
</block>
<field name="work" type="phone">
<prompt>
What is your work phone number?
</prompt>
</field>
</form>
The interaction with the user might proceed as follows.
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: | |
| User: | |
| Application: | |
| User: |
A <block> in a form is saved as an internal stack entry only if it occurs after the first go-back destination in the form. If the form's first item is a block containing a welcoming prompt, no internal stack entry is saved for the block, so it will not be revisited if the go-back facility returns to the first input request in the form.
|
|||
|
The internal stack entry for a block is undone and redone only if the interpreter returns to a go-back destination before the block. As a consequence, a block that is used to prompt for information in the subsequent field is not redone if the interpreter goes back to the field. In the following form, if the user says "go back" when asked for a work phone number, the request for the home phone number would not be replayed.
<form>
<block>What is your home phone number?</block>
<field name="home" type="phone"></field>
<block>Your home number is <value expr="home"/></block>
<field name="work" type="phone">
<prompt>
What is your work phone number?
</prompt>
</field>
</form>
|
|||
|
To avoid any confusion that can occur if the user says "go back" after returning from a subdialog, try to limit your use of subdialogs to requests for confirmation or disambiguation. In addition, you should prevent the subdialog itself from being a legal go-back destination by setting the bevocal.goback property to false inside the <subdialog> element. If the user says "go back" after the subdialog returns, the interpreter will go back to the question preceding the subdialog--presumably the question whose answer required confirmation or clarification.
When the interpreter returns to a particular go-back destination in a form, it clears form-item variables for every block, initial item, and input item that needs to be undone. However, it does not change the values of any other variables declared in dialog, document, or application scope. If the interpreter undoes a transition, going back to a different form, it does not restore the variables declared in the form to the values they had when that transition left the form.
If you use the go-back facility, you should avoid saving state information in variables that cannot be reset by a go-back operation.
In limited circumstances, you may be able to reset variables in an error handler for go-back events. In general, however, the event handler will not have enough context to know what variables need to be reset because the event is thrown at the location where the user says "go back", not at the go-back destination.
 |
Café Home |
Developer Agreement |
Privacy Policy |
Site Map |
Terms & Conditions Part No. 520-0001-02 | © 1999-2007, BeVocal, Inc. All rights reserved | 1.877.33.VOCAL |