Menus:Items
From KDE-HIG_Wiki
In its simplest form, a menu item consists of its option name. Optionally an icon set, a tooltip, a statustip, and an accelerator indicator can be added. When a menu item is enabled and available for use, its text is displayed in black, and the icon set is presented in color. When it is not available, the item is dimmed (grey) and it is not highlighted when it gains the focus.
| Table of contents |
Constructing Menu Items
Guidelines
- Use header capitalization in menu titles and menu items (see section Capitalization).
- Use verbs or verb phrases for commands, and adjectives or adjective phrases for settings.
- Keywords should be located at the beginning.
- Use brief descriptions and phrases.
- Offer accelerator keys for all menu items (see section Keyboard Accelerators).
- Offer keyboard shortcuts for prevalent menu items. Apply them in consistency with the other menus in your application, and in consistency with other KDE applications (see section Standard Keyboard Shortcuts).
- Items that do open further dialogs or require user input should have three dots at the end ("...").
Rationale
The higher the complexity of an application, the more complex is an application's menu. In order to support the user in finding the functions she is looking for, it is important to faciliate scanning by using brief and significant labels.
Accelerator keys are crucial to meet accessiblity standards for software applications, and additionally provide a fast access to the function.
Implementation Notes
<todo>Accelerator keys</todo>
<todo>Keyboard shortcuts</todo>
Related
<todo> </todo>Capitalization
Keyboard Accelerators
Standard Keyboard Shortcuts
<todo> </todo>Accessiblity: accelerator keys, keyboard shortcuts
Available and Unavailable Items
Guidelines
- When a menu item is currently, but not generally unavailable, disable it and dim its text (grey).
- When all the items in a menu are currently unavailable, do not disable the menu so the user can still open it and view the disabled items. The same applies to submenus.
- When a menu item is generally unavailable, remove the item instead of disabling it.
Rationale
An application should always clearly indicate its system state. This also applies to the availability of functions — if they are currently not available they should be disabled to avoid confusion when a user tries to select it.
Another situation is when an item is generally not available to a user. Then, the item should be removed because a disabled item implies that the user can do something to change its state.
Examples
When Copy is not possible because no text is selected, the item is currently not available and should be disabled.
The other case is that there actually is nothing to be copied in an application. Then, the item should be removed permanently.
Implementation Notes
<todo>QAction enable/disable</todo>
Related
<todo> </todo> Accessiblity: Keyboard access in menus
Using Ellipses (...) in Items
In menus, ellipses (...) indicate that the command specified by a menu item needs further input or specifications.
Guidelines
- Use ellipsis only if the command requires further input by the user before it can be performed.
- Do not use ellipses if the command only shows a secondary window, or a confirmation dialog.
Rationale
As is standard practice in software design, ellipses on a menu item indicate that the item invokes a dialog or some other additional to complete the selected action. If there is no action to be completed, ellipses should not be applied to make clear that no further interaction is of need.
Examples
Help->Report Bug... requires further input before the intended action can be performed (Select application, open web location, etc.).
Instead, Help->Handbook opens a secondary window which does not necessarily require further user input.
Implementation Notes
<todo> implementation notes? </todo>
Related
<todo> related? </todo>
Non-Exclusive Toggle Menu Items
A non-exclusive toggle menu item is a menu item that appears with a sunken check mark next to it if it is on, and an empty field if it is off. If an icon set is utilized, the check mark in on state is dismissed, instead the icon is sunken.
Guidelines
- Use non-exclusive toggle menu items to present users with two-state settings of choices that are not exclusive within a group of settings.
- Use non-exclusive toggle menu items only when it is obvious from the label what happens after selecting/deselecting it.
- * Firstly, this means that the two states are logical or natural opposites whose states can be described by on and off. If this is not the case, use two exclusive toggle menu items instead.
- * Secondly, the label must be a verb or verb phrase that indicates what happens after activating the option (e.g. Show Hidden Files, Set Invisible).
- Use non-exclusive toggle items with restraint. If users must set more than one or two related preferences, place the options in a dialog box (or provide a palette or toolbar buttons for the preferences).
Rationale
The way of marking toggle items in QT(tm) 3.x is not optimal, as a menu item in off state does not visually differ from menu items that initiate a command. Therefore, they should be used only if the label clearly indicates what happens after activating the option.
Another argument against applying toggle items extensively is that with all menu items, the menu is dismissed after clicking it. To select another item, the user must reopen the menu.
Examples
Do not mark your non-exclusive toggle items in an ambiguous way: In this example, it does not become clear if the Invisible item displays the current status, or if it initiates the invisible state — unless the user actually clicks the item. It is better to use the unambiguous label Set Invisible instead.
<<IMAGE>> It does not become clear if Invisible displays the current status, or if it initiates the invisible mode.
<<IMAGE>> Only if the item is switched on its state becomes clear.
<<IMAGE>> When the label describes an action, the off state is not contradictory
Implementation Notes
<todo> implementation notes? </todo>
Related
<todo> related? </todo>
Exclusive Toggle Menu Items
Exclusive toggle menu items are a group of items that specify a setting with exclusive options. The currently selected option appears with a sunken check mark next to it, the other menu items display an empty field to their left. If an icon set is utilized, the check mark for the currently selected option is dismissed, instead the icon is sunken.
Guidelines
- Use exclusive toggle menu items to present users with up to five exclusive choices.
- Use two exclusive toggle menu items instead of a single toggle menu item if the settings are not clear opposites.
- Use separators to group exclusive toggle menu items.
- Use exclusive toggle items with restraint. If users must set more than one or two related preference sets, place the options in a dialog box (or provide a palette or toolbar buttons for the preferences).
Rationale
The way of marking exclusive toggle items in Qt(tm) 3.x is not optimal as the same interface elements are used for exclusive and non-exclusive menu items. Due to the equal look, it does not become clear for the user that a group of items are exclusive options. To assist the user in understanding the difference, it is important to clearly mark groups of menu items by using separators. That way you show up their relationship, and separate them clearly from other item groups.
Another argument against applying exclusive toggle items extensively is that with all menu items, the menu is dismissed after clicking it. To select another item, the user must reopen the menu.
Examples
With exclusive toggle menu items, it is hard to identify which options belong together. In this example, the use of icons further hinders the perceptibility of the currently selected option.
<<IMAGE>> In general, Qt(tm) 3.x makes it hard to identify which toggle items are grouped exclusively. When an icon set is applied, it becomes even more difficult.
Implementation Notes
<todo> implementation notes? </todo>
Related
<todo> related? </todo>
Toggle Command Items
A toggle command item changes its label when selected. For example, View->Reload in a browser may change to Stop to allow the user to interrupt the operation if it is taking a long time.
Guidelines
- If you have sufficient space on your menu, provide two separate menu items for the commands. Enable and disable the items as the situation demands.
- Use toggle menu items only to change between commands, not to toggle between two-state settings (for example, Show Statusbar and Hide Statusbar). Present such items as a non-exclusive toggle item instead.
- If you use toggle command items, do not mix them with adjacent non-exclusive toggle items.
Rationale
Toggle command menu items are problematic as the user never sees the menu item changing. Especially for unexperienced users it is not obvious that a new function is available.
As another argument against toggle command items, two separate command menu items make it easier to display keyboard shortcuts for the functions in question.
Examples
Positive Example:
In the Konqueror View menu, there is enough space to use two adjacent command items instead of a toggle command item for Reload and Stop.
<<IMAGE>> Reload and Stop as two adjacend command items.
Negative Example:
KDevelop Designer mixes toggle command items and non-exclusive toggle items. Apart from the fact that you should not use toggle command items for settings, this inconsistency is confusing to the user.
<<IMAGE>> In off state, Show Toolbar and Show Statusbar seem to belong to the same type of menu item.
<<IMAGE>> In on state, Show Statusbar changes to Hide Statusbar, while the Show Toolbar item remains the same.
Implementation Notes
<todo> implementation notes? </todo>
Related
<todo> </todo> Accessibility: Toggle command items
