The notifications issue, part 3: the (possible) solution

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

Preamble about this post

First of all, an obvious apology for the delay. Unfortunately, I got sidetracked by many other things, and this post kept being delayed for any possible reason. But, what matters is the result, isn’t it?

Then, I’d like to clarify the following: this post is mostly about the concept itself and the way the user and the applications interact with the notifications – I am not the best person to talk about UIs, as you might know. So yes, you will see mockups, but please refrain from commenting on the UI aspect because I am not even trying to modify it – their purpose is merely to showcase the concept and the interaction.

Last but not least, you might find yourself saying “this can be done with the current API as well!”. It is in fact true – however, consider that what we are trying to do here is not to find out what is currently wrong with KNotification and friends (see part 1 for that), but to create a full new concept which goes beyond the API itself. Everything else is an implementation detail which will be eventually sorted, either with a KNotification replacement or extension.

Ah yes one last thing: I am assuming you are familiar with my previous blog posts – I won’t re-explain pieces of terminology such as transient and persistent.

That said…

Notifications as a living object

A new API is meant to be used for taking advantage of this new solution. We are used to have notifications be a one-shot mechanism after which we simply forget about them. This can and should still be possible for the most basic case, but what we really want to have is a living object, which exists during the lifetime of the notification. The reason why is quite simple, and it’s one of the things I can’t stand in the various notification systems we analyzed in “the status”.

Suppose you have a “1 unread mail” notification. Instead of clicking on the notification itself, you open KMail, and click on that unread mail. What should happen is that the notification reacts and solves itself after the event has been triggered. This is the basic preamble for the rest: a persistent (transient notifications of course are just a one-shot trigger) notification should be made persistent inside the code of the application itself, and the application must actively interact with the notification.

Grouping for efficiency

Grouping is one of my favorite topics and of course it had to be in. At the moment, grouping is a massive fail and can be solved only in a single way: on the server side. Relying on application for grouping is not a great idea, and kills the concept of being consistent – especially because we can afford to group on the other side.

This kind of grouping I am about to discuss applies only to persistent notifications – a separate section for transient notifications will follow, since the rationale behind both is quite different.

There is one single thing the application has to declare: the types of notifications it will be able to spawn. And this is already there in KDE, in the form of notifyrc files. This allows our server to detect how many events of a specific kind we are going to get. In this regard, we are going to get a notification like:

The main question one could ask himself would be: how do I detect the text then? This is a problem which KDE already solved with i18np, for example, which allows you to give two options for a string, depending if the occurrence the string is referring to is plural or singular. An hypotetical API call could be:

CoolNotification *not = CoolNotification::newPersistent(IMApp::NewMessageEvent, i18n(“%1 sent you a message”, contact), i18n(“You have %1 messages”));

Disclaimer: not meant for real API usage.

The drill is quite simple though – this not only allows our server to stack and group the events efficiently, but also to display the right “singular” message if all notifications but one resolve.

Grouping for spamming

This applies to transient notifications instead. The “hypotetical API” and result would be pretty much the same, but the rationale would be completely different. Suppose 40 of your contacts come online at the same time, or your application fails 40 times in a row – I guess you don’t want to be notified forever. The main difference is that in this case we would group only if we detect spamming. For example, we would refrain from grouping if 2 contacts come online in 5 seconds, even if one notification has not resolved yet. The main purpose of this would be to avoid clutter.

Grouping for activities

Some of you already predicted this – yes, I believe activities can really help in the way we perceive and interact with notifications. Let’s get back to our previous API call:

CoolNotification *not = CoolNotification::newPersistent(IMApp::NewMessageEvent, i18n(“%1 sent you a message”, contact), i18n(“You have %1 messages”));

Now, imagine CoolNotification was smart enough to tell the main server that the application sending that particular event belongs to a particular activity. Or, let’s try even harder – suppose your application does not belong to an activity but your contact is. Maybe the API call might look something more like

CoolNotification *not = CoolNotification::newPersistent(IMApp::NewMessageEvent, i18n(“%1 sent you a message”, contact->name()), i18n(“You have %1 messages”), contact->activity());

Now, let’s assume you are working hard on a project you have to deliver tonight. And contact happens to be your girlfriend/boyfriend sending you some “<3<3<3<3<3<3” over Facebook. Ok, maybe not now. BUT. Your partner is actually associated with your “Leisure” activity, while you’re hard at work in your “Work” activity. What if you got something like that:

Not only – you would get a “reminder” just once. What happens when you click on the notification then? Your context is switched to the “Leisure” activity and the notification is expanded onto the grouping you would instead expect and we described before. And what about transient notifications? In this case, we would simply discard all the transient notifications which have spawned on other activities, as Facebook taught us in the previous post. In fact, I doubt you’d be interested in one of your friends coming online, but you might be in case your boss logs in onto your company’s jabber.

Grouping for backlogs

One of my favorites. Just like any other social network does, we want to keep a backlog of events. As such, we can easily “roll back” to an action we wanted to undertake before (or we actually undertook) and revise it, or do it again – such as reading a mail or talking with somebody. This requires some work in designing the API and for enabling application, but for sure it would be desirable to have something like this:

Integration with the outer world

Aren’t you tired of having your notifications scattered around your browsers, desktops, and whatevers? What if your backlog looked something like:

A big challenge would be trying to integrate all of your events into a single source – your notification area. Is this another step towards the “social desktop” and web integration? You betcha.

Integration with the inner world

Of course, it is important to integrate the other way round. Up to now, my mockups might have tricked you into believing that notification == bubble in some corner of the screen. But that’s very far from my plan.

If you follow my various work in the open source realm, you also know my commitment and passion to the Telepathy project. Telepathy has the peculiarity of being completely modular, by having a channel dispatcher (mission control) and a set of channel handlers. This means that whenever a specific channel request is received, mission control takes care of choosing the most suitable handler between those available.

Why is this relevant? Because I plan on porting the concept of dispatcher+handlers to the notification world. Let’s suppose for a moment that we have 2 main components: the notification server, as our dispatcher, and the notification applet, as the “fallback” handler. Now, every application can register itself to the server via DBus as a handler for a specific set of notifications:

int handler = CoolNotification::registerHandler(this, TypeList() << “newmail” << “error” << “etc”);

CoolNotification::setHandlerActive(handler, true);

Why setHandlerActive? For example, we might want to have our application acting as a handler only when it grabs focus (this could be and actually should be automatic in the final API. But we are just trying to expose the concept here). Now, whenever our server detects a new notification of some kind, it will check if a specific handler is available before falling back to the default one (the applet). If so, the notification will instead be forwarded to the application instead of the applet, BUT it will still feed the backlog. This means, for example, that KMail could display a neat animation upon a new mail whenever it has focus, and save the user from a (in this case) useless bubble.

But there is more: what if rekonq or any other web browser could act as a handler for social notifications (see previous paragraph)? For sure new interesting means of interaction can be discovered here!

Interaction

I saved it for last due to the highly controversial topic. Before we start with this, let me do a preamble: as a clever friend of mine uses to say, there is no way to satisfy everyone, there is instead a way for pissing off the less possible people. And more than this, there is no right solution, but in the specific case there is a solution which in the end might integrate better than others.

That said, I strongly believe our future notifications should have no buttons, which means one single action: Interact (like we have seen in Google+). This because 90% of the cases we want to cover are satisfied by this specific paradigm. What about the rest, you might ask? It is true that some of the notifications we know (incoming call) require more than 1 action – the challenge is to find a way to make this irrelevant by having the application itself (call ui in this case) be able to cope up with a single action.

But there is more – think Active. In an environment like Active (or a mobile shell) we cannot afford to have a notification with more than 1 action, given that pushing a small button is out of discussion. As such, we want to find a mean of interaction which works well on any platform.

We might find out during the road that we were wrong, but up to know we really want to strive for having a single mean of interaction for every action.

What’s next?

Code! Of course all of this should be shaped into something real, possibly into a new framework. You might have more news shortly… who knows 😉

…and it’s over!

I hope you enjoyed this little series. Of course, your feedback, ideas and suggestions are much more than welcome in the comment box below. I will keep you updated on what is going to follow and when you’ll (maybe) be able to see all of this on your desktop, tablet and more!

~ by Dario on 17 September, 2012.