Speech Dialogs
A mobile application is usually divided into a series of different speech dialogs. These correspond to the user's successive interaction steps in the browser or GUI of a non-speech-controlled application.
You manage the speech dialogs technically by setting the browser focus. At the point when the focus moves to an input-ready, speech-enabled screen element, the associated speech dialog is automatically activated. Depending on the context, one of the three possible dialog variants is started in each case. The dialogs are automatically generated during the generation process, if the screens or screen elements are identified as speech-enabled.
The start dialog is essentially not input enabled.
Start Dialog: sayOnPageLoad
If the screen underlying the generation has been identified as speech-enabled, the sayOnPageLoad dialog is always inserted first. This dialog first reads any error messages that occur when the screen is first called. If there are no error messages, there is also no text output, unless the speech attribute PromptText exists with a corresponding value for the screen in question. In this case, the PromptText is then read. After the start dialog has been processed, the focus is set on the successor element defined by the application. If this successor element is defined as speech-enabled, the associated dialog is automatically started. If this element is a button, a command dialog is started, if the element is input enabled, and input dialog is started.
Command Dialog: sayCommand
A sayCommand command dialog combines all of the buttons of a screen that are defined as speech enabled. The text elements are created from the labels of the buttons.
Buttons that have icons instead of text elements cannot be included in the dialog and are therefore ignored.
In this way, the OK codes assigned to the buttons can be triggered using a speech command.
In addition to the OK codes associated with the relevant buttons, two standard OK codes are also always integrated into the dialog:
|
Speech Command |
OKCode |
|
"Enter" |
/0 |
|
"Log off" |
/nex |
The application development has no influence over the structure of the command dialog. You can only manipulate the generation of the dialog using invisible buttons or by deactivating buttons.
Input Dialog: VRFunc_<FIELD NAME>
If the system finds an input enabled, speech enabled element during the template generation, this leads to the generation of an input dialog. Unlike the command dialog, which combines all buttons of a screen, the input dialog is specific to each individual input field.
Another difference is that you can influence the behavior of an input dialog using the XML Properties TimeOut, PromptText, HelpText, FilledText, Grammar, GrammarLink, and NextField.
The input dialog is activated at runtime when an associated screen element takes on the focus of the running application.
In addition to the values configured for the application, two generic input options are always added to this dialog:
|
Speech Command |
Result |
|
"Continue" |
The current field is skipped and the focus passes to the next field. |
|
"Command" |
With this speech input, the user can switch to the command dialog at any point in the running application, for example, to send all of the input already made to the backend with the speech command "Enter", or to trigger another switch of the dialog. |
Sequence of the Speech Dialogs
Every screen displayed in the browser contains a combination of speech dialogs in the following form:
A number of input dialogs are introduced by the associated start dialog and closed using the associated command dialog. The figure below shows a typical sequence of the dialogs as an example:
When generating the templates, the speech-controlled steps are placed in precisely one implicit sequence and this sequence is correspondingly activated at runtime. After a step has been processed, the focus of the application automatically passes to the implicitly defined successor step and its speech dialog is activated. If there is no successor field, the command dialog for the screen is activated.
By setting the VR property "NextField", the application developer can interrupt the implicit sequence and explicitly define the next successor field. This does, however, have some associated risks since the running application must always check whether the corresponding field is visible and active. This check can be difficult, especially in error situations, meaning that the explicit setting of the successor field should only be implemented in exceptional cases.