| RCML . Name Spaces . CICERO |
Cicero
For more information in Cicero, checkout http://cicero. Cicero is a 'multi input' technology, to you and me, that means I can speak into and 'pen' into my applications. For more information about the grammars for each control, click here.
The CICERO namespace consists of a very small schema for voice enabling controls in RCML. The cicero namepsace loader & runtime do most of the work, with the schema exposing exciting customization features, like synonyms.
For example to voice enable a BUTTON, CHECKBOX, RADIOBUTTON, COMBO, LIST, simply add <CICERO:CMD/> as a child of the element you wish to enable, the loader does the rest, e.g.
<RCML>
...
<BUTTON ID="1" TEXT="OK" X="125" Y="7" >
<CICERO:CMD />
</BUTTON>
...
</RCML>
How to voice enable - What are the Elements and Attributes?
Currently these are work in progress. For most controls the CMD element is sufficient. It has attributes of SYNONYM, e.g.
<RCML>
...
<BUTTON ID="1" TEXT="OK" X="125" Y="7" >
<CICERO:CMD SYNONYM="Sure"/>
</BUTTON>
...
</RCML>
The CMD element walks up to its parent, and decides what schema to use to listen for commands on the control. Here it will additionally listen for the synonym "Sure" while it listens for the "OK".
If youre really adventurous and have written your own SAPI5 XML CFG file (http://speech) then you can use this. Of course, when your rules file, the runtime really doesn't know what you want to do with this information. If this is a child of a combo, it will attempt to set the text on the combo to that recognized.
So what do we do if we recognize a command, but cannot execute it? If you have a FAILURE as a child of your element, that will be spoken.
<RCML>
...
<CHECKBOX ID="1" TEXT="R&ead only" X="125" Y="7" >
<CICERO:CMD>
<CICERO:FAILURE TEXT="Please select a file before setting its attributes"/>
</CICERO:CMD>
</BUTTON>
...
</RCML>
If the checkbox "Read only" is disabled, and the user says "Read", the cicero namespace extension runtime will respond by saying "Please select the file before setting its attributes".
What's the 80% coverage?
The attempt with the cicero namespace is to allow the user to command the dialog, without the notion of focus. The user does not, for example, need to say "Font Name Courier, Font Style Bold", but simply "Courier Bold". As a result the grammar rules for each control are continually running, with little prefixing.
For each control there is clearly going to be a well known grammar that can be used to control it. In addition each control has it's own set of 'voice specific' gotchas.
Selecting from a list
Lists are generally filled at WM_INITDIALOG time, a list of fonts etc. However during the run of the dialog, some lists are added to, e.g. on the Run dialog, the MRU list 'grows'.
In addition to this, some lists are so big that the user may make assumptions about them. Take the Font Picker dialog. The user is presented with a list of fonts. The user says "Courier, Bold, OK". And assumes this will work in all cases. Imagine now that the developers have asked to display only non true-type fonts, resulting in no Courier. The user will say "Courier, Bold, OK", and we find our first gotcha.
Any runtime generated schema, would not include an entry for "Courier" in the above scenario. Using various annotation schemes, e.g. CONTENT="FONTS" in RCML, the name space extension could easily generate a grammar based on its understanding of the available fonts, not just the ones displayed to the user, this would/could include Courier. When the user utters "Courier" the grammar rule fires, and the extension attempts to set the text, upon failure, the <CICERO:FAILURE> is processed.
A slightly more understandable and more likely example is combos. As we know, the inherent problem with a combo as a visual device is that the domain is not clearly presented to the user (unlike a list). And this requires the use to 'drop the combo' and 'browse' the list of options. However, users are pretty smart, and when presented with a combo for picking a day of the week, make assumptions. Again, if the developer has restricted the days to only Week days, the user may still utter "Sunday". Any runtime generated schema will probably not have a rule for Sunday, and the machine will ignore the user. The user will attempt a few more times, before giving up, dropping the combo, and realizing that "Sunday" is not an option.
Again, in RCML the list of items are children of a combo, so this 'static' list can be used as the basis of the runtime generated grammar.
Disabled controls.
The rule for all controls are running regardless of visibility, or enabled state. When speaking to a dialog the user may command a disabled control. Currently if this happens to a disabled control, the failure text is spoken. It's assumed that this text will contain enough information to allow the user to rectify the matter. Ideally the cicero runtime would automatically adjust the 'blocking' UI, to make the change. In the case of the Effects tab in Windows 2000, the "Fade Effect" and "Scroll Effect" are disabled if the user has turned off "Transition Effects for menus and tooltips". It would be ideal that if the user said "Fade Effect" the checkbox would become checked, if it were not currently so.
Improving controls
The user may be presented with an edit control and is expected to enter a date. The runtime may build a date grammar, but it may have difficulty determining what kind of date format should be entered into the edit control, e.g. DD-MM-YY or dddd mmmm? Again, though attributing in the RCML file, these can generally be sorted out.
Relationships
The gotcha here is when the user becomes complacent, and says things like "Today/Tomorrow" and "Two days later". Here they are entering data related to other controls. Imaging a form for filling in departure and arrival times. The user may say "today at noon" "returning two days later". The first edit control (departure) is provided with the current date, the second edit control (return) needs to know it's relationship to the departure control, and act accordingly.
Control State.
When our controls are designed, we design them with the mouse in mind, and if we're luck with the keyboard. Take the checkbox for example. Most people know that space will toggle the check, this is analogous to a mouse click. Few people know that '-' and '+' will force the state to 'unchecked' and 'checked' and even fewer know that '=' is the same as '+'.
When commanding the user may often want this level of control, and not simply a toggle command, e.g. "Bold On" and "Bold Off". When the GUI is not prominent or the user isn't paying attention, they may not remember the state, and realize if they wish to toggle the UI or not. They will simply say what they want, e.g. "Do not reinvest" to ensure that the "Reinvest Income" checkbox in Investor's Transaction dialog will NOT be checked.
Many controls
Often dialogs contain many controls of the same type, e.g. many buttons, many sliders. Where the text for the controls are obvious, e.g. checkboxes, we can be pretty accurate at the command the user wishes to use for that control. However when there are many sliders on a page, e.g. hue, contrast, brightness, these controls may need some prefixing, e.g. "Contrast 50%". In addition, synonyms can be used "10% brighter" and "A bit redder", where brighter and redder are the same as "up".
If you have any more needs, or wish
to debate the above, click
here