Problem

A method must be provided to notify the user of arbitrary notifications, of varying priority, without unduly interfering with existing processes.

Solution

A single, consistent notification method is provided across the entire OS. This method does not interfere with any current processes the user is currently involved in, and allow it to be acted upon or dismissed very easily.

Multiple notifications must be able to all be displayed in a single view, so no notification obscures another.

Variations

Multiple variations of this pattern are available.

A dedicated notification strip or area may be used, with a portion of the viewport dedicated to notifications. This may be hidden when no notifications are present, but will fade in, slide up or otherwise appear when notifications are present. Selection of any notification item will display it in the application that hosted the notification. This may be difficult to use for scroll-and-select devices, so will be most encountered on touch and pen input devices.

Notifications may be combined with the Annunicator Row. This is in fact very common on basic and legacy devices, where the envelope icon means new voicemail or SMS messages have arrived. Additional notifications may be added to this area as well. These legacy utilizations are not Notifications as far as this pattern is concerned, as they are not generally interactive; the user must take separate action to dial into the voicemail system or open the text messaging application.

Especially for touch and pen devices, the Annunicator Row may include a notification area. An arbitrary number of notification icons can occupy a designated area in the always visible Annunicator Row, and when opened a complete list of all the current notifications is revealed.

For scroll-and-select devices, and certain other cases (if there is no good place to put a notification area, or the Annunciator Row is unsuitable for repurposing) a simple Pop-Up dialogue box may appear over the current context whenever a notification appears. This is a special case of the Confirmation dialogue, which should be seen for behaviors and layout.

Currently, regardless of the other notification paradigms, incoming voice calls use a completely unique notification method, and automatically launch the phone application full screen. This is a holdover, and may not be a permanent condition. Using any of the notification methods above could provide as suitable a method of informing the user of the incoming call, and of accepting or declining it.

Interaction Details

A key attribute of the Notifications pattern, as distinct from the Annunicator Row pattern, is the ability to directly interact with the alert. Each item must be able to be seen individually within the notification method, and selected for viewing (or other suitable actions), or be able to be dismissed.

When more than one current notification is available, the method must support showing all of them at once. If the Confirmation dialogue style is used, for example, a special version must be made where a list of all the notifications is displayed instead, and selecting one will open a new dialogue with the details and actions of that item alone. Within this list, batch operations, such as dismissing all notifications, should also be available.

When the Annunicator Row is used to access notifications, tapping or dragging the row will reveal the list of notifications. The method chosen for the reveal gesture should be based on other gestures used in the OS, so it is discoverable and understandable when described and demonstrated.

Various actions must be available for any notification item, or for a single notification Pop-Up. See the Confirmation pattern for details on the dialogue especially. Consider which actions might be helpful in reducing the number of steps the user must take. For example, instead of just "Read" and "Dismiss" buttons for a new SMS, a "Reply" button could be added, if the message summary is enough to elicit a response. This will allow the user to act immediately. Use caution not to add too many options, cluttering the selections and reducing the size of displayed information and options.

When a notification is acted up (e.g. the new text message is read) suspend any current operations or actions and save all user-entered data. When the action, application or process initiated by acting on the notification is completed, return to this previous condition.

Presentation Details

Notification areas are most commonly strips along the bottom of the viewport, to differentiate from the Title and Annunicator Row elements. The area should be at a fixed location within the viewport, and not scroll. Scrollbars will not overlap the area when it is displayed. Individual notifications will be displayed as line items, or may be grouped by category, with counters indicating the number of notifications for each category.

Labels for each notification item must be clear and comprehensible. Always state the service or application initiating the notification; usually, an icon will be sufficient for this. If a summary of the message cannot be displayed (such as for voicemail, or an MMS with no text) do not display jargon or difficult-to-parse information such as the sender phone number; use clear descriptions instead, like "New voicemail." Whenever possible, display relevant information; look up senders of SMS/MMS in the address book and when found, display their name instead of the phone number.

If summary information can be provided, such as the content of a text message, this may also be displayed. This is a rare case where "marquee" text, which scrolls within the available space, may be used to good effect. Text messages are short enough that such text display tends to be readable, and to allow the entire message to be read rapidly, without opening the messaging application.

Additional information may also be derived from the notifying application, or other handset services. For the case of a new SMS, any avatar icon for the user may also be displayed, to assist in understanding what is being sent at a glance.

Antipatterns

Do not display notifications serially. If more than one is received at a time, use a multiple notifications method, instead of showing one single notification after another.

Understand and follow the OS's method of notification and "marked as read." Dismissing a message from view in the notification area may or may not mark it as read in the application sending the notification. There is, as yet, no consistency in this regard, so no pattern can be determined as yet.

Examples