Unify and Notify: Shuttleworth Explains Proposed Notification Changes

If you were unable to attend (or follow along with) the events at the Ubuntu Developer Summit, the highlights and more controversial proposals are now being discussed in the wider community.

One proposal for Ubuntu's Jaunty release was to unify notification display and interaction between GNOME and KDE. It's an idea that's been met with nearly every reaction imaginable, but Mark Shuttleworth has a very reassuring post on his blog that explains some of the reasoning behind this proposal.

I am going to share my own little bias here: I find notifications that require action irritating, but they're rather low on the list of life's irritations. I find the idea that I might not be able to make a notification go away exactly when I want irritating as well. Again, low on the list of annoyances, and it's a sad fact of life that I can't have everything both ways.

Higher on the "irritating" list are two far more important things, and Shuttleworth addresses them in a straightforward, honest manner. They have little to do with notifications, and everything to do with developing software in the smaller sense, and having a successful project in the larger sense.

Shuttleworth calls these proposals "constructive experiments" that have as much potential for success as failure, and its not really possible to tell what the outcome will be until everything is tested, and the data and input collected and analyzed. Unlikely ideas can work surprisingly well, and concepts that seem sure-fire winners can turn out horribly wrong. Getting vested in any of these ideas, or writing them off prematurely, sells the software (and ultimately, the users) short.

He establishes that these are experiments -- not done deals, not foregone conclusions. That's a great approach. He also states that these experiments should be positive, successful, first time around, and that if mistakes are made, they should be called as such:

"...We should not inflict bad ideas on our users just because we’re curious or arrogant or stubborn or proud. Despite being occasionally curious, arrogant, stubborn and proud..."

If I can't have the notifications both ways, there is comfort in the idea that if the approach is fundamentally flawed, those involved and affected -- from the user, through the developers, all the way up to Ubuntu's founder, are willing to acknowledge and fix mistakes, or rethink the idea entirely.

That being said, this proposal is less likely to impact the end-user as it is application developers. Notifications being simply notifications -- not critical messages -- the idea that the messages simply appear for a time, and disappear without requiring action (with multiple messages queued for display one at a time) might take a day or two for an end-user to adjust to. The older notification system, Shuttleworth says, will be offered in upcoming Ubuntu releases so that users can test these against each other -- and choose the one they prefer.

Developers with applications using existing notification methods might balk a bit more. There is some consolation here, though. The proposal is based on a specification that's been in the works in the freedesktop.org community. Some features in the notification spec are deprecated, Shuttleworth says, but overall, the proposed changes for Jaunty will be compatible with current notification APIs. Shuttleworth doesn't foresee libnotify needing any changes, although there may be some additional work needed to make alerts that use features the proposal deprecates display through the libnotify API.

Another bright spot for developers: common code is good, but native desktop framework is still very important. The goal for the new notification agent is that it can be built with Qt on KDE and GTK on GNOME. This way, there is a significant amount of streamlining, but the system will feel -- and behave -- "natively."

The proposal -- and the reactions -- highlight how small, almost "thoughtless" sorts of desktop behaviors make the user experience, and how crucial it is to think through every last behavior and interaction, no matter how trivial it seems. The beauty is that this is being done with this proposal, but what makes it as near perfect as a developing project can be is the openness of the discussion, the transparency of the process, and the opportunity users and developers have to participate, or simply watch and learn.