|
Size: 4323
Comment:
|
← Revision 23 as of 2011-07-31 23:56:48 ⇥
Size: 8426
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| 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. | You must inform certain classes of users -- or any user in certain contexts -- of conditions, alarms, alerts and other contextually-relevant or timebound content without requiring them to read the device screen. Practically all mobile devices have audio output of some sort, and it can be accessed by almost every application or website. There can be strict limits, such as devices which only output over headsets, or those which only send phone call audio over Bluetooth, that can limit the use of some tones. |
| Line 6: | Line 8: |
| Much as '''[[Notifications]]''' appear on the device screen (and sound alarms and blink the '''[[LED]]''') when messages arrive or other such alerts activate, '''Voice Reminders''' read the content of a notification so they can be used when the device is not in the hand, or cannot be viewed. | 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 the information can be used when the device is not in the hand, or cannot be viewed. |
| Line 8: | Line 10: |
| 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. | 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. |
| Line 10: | Line 12: |
| '''Voice Reminders''' 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. | '''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 level or type of detail of the read-aloud text. |
| Line 12: | Line 14: |
| {{attachment:VoiceNotification-Pill.png|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 == There are only two basic variations: * '''In Context''' -- The device is operating in the mode or application from which the alert is launched. Often, the alert is integral to the application, and on-screen display accompanies the alert in a critical manner. Turn-by-turn directions are the key example of this variation. * '''Change of Context''' - The device is in an arbitrary mode, on the idle screen, or locked when the alert is read from an application not in focus. A simple example is any typical notification, such as an appointment, or incoming SMS. |
|
| Line 13: | Line 20: |
| == Variations == In context - like turn by turn directions Change of context - Alerts, out of the blue 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. |
If the user requests voice output, or voice output is used as a part of generally navigating the device UI, this is a '''[[Voice Readback]]''' pattern instead. |
| Line 23: | Line 24: |
| '''Voice Reminders''' occur based on time, position, remote messaging or other actions outside the user's direct control. | '''Voice Notifications''' occur based on time, position, remote messaging, or other actions outside the user's direct control. |
| Line 25: | Line 26: |
| 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. | Treat reminders currently being read the same way as other alarms. Make sure they appear in the '''[[Notifications]]''' area, or as '''[[Pop-Up]]''' dialogues, as the rest of the OS standards dictate. You must also enable the same actions; they may be muted, snoozed, or cancelled. Do not snooze alarms that are irrelevant at a later time, such as position-related messages. |
| Line 27: | Line 28: |
| 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. | If the voice component is muted, this is the same as silencing an alarm of '''[[Tones]]'''. The notification itself will remain in the Notifications area, and may be manually selected and viewed (or listened to), or be cleared. |
| Line 29: | Line 30: |
| Alternatively, and as a method to alleviate concerns over privacy or interruption, '''Voice Reminders''' 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. | A privacy mode may only read a generic version of the message. When the user interacts with the device, a more detailed message can be seen, or read aloud. This will rapidly become the '''[[Voice Readback]]''' pattern. See that for specifics of the design and interaction. Consider informing users of the risks of reading private data aloud, when setting up '''Voice Notifications''', and provide methods to change or cancel them easily. |
| Line 32: | Line 35: |
| {{attachment:VoiceNotification-Map.png|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.|align="right"}} | |
| Line 33: | Line 37: |
| 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. | Make sure all alerts are 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 specific, such as an '''[[Annotation]]''' over a map. Only use '''[[Pop=Up]]''' dialogues or other intrusive measures when absolutely required. |
| Line 35: | Line 39: |
| 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: | To inform the user that audio is about to commence, and to prepare them for the volume level, play a subtle tone or unimportant audio message immediately beforehand. This may also be the normal alert tone, to emphasize the device is communicating an alert. Make sure the volume of this tone is similar to (or lower than) the audio to be read aloud, as the intention is not just to consciously alert the user, but to prime their auditory system for receiving messages. 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: |
| Line 38: | Line 44: |
| 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. | Repetition generally is not perceived in a negative way in spoken phrases as in print, due to the immediacy and the way audio vs. visual perception works. |
| Line 40: | Line 46: |
| 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 Reminders'''. | 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. For example, instead of stating the medicine and dosage as above, the message could just be "Time to take your medications.... Be sure to take it with a meal." |
| Line 42: | Line 48: |
| 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. | Use a consistent voice and tone of voice for all notifications. This way, the user can become accustomed to the reminder, and be able to comprehend the intent without listening as closely to opening phrases. |
| Line 48: | Line 54: |
| 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. | Voices provide strong emotional responses, and when not accustomed to it, or expecting it, may be startling. Avoid using '''Voice Notifications''' when users are asleep, and be sure to preceed all notifications with '''[[Tones]]''' to make it more clear that this is a machine, not a scary intruder sneaking up from behind. The voice you use must be as understandable as possible. Even within a single language, be sure to use the most generic possible accents, and be aware of regional idioms. 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. |
| Line 52: | Line 62: |
---- Next: '''[[Haptic Output]]''' ---- = Discuss & Add = Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here. |
|
| Line 53: | Line 71: |
| If you want to add examples (and we occasionally do also) add them here. == Make a new section == Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account. |
Problem
You must inform certain classes of users -- or any user in certain contexts -- of conditions, alarms, alerts and other contextually-relevant or timebound content without requiring them to read the device screen.
Practically all mobile devices have audio output of some sort, and it can be accessed by almost every application or website. There can be strict limits, such as devices which only output over headsets, or those which only send phone call audio over Bluetooth, that can limit the use of some tones.
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 the information 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 level or type of detail of the read-aloud text.
Variations
There are only two basic variations:
In Context -- The device is operating in the mode or application from which the alert is launched. Often, the alert is integral to the application, and on-screen display accompanies the alert in a critical manner. Turn-by-turn directions are the key example of this variation.
Change of Context - The device is in an arbitrary mode, on the idle screen, or locked when the alert is read from an application not in focus. A simple example is any typical notification, such as an appointment, or incoming SMS.
If the user requests voice output, or voice output is used as a part of generally navigating the device UI, this is a Voice Readback pattern instead.
Interaction Details
Voice Notifications occur based on time, position, remote messaging, or other actions outside the user's direct control.
Treat reminders currently being read the same way as other alarms. Make sure they appear in the Notifications area, or as Pop-Up dialogues, as the rest of the OS standards dictate. You must also enable the same actions; they may be muted, snoozed, or cancelled. Do not snooze alarms that are irrelevant at a later time, such as position-related messages.
If the voice component is muted, this is the same as silencing an alarm of Tones. The notification itself will remain in the Notifications area, and may be manually selected and viewed (or listened to), or be cleared.
A privacy mode may only read a generic version of the message. When the user interacts with the device, a more detailed message can be seen, or read aloud. This will rapidly become the Voice Readback pattern. See that for specifics of the design and interaction.
Consider informing users of the risks of reading private data aloud, when setting up Voice Notifications, and provide methods to change or cancel them easily.
Presentation Details
Make sure all alerts are 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 specific, such as an Annotation over a map. Only use Pop=Up dialogues or other intrusive measures when absolutely required.
To inform the user that audio is about to commence, and to prepare them for the volume level, play a subtle tone or unimportant audio message immediately beforehand. This may also be the normal alert tone, to emphasize the device is communicating an alert. Make sure the volume of this tone is similar to (or lower than) the audio to be read aloud, as the intention is not just to consciously alert the user, but to prime their auditory system for receiving messages.
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:
- "Turn coming up... turn right in 500 yards."
- "Time to take your medications... take one Ritalin now."
Repetition generally is not perceived in a negative way 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. For example, instead of stating the medicine and dosage as above, the message could just be "Time to take your medications.... Be sure to take it with a meal."
Use a consistent voice and tone of voice for all notifications. This way, 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."
Voices provide strong emotional responses, and when not accustomed to it, or expecting it, may be startling. Avoid using Voice Notifications when users are asleep, and be sure to preceed all notifications with Tones to make it more clear that this is a machine, not a scary intruder sneaking up from behind.
The voice you use must be as understandable as possible. Even within a single language, be sure to use the most generic possible accents, and be aware of regional idioms.
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.
Next: Haptic Output
Discuss & Add
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.
Examples
If you want to add examples (and we occasionally do also) add them here.
Make a new section
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.