Speak the appropriate information at the appropriate time and in the appropriate order

Rationale

Deciding what to speak and when is crucial to the usability of the interface.

Interface design is an art as well as a science. An intelligent designer can create an interface that wrings all the performance it can out of the hardware. But it must also accomplish much more. It must anticipate user needs, abilities, assumptions and preferences while striking just the right balance between ease of use and intrusive handholding. An interface that is confusing, illogical or inconsistent can drive a user away. But an interface that goes too far in the other direction, offering so much assistance and guidance that it actually prevents the user from making any forward progress, can be equally maddening.

Developer's Guide to Creating Talking Menus for Set-top Boxes and DVDs, WGBH National Centre for Accessible Media.

Users do not necessarily need to hear all the information that is displayed. For example, in a programme listing, the user may need only enough information to decide whether they are interested or whether they want to go on to the next item. For this reason, information should be prioritised by reading the important information and to allow the user to stop the speech output or move on to another item before it is finished.

Not all of the available information needs to be spoken every time it appears or changes. To use an extreme example, sometimes the viewer will want to know the time, but the displayed time may change every minute or even every second and repeatedly reading out the time whenever it changes would be intrusive and unhelpful.

Some good evidence regarding when to speak which information is provided by a 2007 survey by the Royal National Institute of Blind People of blind and partially sighted television viewers. Almost 70% said they would want the current time spoken anytime I ask for it and 20% said never. Very few want the time spoken when I switch the TV on or each time I change the channel. 75% of blind and partially sighted people said they would want similar on-demand access to the programme summary and the˜now & next" programme information. Almost 70% would like the programme start and end time spoken anytime I ask for it. For the channel number, channel name and programme name, the preferences were more variable, as shown in table 1. Significant numbers would like it spoken on channel changes and on request.

The findings of this study are reflected in the following directions and techniques. However, these findings are limited by the fact that the survey respondents did not have any real experience of spoken output, so it might be difficult for them to know, for example, whether they would like the current time spoken when the programme guide opens.

Directions and techniques

Speak information only when relevant or on request (high priority)

The following default behaviours should be adopted:

• The current time should not be repeatedly spoken but should be available on request.
• When the viewer changes channel, speak the channel number, channel name and programme name.
• The programme summary and the "now & next" programme information should be available on request.
• The channel number, channel name and programme name should be available on request.

More information or user testing is required to determine other requirements, for example what should be spoken when the programme guide opens.

Speak the most important information first (high priority)

Information should be prioritised and the most important spoken first. For example, when switching to a new channel or selecting channels in the programme guide, information might be given in the following order (which should be determined in consultation with the target users):

• Channel number
• Channel name
• Programme name

This gives users the essential information first, allowing them to move on when they have heard enough without waiting to hear the whole spoken output. For example, given the channel numbering shown in figure 17, the viewer can change from channel 105 to channel 111 by repeatedly pressing the down arrow button and the following information can be spoken:

106, Sky1, An Idiot Abroad.

107, Sky Living, Britains Next Top Model.

111, Dave, Live at the Apollo.

The user can move on as soon as they have heard the channel number 6, 7, 8, 9, 10, 11, without waiting to hear the channel names and programme names. Viewers who are less familiar with the channel numbers may want to listen to the name and number of each channel before moving on, but not the programme name.

Figure 15. On-screen programme guide showing multiple channels.

The example above prioritises the task of navigating by channel number and name over the task of navigating by programme name. Which is the most important task would need to be ascertained by user testing and it is likely that there will be differences among users. It is difficult to give hard and fast rules covering every possible situation. To find out what is best, it is most useful to have prototype designs tested in a realistic situation by people with sight loss.

Pop-up warnings should be given priority over everything else, interrupting the currently spoken output.

Speak the right amount of information (high priority)

The amount of information spoken should not be so much as to overwhelm the user. For example, the programme guide in figure 17 includes some essential information the screen name TV guide and the fact that this is a list of all channels. It also contains a lot of instructional information the functions of the coloured buttons and how to view or record a programme. Speaking all this information before speaking the current channel and programme would not be helpful. Unfamiliar users may find it useful to be told the most important instruction how to view a programme so when first opened it might start by reading TV guide, All channels, 101 BBC 1 London, Single Father, Press Select to view..

Avoid speaking information that is already known (high priority)

When information is repeated in the user interface it should not be re-spoken unnecessarily. For example, if the current date and time is displayed on every screen or pop-up message, it is not necessary to read it every time. It may be spoken if it is likely to be needed at a specific time, such as when a user first enters the programme guide. Then it would be useful to speak the current time, so that the user has something to relate the programme times to.

Another example of unnecessary repetition is where the user scrolls through the chronological list of programmes on a single channel. The channel number and name should not be read out for every programme, but only when the user first selected that channel.

How you could test for this

Test prototype speech output with a number of blind users, using a Wizard-of-Oz methodology, to determine whether users find it informative, sufficient, succinct and satisfying. The Wizard-of-Oz methodology enables the tests to be carried out at an early stage, before the speech output is implemented, by using an experimenter to act the part of the speaking user interface. Tests should be task-based, in which users are required to understand and react to the information provided as speech in order to carry out typical viewing, navigation and set-up tasks. While the user operates the visual interface using the remote control, the experimenter speaks what the interface would output in response to each user action. This allows various approaches or variations of speech output to be trialled without the cost of implementing any of them first.