Share via


Employing Confirmation and Correction Strategies

  Microsoft Speech Technologies Homepage

(Dialog Speech Control Sample)

This sample presents part of a basic pizza ordering system that prompts users to specify the size (large or regular) and choice of topping (mushroom or pepperoni) for a pizza they would like to order.

This sample illustrates the use of the following confirmation and correction strategies: Implicit Confirmation (IC); Short Time-out Confirmation (STC); and Explicit Confirmation (EC). An effective confirmation and correction strategy is vital for voice-only applications due to the potential for speech recognition errors, coupled with the fact that there is only a single audio channel of communication between the user and the application.

The sample begins by playing the prompt "What size pizza would you like?" The user can respond by saying either a size (regular or large), or by saying both a size and a topping (mushroom or pepperoni). For example, the user can say simply Large, or A large mushroom.

Implicit Confirmation Strategy

If the user responds to the initial QA cycle with a size only, the application initializes the second QA cycle which employs an Implicit Confirmation (IC) strategy. If the user responds to the initial QA cycle with both a size and a topping, then the application skips the second QA cycle and initializes the third QA cycle, which is described later.

  • If Size Only is Specified:
    The application implicitly confirms the requested size by stating the size and asking for a topping in a single prompt (for example, "A large. What topping would you like?"). The user can respond by:
    1. Correcting the size (for example, No, regular).
    2. Specifying a topping (for example, Mushroom please).
    3. Simultaneously correcting the size and specifying a topping (for example, No, a regular mushroom). If the user chooses to correct the size (option 1 above), then the current QA cycle is executed again and the application states the corrected size and again asks for a topping. If the user chooses to specify a topping (option 2 above) then this is implicitly confirming the stated size and the application moves to the next QA cycle. If the user chooses either to simultaneously correct the size and specify a topping (option 3 above), then the application has no more questions with which to implicitly confirm previously provided data (the user has given an answer to both questions), and the application moves on to the next QA cycle.

Short Time-out Confirmation Strategy

A Short Time-out Confirmation (STC) strategy is illustrated in the third QA cycle. There are several key aspects to the STC strategy. First, the prompt for the QA cycle consists simply of the names of the unconfirmed items in the form of a question, thereby making the prompt as short as possible. Second, the application gives the user a shorter amount of time in which to respond (hence Short Time-out). Third, the application treats user silence in response to this question as a Yes response. The STC strategy can be thought of as a statement of understanding on the part of the system (it may not be phrased as a question), to which the user need not necessarily respond and the application moves forward as quickly as possible.

  • If Both Size and Topping Were Simultaneously Specified
    If both size and topping were simultaneously specified either during the first QA cycle, or as a correction in the second QA cycle, the application begins the third QA cycle by repeating the specified size and topping in the form of a question. For example, "A large mushroom?"
    The user can respond by:
    1. Correcting either the size or the choice of topping or both.
    2. Confirm both choices by saying Yes or remaining silent.
    3. Reject both choices by saying No.
  • If Size Only Was Initially Specified in the First QA Cycle:
    The application will have already implicitly confirmed the size when it asked the user to additionally specify a topping, leaving only the choice of topping to be confirmed. Thus, the application begins the third QA cycle by repeating the name of the topping in the form of a question. For example, "Mushroom?"
    The user can respond by:
    1. Correcting the choice of topping.
    2. Confirm the choice of topping by saying Yes or by staying silent.
    3. Reject the choice of topping by saying No.

Explicit Confirmation Strategy

The application shifts to an Explicit Confirmation (EC) strategy if the user responds to the STC question with anything other than a response of Yes or silence (option 2 above). This includes the other options described above together with responses such as, if the user mumbles, asks for help, or says repeat. When this happens, the application requires an explicit answer to the question asked. For example, a dialogue may proceed from the second QA cycle as follows:

Application: Mushroom?
User: [mumble]
Application: I'm sorry, I didn't understand that. Am I right with mushroom?
User: [silence]
Application: I'm sorry, I didn't hear you. Am I right with mushroom?
User: Yes

Note, as illustrated in the example above, that the application no longer accepts silence as equivalent to a "yes" response. Also, the application reverts to using the normal time-out for a user response (in other words, the same amount of time that the user was given to respond to the first question in the QA cycle).

Note also, that a single QA control implements both the STC and EC confirmation strategies. The RunSpeech algorithm detects the condition for a shift to EC and alters the parameters of the QA control accordingly before executing it again.

  • Confirmation and correction of the user's responses using a mixture of IC, STC, and EC strategies.
  • Implementation of the global commands Help, Repeat, and Start Over.
  • Use of a prompt function as opposed to inline prompt text.

Running the Sample

Open the sample. Try each of the three different confirmation and correction strategies by working through the scenarios outlined in the descriptions above.

Say Start Over at any time to restart the application.

Remarks

This sample does not support:

  • BargeIn. In other words, the user cannot interrupt the prompt with a response.

See Also

Dialog Speech Controls Overview | Command Control | QA Control | SemanticMap Control | InlinePrompt Property | PromptSelectFunction Property

Creating Prompt Functions | Using Prompt Databases | Voice-only Run-time Behavior