Notifications, popups, and how I’d use them

Well, the latest design of my RPC model seems to be sufficiently bullet-proof, so if nothing new has happened in this area on Saturday I’ll start to do code some viability test in order to see how much performance it’d eat, especially on initialization (as it is the most costly and optimizable part), and if it is sufficient.

In meantime, I have some spare time, so here’s a bit of higher-level thoughts on notification and pop-ups, why I believe that they are misused today, and how I’d like to see them used instead.

Terminology

I call a notification a transient, non-obtrusive visual and/or audible signal that tells the user that something’s going on without forcing him to care about it now (or at all). Examples include Windows’ and Growl’s balloon tips and Gnome 3’s notifications. Optionally, notification may leave a persistent, subtle indication in a corner of the monitor, so that they get noticed even if the user was not there when they arrived.

I call a pop-up a strong signal that the user can’t ignore, and requiring explicit feedback from him before disappearing and leaving him going back to his work. Examples include the unsaved document warning of many office suites, or the “battery is going critical” warning of OS X and Windows 7. It should be noted that displaying a pop-up does not imply getting immediate user feedback : the user may be away from the computer, and said computer may have to decide for him anyway. But user knowledge and feedback is highly preferred.

Notification horror museum, and the way I think it should be done

Flash Player updater

On a nice day, you arrive at work, turn on your computer, prepare to work on something, when suddenly a window jumps on your face. Holy crap ! This window has an unusual visual design, so you take some time to figure out what it is, and when you finally do, you learn that some random “flash player” program which you’ve never heard of absolutely HAS to be updated, here and now, or otherwise the Earth might blow up.

Is this critical enough to pollute your desktop with a permanent pop-up that won’t go away until you’ve answered its question ? No.

Is it reasonable for the unskilled user, who doesn’t know where Flash Player update settings are being set up, NOT to install security updates to Flash Player ? No.

Then why is there something at all ? Just update it in the background and leave power users with the option to disable it if you really think this is vital, silly !

A related issue is Java Update : at first look, it seems less wrong, since it’s only a balloon pop-up. But the unskilled user shouldn’t have to take part in the installation process, and the UAC windows triggered by Java Update on each boot definitely counts as a pop-up window.

Bad battery status notifications

Nowadays, it is common for laptop batteries to provide the OS with various information, through ACPI. One of these are the “Low” and “Critical” battery levels. When the battery’s charge level reaches the “Low” level, the OS is advised to notify the user. When reaching the “Critical” level, the OS is advised to enter a crisis state, do every possible thing to save the few remaining minutes of battery power, and put the laptop in hibernation state if the user doesn’t quickly ends what he’s doing and turns it off.

So far so good. Now how is this handled on the Fedora 14 linux distro, and many other based on the GNOME 2 desktop ?

  • When battery reaches the low level, one or two notifications are emitted, basically stating “Oh, you should be careful, but you still have time left”.
  • When battery reaches the critical level, one notification is emitted, stating “You only have a few minutes left, you should do something quickly or else the computer will enter an hibernation state”.

The first one is good, when coupled with a visual modification of the battery icon, which Windows and Linux do. A notification is sufficient, because the situation is not critical, and it’s not too much because the user should know about power shortage in advance if he has no way of plugging the computer in.

The second one, on the other hand, is awfully bad. If the situation is critical and the user is there, everything should be done to ensure that he has seen and read the warning. Putting a popup on top of everything else and requiring the user to acknowledge it, as done by both Windows 7 and Mac OS X, is a good practice.

Annoying system updaters

To date, neither Windows, Mac OS X, or any Linux distro which I know of, have managed to produce a system-wide updater which doesn’t suck.

Let’s recall what the main purposes of system updaters are. The first, most critical task, of update systems in any OS which may afford them, is to apply security updates and bug fixes. Those updates do not include features, and are sufficiently simple that they should never, ever, break anything. But they improve the system’s security and stability, and as such should be applied as soon as possible. I’ll call them maintenance updates.

Optionally, system updaters may also take care of bigger updates, which come with a higher risk for the user because they bring new features, change the way software works, and may break things. I’ll call them feature updates.

Maintenance updates are something which represents little risks and significant benefits for the user, so unless he’s a geeky guy who knows how to tweak updater settings, he wants them, and doesn’t care so much about them. Just like car maintenance : you don’t care so much what the mechanic has done, as long as your car still works in the same way as before or better, and is good for the upcoming year. So maintenance updates shouldn’t require the user to care. They should happen behind his back, in a transparent fashion.

Instead, here’s what happens.

  • Windows : “Security updates have been applied, so we are now going to reboot your computer. You have 15 minutes to save your data, or else it will be lost. If you’re an unprivileged user, you have no way to abort this procedure. We warn you through a pop-up warning that is hidden behind other windows, and don’t care if you’re currently away from your computer and drinking cofee. Lost data is YOUR problem, not ours.”
  • OSX : “Look, look, we have lots of shiny security updates for you, please please click yes in this permanent pop-up so that we may install them because it’s just too difficult to do it on our own !”
  • Linux : Behaviour varies from one distro to another, but the default behaviour frequently asks you to confirm the installation of any kind of updates (not only feature ones), and may optionally also include pop-ups at the end of the notification process telling you that you should reboot so that the updates are fully applied.

On their side, feature updates shouldn’t be applied as a default, as they represent a significant risk of user experience change and breakage. The choice of installing them or not should be left to the user. In my opinion, the OS shouldn’t even care about them as a default setting, only leaving the option to enable them to power users, but different OS manufacturers have a different vision of things. Anyhow, feature updates are not something critical. They’re a comfort. If the user chooses to ignore them, nothing bad should happen to him. So obtrusive pop-ups are not a good option, the updater should instead resort to transient notifications. Sole exception would be deprecated software : if a program has grown so old that no maintenance updates are available anymore, the user should know. And even then, it’s debatable whether this situation requires a full-blown pop-up instead of a subtle notification.

Many modern OSs still don’t make a difference between feature and maintenance updates.

Killing without caring or hanging indefinitely ?

On most Linux distros, when you turn off the computer while some piece of software has unsaved data in it, the unsaved data is lost. The system doesn’t care about the opened “save or quit” pop-up that could be triggered by SIGTERM in GUI programs and simply sends SIGKILL on every still living process after a few seconds. Much pain may ensue.

On Windows 7, when you do this, the computer hangs indefinitely on a “Do you want to kill the blocking program ?” full-screen pop-up. Windows considers programs displaying pop-ups as an annoyance, like Linux, but it’s polite enough to ask you first before going on a crazy rampage. The thing is, it’s still not optimal, for a few reasons.

Obvious issue with using a full-screen pop-up is that you can’t see what’s happening without canceling the shutdown. But that’s just a visual design problem. No, what annoys me significantly more is the consequences of the computer being hung for an undefinite period of time. Especially when keeping in mind that when a user asks a computer to turn off, he expects it to turn off, not to do fancy tricks. Many users, like me, just press the power button and go do something else. As a consequence…

  • Desktops may waste lots of power, and annoy the user when he comes back. Imagine that a user presses the power button on Friday evening, at the end of a work week, and only comes back on Monday. The computer will have been running for the whole week-end. There are already sufficient problems with users not turning off their computers that we shouldn’t have to care about those who try and fail too, in my opinion. Also, on Monday, the user will probably not be happy to find his computer still in a dirty state, instead of being able to directly boot it in a clean state.
  • Laptops, in similar circumstances, may eat up all their battery power and go in deep sleep, leaving the user under the impression that they have shut down fine. When he then tries to turn it on again, the user only has very little time left to understand the situation and find a power socket or save the document. After that, the computer becomes unusable if no power socket is near. And again, power has been wasted.

For this reason, I think that pop-ups should have a time out. Once some time has elapsed, a decision is taken, preferably the most conservative one (e.g. saving the file under a different name, in the case described above). This solves the “shut down” problem, among others.

Conclusions

Sometimes, computer programs have to communicate with their users. Two mechanisms have been conceived for this purpose, notifications (with and without permanent reminders) and pop-ups. These mechanisms are both necessary, and one can’t be fully replaced by the other.

When designing software-user communication situations, software developers should, in my opinion, always ask themselves the following questions :

  • Do I really need to tell the user about this ? (If not, keep silent. Notifications work better when they are less frequent and not trivial)
  • Is this information purely transient, or does it remain valid even after an extended period of time ? (If the information is transient, go for reminder-less notifications and keep the workspace clean. Examples include IM messages, “operation completed” notifications, etc…)
  • Is it vital that the user knows about this right now, if he’s there ? (If so, go for pop-ups, if not use something more subtle that does not require explicit acknowledgement)

Well, I think that’s all. Thanks for reading !

5 thoughts on “Notifications, popups, and how I’d use them

  1. Amenel June 15, 2011 / 2:52 pm

    As soon as I saw the notification email for this post, I thought “man, I need to read this”. Recently, I’ve been pondering over high-level aspects of software systems, especially with respect to the way software effectively makes life easier for users.

    In the “Annoying system updaters” section, I think there is only one reason why systems ask the user to “confirm” (which, in itself, is stupid since the users didn’t do/trigger anything, they are just presented with the fact that something will be done on their systems): the systems are just incapable of guaranteeing a problem-free system update be it a security update or a feature update. Hence the confirmation asking, so that they could say, in case things go awry, “oh, you knew, you even gave your consent”. That happens a lot in real life situations: never heard a “you knew so what are you whining about?”

    As to the killing or saving, you put your finger on a salient problem that most people are oblivious to: lack of “consideration” (that’s the term I personally use, to say “putting oneself in someone else’s shoes”) for the user. In the specific case of Linux, I didn’t even know that data could be lost thanks to SIGTERM, which is hilariously… bad; no kidding, that’s ludicrous if still true. I mean, how difficult can it be for any OS to force the application to save the data and just bail out? That would solve a huge portion of those “blocking application” popups I see on my Windows systems. Really, what prevents Linux from creating a specific signal (that says “save data now at all costs and exit”) to send when shutting down or rebooting the system? The salient problem extends into multiple directions that are all characterized by the lack of a standardized or uniform way to do something.

    For instance, imagine there is a WM_EMERGENCY_SAVE_DATA_AND_BAILOUT (tm, of course… copyrighted too) message on Windows. The something to do in this case would be “create another version of the file contents in an alternate data stream”. Any app would implement the proper handler the way it sees fit, just like they implement for WM_CUT or any other message. If it doesn’t the toolkit’s default handler would kick in and perform the appropriate actions, i.e. output the file contents to the ADS. After the system is up again, the application performs a quick check and sees that the multiversion file has its last version tagged as an automatically saved file contents. This is possible except that today, the OSes are built in a manner that almost insurmountable hurdles exist. I mean, how does the toolkit or handler know what to write to the disk as the file contents? what’s the format? What about accessing other processes memory? I know the problems are numerous but OS makers should have known better.

    There is a lot to be said about notifications, UIs and HCI in general. For instance, why can’t I have a notification-like window remain visible? I am specifically thinking of Winamp here. Sometimes, I want the notification to stay on-screen and whether doing so turns “notification” into a misnomer isn’t something I care about. We need more uniformity, configurability and control into the hands of users. And the obvious problems about the current notification systems you pointed out are just an aspect of that. Except, although full of common sense, your offerings in the conclusion are what people who care come up with and obviously, the current OSes do not care enough or they care more about other things.

    Anyway, nice read. And yes, the Flash updater is a very relevant pick.

  2. Hadrien June 15, 2011 / 5:12 pm

    In the “Annoying system updaters” section, I think there is only one reason why systems ask the user to “confirm” (which, in itself, is stupid since the users didn’t do/trigger anything, they are just presented with the fact that something will be done on their systems): the systems are just incapable of guaranteeing a problem-free system update be it a security update or a feature update. Hence the confirmation asking, so that they could say, in case things go awry, “oh, you knew, you even gave your consent”. That happens a lot in real life situations: never heard a “you knew so what are you whining about?”

    I don’t think it’s a valid enough concern. In that case, system manufacturers could just ask the user once, on installation or first boot, whether they want security and bugfix updates to be automatically installed, and never ask again. Continuously asking is just a waste of time. I think Windows doesn’t do it anymore, actually, although it also got this silly 15 minutes dialog in the way.

    To say it otherwise, would you imagine dealing with software which asks you to agree with the EULA on each startup ?

    As to the killing or saving, you put your finger on a salient problem that most people are oblivious to: lack of “consideration” (that’s the term I personally use, to say “putting oneself in someone else’s shoes”) for the user. In the specific case of Linux, I didn’t even know that data could be lost thanks to SIGTERM, which is hilariously… bad; no kidding, that’s ludicrous if still true.

    First, many apologizes as I confused SIGTERM and SIGKILL. SIGTERM is the clean one, SIGKILL is the dirty one. Fixed in the article.

    That being said, I’m pretty sure it’s still true, both for command-line shutdown and for GUI shutdown, that on shutdown, the normal Linux behaviour is to send SIGTERM, wait a few seconds, and send SIGKILL if processes are not dead already. Will check this evening and report :)

    The main issue is not that SIGKILL (aka signal 9) kills apps so brutally, in my opinion. It has been designed to do so, it’s the kill switch for hung apps. What’s wrong is that Linux apps do not react appropriately to the first SIGTERM of init, dying right away without any attempt at data conservation.

    (By the way, speaking of consideration for the user… Have you noticed how WordPress’ comment section now automatically expands downwards as you type ? I think that’s a great, welcome touch. Could be the perfect solution to a problem which I keep having with small memo fields in websites)

    I mean, how difficult can it be for any OS to force the application to save the data and just bail out? That would solve a huge portion of those “blocking application” popups I see on my Windows systems.

    Afaik, those popups appear when Windows has sent its equivalent of SIGTERM, but the application did not respond in any way that’s obvious to Windows. So Windows basically tells the user : “This software may still be saving data or cleaning things up. Do you want to send the Windows equivalent of SIGKILL now or do you want to give it a chance ?”.

    If Windows events are managed asynchronously and the event handler of the application is stuck in an infinite loop or a computationally expensive operation, it may happen. In that case, what signal has been sent by Windows doesn’t matter : it will never arrive. This is one of the reasons why I’m so fond of multithreaded approaches, even though they may sometimes make things more complicated…

    Really, what prevents Linux from creating a specific signal (that says “save data now at all costs and exit”) to send when shutting down or rebooting the system? The salient problem extends into multiple directions that are all characterized by the lack of a standardized or uniform way to do something.

    Frankly, I don’t know. I agree with you that it could be a way of solving the problem. Maybe people from the Unix world are shy about defining new signals because they fear proliferation of proprietary signalling if they did so ?

    There is a lot to be said about notifications, UIs and HCI in general. For instance, why can’t I have a notification-like window remain visible? I am specifically thinking of Winamp here. Sometimes, I want the notification to stay on-screen and whether doing so turns “notification” into a misnomer isn’t something I care about.

    Would you be satisfied with having a “mailbox” of notifications in a corner of the screen, allowing you to review past, non-acknowledged notifications, without having them stacking up on the screen and eating up screen estate ? KDE 4 does it this way, and I play with the idea of embracing something like this too, to some extent (more on that in a later article if I manage to get something viable and consistent out of my pen&paper work).

    We need more uniformity, configurability and control into the hands of users. And the obvious problems about the current notification systems you pointed out are just an aspect of that. Except, although full of common sense, your offerings in the conclusion are what people who care come up with and obviously, the current OSes do not care enough or they care more about other things.

    Yup. And I think the way to achieve that uniformity is to put proper notification handling at the core of the OS (or desktop environment for the “Linux is just a kernel” kind of people). Applications should not reimplement it in an inneficient and proprietary way, and in fact the OS should purposefully make it difficult when possible.

  3. Hadrien June 15, 2011 / 7:01 pm

    Confirmed. On my Fedora 14 at least, shutdown kills all processes without any hope of data recovery. (Tested by running GIMP, drawing a line on a picture, and then attempting shutdown, either through low-level or high-level methods).

    EDIT : After manually checking, most desktop linux software actually doesn’t even bother reimplementing SIGTERM to manage unsaved file problems, contrary to what I thought. A killall -15 already destroys the apps and all unsaved data.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s