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.

~ by Dario on 19 July, 2012.