A change in status

Canonical, the company behind the popular Ubuntu Linux distribution, has announced plans to overhaul desktop notifications. The project is part of a broader initiative that the company launched earlier this year to boost the usability of the Linux software ecosystem.

Transient visual notifications are employed extensively in desktop applications to provide users with passive updates about application status or system events. Some typical usage scenarios include notifying users when they receive new e-mail, when an instant messaging buddy signs online, or when a CD finishes burning.

The current status of notifications on Linux



The most widely-used notification system on the Linux desktop today is based on the FreeDesktop.org (FDO) notification specification. The spec, which was authored by the developers behind the Galago project, describes a standardized API that can be accessed through the desktop-neutral D-Bus interprocess communication protocol to display visual notifications on the user's desktop. The authors of the spec supply a reference implementation called notification-daemon that is shipped with the GNOME desktop environment in many popular Linux distributions. An accompanying library, called libnotify, provides a lightweight abstraction layer that helps applications interact with the daemon.

Although notification-daemon is included in many distros and is used heavily by GNOME applications and many components of the desktop environment itself, the GNOME community has consistently rejected proposals to formally include it as a core dependency of the environment because it still has some technical limitations and usability issues that need to be addressed. The lead notification-daemon developer, Christian Hammond, is very busy with other projects and doesn't have much time to work on the notification system.

In October, following the release of GNOME 2.24, the GNOME community began the process of nominating modules for inclusion in the next major version of the desktop environment. Developer Colin Walters proposed notification-daemon once again and started a new discussion about its suitability. The outcome of this discussion was productive on several levels. Hammond acknowledged the need for additional maintainers to help apply patches and also proposed migrating the source code over to GNOME's subversion repository.

Last month, he announced the first new libnotify and notification-daemon release since 2007. It contains several much-needed bug fixes and a new preference tool for configuring the default notification bubble theme and position.

Canonical's vision for better notifications



As the notification-daemon project is regaining some of its lost momentum, there is a very clear need for strong technical leadership and usability expertise to help accelerate development and make notifications shine on the desktop. Canonical has identified this task as an ideal starting point for its new desktop experience engineering team.

In a blog entry written Monday, Ubuntu overlord Mark Shuttleworth has outlined some ideas for a next-generation notification system. These ideas, which are based on collaborative design discussions that took place during the recent Ubuntu Developer Summit in California, include some controversial concepts that will subtly alter the way that visual notifications are used. Although the changes will create challenges for application developers, the new approach also promises to reduce the intrusiveness of notifications and increase usability in a number of compelling ways.

Shuttleworth says that notifications should be simplified to completely eliminate the need for user interaction. To accommodate that goal, the new notification system will not support response buttons or any other interactive elements. This change is intended to reduce the disruption caused by notifications. He says that applications which require persistent notifications should use panel notification area icons and that conventional popups and other mechanisms can be used for messages that require an interactive response.

The new notification system will leverage modern compositing functionality to increase the aesthetic quality of the notification bubbles and reduce their detrimental impact on usability. On systems that support compositing, the notifications will be displayed with a translucent background so that it will be possible to see what is behind them when they obscure content on the screen. When the user moves the mouse cursor over a bubble, the level of opacity will adjust so that the bubble is barely visible. Users will be able to click through and interact with the elements behind the bubbles as if the notifications don't even exist.

These visual effects, which are demonstrated in a mockup video that Shuttleworth published this morning, are impressive and could make notifications feel like a more natural part of the desktop.





A Video courtesy of Mark Shuttleworth full size version is available from his web site.

Implementation details



To make these features a reality, Canonical will be creating a new implementation of the notification specification. It will be compatible with the existing notification-daemon in many ways and will support the same basic D-Bus API. This means that libnotify will still work with the new daemon and some applications will be able to function properly with the new system without requiring any modifications.

It will not be 100 percent compatible, however, and some applications will have to be modified. The notification spec defines several sets of capabilities and provides applications with a method for querying the daemon to determine what capabilities are supported. Unfortunately, very few applications actually take that step and many programs are designed with the assumption that the ubiquitous reference implementation is the one in use. Those applications will not work properly with the new system and will have to be changed in order to be fully compatible.

The Ubuntu developers plan to update the applications in the main Ubuntu software repositories so that they will work with the new notification system. During the transition period, a fallback mechanism will also be included to prevent users from losing functionality in applications that currently require buttons on notifications.

I discussed these plans with Canonical developers Ted Gould and Mathew Paul Thomas who are working on the notification system. They have several ideas about how to encourage application developers to make their software compatible with the new system. They also shared with me several of the technical challenges that they expect to face during the transition.

They think that getting major desktop applications to support the new system will be relatively easy, but where they foresee difficulty is in getting independent developers to update the countless one-off utilities that leverage notifications for various specialized purposes. It's very easy to write simple scripts that tie together various platform services via D-Bus and use notifications as an interface. We demonstrated how to do this in our review of Pidgin last year. Those kinds of scripts will be the hardest to accommodate and will depend heavily on the fallback mechanism until individual developers convert all of them. These kinds of custom utilities are used at some large Ubuntu deployments, including some at universities and other similar facilities.

Another challenge will be providing an adequate user experience on systems that don't support compositing. Translucency is a fundamental aspect of the design for the new notification system, but this feature requires Compiz or some other compositing window manager. Not all users can or will run a compositing window manager. On a lot of conventional hardware, this requires proprietary binary drivers, which makes it ideologically unpalatable to free software purists. The notification system will likely be designed to degrade gracefully in such scenarios but will only provide the full scope of functionality when compositing is available.