Notifications – What I’d like to see

It’s kind of an interesting coincidence that about a week before Mark Shuttleworth posted in his blog about Canonical’s plans for notifications, I had started experimenting with a new IRC client, Quassel, that provides a notification when you are highlighted or sent a personal message.
I’ve waited a bit to reply to his plans to gain more experience with notifications from Quassel and to think things through and not just give a knee jerk reaction. My initial reaction was very similar to Aaron Seigo’s. So I’ve spent a week or two thinking about it on and off and I really haven’t changed my mind.
Let me use Quassel’s notification as an example and give you an idea of what I want and why…
The proposal from Mark Shuttleworth has two key points:

– There should be no actions on notifications.
– Notifications should not be displayed synchronously, but may be queued.

To the first point, my experience with Quassel notifications is that I will have one of two reactions:
1. I read the notification and I both understand the context sufficiently I don’t need to look at the IRC channel and I have no immediate interest in responding. I get the notification, read it, and go back to what I was doing. This seems to fit the proposed model quite well. I want the information in the notification and I want it to hang around just long enough to read it and not require that I dismiss it.
This is how Quassel notifications work today. In some cases, it’s great and it’s a feature I really like that Konversation didn’t have. In other cases, it drives me nuts.
2. I either need more context to understand the message or I want to reply. In this case I inevitably click on the notification thinking it will take me to the Quassel window with the message, even though I know it doesn’t do that from repeated tries.
This is where I think the notifications proposal is off base. The idea of not requiring interaction (the notification just goes away after some period) is a good one. The idea of not allowing interaction is, I think flawed. I thought that perhaps I was misunderstanding the proposal and left a comment. It didn’t draw a response, but a similar comment did get a reply. I understand the reply and it does make things not quite as bad as I had feared, but it still doesn’t solve the problem.
For about a month now I’ve been using an application where I get regular notifications. I know that clicking on the notification doesn’t actually do anything and I need to click on the icon in the taskbar. I know this and still I click on the notification first every single time. Why, because it’s the thing that just flashed a message to me and it’s the most natural thing in the world for me to click on that message to get more information/act on it.
I don’t get stacks of notifications often enough to have a strong opinion about that bit, but Aaron Siego’s idea to reduce notifications and not just queue them seems sensible to me. If there are a lot of notifications, queuing them will just make them late and less useful.
So what would I like to see in notifications:
1. Clicking on the notification takes me someplace to act on it.
2. I’m not required to dismiss it.
3. It’d be nice if it picked up the desktop theme and didn’t give me Ubuntu standard colors on a Kubuntu desktop.
Fortunately, at least from my perspective, it doesn’t look like the chances of this getting implemented in Kubuntu for Jaunty. It’s not in any of the approved specs and I don’t know of anyone who is working on it (Note: If someone is working on an implementation of this aimed at Kubuntu Jaunty, use Kubuntu developers would be interested to know about it).
It’d be nice to see a follow-up post explaining why having clicking on the notification doing something useful is a bad thing? The lack of it is currently driving me nuts.


14 Responses to “Notifications – What I’d like to see”

  1. 1 ethana2 January 5, 2009 at 00:59

    I guess I’m okay with notifications, like, existing, as long as I don’t get a single one that I don’t want to.

  2. 2 Roshan January 5, 2009 at 03:16

    Exactly! I agree. I often find myself clicking on the notification to go to the window. It just seems like the obvious thing to do!
    P.S. You can theme the tooltip using .gtkrc, I think. I do remember having different coloured tooltips by editing colours in Gnome Appearance Properties.

  3. 3 Udo January 5, 2009 at 03:54

    Your 3 points are exactly like mine šŸ˜‰
    Great post.

  4. 4 nnonix January 5, 2009 at 04:15

    I agree completely.
    I believe where you’re going to get some argument is from the people who believe that clicking on the notification should close the notification. Since the spec says that notifications go away on their own, this opens the possibility for notifications to take you to the notifying application.
    It’s the intuitive thing to do!

  5. 5 Kai Grossjohann January 5, 2009 at 05:51

    I guess perhaps the problem is the looks of the notification. I used to use Growl on MacOS and its notifications looked different, and I never had the urge to click on them. (There was a notification when changing the volume via the keyboard, and it looked the same: A greyish transparent rectangle with rounded corners and a frame with white text/graphic inside.)
    Can you change the look of the Quassel notifications to be like this? And perhaps move them to the center of the screen? What happens when you do?

  6. 6 ScottK January 5, 2009 at 06:24

    I think it’s more a question of the context. I get similar volume notifications and I don’t get the urge to click on them either.
    The difference is that’s giving me feedback on an action I’m taking, not informing me about something I might want to react to.
    Quassel supports both QT bubbles and Dbus notifications. The QT bubbles look a lot more like what you are describing. I still want to click on those because I want more information.

  7. 7 Lure January 5, 2009 at 08:47

    Scott, I agree with your summary 100%.
    Did you ever tried Kopete and its notifications? They operate similar to this: they offer “View” and “Ignore” buttons. I think Ignore is not needed, if notification goes away quickly (in seconds) and View could be click on notification itself…

  8. 8 Stoffe January 5, 2009 at 09:52

    I’m just going to ask you to read the whole post again, and don’t stare yourself blind at notifications as if it is the only thing mentioned. Not that you are alone in this knee-jerk reaction, though.
    On the other hand, you may well be right, everyone knows this, and exactly for this specific reason, brave people will not sit idly saying “it will never work”, but will rather carry out actual, empirical experiments.

  9. 9 Michael "Click" Howell January 5, 2009 at 11:43

    The reason given for not allowing notification clicks is, to quote, that it gives the “obligation” to click it (no comment).

  10. 10 ScottK January 5, 2009 at 11:54

    Lure: Not in a long time. I do vaguely recall the View/Ignore. I think what you’re saying makes sense.
    Stoffe: I know that’s what it says, but that doesn’t make any sense. There will be things that can be clicked on (in KDE I’d call them icons on the taskbar, not sure what Gnome calls them), so the ‘obligation’ is still created, just in a less convenient way.
    I confess that I don’t get it at all. It may well be that this experiment proves to be wonderful, but my personal experience with notifications suggests otherwise.

  11. 11 Paul Kishimoto January 5, 2009 at 17:06

    I noticed in the mock-up video that notifications went mostly transparent when moused over. To me that very clearly conveys “You can’t click this!” On the other hand, I agree with your point about a “click reflex” when things pop up that one is curious about.
    Maybe a compromise: a notification can EITHER be actionless OR have a target that gets opened when clicking on it.
    For example, it is probably not necessary to click a “WiFi signal lost” or volume notification when there are icons nearby in the system tray.
    On the other hand, IM and IRC windows buried under many others and with several tabs would be a good candidates for clickable notifications.
    Perhaps the user could indicate (according to status?) which notifications are “important” (always clickable) or “unimportant” (always actionless) or “in between” (use application default).

  12. 12 ScottK January 5, 2009 at 20:34

    I know that not all notifications will have a useful actions. What concerns me with the proposal is that it would prohibit actions even in useful circumstances.
    It’s tempting to fall back on the standard “Gnome takes choices away from the user while KDE encourages user choice”, but I don’t know that this is at issue here. If this is going to get done for Kubuntu, I would like to see there be more choice.

  13. 13 Rexbron January 6, 2009 at 22:41

    I think growl would serve as an example worth considering.
    Growl uses the interaction model of notifications not requiring user interaction, they will go away on their own on a configurable interval. Mousing over the notification makes a close button appear, clicking anywhere else takes you to the app in question. This makes the most sense IMO.
    However, growl does not address the “message flood” scenario. Email notifications would be the best example I can think of. Emails (for me at least, scottK, thing are probably different for you šŸ˜‰ tend to trickle in, but when I fire up my email client after say sleeping, I get a barrage of emails. Have a notification for each would flood the screen. What would be much more useful would be the notification daemon noticing that Thunderbird has just sent 100 notifications and condensing it down to 1 “100 new messages” notification.

  14. 14 ScottK January 7, 2009 at 11:49

    Quassel will notice if it’s the foreground application and not send notifications then. I think that’s the best solution to the flooding problem.
    I think message abstraction (e.g. you have 100 new mails) is best done by each application as the appropriate method for abstraction is going to be application specific.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s


%d bloggers like this: