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.

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.

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.

Examples