Problem

Certain classes of users, or any user in certain contexts, must be informed of conditions, alarms, alerts and other contextually-relevant or timebound content without reading the device screen.

Solution

Much as Notifications appear on the device screen (and sound alarms and blink the LED) when messages arrive or other such alerts activate, Voice Notifications read the content of a notification so they can be used when the device is not in the hand, or cannot be viewed.

These can be especially useful for users or contexts in which reading would be difficult. A common case is turn-by-turn directions. The reminders are based on telemetry information instead of time (like alarms) or remote information (like messages), but the principle is identical; a message is read, without specific user input, at the relevant time.

Voice Notifications also allow the screen to remain available for the display of other content. It may be able to be glanced at to retrieve certain types of data (such as a map, in the navigation example), but not to the detail that text can be read easily or safely.

The best way to notify is using technologies like push messaging, supported by a surprising number of devices, on most networks. Remote messages can launch the application, then not only read the alert but present a correspondingly well-formatted page to look at. Note that the audio only plays when the entire message has loaded, so the user may glance at the device to get other information and follow along. The audio must always be able to be paused or stopped, in case it is disrupting an event, or the user has privacy concerns.

Variations

Voice output that is requested to be presented, or the use of voice to navigate the device UI is discussed under the Voice Readback pattern.

Interaction Details

Voice Notifications occur based on time, position, remote messaging or other actions outside the user's direct control.

Reminders currently being read should be considered the same as other alarms, and should appear in the Notifications area. They may be muted, snoozed, or cancelled. Do not snooze alarms that are irrelevant at a later time, such as position-related messages.

When the voice component is muted, or the entire notice is snoozed, it will remain in the Notifications area, and may be manually selected and viewed (or listened to), or be cleared.

Alternatively, and as a method to alleviate concerns over privacy or interruption, Voice Notifications may be very simple, stating that it is time to take medication, for example. When the user responds (by voice or on-device selection), the remainder of the message will be read aloud.

In context Voice Notifications are most often used for features like turn-by-turn navigation. The display is mostly reserved for pictorial displays of information, which are more glanceable, and allow multiple types of information to be presented at once. A summary of the audio message should be presented on screen, even if expected to be unreadable; the user may change contexts (e.g. stop the car), another individual may be able to assist the user, and the mere presence of the information box reinforces that the message is originating from this device, and relates to this task.

Presentation Details

Alerts should always be presented visually as well as via audio. See the patterns under Notifications for display of notifications. Even in-context, the alert should be noted in some manner, though this may be more contextual, such as an Annotation over a map.

To inform the user that audio is about to commence, and to prepare them for the volume level, a subtle tone or unimportant audio should be played immediately beforehand. This may also be the normal alert tone, to emphasize the device is communicating an alert.

Use syntax that makes it clear what is being communicated, and attempt to give users a moment to acclimate to the voice and the instruction format, even after any notification tones. For example, state the type of message or action that the user must take, then the details:

Repetition generally is not perceived the same in spoken phrases as in print, due to the immediacy and the way audio vs. visual perception works.

Use caution when choosing what sort of content will be read -- and to what level of detail. Alerts will generally be sent through the speaker, so have minimal privacy. Since anyone nearby can hear, messages must be formatted to be general or have no explicitly secret information, and the user should be reminded of this risk when setting up Voice Notifications.

Use a consistent voice and tone of voice, so the user can become accustomed to the reminder, and be able to comprehend the intent without listening as closely to opening phrases.

Antipatterns

Avoid "blurting out" alerts or instructions, especially with important information in the beginning of the phrase. Directions such as "Turn Right in 500 yards" are often not useful, as the user is still acclimating to the voice speaking through the direction statement; they may only hear "... in 500 yards."

The voice used must be as understandable as possible. Text-to-voice translation of names, especially, can be difficult to understand or improperly pronounced. If quality is too low with the available hardware and software, do not implement the solution.

Examples