The notifications issue – part 1: the problem

Howdy,

I will skip the obligatory wrap-up with where I’ve been and what I did, since it would be random boilerplate you are probably not interested in. Instead, I want to start a small series of blog posts about the status of notifications.

Why?

I didn’t wake up this morning with the idea – I am cooking this since several months instead. I’ve been talking extensively about this during the Workspace sprint in Barcelona, had some quick chats at Akademy, some others with some of the Ubuntu Designers at UDS, and more. Let me get this straight from the beginning: this is not really about the appearance or the technical implementation: this is mostly about the concept of notifications itself. But let’s start analyzing the problem.

Preamble about this series

This series will be structured in 3 posts:

  • The problem – outlining what currently we don’t have or doesn’t work (all of this in my opinion) in KDE.
  • The status – what have been others up to in this topic.
  • The solution – a proposed solution to improve our system, based on the previous posts.

This is, guess what, part 1.

Preamble about this post

Some readers might say: “hey, you’re outlining problems which we have in KDE that $STUFF already solved”, and in fact they’re right. I’m not ranting even here, I am just trying to approach the issue one step at a time. The solution I want to propose is a mixture of my own ideas and already existent solutions – this is why I want to try to be as clear as possible starting from the very beginning, which is finding out why we need something better.

What is wrong about notifications?

This question probably has a gazillion answers which might all be right or wrong, but I want to try and focus on a specific thing before anything: purpose. Let’s consider a number of use cases:

  • A file transfer finished
  • I received a new mail
  • A friend got online
  • Somebody sent me a message on IM
  • My battery is running short
  • An application encountered a non-critical error

What is the question here? Hypothetically, the first one which might come to one’s mind might be “Do I want to be notified?”, which is sensible – I have been asking myself this question quite a number of times. But we’ll get to that later. Another question, which is the one which bothers me the most, is “How do I want to be notified?”. I didn’t mention those use cases by chance – in my opinion (but I think this might be applied to many of my kind readers) there are very different ways in which those events should be displayed. I often get very annoyed by the fact I don’t have a way for interacting sensibly with my events.

Transient vs. Persistent

This is what I usually call the “transient vs. persistent” issue. Supposing I’m away from my laptop, if a friend of mine goes online or an application warns me about, let’s say, “connection dropped”, I sure don’t want to have a reminder about this when I get back to my PC. Although, I’d like to have a way for knowing that I got mail and a friend contacted me.  At the moment, this is something we completely lack.

In my view, a notification should ease the workflow, not interrupt it. Easing the workflow means allowing me to quickly reach to the actions I need to undertake (such as reading an [hopefully] important mail or message) and not being bothered by stuff I don’t care about. Persistent notifications are probably the most obvious way to separate “todos” from “stuff that happened”. Which somehow links us to another problem…

Spam

Yes, spam. When an application goes totally crazy and starts spawning a number of notifications bothering the user and possibly your CPU as well. When I’ve been talking about this problem with some people, one of the first answers I got was “well, fix the application then”. Here’s why, in my opinion, this won’t work:

  • You cannot fix every application out there
  • At the same time, an application can be designed in a way such an event happens due to some unforeseen circumstances. Implementing a “spam control” on an application basis means introducing complexity just for the sake of notifying the user.
  • The definition of “spam” itself is quite tricky: having a serious HIG saying “you cannot stream more than x notifications every y” is very hard to follow for everyone, and applications might decide to go for their own “spam control” with their custom rules.
  • In general, this could be summarized with: “Letting the application handle that means introducing new complexity at the risk of sacrificing consistency”

This is why I strongly believe the notification system itself should be capable of handling correctly this case.

Interaction

There, I know you’ve been waiting for this. It’s likely the most controversial topic when talking about notifications, on which everyone has his own ideas. The very reason why I’ve not been talking about this before is that I wanted to show that this issue is strictly linked to what I said above. You might in fact find out that in most cases, persistent notifications require interaction, some transient might suggest an interaction, some transient can’t even do that. Let’s analyze our previous use cases in this light:

  • A file transfer finished (transient) – I’d say no interaction, one might go as far as “open target folder/file”
  • I received a new mail (persistent) – Open that mail
  • A friend got online (transient) – Suggest to open a chat with him
  • Somebody sent me a message on IM (persistent) – Open that chat
  • My battery is running short (transient) – Not much I can do with that
  • An application encountered a non-critical error (transient) – Same as above

As you see, there is a pattern there – it’s not by chance that interaction is required specifically by persistent notifications – as I said before referring to persistent notifications, they need to “reach to the actions I need to undertake”. But besides that, there is another interesting story here – you might notice that every notification only allows for one obvious action (apart from “discard”, which is a different business). Exercise to the reader: can you think about a concrete case (not a weird corner case) in which a notification might need to suggest more than one action? (as I said before, discard doesn’t count as such).

Context

It’s quite hard to find out if a notification has a context or not. If I’m working hard and I don’t want to be distracted, I sure don’t want that friend of mine telling me “OMG LOOK AT DIZ VID LOL”. My fault in the first place for leaving my IM open, but this happens so many times. This part of the problem is not really specific to notifications, which is just a small part to the bigger issue. But it is true indeed that the next step after solving the persistency of notifications would be solving the conflict of notifications not belonging to your current context.

Wrap up

There is indeed room for improvements. Where do we go from here then? If you’ve been following me, we need a system which is capable of bothering us as less as possible, while “remembering” us what we need to do, and allowing us to interact in a sensible way. Does such a system already exist? Yes and no. I guess this will be food for part 2, though.

In the meanwhile, why not dropping a comment about how you like the initiative, and what are your feelings towards the problems I explained? Maybe I missed something obvious? Discussions welcome. Until then, see you for the next part.

About these ads

~ by Dario on 19 July, 2012.

33 Responses to “The notifications issue – part 1: the problem”

  1. There is, optional support, for some of this already in the messaging indicator work that Aurélien Gâteau did three years ago:

    http://agateau.com/2009/09/18/indicators-notifications-and-co/

    While I wasn’t originally enthused with the idea, I stuck with it and have come to quite like aspect of it. I particularly like getting a list of times and IRC channels that I got highlighted on when I get back to the computer.

    I don’t think it’s a perfect solution by any means, but if you’re going to do some work in this area, I think you ought to look at it and maybe discuss it with Aurélien (since he did it for $FORMER_JOB, I’ve no idea if he’s still interested).

  2. My biggest issue is just that notifications aren’t as easy, nice looking, or useful as the original KDE4 mock-ups promised.

    It’s terribly annoying to have a widget that pops up, occasionally in random places, is locked to it’s location on the panel, which I center, and is obnoxious to dismiss.

    I much prefer the approach unity took. Those are spaced, easy to read, and unobtrusive. Also, I’ve found that buttons on notifications are slow to respond, ugly, and workflow-breaking.

  3. “can you think about a concrete case (not a weird corner case) in which a notification might need to suggest more than one action?”

    I can think of a few that I encounter very often:

    1. A file transfer didn’t succeed, due to some non-trivial error like a name conflict. There are at least 3 actions for a single file here.

    2. Any sort of invitation (party, meeting, friend or group invite on a social networking site, etc). Here, there are at least 3 options: accept, reject, ignore this for now (i.e. dismiss). For some invitations, like social events, “maybe” would also be a valid answer. You can’t have “dismiss” as “reject”, since someone might just not know the answer now and wants to deal with it later.

    3. You’ve connected a new removable storage device or disc and need to decide what to do with it. This currently isn’t implemented in the notification system in KDE, but at a conceptual level it is still a notification. Same goes for some other classes of removable devices, like external monitors or projectors for a laptop.

    Of course you could just say “we will deal with this in a separate window”, but it doesn’t change the fact that there are multiple possible actions that could be picked from.

    • I agree with Dirk S. here (see below). One button is enough:

      1: (persistent) A conflict occurred during the file transfer, click to resolve.
      2: (transient) You have X open requests in $socialNetwork. Click to open your profile. (c.f. android or iphone)
      3: (transient) A device has been connected, click to open device manager.

      I really _don’t_ want to have many choices in the notification area, and I especially don’t want the interaction to be bound to happen in the notification area. It exists to _notify_ me, not to cram all action into a small part of the screen where it doesn’t belong.

      • There are two different issues here.

        1. Are there any cases where there is more than one useful response to a notification?
        2. Do those responses belong in the notification or somewhere else?

        The answer to 1, as I pointed out, is “yes”, and that is what I took the question to be asking.

        The answer to 2 is a value judgement, and may vary from case to case. It may be that we never want to put more than response in a notification.

        However, the goal here is to figure out how to improve notifications. I think it is a bit premature to say that we will never put more than one response in a notification before we even begin considering how notifications might be improved. I think the first step is to figure out what the use cases are, the situations users have to deal with, and then come up with an improved version that best deals with all of them.

        If we state up-front that we going to exclude certain use-cases from consideration, we may miss something important, and I think it is much less likely we will reach the best solution. I think it is better if we set aside our preconceptions about how notifications should behave so we can look at the big picture.

        For the record, at least with how notifications currently behave, I agree that these cases would not be best handled by notifications, and I see no obvious way that notifications could be changed such that this would work. But that does not mean someone else might not be able to figure out a system that can handle this, and it does not mean this system might not be superior to the other proposals.

  4. PLease, redesign notifications in KDE!!!

  5. I’m guessing the outcome of this blog series is gonna be a suggestion about linking notification disturbance level with activities, which I would very much welcome!

    Personally, for the most part I would like some kind of “work/office” activity setting, I recognize that some people want popups… I don’t. Rant about this follows:

    The progress tracking part of the notification system is pretty nice, but I don’t need a popup (neither transient nor persistant) telling me that it completed successfully. Actually I don’t want one for failures either. That pie chart thing can just quietly go back to an “i” symbol or disappear. When I have a moment when I’m not so busy I will glanze at the pie chart, if it’s gone maybe I will open the application and either check out my successfully downloaded/copied file . Or… If there was a problem, that’s also the place to do something about it.
    Not nice when the notifications create another place where you need to click some button to dismiss/acknowledge a message, typically it will be enough with the popup in the application!
    Nothing is critical to do NOW on a general purpose computer… unless, of course, you control your home-made nuclear power plant with your laptop. So.. no blinking entries in the taskbar! No popups! Just icons that are in the notification area, or not.
    People will quickly learn which icons to look out for to learn if something has happened, seeing an icon in the corner of your eye becomes almost instictive.. you’re gonna notice that there’s one more icon than usual without even thinking.

    On a related note…
    I wrote a patch for the device notifier plasmoid to optionally not popup either, just quietly show its icon. If I want to do some action that the device notifier can offer me, then I can click its icon. The patch was rejected, Aaron thought that most users do some action from that list most times when they plug in something, so it’s worth potentially saving a click for them (if they’re fast enough before the popup goes away). I think either it should stay up longer (for people who click something there most of the times) or not show at all (for people who often charge phones/mp3 players in their computers). I do want to mount the phone/player sometimes, so the “hide device” option is not really an option.

  6. “can you think about a concrete case (not a weird corner case) in which a notification might need to suggest more than one action?”

    Some persistent notifications suggest two actions: “Do it now” and “Remind me later”. You might want to solve “Remind me later” on the framework level (just like “Discard”).

    On a related note, one thing which particularly annoys me about the current KDE notifications is that they do not have any keyboard interaction. While this would not be particularly problematic for any other Plasma applet (keyboard interaction is definitely not a focus of Plasma as of now), it is problematic for notifications because they, while displayed by Plasma, still belong to an application which might have a useful keyboard interaction pattern (e.g. a browser, a terminal, a text editor, an IDE).

  7. Cases with few actions:
    file exists (during copping) overwrite,rename
    Someone goes online start chat, audio/video call

  8. Lots of interesting idea’s here. In the end such new system will obviously have much better results! :)

    To be honest, I’m a bit tired of the persistent notification spam, for stuff that obviously doesn’t need a manual discard later. That includes stuff like “Email was sent” (well thank you very much :-) and the KIO notifications on remote smb/ftp/webdav shares: “File was deleted”, “file was deleted”, “Folder was moved”, “A file was copied”. Imagine every “cp” giving a notification popup…

    Just having those persistent/manual discard notifications out of the way would solve a lot! I hope you can find a simple and quick solution for this :-D

  9. Hi,

    Nice initiative. I’m pretty much excited to see where you’ll lead us.
    I’ve myself started to (re)think about notifications a few weeks ago and I’m really curious to see if we share the same ideas to improve the thing.
    Well, I’ll wait for the next posts with enthousiasm :)

  10. Hi,

    I really like your analysis.

    Regarding the “Transient vs. Persistent issue” I would suggest to allow transition between these states. A file transfer notification for example is persistent in the sense that it will show the progress until it is finished. Then the same notification (popping up a new one would just mean more distraction for the user) should display “transfer complete” for a short time and thus become transient. If an error occurred during the transfer, the notification should stay persistent and provide the user with the needed information.

    I think that having one action for a notification must be enough in order to keep the interface simple. If you want to provide more options, just do it inside your application after the user clicked on the notification. This would also make buttons in notifications superfluous: you could make the notification itself clickable and display a text (for example in a grey color) within the notification explaining what will happen if the user clicks onto the notification. For the file transfer example it could say “Click to open detailed progress” during a transfer and “open destination folder” after a successful transfer. Of course some sort of “discard” must also be implemented, but this could either be done with some close-symbol or just with a right-click (or both). If you got rid of the buttons, you might also consider getting rid of the progress bar (in a case where it is needed of course): just make the background of the notification resemble a progress bar. Windows 7 does that with its launchers and it’s quite nice in my opinion.

    I agree with lunarcloud that notifications should stay in a predefined (possibly configurable) place and not pop up depending on the panel. I also think that the current notifications are way to big and cover to much of your working space, especially when you’re using a laptop. This is why I suggested to get rid of the buttons and progress bar.

    Good luck with your initiative, I really hope we’ll see some new notifications :)

  11. Interesting blog serie, I like the distinction between persistent and transient, I also agree notifications should not need more than one action.

    As the developer of Colibri, “I will watch your career^W blog with great interest!” :)

  12. My biggest problems with notifications are:

    1) mass notification (aka spam): I agree with handling it at one centrol place Good summarizing, condensing, or ignoring are really missing or redirecting to
    xsession-error ( _with_ time/application info added).

    2) One problem I missed in the list is the ‘useless’ error notification:

    file not found
    resource with same name exits

    I often have the feeling that API should _not_ support to sent just a fixed string.
    Min is 3: info text, variable text (file/resource name, %battery) and a URL or action (goto settings, filebrowser, default maybe ‘google search’)

    If it’s worth bothering the user with an ‘problem’ notification it should standard to give first aid. Instead of forcing users to find something in google, forums. etc.

    I’m glad someone it tackling the notification problem again!

    Achim

  13. Some of these issues can easily be tackled with specific widgets instead of notifications. Here is what-I-do(C). From the post:
    “Let’s consider a number of use cases:
    A file transfer finished”
    – Yes, please! I want to know when I can start working with that file!

    ” I received a new mail”
    – I use lion-mail instead

    ” A friend got online”
    – I use the ktp friend widget for the friends am really interested on status.

    ” Somebody sent me a message on IM”
    – I use the ktp conversation widget on a panel.

    ” My battery is running short”
    – Yes please! Notifications for this are never enough.

    ” An application encountered a non-critical error”
    – Sure! If the error is so frequent that it becomes spam, then the app needs fixing. -> Submit bug report.

    Just my 2c.
    Cheers and thanks for trying to tackle this issue.

  14. You are talking about transient versus persistent notifications.
    I thought that this was already implemented in the current kdelibs and plasma stuff. Isn’t it ?

  15. About avoiding spam there’s difficult to do it in notification system.
    Examples:
    user goes online: you could be interested in status changes of few declared contacts contacts (eg. it has special tag or it is connected with task “talk to” )
    new rss. there is set of rss feeds with important information being updated rarely. You want to be notified only about them.

    You want to be notified about spacial type of emails

    Etc.

    examples shows that some information are only know to application and could not be handled in generic way by notification system.

    I think that cases could be handled by something like recommendations in Plasma Active

  16. Finally! I begin to think that KDE will stick with those nasty notifications forever

  17. Some good information. Hopefully some more thoughtfully developed posts from this or an improved perspective are forthcoming.

    But you asked for something obvious you missed and here it is:

    “can you think about a concrete case (not a weird corner case) in which a notification might need to suggest more than one action?”‘

    God, if I sat here and thought about it I could come up with a million actions for each notification I’ve ever gotten. The notification implementation presently defined in KDE is just too simple. It seriously feels like I’m using a Crapple – or worse – ubuntu Unity desktop. It’s very close to completely useless right now and yet now in this post I’m looking at what looks to me to be a completely backwards (in my opinion of course) approach to a solution to making it ‘better’.

    No, no, no. This is all wrong. So first of all – to get this out of the way – there seems to be an acknowledgement that there is purportedly at least one case where more actions might be ‘suggestible’. But those are just “weird” “corner case”, and presumably only non-weird general cases are preferable. WHY. That’s not clearly explained. Secondly, if only non-weird cases are preferred, what happens to the weird case(s) that you have *already acknowledged* to exist.. Do you just ignore it and pretend it doesn’t exist? If the final proposed implementation is going to shove every shaped peg into a round hole whether it’s round or not, I would hope to at least see that there was a reasoning behind that preference.

    In other words: I think the approach to these types of problems should begin with ‘how many situations/circumstances can you think of. then add to that every situation you can’t think of.’ Not, ‘subjectively define a single narrow use case and pretend it’s the best solution.’

    Take a random real world example. Consider ubuntu’s Unity. It’s bad – very bad – for any real workflow management work and is relatively featureless and not very useful. However… There is one component that inadvertently exemplifies this correct (in my view) approach mentioned above, which is the addition of application specific file menus into its HUD. From a theoretical design perspective, the question asked is not ‘what menu actions are the most common for each application and/or how can it all be condensed into a single, oversimplified, (essentially useless) interface’. Instead, the entire menu structure is exported and the user decides on his or her own as s/he is given access to every possible defined action.

    Now as you can see, the reasoning for this approach is to allow applications developers and users to decide for themselves which actions are useful and which to use at any given time. In the context of notifications, restricting users’ and applications developers’ capacity to make decisions about utility of their own possible and available actions doesn’t resonate with me…and seeing this potential perspective crop up from within KDE is always slightly disappointing to see.

    It’s 2012. Data abstraction has never been easier in high level C++, libraries, KDE, and Qt. RAM and disk space access are increasing. Creativity is everywhere and possibilities are increasing. Desktop wide notifications specifically affect everyone in the user experience stack, not just single, narrowly visioned implementers. So why go backwards….

    • I was planning on not to answer any comments, saving discussions for the next posts, but indeed you read a “little bit” too much and deserve a reply:

      1. I am not even proposing a solution here, just doing an analysis of the situation. How is that going backwards?
      2. I never said there is NO need for more than one action, neither that all of them are corner cases – I instead challenged the readers to find out what they are on their own (some of them in fact did in the comments, with valid answers). You basically said there’s a million but… you pointed out none :P
      3. I think I was pretty clear when I said in this post I would have just done an analysis and not proposing any solution.
      4. I’d suggest saving your “narrowly visioned” epithet for when I’ll actually explain my full vision, and not just when you see a conspiracy theory in my analysis
      5. Unrelated – remember that no matter how wide you think your perspective is, you will never manage to please anyone. Instead, you should aim to piss off as less people as possible, which is already quite hard.

    • > The notification implementation presently defined in KDE is just too simple.

      > Consider ubuntu’s Unity. It’s bad – very bad – for any real workflow
      > management work and is relatively featureless and not very useful.

      Well the primary goal of notifications is to /notify/, not to give you a gazillion possible options what can you do with it. That should be handled by the application itself imho and leave the notifications “featureless”. Too many choices may sometimes be actually worse than being simple (for most users anyway).

      > In the context of notifications, restricting users’ and applications
      > developers’ capacity to make decisions about utility of their own possible
      > and available actions doesn’t resonate with me

      I believe that sometimes you just have to impose some (even smaller) restrictions, otherwise there will be a mess.

      > ..the reasoning for this approach is to allow applications developers and
      > users to decide for themselves which actions are useful and which to use
      > at any given time.

      Users always want everything everywhere (speaking from experience). So it’s up to the developers to make sensible and balanced defaults (if does not want to turn his app to a bloated over-button crap). And even after long discussions among developers these defaults might be wrong for users anyway because they are just, well, developers (experience as well).

      As stated above, thanks to those restrictions you actually make developers think more/harder about what action to put in there, which might lead into simpler&cleverer software in the end.

  18. > can you think about a concrete case (not a weird corner case) in which a
    > notification might need to suggest more than one action?

    Thinking about incoming call notifications – I think there should either be a “Reject” button next to the “Accept”, or the discard action should be made clear that it rejects the call in this case. Another thing you might want there is “Mute”, so it stops ringing while you’re running off the room with your laptop, though that’s on the border with corner cases. Still – “Accept” | “Reject” seems pretty sensible.

  19. Two things about notifications annoy me as a user.
    1) They often disappear before I have read them properly – I’d like, somewhere in the system, the ability to adjust how long they stay on screen, rather like slowing down the keyboard repeat to help with typing errors.
    2) Some notifications are so important to me that I want them to stay on screen until I dismiss them. If my battery status goes low while my attention is elsewhere it’s no earthly good telling me so for a fraction of a second. Some, of course, vary in importance per user. Again, I’d like the possibility of setting things like file transfer results to be on screen until dismissed. Options are good. I don’t want to force my needs on anyone else.
    I suspect that the same solution would deal with both of these. There is a real need to acknowledge that users do not have 100% focus on the screen at every moment. We all juggle.

  20. For the “Somebody sent me a message on IM (persistent) – Open that chat” case just an idea: Why not just display the message itself if its not too long? I think GNOME 3 is doing that and you can even reply from within the notification.

    Also this is a case where several options IMHO do make sense:
    – open chat
    – reply (with input box directly in note)
    – set status (to do not disturb for example)

    I think notififications for chat messages should respect online status.

    If its “do not disturb”, IMHO there should not be any notification at all. If you set back to “ready to chat” and messages appeared meanwhile a note should appear telling that there has been messages. Option for that would be “details”. And I think it should give some kind of a summary instead of plopping up all messages individually. This should probably go inside a window of the chat application

  21. A case for spamming I see quite some time is kernel messages: If the kernel has something serious to complain it may take a time till ratelimiting comes into place. And then each line usually is a different notifification and the formatting is less than optimal.

  22. I would suggest this one to be considered seriously because it is best idea what I have seen for any system (windows, OSX, iOS, Android, Gnome (2x/3x), Unity and so on).

    http://forum.kde.org/viewtopic.php?f=83&t=91258

    Here is his/her documentation for it http://www.mediafire.com/?fcaa8mmmh4f8m97

  23. [...] The problem – outlining what currently we don’t have or doesn’t work (all of this … [...]

  24. [...] The notifications issue – part 1: the problem [...]

  25. [...] current notifications suck and we know how to fix’em (1) (2) [...]

  26. Right away I am going away to do my breakfast, later than having my breakfast coming
    again to read other news.

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

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: