Certainly, you will want to have the command Help (and possibly a set of alternative phrases that act as synonyms for help) in a global grammar. But what should you do when a user asks for help? You can either switch to a separate help mode, or engage in a technique known as self-revealing help. Table 1 compares these help styles:
| Help mode | Self-revealing help |
|---|---|
| Help is provided through a separate dialog. | Help is integrated into each application dialog. |
| You will need to save the state of your application
dialog so that you can return to it when the user exits help mode,
and you must tell the user how to exit help mode. Alternatively, you could use a “one-shot” help mode message that automatically returns to the application after presenting the help text. |
Does not require explicit mode management. |
| You may want to use a help mode indicator (such as a background sound, a different voice, or introductory and terminating audio cues or messages) to signal when the user is in help mode, rather than in the regular application. | Audio formatting is not required because help is integrated into each application dialog. |
| Good for providing general help information at an application, module, form, or menu level. | Uses a sequence of prompts to provide progressively greater levels of context-sensitive assistance at each turn in a dialog. |
| Requires less help text, but generally provides less-specific information. | Requires you to compose multiple prompts for each turn in a dialog. |
| Must be triggered explicitly, by the user speaking something from the Help grammar. | Can be triggered:
|
| Can transfer to a human agent explicitly, by the user speaking something from the Operator grammar. | Transfer to a human operator can be triggered:
|
Because the introduction of modes into a system complicates the interface, we generally recommend the self-revealing help technique. Alternatively, the requirements of your application or users may lead you to adopt a strategy that incorporates both styles of help: a <catch> element in the application root document, plus context-sensitive self-revealing help where appropriate. Regardless of the help style you choose, you should use it consistently throughout your application.
It is possible that a user might experience momentary confusion or distraction, which leads the user to explicitly request help. If the system has been designed to be self-revealing, these explicit requests for help could receive the same treatment as a silence timeout or any out-of-grammar utterance, allowing you to reuse the same code and prompts. This is style of help is referred to as “implicit” because the system never enters an explicit help mode. The theory is that implicit help provides more of a sense of moving forward (resulting in a better, more satisfying user interface) and is simpler to code than explicit help.
The following example assumes barge-in enabled:
|
Notice the self-revealing nature of the dialog, and the way it works whether triggered by a silence timeout, an utterance from the Help grammar, or any out-of-grammar utterance. In addition, if this application is able to detect when the user requests an unsupported name or city, it can respond appropriately (for example, “Sorry, but there's no office in that location”).
Also note the pattern for the introduction, which has the general sequence Welcome-Purpose-MoreInfo, followed by an ExplicitPrompt. Usually, the explicit prompt at the end of the introduction is enough to guide the user to provide an appropriate response; however, if the user input after that explicit prompt is an out-of-grammar utterance, something from the Help grammar, or a silence timeout, then the system falls through a sequence of prompts designed to provide progressively greater assistance. The beauty of this system is that the user never hears the same prompt twice, so the system appears to be responsive to the user and always moving the dialog forward; this help style promotes efficient use by most users. If the user still fails to provide an appropriate response, the sequence of prompts ultimately “bails out” (typically, transfers to a human operator or apologizes and exits).
Deciding how many attempts to allow the user before bailing out (leaving the speech application) is a judgement call. You do not want to bail out after the first unsuccessful attempt, or you will lose users too quickly; conversely, you do not want to require too many attempts, or you run the risk of frustrating users who are experiencing serious problems with the system. For most applications, if users are experiencing serious problems with the system, it is better to get them out of the system quickly and, if possible, give them another means to access the desired information (say, by pointing them to a visual Web site, switching to a DTMF system or transferring them to an agent).
In general, two or three progressively more directed prompts should suffice to help users recover from noinput events, nomatch events, or explicit requests for help. For example:
|