Notifications
Caveats
Most if not all pages are just rough notes, and these pages as a whole are far from complete. More notes will be added in time, eventually, maybe.
If, from reading these notes, you conclude that I am off my rocker, you won’t be the first, and you may even be right. These pages may simply position me as an acolyte to the late Gene Ray.
No doubt there are a dozen and one reasons why none of this would ever work, but perhaps somewhere deep down there is a tiny fragment that could be used for something.
Contents
Session level
Thus far, it is not clear whether any GUI has ever implemented notifications correctly. In Mac OS 9 and earlier, most programs called for attention by alternating the icon of the active application (at the top-right of the screen) with their own icon. If multiple programs sought attention at once, the active application icon would cycle through the icons of all such programs along with that of the active application. Under such conditions, the user was unable to see what any program wanted without first switching to it.
Some applications on the Mac would, however, show a floating modeless window containing a message. These were fairly small and unobtrusive, but ultimately no more scalable than any other design.
The approach found in Windows was a balloon message associated with an icon in the taskbar notification area (commonly known as the “system tray”). These messages were painfully transient, often vanishing before you had time to read them or take a screenshot.
This was followed by “toast” messages, that are fairly similar but are no longer associated with a tray icon.
These floating alerts constantly get in the way. No matter where they appear on the screen, they block access to some window control, block the location where you are typing or otherwise get in the way. Various programs—Microsoft Teams being a perfect example—are too arrogant and self-centred to use Windows standard notifications and implement their own, and then notifications from one program block another. A Teams notification stops you reading an Outlook notification and vice versa. This is a synergy violation and a consistency violation.
Exactly how anyone is supposed to create a notification system that actually works, is not clear. With that said, so long as all applications use the same API, this decision is not set in stone as the presentation can be modified by the user.
Termination of alert conditions
There are various situations that generate alerts, where the condition that led to the alert may be temporary. For example, Microsoft Windows issues an alert notification when your anti-virus software is disabled. If this occurred due to an update of the anti-virus software, the alert condition will automatically clear. The problem here is that the notification is neither cleared nor revoked. The user is left with a notification representing a problem that no longer exists, and no indication that there is no longer anything to be concerned about.
One option is to use an alert classification ID (creating a new notification of the same classification will update or delete any still open or still queued alert) or a rescindment reference handle (to be able to modify the notification) so that the notification can be cleared automatically, using either of the following options:
- Delete the notification. Confusing as it means that the alert appears and then vanishes.
- Modify the notification: add some kind of appendix to indicate that all is OK.
Another option is to simply issue a follow-up with an “all clear” notification. The user now has to mentally tie the two together. This behaviour will also apply under the first option if the user has already dismissed the original notification.
Application level
A means is needed for applications to present modeless notifications within themselves. These are messages that don’t require the user’s attention to be sought while the application is in the background. Existing behaviours include a bar at the top of the window and issuance of a session-level notification. As with session-level notifications, these also have a particular habit of getting in the way of something (a bar covering over part of the window) or shunting the window contents (a bar injected into the window).
Programs must be encouraged to show modeless notifications where possible, as modal windows have a habit of stealing focus, and focus theft protection doesn’t make sense when the thief is the active application.