Is this the right user interface?
Design concepts
Usage patterns
Guidelines
Text

A notification informs users of events that are unrelated to the current user activity, by briefly displaying a balloon from an icon in the notification area. The notification could result from a user action or significant system event, or could offer potentially useful information from Microsoft® Windows® or an application.

The information in a notification is useful and relevant, but never critical. Consequently, notifications don't require immediate user action and users can freely ignore them.

A typical notification.

In Windows Vista®, notifications are displayed for a fixed duration of 9 seconds. Notifications aren't displayed immediately when users are inactive, applications are running in full-screen mode, or screen savers are running. Windows automatically queues notifications during these times, and displays the queued notifications when the user resumes regular activity. Consequently, you don't have to do anything to handle these special circumstances.

Developers: You can determine when the user is active using the SHQueryUserNotificationState API.

Note: Guidelines related to notification area, taskbar, and balloons are presented in separate articles.

Is this the right user interface?

To decide, consider these questions:

• Is the information the immediate, direct result of users' interaction with your application? If so, display this synchronous information directly within your application instead using a dialog box, message box, balloon, or in place UI. Notifications are for asynchronous information only.

  

  In this example, the Windows Firewall exceptions dialog box is displayed as a direct result of user interaction. A notification wouldn't be appropriate here.

• Is the information relevant only when users are actively using your application? If so, display the information in your application's status bar or other status area.

  

  In this example, Outlook displays its connection and synchronization state on its status bar.

• Is the information rapidly changing, continuous, real-time information? Examples include processing progress, stock quotes, and sports scores. If so, don't use notifications because they aren't suitable for rapidly changing information.
• Is the information useful and relevant? Are users likely to change their behavior or avoid inconvenience as the result of receiving the information? If not, either don't display the information or put it in a status window or log file.
• Is the information critical? Is immediate action required? If so, display the information using an interface that demands attention and cannot be easily ignored, such as a modal dialog box or message box. If the program isn't active, you can draw attention to the critical information by flashing the program's taskbar button three times and leaving it highlighted until the program is active.
• Are the primary target users IT professionals? If so, use an alternative feedback mechanism such as log file entries or e-mail messages. IT professionals strongly prefer log files for non-critical information. Furthermore, servers are often managed remotely and typically run without any users logged on, making notifications ineffective.

Design concepts

Synopsis:

Effective notifications that promote a good user experience:

• Are asynchronous (unrelated to the current user activity), useful, relevant, non-critical, actionable, and appropriately presented.
• Help users maintain their flow by presenting information in a way that users immersed in their work can easily ignore.
• Don't require immediate user action and users can freely ignore them.
• Most importantly, are not annoying!

If you do only three things...
1.  Use notifications only if you really need to. When you display a notification, you are potentially interrupting users or even annoying them. Make sure that interruption is justified.

2.  Use notifications for non-critical events or situations that don't require immediate user action. For critical events or situations that require immediate user action, use an alternative UI (such as a modal dialog box).

3.  If you use notifications, make it a good user experience. Don't try to force users to see your notifications. If users are so immersed in their work that they don't see your notifications, your design is good.

For more information and examples, see Notification Design Concepts.

Usage patterns

Notifications have several usage patterns:

Guidelines

General

• Select the notification pattern based on its usage. For a description of each usage pattern, see the previous table.

What to notify

• Don't notify of successful operations, except in the following circumstances:
  • Security. Users consider security operations to be of the highest importance, so notify users of successful security operations.
  • Recent failure. Users don't take successful operations for granted if they were failing immediately before, so notify users of success when the operation was recently failing.
  • Prevent inconvenience. Report successful operations when doing so might avoid inconveniencing users. Consequently, notify users when a successful operation is performed in an unexpected way, such as when an operation is lengthy or completes earlier or later than expected.
• In other circumstances, either give no feedback for success or give feedback "on demand." Assume that users take successful operations for granted. You can give feedback on demand by displaying an icon (or changing an existing icon) in the notification area while the operation is being performed, and removing the icon (or restoring the previous icon) when the operation is complete.
• For the FYI pattern, don't give a notification if users can continue to work normally or are unlikely to do anything different as the result of the notification.

  Incorrect:
  

  In this example, the information is useful only if the user already has the ports installed. Otherwise, the user isn't likely to do anything different as the result of it.

• Exception: You can notify users of information of questionable relevance if it is optional and users opt-in.

  Correct:
  

  In this example, users are notified when contacts come online and they chose to receive this optional information.

• For the non-critical system event and FYI patterns, use a single, complete notification for a single event. Don't present several partial ones.

  Incorrect:
  
  
  
  

  These examples show just four of the eight notifications that were displayed by Windows XP when a user attaches a specific USB keyboard, each presenting incrementally more information.

  Correct:
  

  In this example, attaching a USB keyboard results in a single, complete notification.

When to notify

• Display a notification based on its design pattern:

  Pattern	When to notify
  Action success	Upon completion of an asynchronous task. Notify users of successful actions only if they are likely to be waiting for completion, or after recent failures.
  Action failure	Upon failure of an asynchronous task.
  Non-critical system event	When an event occurs and the user is active, or the condition continues to exist. If this results from a problem, remove the currently displayed notification immediately once the problem is resolved.
  Optional user task	When the need to perform a task is determined and the user is active.
  FYI	When the triggering event occurs.
  Feature advertisement	When the user first performs an action where the feature is relevant.

• For the action failure pattern, if the problem might correct itself within seconds, delay the failure notification for an appropriate amount of time. If the problem corrects itself, report nothing. Notify only after enough time has passed that the failure is noticeable. If you report too early, most likely users won't notice the problem reported, but they will notice the unnecessary notification.

  Incorrect:
  
  
  Immediately followed by:
  

  In this example, the notification of no wireless connectivity is premature because it is immediately followed by a notification of good connectivity.

• For the action success and FYI patterns, use the real-time option so that stale notifications aren't queued when users are running a full-screen application or aren't actively using their computer.
• For the non-critical system event pattern, don't create the potential for notification storms by staggering events tied to well-known events such as user logon. Instead, tie the event to some time period after the event. For example, you could remind users to register your product five minutes after user logon.

How long to notify

In Windows Vista, notifications are displayed for a fixed duration of 9 seconds.

How often to notify

• The number of times to display a notification is based on its design pattern:

  Pattern	How often to notify
  Action success	Once.
  Action failure	Once.
  Non-critical system event	Once when the event first occurs. If this results from a problem that users can solve, redisplay once every ten minutes if users must resolve within an hour, or once every hour if users must resolve within a day.
  Optional user task	For security-related tasks, once an hour. For all others, once a day for a maximum of three times.
  FYI	Once.
  Feature advertisement	Once a day whenever the feature is relevant, for a maximum of three times.

• For optional user tasks, don't try to pester users into submission by constantly displaying notifications. If once an hour isn't frequent enough for a specific security-related task, then in essence the task is required. Display a modal dialog box immediately instead of using notifications.

Notification escalation

• Don't assume that users will see your notifications. Users won't see them when:
  • They are immersed in their work.
  • They aren't paying attention.
  • They are away from their computer.
  • They are running a full-screen application.
  • Their administrator has turned off all notifications for their computer.
• If users must eventually take some kind of action, use progressive escalation to display an alternative UI that users cannot ignore.

Interaction

• Make notifications clickable when:
• Users should perform an action. Clicking the notification should display a window in which users can perform the action. This approach is preferred for the action failure and optional user task design patterns.
• Users may want to see more information. Clicking the notification should display a window in which users can view additional information.
• Always display a window when users click to perform an action. Don't have clicking perform an action directly.
• Clicking to show more information should always show more information. Don't just rephrase the information already in the notification.

Icons

• For the action failure pattern, use the standard error icon.
• For the non-critical system event patterns, use the standard warning icon.
• For other patterns, use icons showing objects that relate to or suggest the subject, such as a shield for security or a battery for power.
• Use icons based on your application or company branding if your target users will recognize them and there is no better alternative. However, these icons are preferred for the feature advertisement pattern.
• For progressive escalation, consider using icons with a progressively more emphatic appearance as the situation becomes more urgent.

  
  

  In these examples, the appearance of the icons becomes more emphatic as the urgency increases.

• Don't use the standard information icon. That notifications are information goes without saying.
• Consider using large icons (32x32 pixels) when:
  • Users will quickly comprehend the icon rather than the text.
  • The large icons convey their meaning more clearly and effectively than the standard 16x16 pixel icons.
  • The icon uses the Aero-style.

    

    In this example, users can quickly comprehend the nature of the notification with a glance at the large icon.

Notification queuing

Note: Notifications are queued whenever they cannot be displayed immediately, such as when another notification is being displayed, the user is running a full-screen application, or the user isn't actively using the computer. Real-time notifications remain in the queue for only 60 seconds.

• For the action success and FYI patterns, use the real-time option so that the notification isn't queued for long. These notifications have value only when they can be displayed immediately.
• Remove queued notifications when they are no longer relevant.
  Developers: You can do this by setting the NIF_INFO flag in uFlags and set szInfo to an empty string. There is no harm in doing this if the notification is no longer in the queue.

System integration

• If your application doesn't always have an icon in the notification area when it's running, display an icon temporarily during the asynchronous task or event that caused the notification.

Text

Title text

• Use title text that briefly summarizes the most important information you need to communicate to users in clear, plain, concise, specific language. Users should be able to understand the purpose of the notification information quickly and with minimal effort.
• Use text fragments or complete sentences without ending punctuation.
• Use sentence-style capitalization.
• Use no more than 48 characters (in English) to accommodate localization. The title has a maximum length of 63 characters, but you must allow for 30 percent expansion when the English-language text is translated.

Body text

• Use body text that gives a description (without repeating the information in the title) and, optionally, that gives specific details about the notification, and also lets users know what action is available.
• Use complete sentences with ending punctuation.
• Use sentence-style capitalization.
• Use no more than 200 characters (in English) to accommodate localization. The body text has a maximum length of 255 characters, but you must allow for 30 percent expansion when the English-language text is translated.
• Include essential information in the body text, such as specific object names. (Examples: user names, file names, or URLs.) Users shouldn't have to open another window to find such information.
• Put double quotation marks around object names.
• Exception: Don't use quotation marks when:
  • The object name always uses title-style capitalization, such as with user names.
  • The object name is offset with a colon (example: Printer name: My printer).
  • The object name can be easily determined from the context.
• If you must truncate object names to a fixed maximum size to accommodate localization, use an ellipsis to indicate truncation.

  

  In this example, an object name is truncated using an ellipsis.

• Use the following phrasing if the notification is actionable:
• If users can click the notification to perform an action:
  <brief description of essential information>
  <optional details>
  Click to <do something>.

  

  In this example, users can click to perform an action.

• If users can click the notification to see more information:
  <brief description of essential information>
  <optional details>
  Click to see more information.

  

  In this example, users can click to see more information.

• Don't say that the user "must" perform an action in a notification. Notifications are for non-critical information that users can freely ignore. If users really must perform an action, don't use notifications.
• If users should perform an action, make the importance clear.
• For the action failure and non-critical system event patterns, describe problems in plain language.

  Incorrect:
  

  In this example, the problem is described using overly technical, yet unspecific language.

  Correct:
  

  In this example, the problem is described in plain language.

• Describe the event in a way that is relevant to the target users. A notification is relevant if there's a reasonable chance that users will perform a task or change their behavior as the result of the notification. You can often accomplish this by describing notifications in terms of user goals instead of technological issues.

Documentation

When referring to notifications:

• Use the exact title text, including its capitalization.
• Refer to the component as a notification, not as a balloon or an alert.
• To describe user interaction, use click.
• When possible, format the title text using bold text. Otherwise, put the title in quotation marks only if required to prevent confusion.

Example: When the Critical updates are ready to install notification appears, click the notification to start the process.

When referring to the notification area:

• Refer to the notification area as the notification area, not the system tray.

Guidelines feedback