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.

Matthew Paul Thomas, 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 programs, known as “application indicators”

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

These guidelines cover how to design your program’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 program running in the background without any windows open. (Do not count quicker startup as a benefit here: a program’s presence in the panel should not depend on how bloated the program happens to be.)

You do not need a custom status menu if:

• The application is for IM, IRC, e-mail, or newsreading. Instead, integrate the application with the messaging menu.

• You just want the program to take up a small space in the panel when minimized. The window switcher can take care of this. We welcome ideas (in prose or code) for enhancing the window switcher, to cater better for long-running minimized applications.

What should the title look like?

The menu title should almost always be a symbolic icon (using IconName). Keep the icon appearance the same, varying it only if necessary to represent changing status. Avoid animated or flashing icons.

In rare cases, it may be appropriate to add text alongside the icon (using Label). Keep this text short, and do not change it more than about once a minute.

What about tooltips?

Status menus do not have tooltips. This is for consistency of behavior: most menus have never needed tooltips, so it is most consistent if all menus are designed to not need them, rather than some menus having them and some not.

If a notification area item had a tooltip with important information, it will be a small challenge to present this information somewhere else when converting it to a menu.

• If the information is very short and useful to see at a glance, consider including it as part of the menu title, alongside the icon.
• If the contents of the menu already conveys the information, you do not need to duplicate it.
• It may be appropriate to convey the information in brackets at the end of an existing menu item.
• As a last resort, it may be necessary to add a first item to the menu that is always insensitive, where the text of the item conveys the information that the tooltip previously did.

What should be in a custom status menu?

When porting a program 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 (e.g. right-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 program.

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

Icons in menu items

We follow the draft Gnome guideline for which menu items should have icons: ▶ An item should have an icon if the item represents a “dynamic object”, something of a type that may be added to or removed from the menu without customizing the software itself. Examples of dynamic objects are applications, documents, folders, disks, bookmarks, history items, user accounts, wireless networks, printers, fonts, and instant messaging statuses.

When you apply this guideline to a well-ordered menu, you will discover two things:

• Items that should have icons are grouped together.
• Items that should not have icons are either grouped together, or at the beginning or end of a section. (For example, a menu section providing quick access to recently-used things might have an item with icon for each thing, followed by an “Other…” item without an icon.)

Taking advantage of this, Ubuntu status menus save space by using an indentation style different from traditional GTK menus: the leading (e.g. left) edge of the icon, in items with icons, is lined up with the leading edge of the text in items without icons.

If you find this has produced a ragged-looking menu, it’s probably for one of two reasons:

• There are items in the menu that have icons and shouldn’t.
• The menu items could be rearranged to a more logical order.

How should people hide the menu?

A custom status menu should be optional.

If the program 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 program does not have a Preferences or Settings window, add a “Show in Panel” checkmark item to whichever menu contains other view settings.