Followers

Thursday, December 25, 2008

Understanding Canonical's new Linux notification system

By Ryan Paul

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.


Video courtesy of Mark Shuttleworth
A 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.

Cross-desktop interoperability


I also learned about Canonical's plans to bring this new notification system to KDE. Gould says that Canonical is actively seeking a KDE developer to join the company's interaction and design team. He suspects that the new notification system will be ready for preliminary testing in Ubuntu 9.04, codenamed Jaunty Jackalope, which is scheduled for release in April. The KDE version, however, will probably require an extra release cycle after Jaunty. Shuttleworth says that, ideally, he would like to have both the KDE and GNOME versions delivered simultaneously.

KDE developer Aaron Seigo has written a blog entry commenting on Canonical's plans. KDE 4.2 introduces its own notification system that integrates with the Plasma desktop layer and is based loosely on the FDO spec. The KDE developers had to deviate from the spec in several ways in order to meet the needs of their desktop environment. Canonical has an opportunity here to work with the KDE community to help bridge the gaps and build a solution that will be fully interoperable between the two desktop environments.

"I'm hopeful that soon all FOSS desktop apps (KDE, GNOME, Mozilla, etc) will be able to show their visual notifications in a way that integrates well with whatever the host desktop shell is. The rough goal we talked about on IRC is by the releases in the second half of 2009 to be sharing something, with the possibility of even making it happen in the spring releases," Seigo wrote.

Shuttleworth speaks

Shuttleworth addresses many of the potential technical challenges in his blog entry and also provides some insight into the philosophical basis for the new changes. He acknowledges that many of the new ideas are unproven and will require testing and experimentation before they are ready to be adopted upstream. Using the Ubuntu audience as test subjects will allow for the system to be refined and evaluated before it is adopted more broadly. He plans to work closely with upstream developers to make sure that it will serve the needs of the developer community and end users.

"Some of these ideas are unproven, they boil down to matters of opinion, but since our commitment to them is based on a desire to learn more I think of them as constructive experiments. Experiments are just that—experiments. They may succeed and they may fail. We should judge them carefully, after we have data," he wrote. "We are putting new ideas into the free desktop without ego. We know those ideas could be better or worse than similar work being done in other communities, and we want to gather real user feedback to help find the best mix for everyone."

He also encourages users to keep an open mind and be patient with a deviation from what is shipped by upstream projects. Many users tend to dislike when distributions include experimental components that are significantly different and perhaps less functional than the stock components. Shuttleworth hopes that users will understand the need for experimentation and will provide constructive feedback to help improve the new notification system so that it can be adopted universally.

"So, for those folks who were upset that we might ship something other than a GNOME or KDE default, I would ask for your patience and support—we want to contribute new ideas and new code, and that means having some delta which can be used as a basis for discussions about the future direction of upstream," he wrote.

He also reveals that the new notification system will probably be shipped during the 9.04 cycle on netbook products by at least one major hardware vendor.

Conclusion

There is considerable room for skepticism about several of the changes proposed by Canonical—particularly the decision to abandon action buttons on notifications—but the ideas are very intriguing and it's clear that the proposal was crafted with immense care and impeccable attention to detail. It will be a fascinating experiment and it could provide valuable insight into potential solutions for a variety of related usability problems.

I was also very impressed with Shuttleworth's honesty and the thoroughness with which his blog entry addressed a multitude of foreseeable issues and concerns. This demonstrates a laudable willingness to supply the transparency that will be needed to make the project a success. Although I think that this is a very good start, there are also some areas where Canonical needs to improve its collaboration skills.

Seigo points out in his blog entry that Canonical should have brought its thoughts about desktop notifications to the FDO mailing lists from the very start before assembling a grand vision for sweeping changes. Similarly, it's disappointing that Canonical hasn't been participating in the ongoing discussions about the future of notification-daemon on GNOME's desktop developer list.

All things considered, I think that Canonical's plans for a desktop notification overhaul will be very positive in the long run. Even if some of the specific ideas don't work out, a lot of valuable things could be learned along the way. This is definitely a good area for Canonical to be contributing and it will be fascinating to see the end result.

Original here

No comments: