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.
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.
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.