Message Tray
The Message Tray design pages are out of date, and are being retained for reference purposes only. For up to date designs, see the notifications page.
The primary goal of the Message Tray is to provide the user with enough information to quickly assess an event but limit the severity and duration of the preemption. Another important goal is to allow but not compel the user to respond to the event. The tray also provides an important reminding function for messages that the user has deferred addressing.
More specific goals include:
- permit the user to stay focused on the primary task
- provide awareness of new notifications
- remind for unseen messages
- direct attention to high priority messages and alerts
- unobtrusive display
- provide a uniform interface for messages, notifications, and alerts
- allow the user to control the information display
- provide a lightweight interface to background operations
Notifications are events that are ephemeral and do not require direct action or response. Messages are events that either require or imply a response or should be acknowledged in some way.
Conceptually each Message comes from a Message Source. Sources of messages may include, at the user's discretion: e-mail, calendar appointments, instant message chat, stock market data, weather advisories, and system alerts. These should map to applications or to the services of the core system itself.
In order to not compel the user to action all Messages (events that request or require action, response, or some form of acknowledgement) should be queued for the user. or Notifications and Messages that do not require acknowledgement or that have alternate indicators should not be queued (eg. A low battery warning does not require a response and the battery level already has an indicator in the System Status Area).
Usage Guidelines
Porting
Implementation
BoF Feedback
We held a BoF about the message tray at GUADEC on July 31, 2012.
The desktop should go modal and be dimmed when the message tray is shown. This is being implemented as part of bug 681480 and bug 681392.
- How should we indicate to the user that there are new notifications when the user comes back from away? The designers will create a mock up of a special-purpose notification that indicates that there was a certain number of missed messages. Other approaches discussed were replaying the notifications or showing the tray. Replaying notifications could be problematic because there could be many of them. Also, we could only replay notifications as banners, which would not allow us to indicate to the user that there are more notifications in the queue. The current design for indicating more queued notifications only applies when the user is interacting with the notifications, causing them to expand and separate from the screen edge, allowing for the next notification to peek out. Showing the tray is problematic because now that showing the tray moves the desktop, we never want to do that automatically.
Jasper implemented triggering the tray with downward pressure. However it depends on his implementation of the pointer barrier events for the X Server, which will need to wait for the next release of the X Server that will happen at the unspecified date past GNOME 3.6 release. We will likely want to create another implementation of that feature that uses a 1 pixel actor at the bottom of the screen and some of the heuristics suggested by Allan.