Projects/Usability/HIG/Menu Bar: Difference between revisions
(Added Implementation section) |
No edit summary |
||
Line 1: | Line 1: | ||
__NOTOC__ | |||
== Purpose == | == Purpose == | ||
A menu is a list of functions or options (respectively menu items) available to users in the current context. Menus are often displayed from a 'menu bar' that appears at the top of a main window and provides access to all commands and most of the settings available in an application. It contains menu titles which describe the content of each menu. Each menu title is accessible by accelerator keys, which must be set by the developer. | |||
By contrast, a context menu drops down when users right-click an object or window region that supports a context menu. A submenu or ‘cascading menu’ is a secondary menu displayed on demand from within a menu. Menus are normally hidden from view (except menu bars) and therefore are an efficient means of conserving screen space. | |||
== Examples == | |||
[[File:Menu_bar.png]] | |||
== Guidelines == | == Guidelines == | ||
=== Is this the right control === | |||
* Provide a menu bar in every application main window. | |||
* Don't have more than seven menu categories within a menu bar. Too many menu categories are overwhelming and make the menu bar difficult to use. | |||
* Don’t put more than 12 items within a single level of a menu. Put separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items. | |||
* | * Use standard items for categories: | File | Edit | View | Insert | Format | ''Application Specific Menus'' | Go | Bookmarks | Tools | Settings | Window | Help | ||
* | * If an application does not have options under one of the standard menu items, do not include it in the menu. At the minimum, all windows should have a File (or File equivalent, such as in the case if Konqueror and Amarok) and Help menu. | ||
* Use standard items for menus. File should contain of Open | Save | (Save as...) | Exit | |||
* | |||
* Do not make the menu bar 'hideable', users may not easily be able to make the menu bar viewable again. | |||
* Do not display a menu bar in secondary or internal windows. | |||
=== Behavior === | |||
* Choose single word names for menu categories. Using multiple words makes the separation between categories confusing. | |||
* Disable menu items that don't apply to the current context, instead of removing them. | |||
* Hide menu items that not apply at all. | |||
* Don't change labels of menu item dynamically. | |||
* Assign shortcut keys to the most frequently used menu items (Ctrl+<Key>). For well-known shortcut keys, use standard assignments. Use function keys for commands that have a small-scale effect (F2 = Rename) and Ctrl key for large-scale effect (Ctrl+S = Save). | |||
* All menu patterns except menu bars need an arrow indicator for pull-down menu. | |||
=== Appearance === | |||
* Indicate a function that needs additional information (including a confirmation) by adding an ellipsis at the end of the label (e.g. ‘Save as…’). | |||
* Provide menu item icons for the most commonly used menu items. | |||
* Turning "on" an item in the menu should always enable the option. Negative options create a double negative which can be confusing. For example, use "Show hidden files" instead of "Hide hidden files". | |||
* Do not use compound words (e.g. ToolOptions), and hyphens (e.g. Tool-Options) in label names; they make words harder to read and recognize. | |||
== Implementation == | == Implementation == | ||
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMenuBar.html KMenuBar], but in most case you should instead define the content of the menu bar using [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKXmlGuiWindow.html KXmlGuiWindow.html] | * [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKMenuBar.html KMenuBar], but in most case you should instead define the content of the menu bar using [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKXmlGuiWindow.html KXmlGuiWindow.html] |
Revision as of 14:44, 18 September 2013
Purpose
A menu is a list of functions or options (respectively menu items) available to users in the current context. Menus are often displayed from a 'menu bar' that appears at the top of a main window and provides access to all commands and most of the settings available in an application. It contains menu titles which describe the content of each menu. Each menu title is accessible by accelerator keys, which must be set by the developer. By contrast, a context menu drops down when users right-click an object or window region that supports a context menu. A submenu or ‘cascading menu’ is a secondary menu displayed on demand from within a menu. Menus are normally hidden from view (except menu bars) and therefore are an efficient means of conserving screen space.
Examples
Guidelines
Is this the right control
- Provide a menu bar in every application main window.
- Don't have more than seven menu categories within a menu bar. Too many menu categories are overwhelming and make the menu bar difficult to use.
- Don’t put more than 12 items within a single level of a menu. Put separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items.
- Use standard items for categories: | File | Edit | View | Insert | Format | Application Specific Menus | Go | Bookmarks | Tools | Settings | Window | Help
- If an application does not have options under one of the standard menu items, do not include it in the menu. At the minimum, all windows should have a File (or File equivalent, such as in the case if Konqueror and Amarok) and Help menu.
- Use standard items for menus. File should contain of Open | Save | (Save as...) | Exit
- Do not make the menu bar 'hideable', users may not easily be able to make the menu bar viewable again.
- Do not display a menu bar in secondary or internal windows.
Behavior
- Choose single word names for menu categories. Using multiple words makes the separation between categories confusing.
- Disable menu items that don't apply to the current context, instead of removing them.
- Hide menu items that not apply at all.
- Don't change labels of menu item dynamically.
- Assign shortcut keys to the most frequently used menu items (Ctrl+<Key>). For well-known shortcut keys, use standard assignments. Use function keys for commands that have a small-scale effect (F2 = Rename) and Ctrl key for large-scale effect (Ctrl+S = Save).
- All menu patterns except menu bars need an arrow indicator for pull-down menu.
Appearance
- Indicate a function that needs additional information (including a confirmation) by adding an ellipsis at the end of the label (e.g. ‘Save as…’).
- Provide menu item icons for the most commonly used menu items.
- Turning "on" an item in the menu should always enable the option. Negative options create a double negative which can be confusing. For example, use "Show hidden files" instead of "Hide hidden files".
- Do not use compound words (e.g. ToolOptions), and hyphens (e.g. Tool-Options) in label names; they make words harder to read and recognize.
Implementation
- KMenuBar, but in most case you should instead define the content of the menu bar using KXmlGuiWindow.html