CustomStatusMenuDesignGuidelines

Revision 1 as of 2010-01-11 16:36:27

Clear message

These guidelines are licensed under the GNU Free Documentation License version 1.1 or any later version. By editing this page you agree to license your contributions under those terms. Feedback is welcome at CustomStatusMenuDesignGuidelines/Comments.

Canonical Design team, January 2010

Over the next few releases, Ubuntu is phasing out the notification area (sometimes known as the “system tray”) because of its clutter, inconsistency and poor integration with the rest of the panel. We are replacing it with two types of status menu:

  • custom status menus for applications (known as “application indicators”)

  • system status menus for messaging, power, sound, etc.

These guidelines cover how to design your application’s presence in the status menus. (For implementation details, see DesktopExperienceTeam/ApplicationIndicators.)

Does your program need a custom status menu?

Consider using a custom status menu if there is a substantial benefit from the application running in the background without any windows open. (Do not count quicker startup as a benefit here: an application’s presence in the panel should not depend on how fat the application happens to be.)

You do not need a custom status menu if:

  • You just want the application to take up a small space when minimized. The window switcher can take care of this. We welcome ideas for enhancing the window switcher to cater better for long-running applications.
  • The application is for IM, IRC, e-mail, or newsreading. Instead, integrate the application with the messaging menu.

What should be in a custom status menu?

When porting an application that previously had a notification area item to use a custom status menu, remember that you will need to consider:

  • any action that happened when clicking (or double-clicking) the notification area item
  • any menu that appeared when clicking the notification area item
  • any menu that appeared when secondary-clicking the notification area item.

Concentrate on actions that people are likely to want to perform without first opening or focusing a window of the application.

Arrange items in a custom status menu just as you would for an ordinary menu bar menu: related items together, more common items first.

How should people hide the menu?

A custom status menu should be optional.

If the application has a Preferences or Settings window, there should be a checkbox in that window (typically under a “General” or “Appearance” category), with a label of the form “Show {Application Name} menu in the panel” or “Show {type of status} in the panel”. The menu itself should end with a separator followed by an “{Application Name} Preferences…” or “{type of status} Settings…” item that opens/focuses the window to display the checkbox.

If the application does not have a Preferences or Settings window, add a “Show in Panel” checkmark item to whichever menu contains other view settings.