The notifications issue – part 2: the status

Howdy,

welcome back!

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

About the previous post

It was great to see interested comments and most of all actual replies to my questions. I want to clarify a couple things before moving on:

Some of you mentioned the existence of indicators, Colibrì and such. No worries: I know about them and of course they played a big role in my analysis. Though, I intentionally left them out of my problem analysis since they’re not a part of the stock KDE framework, and we want to aim for a solution which somehow “integrates” everything in one single place and API

I got some great answers to the “more than one action question”. Especially, several people agree on the “invitation” (I really like the name, credits to TheBlackCat) to A/V calls. We’ll see how they scale as we go 🙂

Also, Celeste pointed me out a usability study she is promoting targeted towards finding out how to make the notification system better. Needless to say this is also very helpful for the project you’re reading about, so I encourage you to spend some minutes of your spare time to help out. The link is above, but in case you read through it, here it is in its full glory: http://community.kde.org/Projects/Usability/KDE_Notification_User_Experience_Study

Preamble about this post

Those of you who might have come here getting ready to read a comparison between GNOME, Windows, Mac OS, etc. will probably be partially disappointed in seeing that my primary case studies actually do not belong to a desktop environment. Why, would you say, since this is what we’re trying to address? The first and obvious answer is that KDE is no longer “only” desktop, and needs a concept which scales. The second one is that (not even that) surprisingly, completely different appliances have the same needs and the same problems to address. After all, when you come to think about it, a notification is just… a notification.

WARNING: Long post is long.

Facebook

We will start by analyzing Facebook first. It is a great example in many ways, and a bad example in other ways, and we will now see why. First of all, let’s take a look at the basics. I guess all of you know the system fairly well, but I found a couple pictures which are especially valid for showing you what I want to show you:

Let’s start analyzing the picture. First thing we notice, Facebook is split in 3 areas: friend requests, messages, and other. First question – why the heck do I have a friend confirmation on my “other” stream? I’d expect all friendship-related activities would go in the “friend” area.  There is a reason for that, though, and it makes sense to me. Also, you might have noticed that this screenshot is from an old version of the system – intentionally. I want to try to focus on the differences and on the evolution.

Now, notice the left bar. We see that we have Messages and Friends again. Does it make sense? Why is that? To be honest this is a part I don’t like, since it’s a duplication of information, but it helps in proving a point: friends and messages are stuff on which you want to take an action, which might be delayed, but still needs to be undertaken. On the other hand, you can disregard and not be reminded of the fact that $GUY is stalking your pictures.

This is a child of the “transient vs. persistent” issue. In the web world, the concept of transient notifications almost doesn’t exist after all, but here we stepped over a similar principle: prioritization. Facebook clearly tells us that some events are more important than others, and should be considered in a different way. Coming to think about it, isn’t that also partly true for your desktop?

But the reader might now think: then maybe the whole transient deal is just bul^Wcrap. Not really – the reason is that a web application such as Facebook cannot really have such a concept since it acts in a disconnected way most of the time. But in that list, for example, I’d rather not have a persistent notification everytime someone “likes” my post. Ok, it sets my ego on fire, but it can become annoying. That’s a case where probably a transient notification would have cut it better.

But, let’s move on with our analysis.

Ok, that’s something more recent. What changed? The first impact would say “The picture on the left”, which is correct. But to me there is something much more important: grouping. Notice how before we had a notification about “X commented Y”, whereas now we have “X,Y,Z and other stalkers commented W”. There is also something else which gives grouping even more sense, you can notice it on your account: a small “x” icon on the top right of every notification. I understand it’s not really discoverable, and also its purpose is weird: if you hover on it, you’ll see a label “Unfollow”. In fact, clicking that button will simply stop giving you notifications about that specific post.

This is quite awesome in my opinion – not really for the feature itself, which I consider quite undiscoverable and barely useful for most of the audience (probably the reason of its discoverability), but for showcasing the power of grouping. Not only I will get one single notification for any event happened in a particular stream, but I also have a single entry point for deciding not to be notified of a particular stream anymore. In particular, there is something really significant here if you compare this approach with messaging: we are now used (thanks to mobile phones which now find fancy to arrange SMSs by conversation [yes I know threads existed before that but I’m considering what IMHO made them mainstream</hipsterism>]) to consider messages in the context of a thread.

Slowly, we are starting to consider events in a thread as well, where a starting point (in this case, a post) leads to a chain of events belonging to the same thread. To counter the obvious “posts can be considered behaving as messages”, sharing notifications and like notifications work in the very same (threaded, grouped) way.

Also, this leads to a MUCH lower number of notifications, and *uh oh* introduced somehow transient notifications in Facebook! If you notice, now everytime a notification enters your stream, you get a nice bubble on the bottom left, sitting there a couple seconds. The behavior of this thing is really interesting and worth a study.

This picture is good enough for showing you what I am talking about, but not for proving my point in its entirety. Suppose a new event happens, $GUY comments a picture of yours. The bubble will appear and a notification stacked. You can directly take the action by clicking on the bubble itself, including discarding (the X is much more discoverable here, imho). In this case, the notification will disappear. But there’s more to that, and here comes the concept of a transient notification.

Suppose you weren’t at your PC, you come back and you see a “1” in your “other stream”. Now, another guy comments. The same bubble appears, the notification is grouped, but “1” remains “1”. This is as close as a transient notification can get, since you will just notice 1 notification if you weren’t in front at your PC, but you would have witnessed a whole stream of comments if you were sitting right there, and you could have taken action on any of them. Instead, the “root” notification will just bring you to the first unread comment.

Also, the “x” in the bubble behaves in a very different way: instead of unfollowing the related stream of events, it simply “silences” the notification.

Enough with Facebook? Not yet, there is one last thing.

I am sorry I couldn’t find a better picture, but as you know the notification area looks exactly the same as this screen. What is weird? Yes, interaction. We’ve seen how Facebook is keen on having us clicking the notification to pursue an action, but here we have 3 choices:

• Look at his profile
• Accept
• Reject

I think it’s bad. It’s really inconsistent with the rest of the interface, and kind of breaks the paradigm we’ve seen in the rest of the system, which in my opinion remains really good.

Google+

Google+ notifications are a very good case study for tackling the two weird things we found in Facebook: the separation between events (G+ has a single notification area) and the interaction. Let’s see why.

First of all we notice two obvious things: the grouping is even more aggressive: the “Friend” area of Facebook has been shrinked to a single grouped notification (this is closely related to how interaction works). Secondly, the layout helps the impression of grouping by showing a visual feedback of roughly how many events the notification refers to (by showing a set of pictures, or a “stacked” set of pictures). But the way one interacts with notifications is probably the most interesting part of G+:

Clicking on a notification brings up a full interface to the event that notification would have led to. This solves in a very interesting way the issue with interaction. Usually, the chain of arguments is that you need more than one action, you need a lot of them since otherwise the problem would be made worse, as instead of having one clear thing to do, you would have to cope with a downscaled interface for making your choice. There I fixed it: now you simply have your whole interface to deal with. But when we port this to our case (KDE), we should ask ourselves: is this that much different than opening a new window?

My answer is: not that much. The reason why people like this approach is that their workflow is not interrupted in any way – they can check out the event, maybe even reply to a message, then they can close the notification area and – bang – back to where they were. In a way, we can say that every G+ notification has one single action: “interact”.

Bored with all this social crap? Time for…

The N9, or: the mobile world

I am intentionally considering only the N9 since it’s the only smartphone I know really well (since I use it daily). I won’t be as long as before, since many things are just the same as before:

• The N9 groups events: you get a single notification about having 5 sms incoming
• The N9 does something very close to Facebook about transient/persistent notifications: you get the equivalent of the “bubble” which is instead a small banner on the top of the screen. The behavior upon clicking/stacking is exactly the same
• The N9 allows a single action a-la-G+: when you act on a notification, a full interface is brought up for you to choose how to interact with it.

There are, though, a couple really interesting things in the N9. Let’s have a look at them.

Oh, how much I love this. The notifications on the lock screen really just cut it when I check my phone for events. And what about swiping on them to activate the notification itself? Just amazing.  This really shows how it is possible to make notifications an integral part of your experience when you are “offline”.

I am really sorry I couldn’t really find a picture for the next thing I want to show you. Some of you might know the N9 integrates its notifications with Facebook ones, basically showing notifications from Facebook as native. The interesting part here is that the grouping happens in a completely different way. A typical example of notification you might get is:

• 3 new notifications
• 4 new messages
• 15 new friend requests

Whereas for the “global notifications” it doesn’t really make sense, it is really interesting to see that the “new friend requests” grouping is incredibly close to G+ as a concept, and acts in the same way.

Differences

Those three cases quite cut it in my opinion, and really help in showing mutual similarities and differences. In particular, we’ve seen how G+ tackled the concept of notifications in a way which is really close to the mobile world: a notification opens an application. Sure, the interface is different, but the principle remains – instead of giving the choice of taking a stock action, it leads you to a richer interface in case it’s obvious that you might want to undertake more than one choice. Facebook does this when it comes to messages and posts, but fails in applying this concept to friend requests – probably on purpose.

Recap

So what did we learn today? That the outer world already found several possible solutions to the problems we have previously outlined, and somehow faced most of the challenges we are up to. The circle is about to close with the next blog post, where I’ll try to gather what we learned up to now and try to come up with a concept which might, eventually, become the guideline for a new notification system in KDE. While you’re waiting, are there any other existing notification examples you’d like to point out? And thanks for reading until here, that was indeed a long run.

~ by Dario on 31 July, 2012.