Archive for January, 2011

Notifications with Character

Friday, January 7th, 2011

The message tray in GNOME Shell enables persistent notifications. A new notification is first shown as a pop-out for a certain time period. When the pop-out is hidden, the notification is still available to the user in the message tray. The notification is only removed when the user interacts with it or switches to the application that sent it. This default persistent behavior ensures that the notifications are less disruptive to the user because the user is no longer forced to react to them before they time out.

Before the holidays, I finished implementing support for two other types of notification behavior: resident and transient. Resident notifications are available to the user even after the user has interacted with them or with the application that sent them. On the other hand, transient notifications are not kept around for the user at all after they are initially shown.

Jon McCann has updated the Desktop Notification Specification to expose these new features to applications. The “persistence” capability advertised by the notification server means that the notifications are persistent by default and that resident and transient notifications are supported. “resident” and “transient” hints on the notifications are used to mean that the notification should be resident or transient.

Resident notifications often go along with rich controls in notifications. Rhythmbox notifications are a good example. During his GSoC, Matt Novenstern came up with a way of specifying icons to be used as notification’s actions, enabled this feature in GNOME Shell, and wrote a patch for using icons for the playback buttons in Rhythmbox notifications. Jon has updated the Desktop Notification Specification to reflect this feature. When the notification server has the “action-icons” capability and the notification has the “action-icons” hint set, named icons that match the action identifiers are used for the notification’s action buttons.

Putting it all together, Jonathan Matthew has reviewed and pushed Matt’s patch for playback icons and made Rhythmbox notifications resident. Resident behavior of Rhythmbox notifications allows the user to see what’s playing and use the playback controls at any time. Incidentally, Jonathan has also worked on the GNOME Shell side of things, coming up with the initial patch for the resident notifications support.

Empathy chat notifications are also resident in GNOME Shell. Because they allow chatting inline in the text entry field they contain, making them resident enables the user to continue a conversation at any time.

The resident behavior and rich features of Rhythmbox and Empathy notifications help minimize the distraction from intermittent events. They allow the user to react to such events at the user’s own convenience and without switching away from the window the user is working in.

Applications should use resident notifications if they are so heavily notification based that the user would expect to see a notification in the tray most of the time and use the application by interacting with its notification’s rich features. In this case, the user should be able to reliably find the notification and not have to guess if there is one in the tray or not.

The other new type of notifications, transient notifications which don’t stay around in the message tray, are mainly intended for use by the system components that have a permanent representation elsewhere, such as in the system status area in the top panel. For example,  non-critical battery information notifications are transient.

Transient notifications can also be used as a feedback for the user’s action within the system. For example, they are used when the user adds or removes a favorite application in the Activities Overview mode and allow undoing the action.

Persistent and resident notifications enable complete interaction between the user and the application using only notifications. In GNOME 2, authors would use GtkStatusIcon to anchor the information shown in the notifications, but this is no longer necessary and the applications should move away from the GtkStatusIcon usage. The suggestions for individual applications and system components can be found in these compatibility guidelines. Please find us on #gnome-shell IRC if you would like to discuss the use of the notifications by your application in GNOME 3 or help out with the message tray features.