One of Jaunty’s more controversial new features was the new notification server. It’s easy to decry as something Canonical pushed unilaterally, breaking a lot of GUI software and requiring fixes for unclear gain.

I’ll admit: I can see areas in which notify-osd can use improvement. At least the bubble background and text color should be customizable (not everyone likes black), as well as their position — they should at least be bindable to any of the four corners of the screen.

Yes, Jaunty shipped with an uncustomizable notification server that, at first sight, seems like a major regression from notification-daemon (no custom positioning, no actions, no clickable links…) and requires a custom GNOME session to replace. But while it may not have been completely polished on Jaunty release, from my (a mere user’s) point of view, I believe it’s a step in the right direction.

First, let’s be honest here: many applications, especially outside of the official GNOME set, didn’t have a well-thought-of concept of usability regarding notification bubbles. I pretty much agree with most of the usability concerns put in the notify-osd wiki articles. For me, a notification bubble is a signal that “something of interest happened”. I don’t usually read into them — I just scan them quickly with my eyes and switch to the application. Displaying a notification bubble indefinitely and expecting a user to click a button is just unwieldy.

Second: uniformity. I can’t stress enough how important this is for a professional feel. I know there are people for whom free software means, first and foremost, freedom of expression. So let’s have ten widget toolkits, five notification systems and innumerable icon themes that all look at odds with each other. The consequences of such a mindset can be seen most prominently in, ironically, Windows. With even Microsoft changing its aesthetics radically with every release (compare different versions of Office and Visual Studio), if the king does not lead, how can he expect his subordinates to follow? Add independent proprietary software developers each trying to make their application visually stand out with bling, older software retaining the Windows Classic theme, and we have a recipe for an eclectic mix that doesn’t feel like a cohesive desktop environment at all.

But let’s head back into the desktop Linux world. There are GTK and Qt, plus various more obscure toolkits — they’re of little interest to me, especially given that some (like wxWidgets) act as wrappers around the mainstream toolkits or emulate their look. But even two toolkits are troublesome on their own — how are you going to explain to Aunt Jane why that shiny DVD creator she has just installed looks so different from the rest of the desktop? That’s why, as a GNOME user, I regard the inclusion of qgtkstyle in Qt 4.5 as probably its single most important improvement in the X11 version. Common GTK users will have their uniformity by default, advanced users can install qt4-qtconfig and go from there, and for KDE, of course the issue is backwards.

Even among a single toolkit, guidelines exist to ensure that applications behave consistently. You can have varying opinions on the GNOME HIG and its practical implications, but you can’t really deny its clarity, internal consistency, and logic. There is nothing in GTK itself that stops you from placing the Help menu on the leftmost side of the menu bar, but should you really? Similarly, when I open the About menu, I have every right to expect that I’ll be shown the standard GTK about dialog, not the developer’s custom creation. This is actually important enough for me that I started filing bugs about HIG non-compliance, and some time ago joined gtkpod’s upstream development specifically to revamp its aesthetics, including the icons, about and preferences dialog, to make it feel more in place in a GNOME environment.

So, we have the GNOME HIG for general application behavior, the Tango guidelines for icons (I don’t use the default Tango or Human theme, but a custom ones following the guidelines, and it integrates well), and freedesktop.org standards for interoperability, including the notification specification. I don’t understand why KDE has its own notification system instead of implementing the standard, although they might have a good reason — but this doesn’t help interoperability. But the specification only defines what applications can expect, not what they should and shouldn’t do to be consistent. As it turns out, many fail even at expecting: they expect a specific implementation, notification-daemon. The Ubuntu developers weren’t out hunting for “non-compliance with notify-osd” — from what I understand, they were out finding such implementation assumptions, such as expecting support for actions, and making the applications behave with different implementations, including notify-osd.

In fact, I’m seeing the Notification Design Guidelines as Canonical’s more important contribution to this area — that is, more important than notify-osd. Why did they define these guidelines? Because nobody did it before, and nobody had a clear idea how notifications should be used. This is an important step on the way to a uniform, cohesive desktop, no matter what notification implementation is used.

As for notify-osd itself, it’s a question of taste. I hope it will eventually become configurable enough to mitigate some of the common complaints, and of course the default behavior of affected applications could use some improvement. I don’t know anyone who would like the proverbial example of Update Manager popping up — the old behavior with an icon and notification bubble seems more sane to me, even if the bubble is unclickable now. What notify-osd really succeeds in is making notifications looking consistent with each other and, let’s face it, slick. While it’s hard to define what a slick desktop or application is, for me, it means sensible intuitive layouts, with eye-capturing graphics and putting emphasis in accordance to how important or commonly used the information is. For applications most prominently following this kind of philosophy, of those I know, I can name Qt Creator, Brasero, GNOME Do, and now notify-osd — all displaying stark contrast to traditional “Windows-like” layouts.

On my quest for consistency, I’ve started looking for ways to make all notification popups go through notify-osd. That’s why I welcomed the experimental Firefox notify extension, why I’m looking for the Thunderbird one to exclude notifications of Gmail spam so I can actually start using it, and why I rebuilt Quassel without kdelibs to enable support for freedesktop.org notifications. Because order matters.