# Design and Applications of GLANCE: GLanceable Alarm Notification for a User Centered Experience
### Daling with Notifications in Network Management  
In summary, the basic approach underlying the studies about \"interruptiveness\" is to reason on the timing (the _when_) of the interruption, under the hypothesis that the notification delivery can be subject to some sort of scheduling based on the stages of the ongoing tasks (in other words, the ongoing task \"wins\" over the source of the notification). As already observed, in an application domain like network management, this is not always the case, with the \"winner\" between the ongoing task and (source of the) notification being dependent on the severity of the fault. An alternative solution can be found by reasoning about the format (the _how_) of the notification, making it dependent on the notification severity and capable of capturing the correct degree of users' attention: While the customary solution (found both on desktop PCs and in mobile devices) is to adopt a unified format for all notifications (typically a badge possibly associated to auditory and haptic cues), a severity-based solution would associate low severity alarms to notification formats that do not distract operators from the foreground tasks and high severity alarms to notification formats that provoke the operator's reaction. This is the approach proposed in this paper, based on a glanceable peripheral display, that, residing in the sensory periphery, conveys information that can be of some importance for users, in a way that it is able to exploit the \"pre-attentive\" processingability of the human brain; as long as the alarm severity is not high, the display behaves like an ambient display [30], which lets users absorb the information in a subliminal way, without having their attention diverted from the foreground task (ambient systems are diffused in a variety of contexts, like, e.g., [31; 32; 33]). Only when a high severity notification arrives, the display changes its (static and dynamic) features to behave like an alerting display moving from the periphery to the foreground of the user's attention. Another aspect of customary solutions that make them poorly performant in the case of network management is their perspective of streams of individual notifications displayed one at the time and inserted in lists ordered by the time of arrival without any overview capability. The burden of creating a mental map of the overall state (who/which source sent what when) is entirely on the users that can only scroll lists of badges. A notifier oriented to network management should be capable of offering, at the same time, information on individual recent faults and overview on the network as a whole. The one-notification-at-the-time perspective is generally also typical of studies focusing on features and classifications of peripheral displays, design guidelines for criticality-based displays, and the prioritization of notifications [34; 35; 36; 37; 38; 39; 40; 41]. One notable exception is the Scope notifier [42], offering an overview on multiple prioritized notifications coming from heterogeneous sources (among which, email, calendar, and pending work items) using the metaphor of a traditional radar view (the closer to the center, the most urgent/important the item). The Scope peripheral awareness mode is extremely abstract and concise, representing notifications just as markers on the radar and leaving the initiative primarily to the users that are required to switch from the foreground task to the Scope active interaction mode to inspect items and decide whether to open it in the native application (only for urgent notifications details are automatically displayed). On the contrary, we aim at _a notifier that always retains the information expressiveness of the one-notification-at-the-time perspective, though guided by severity-based coding strategies, while enriching it with overview capabilities_, to guarantee (possibly subliminal) long-term local and global content comprehension and prompt reaction when the interruption from the foreground task is dictated by the fault severity.