Illegitimi non carborundum


Desktop Notifications and User Interaction

For many years now I've been following the work done over at Galago Project with regards to the Desktop Notifications Specification.

I've never been a massive fan of the design of these popups and have followed work done in AWN and other systems to produce more attractive alternatives, but these always turned out to be a little less than satisfactory. I have toyed with the idea of writing my own implementation (or just a style for notification-daemon itself as it is pluggable), but never really had time to focus on this.

So it was with considerable delight that I noticed MacSlow's latest blog post about the work he was doing on notify-osd. Once I remembered that he's now working for Canonical and I recalled an article on Mark Shuttleworth's blog a while back on which I commented, I realised that I actually had a bit of beef with the approach being taken by Ubuntu...

Now let me clarify. I've followed MacSlow's work for years and I've got about as much respect for him and his work as it's possible to have (not to mention that we've had several very pleasant conversations on IRC in the past too) but I can't help but feel that Canonical's approach here is just very wrong with regards to their approach to notifications.

To explain, the Desktop Notifications Spec is a DBUS standard which allows for the display of passive popups to alert the user of interesting events that have happened (and IM buddy signing on, a new message on IRC, a remote computer trying to connect to your machine, a new email etc.). One of the really useful features it has is an "actions" callback scheme where the app displaying the notification can register some actions which allows the user to interact with these notifications.

I am planning on using this scheme to implement a simple UI in pulseaudio to inform the user when a new audio device is discovered and give the user the option to make this new device the default and move all the currently playing sounds across to it. This would be a typical use case scenario when a user plugs in a new set of USB speakers for example.

In other areas of general desktop use, I use the notifications a fair deal. I have pidgin configured to pop up a notification when my friends login. It provides an action callback so I can open a dialog window to start chatting with the friend in question. This is really useful. Ditto for say a new email notification - I'll only get a small synopsis and it is a serious feature deficit if I cannot interact with that notification to open that mail in my mail client for full viewing.

In his blog post I mentioned earlier, Mark talks about how Canonical are going to create their own notification daemon implementation that will not support these "action" callbacks. This in itself is fine and the Desktop Notifications Spec does support such implementations through a "capabilities" query. However, this does set a bad precedent. The Ubuntu wiki contains HIGs that talk about how to cope when your notification daemon cannot handle actions. In principle, this is good advice, but the advice talks about how to make your application pop up it's own window (the "Alert Box"), that doesn't "time out" the same way a notification can. It is this point that I have a serious problem with.

One of the great things about this spec was it provides a standard way of achieving simple user interaction in a standard but themeable way. Encouraging applications to "do it their own way" is going against this common approach. I come from a very Desktop Environment agnostic stance. In other words I don't particularly favour GNOME or KDE or whatever. I'm currently using KDE but that's only recently become the case. I use a fairly healthy mix of GTK and KDE apps in my daily operations. By encouraging application developers to cope with the case when a notification daemon cannot do actions by implementing the interaction themselves, we are setting ourselves up for a massive amount of diversity in the look and feel of such popup windows. Each app will do things slightly differently, and when you move across to an app from a different desktop system, it will be unfamiliar to the user and the whole desktop experience will be less consistent.

OK, KDE has not implemented the Desktop Notification Spec yet (it's been discussed and it'll just take someone to do it - unless I'm a bit behind and there is a solution already...) and they use their own knotify system for such popups. It has similar abilities to be able interact with users via simple actions too AFAIK (I've not looked closely), so it should be pretty trivial to make knotify integrate with the Desktop Notification Spec.

The whole point in HIG is to help make things more consistent and usable. This is a laudable goal and one I would encourage whole heartedly, but sadly, Ubuntu is just thinking in a very GNOME centric way here. It's giving no thought to cross desktop consistency and even to cross application consistency. Implementing action callbacks is a breeze with a notification daemon that supports it and you could be sure that the user would be comfortable with this approach to interacting with applications.

So what to do? Well I would certainly discourage using notify-osd until it can be made to support actions. This is really galling for me as the popups are by far the most attractive implementation of this actual notifications I've seen so far!! I would also encourage upstream application developers to not code their own workarounds for a lack of notification daemon that supports actions - let the user suffer if it doesn't support it! And please, please, don't code your own popup windows for this kind of interaction with the user. Whatever you do will be inconsistent with other applications and desktop environments.

For their own sake, I really hope Ubuntu and Canonical realise what a mistake they've made and that someone will come along and make an equally slick implementation of the spec that does support actions.


Share and Enjoy:
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Slashdot