Help and Support‎ > ‎User Guide‎ > ‎

1. Introduction


Snarl is an application that allows other applications to alert the user to an event in a structured, unified way through the creation of on-screen notifications. Ultimately, the end-user has final say over which events an application notifies, and how they are presented based on the user's presence and whether they want to be disturbed or not.

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;
  • Extensibility (i.e. the ability to have new ways of notifying a user) can be provided by plugins or add-ons to the service;
  • The user is empowered to determine how all event notifications are handled from a single point.

Use Cases

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:
  1. Bob is preparing for a presentation to his CEO
  2. He's checking a few last minute issues with Sarah via his IM application
  3. Bob begins his presentation
  4. Five minutes in, Sarah sends him a "Good luck!" message via IM
  5. 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 the battery was getting low. Both of these issues can be solved by allowing the user to define (a) which notifications must always be seen (priority notifications) and (b) when they should not be disturbed (Do Not Disturb mode).