Frequently applications will need to alert the user about certain events. These events can be blocking (modal) whereby normal application execution cannot continue until the user has either acknowledged the event or selected an option to proceed with. An obvious example of such an event is an application querying if the current document should be saved or discarded. Some events, however, do not need the user to explicitly acknowledge them, or to select an option – these events are non-blocking and could include notifying the user that they have a new email, the battery on their device is getting low, a new contact has signed in, and so on.

For the latter category of notification, modal dialog boxes are both unintuitive and unsuitable in a multi-tasking environment and, as such, different options must be considered, including:

  • Displaying a non-blocking floating window;
  • Displaying a notification balloon in the Windows notification area;
  • Displaying a bespoke pop-up or otherwise animated window.
  • All of the above have individual flaws and also require additional code to be added to the application. Furthermore – and probably worst of all – none of these methods allow for user customisation of how (or, indeed, if) the notification is displayed.

Where a user receives a notification is becoming more important as well. It is perfectly conceivable that a user may which to be emailed, be sent an SMS, or receive a push notification that notifies them that a particular event has occurred. An example would be a developer who sets his project compiling and then leaves for a coffee break – he or she would want to be notified that the compilation succeeded or if any errors were detected, and they would want to receive when away from their workstation.

A single service which takes care of all this is a necessity. Having a single service:

  • Reduces the requirement for application developers to craft their own notification handling code;
  • Provides a consistent interface to the end user;
  • Allows for extensibility (i.e. the ability to have new ways of notifying a user) through the use of plugins or add-ons;
  • Empowers the user by letting them determine how – and which – event notifications are displayed.

Example Use Case

In addition to the problem of how a user should be notified of a particular event, it’s also a question of allowing the user to decide when they’re notified of a particular event. Take the following scenario:

  • Bob is preparing for a presentation to the senior management team
  • He’s checking a few last minute issues with Sarah via his IM application
  • Bob begins his presentation
  • Five minutes in, Sarah sends him a “Good luck!” message via IM
  • Twenty minutes in, Bob’s laptop battery drops to 10% charge left.

In this scenario, Bob would not want to be disturbed by Sarah’s IM message but he would most definitely want to know that he’d forgotten to plug his laptop in and that the battery was getting low. This highlights the need to for contextualisation of alerts – in this case, Bob would enable Do Not Disturb mode ensuring that priority notifications (the one about his battery getting low) would still be displayed while others (Sarah’s friendly but unwanted) IM wouldn’t.

In order to maintain a consistent appearance, your application should follow these guidelines. They’re not meant to be restrictive; instead they are recommendations.

Inside the Notification

Title and Text

  • Keep the title and text short: Notifications appear unsolicited and, as such, the user will want to be able to digest the meaning of the notification as quickly as possible without interrupting their flow.  Titles should be kept as short as possible, typically no more than four words; the notification text may be longer but should still be as concise as possible. If you need to pass a lot of information to the user, consider using a static callback or action which will direct the user to a document that contains it.


  • Use icons wherever possible: icons are multi-lingual and can convey greater meaning with less effort.
  • Choose wisely: a well-chosen icon can convey the meaning of the notification without the user having to read the associated text.  Snarl includes a large number of stock icons which the user will become familiar with over time.
  • Ensure the icon relates to the urgency of the notification: icons such as !system-critical should be reserved for only the most urgent or important notifications.  Consider using !system-info or !system-warning instead.

Outside the Notification

Dynamically Modifying Notifications

  • Avoid programmatically hiding notifications: The hide command should be avoided as it is impossible for your application to tell whether the user has been able to fully digest the notification content. The only time hide may be of use is if the event the notification is alerting the user to no longer exists (for example, a “power disconnected” notification when the power supply has been restored).


  • Avoid high-priority notifications: Generally speaking the user should be left to determine which notifications constitute high-priority status. When deciding whether a notification should be displayed as high priority or not you should consider the context your notification will be displayed in and that, although you may feel the notification requires urgent from the user, the user may disagree.

Do Not Disturb (DND) mode can be enabled manually by the user or Snarl can be set to automatically enable it if the foreground application appears to be running in full-screen mode. In addition to this global on/off switch, the user can also define which notification classes should be treated as priority notifications so, in reality, all your application can do is recommend which notification classes should be treated as priority; the user has the final say in the matter.


  • Avoid sticky notifications: notifications which do not disappear automatically quickly take up screen space and can be frustrating to the user as they must then stop what they’re doing, navigate to the notification and dismiss it manually.  The process is compounded if the notification has a default callback as the user must navigate specifically to the Close gadget on the notification – a much smaller area of screen than the notification itself.
  • Use the Snarl default duration: there are very few examples where using something other than the default notification duration is suitable and using the default duration ensures consistency across notifications and allows the user to determine how long they would like notifications to remain on screen.