Natural vs. Direct Dialog and How VoiceXML Enables Both
This article is the third article in a three-part series that provides an introduction to VoiceXML, as well as SRGS, SSML, and SISR for building conversational web applications. The first installment discussed building VoiceXML dialogs through both menu and form elements. The second outlined how VoiceXML takes advantage of the distributed web-based application model as well as advanced features including: local validation and processing, audio playback and recording, support for context-specific and tapered help, and support for reusable sub dialogs. Finally, this piece will discuss natural vs. direct dialogue and how VoiceXML enables both by allowing input grammars to be specified at the form level, not just at the field level.
To review from the first two articles, the web has primarily delivered information and services using visual interfaces and as a result has largely bypassed customers that primarily use the telephone - for which voice input and audio output provide the primary means of interaction. Building on top of the market established in 1999 by the VoiceXML Forum's VoiceXML 1.0 specification [VXML1], VoiceXML 2.0 and several complementary standards are changing the way we interact with voice services and applications - by simplifying the way these services and applications are built.
VoiceXML as presented in the first two articles provides the capability for simple "directed" dialogs, meaning that the computer directs the conversation at each step by prompting the user for the next piece of information. Dialogs between humans of course don't operate on this simple model. In a natural dialog each participant may at various stages take the initiative in leading the conversation. A computer-human dialog modeled on this idea is referred to as a "mixed-initiative" dialog because either the computer or the human may take the initiative in leading the conversation.
The field of spoken interfaces is not nearly as mature as the field of visual interfaces, so standardizing an approach to natural dialog is more difficult than designing a standard language for describing visual interfaces like HTML. Nevertheless VoiceXML takes some modest steps toward allowing applications to be built that give the user some degree of control over the conversation.
In each of the dialogs shown below (taken from part #1 in this series), the user is asked to supply input by speaking a value for each field of a form in sequence.
Browser: Please say your complete phone number.
Browser: Please say your PIN code.
User: 1 2 3 4
Browser: What would you like to drink?
User: Orange juice.
Browser: What sandwich would you like?
User: Roast beef lettuce and swiss on rye.
The set of phrases that the user could speak in response to each field prompt was specified by a separate grammar for each field. This approach allows the user to supply one field value in sequence.
Consider a dialog for making airline travel reservations in which the user must supply a date, a city to fly from, and a city to fly to. A directed dialog conversation for completing such a form might proceed as follows:
Browser: Where are you traveling from?
User: New York.
Browser: Where are you traveling to?
Browser: When would you like to travel?
By contrast, a somewhat more natural dialog might proceed as follows:
Browser: How can I help you?
User: I'd like to fly from New York To Chicago
Browser: When would you like to travel?
VoiceXML enables such dialogs by allowing input grammars to be specified at the form level, not just at the field level and by further annotating the rules in the grammar to identify which portion of a user's input is intended for which field in the form. This annotation is accomplished through semantic interpretation.
Consider the following VoiceXML document:
<vxml version="2.0" xmlns="http://www.w3.org/2001/vxml"> <form id="traveling"> <grammar src="travel.grxml" type="application/srgs+xml"/> <initial name="get_info"> <prompt> How can I help you? </prompt> <catch event="nomatch"> <prompt> Let's try getting each field separately. </prompt> <reprompt/> <assign name="get_info" expr="true"/> </catch> </initial> <field name="from_city"> <grammar src="travel.grxml#fromWhere"/> <prompt>What city are you traveling from?</prompt> </field> <field name="to_city"> <grammar src="travel.grxml#toWhere"/> <prompt>What city are you traveling to?</prompt> </field> <block> <submit next="http://www.example.com/servlet/flyaway"/> </block> </form> </vxml>
And the grammar that it references:
<grammar mode="voice" xml:lang="en-US" version="1.0" xmlns="http://www.w3.org/2001/06/grammar" root="travel"> <rule id="travel"> <item repeat="0-1"> I'd like to fly </item> <one-of>> <item> <ruleref uri="#fromWhere"/> <ruleref uri="#toWhere"/> <tag> $.from_city = $fromWhere; $.to_city = $toWhere; </tag> </item> <item> <ruleref uri="#toWhere"/> <ruleref uri="#fromWhere"/> <tag> $.to_city = $toWhere; $.from_city = $fromWhere; </tag> </item> </one-of> </rule> <rule id="fromWhere" scope="public"> <item> <item> from </item> <ruleref uri="#cities"/> <tag> $ = $cities </tag> </item> </rule> <rule id="toWhere" scope="public"> <item> <item> to </item> <ruleref uri="#cities"/> <tag> $ = $cities </tag> </item> </rule> <rule id="cities"> <one-of> <item> New York </item> <item> Chicago </item> <item> San Francisco </item> </one-of> </rule> </grammar>
Although the grammar looks fairly complex, it's not really. It differs from earlier grammars only in that it now has semantic interpretation information included within it, indicated by the <tag> elements throughout.
Page 1 of 2