This is a work in progress! Contributions/comments/criticism are welcome!
Contents
This is an idea for how to redesign the GNOME notification area. It has similarities with a few other things that are out on the web. The principal aims of the design are to clean up the notification area, to instill a sense of the desktop as an assistant, and to make using the desktop a fun, enjoyable experience [1].
Mockups
System menu and notification dialogue
Action required, notification pop-up
Design elements
Notification area
- The notification area is preserved.
- Very few icons in the notification area.
Notification icon
- Located in the top right hand corner of the screen - making it easy to hit with the mouse cursor.
- Notification pop-ups originate from the icon.
- Clicking the icon activates the notification/system menu.
- The notification icon is dynamic [1]:
- It changes appearance in order to display particular kinds of notifications (those which require the user needs to take action - software updates, system restarts, etc). This could be done in a number of ways - it could change shape and colour, or other icons could be overlaid.
- It moves (I like the idea of it spinning) to indicate that ongoing processes (file operations, downloads, etc) are taking place. It would be really cool if the speed of the movement could relate to the speed of the process [2].
- I like the idea of having the icon as a cog (like the current system icon) - it communicates the idea of machinary that is working. Cogs can spin, which communicates useful additional meanings.
Notification/system menu
Notification panel
- The right-hand panel of the system menu displays a list of ongoing and previous notifications.
- The list is organised chronologically, with separate sections for ongoing notifications and notifications which require a user response (these are placed at the top of the list).
- Clicking an item switches to (or opens) the appropriate application.
- When there are several notifications of the same origin close together, the notifications are grouped in the history. Tracks played and emails received could be summarised in some way, for example.
- The menu is scrollable.
- A user can manage which applications and services are registered with the notification service through a dialogue.
System information
- The left-hand panel of the system menu contains links to system resources as well as system information. It would be cool if this could include some pretty system monitors.
Notification types
The notification area is premised on the idea of there being a number of types of notification. A rough idea for types:
- Constant
- These notifications have a dynamic icon placed in the notification area.
- Examples of services which might use this notification type: wifi strength, the time and weather, battery charge.
- Requires response
- A pop-up bubble announces the notification.
- The notification is placed in the 'Requires action' section of the notification history.
- The notification button changes appearance as a reminder to the user that they need to do something.
- Examples of services which might use this notification type: software updates, system restarts, etc.
- Process
- For operations that take place over a period of time.
- The start and end of the process is acknowledged with a pop-up bubble.
- The notification is entered in the notification history under the 'Ongoing' section.
- The notification icon is animated so as to register that the process is ongoing.
- Examples of services which might use this notification type: file operations, downloads.
- Standard
- Displayed as an info pop-up.
- Entered in the notification history.
- Examples of services which might use this notification type: new tracks in the media player, email arrivals, Twitter notifications, RSS.
- Persistent
- Displayed as an info pop-up.
- Icon entered into notification area. Icon disappears once acknowledged.
- Entered in the notification history.
- Examples of services which might use this notification type: email arrivals.
- Minor
- Displayed as a temporary info pop-up.
- Is not entered in notifications history.
- Examples of services which might use this notification type: IM contacts going offline.
Possibilities for further development
- In line with the idea of 'the system as helper', drag-and-drop actions could be built into the notifications/system button. You could drag email addresses, links of various kinds (RSS, Podcasts) onto it. In each case, the item would be allocated to its proper home. RSS links would be added to your RSS reader. Podcasts added to your media player. Email addresses would be added to your contacts.
- The length of time that temporary information bubbles are displayed could be determined by the amount of text that they contain.
The framework could allow applications to indicate, with a string handle, the general 'class' or 'source event' of the given notification message. This in turn would allow the framework to treat messages with different semantics differently, without actually comprehending those semantics. For instance, the framework might allow the user to indicate particular classes of messages not to be shown in the future (e.g. via a "Do not show this message again" checkbox). More advanced usages of this feature could also be conceived - for instance the framework might forward certain classes of messages to the user's mobile phone, etc. etc. As stated, the semantics of each class handle would be out of the scope of the framework itself and the handles would be namespaced, typically per-application. For the sake of RDF compatibility, the class handles could be formatted as URIs.
Footnotes
[1] Fun is an important aspect of the desktop experience (this is something that Apple understand very well). There is nothing wrong with trying to design a bit more fun into GNOME.
[2] Would a moving icon be too distracting/annoying? Here, the variable speed thing would help, at least. A long running process would result in the icon moving more slowing, therefore reducing the distraction level.
Comments
AndersFeder: It would be useful if different classes of messages were given identifiers and the notification interface on each message would let the user indicate whether or not she is interested in other messages of the same class in the future.
AllanDay: Anders: Can you clarify what you mean by class? Do you mean the types described above? The way I conceived the design, the framework would provide a number of types of notifications, which applications would then use as appropriate. You wouldn't 'turn off' notification types. You'd tell the application to stop using them.
AndersFeder: No, I do not mean types but rather string symbols that applications use to indicate 'what kind of information' the message is about. For instance, I could write a daemon monitoring disk usage and give the user a notification message if the disk is nearly full - it might give off a notification at 10% and 5% disk space left. One of the arguments when invoking the notification framework would be the message class string symbol - it could e.g. be "msg_diskusage_90_percent_full" and "msg_diskusage_95_percent_full" for 10 and 5 percent space left respectively. If the user clicks "Do not show this message again" for e.g. the 10% space left warning, the framework would register in a database that messages of class symbol "msg_diskusage_90_percent_full" are not to be shown in the future. If my disk usage monitor daemon detects the disk nearing 10% space left again and invokes another notification with the "msg_diskusage_90_percent_full" class symbol, the framework would then simply ignore it (seeing that it is registered in the database). I'm not sure if this is a clear enough description, but that's the basic idea I had in mind.
AllanDay: Interesting idea. Perhaps you could add it to the possibilities for further development section?
AndersFeder: It's done.
Re. notification type 5 (was 4 at time of writing)
AndersFeder: I suggest that this type remains on the screen until the user explicitly acknowledges having read them. For instance, if I receive e-mail while away from my computer, I will still want to see the 'new mail'-notification when I return.
AllanDay: Would this kind of behaviour be accounted for by type two (requires a response) notifications? If it is, perhaps a new type is called for - Requires response (application)
AndersFeder: IMO not. As I understand it, type 2 notification requires response to the application while a response to type 4 notifications go only to the notification framework/daemon and indicates that the notification bubble may now be closed. Responses to the application would also typically be more detailed than merely 'close notice' - e.g. 'reboot now' or 'reboot later'.
AllanDay: OK, I see that this might require a separate notification type. I'll rework the typology to fit this in. One question: where should the persistence take place? I don't like the idea of popups sitting around on-screen. Perhaps an icon could temporarily be placed in the notifications area, like what currently happens with Evolution mail notifications?
AndersFeder: I was imagining a bubble emanating from the notification area, growing horizontally as (and if) more persistent messages came in. If that's too ugly then, yeah, a "you have unread notifications"-icon might do the trick.
Re. notification type 6 (was 5 at time of writing)
AllanDay: Anders: Is the main difference between a type 4 and a type 5 that type 5's aren't entered in the notification history? Decisions as to which types of events trigger which kinds of notifications would have to be made by applications, not the notifications framework itself.
AndersFeder: Yes, that would be difference, along with the fact that type 5 message bubbles disappears after a while even when not explicitly closed by the user.
Drawbacks of the proposed design
PhilipGanchev: As I understand, the user would not be able to interact directly with the applets on the panel. She would have to open the notification area menu and then interact with the applets. For example, you would not be able to hover over the mail applet and see a tool tip showing the first few lines of recent emails; you could not change the wireless network directly on the panel. I think this is not a good trade-off. Also, why does the clock have to be part of the notification area? That means you can't even see the calendar by clicking on the clock, and can't see the date on hover.
AllanDay: you'd be able to interact with the applets, in my mind, at least. 
Accessibility
From WillieWalker: I think accessibility considerations need to be made as part of the overall design. So, I'm making a placeholder section here (hope that is OK with you guys). Some of the main things that need to be considered are:
- Theming - are system themes honored?
- Keyboard traversal - can you unplug the mouse and get to all the information and interact with the components?
- AT-SPI support - is the information visible via the AT-SPI (try getting to it from "accerciser") and are events delivered when things change?
More detailed information can be found in http://library.gnome.org/devel/accessibility-devel-guide/nightly/.
AllanDay: yes, it's important to think about accessability. Keyboard navigation is something that I'm particularly keen on. I guess you could have a global hotkey to focus on the notifications interface - perhaps focus could switch to the notification icon? That way, you could scroll right and left to access notifications items in the panel, and up and down to access items in the notifications history.
Status/Notification/Applet approach
From BulatSirazetdinov: Maybe we should have three different types of "notification" area? I suggest this three: 1) Status 2) Notification 3) Applets
This way we'll not confuse user by combining different application behavior in one area and distributing the same behavior among several areas. I think this would be more tidy and elegant way of doing things.
1) Status. It is a placeholder for all status icons: network, CPU frequency, battery state, file copying, file archiving or download progress information, data/time, etc. It should have several different views - shrunk, expanded, full, etc. People like to have a one-click way to access all status information on their system. 
Views can be switched (maybe temporarily) by a click or by a mouse-scroll.
2) Notification. Only notifications should be placed here: you've got mail, download complete, etc. And it should be an icon with a drop-down list of all notifications as it is described above in a mock-up. New notifications should appear in a bubble (growing bubble with several notifications within it simultaneously when they appear in a short time one after another) with an application (or a situation/event) icon. This icon should be optional - let user decide weather such visual feedback is important for him, or it is more of steeling an attention from real tasks.
There is a slightly other way for Notification area to behave - the bubble (icon change, etc.) can appear near the application icon in a Status (File copying complete) or Applets area. Nevertheless, notification list will still be useful. Application (situation/event) icon inside a bubble would become handy also.
3) Applets. It's a place where all applications that want to behave like an applet should reside when you run them. It may behave as notification area used to behave nowadays. :)
Process status and notification feature dreams :)
It would be great to think of other processes the status of which user may become interested in (not only those that we've get used to today), and to provide some use-cases that describe them to the community. Such as, for example: remote server boot-up process; some collaboration work phase or it's progress; application testing process; OpenOffice download counter ; etc. Every background process that user would like to check from time to time or be aware of by using his or her side-view, and get notified on their completion or phase change. The main idea is - let user concentrate on the task he is doing now, and not disturb him by the necessity of manual status checking of background processes. To my mind, it may become a really killer (or at least very handy ) feature when it'll acquire broad application support. Especially in conjunction with simple system-wide user commands queuing/ordering (run tests, if ok archive this, copy there, burn disc while uploading results to the web-server, then restart the web-server, check it's status and report to user). The easy way to access Notification and Status area from scripts is another important thing to think about. (but, ofcourse that is more about API, not UI)
Application status - Applets or Status area ?
So, now there's a question - where an application status should be depicted - Applets area or Status Area ? One of the approaches is: Status icon depicts status of a process or a system resource - not an application status! Status of an application should be depicted (if needed) in a Applets area - not in a Status area. But it still can be hard to distinguish which process deserves depiction in Status area and which does not. (File downloading process or is it a status of a file manager ? E-mail checking ? Application start up ? IM login process ?) And the same thing about resources - is Instant Messaging connection a resource for Status area, or does it fit better to Applets area as an application status ? For some of them it is easier to decide (especially for those that I've listed already), but there'll be more not so straightforward cases.
UIs and APIs
It's not about the API - it's all about the UI (User Interface). I propose 3 different UIs for different application behavior and user interaction. And as for the API - we can fit it all in one API and let GNOME panel (or whatever) to choose the way it should be visualized and the way user interaction should be handled. It can even provide different icon and notification placement on a per application basis (let user decide weather to mess things in a way that he used to, or to accept tidiness and structure GNOME developers have though out ).
Inspired by: Hylke's notification area mock-up discussion