diff --git a/source/components/navigation/contextmenu.rst b/source/components/navigation/contextmenu.rst index 36fd40a..106cc03 100644 --- a/source/components/navigation/contextmenu.rst +++ b/source/components/navigation/contextmenu.rst @@ -1,75 +1,35 @@ Context menu ============ Purpose ------- -A *context menu* is a list of functions or options (respectively menu -items) available to users in the current context. A submenu or cascading -menu is a secondary menu displayed on demand from within a menu. +A *context menu* displays a list of actions applicable to the current context. +It is normally hidden from view (except :doc:`menu bars `) and drops +down when the user right-clicks on something. -Menus are normally hidden from view (except :doc:`menu bars `) and drop down -when users right-click an object or window region that supports a -context menu. They are an efficient means of conserving screen space, -therefore. +Context menus should be considered accelerators for advanced desktop users. +Many mouse users don't think to right-click on things. The right-click gesture +required to show a context menus can be difficult to perform on many laptops, +and it is flat-out impossible on a touch device. Examples -------- Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ -- Provide a context menu for inherent functions. For instance, - functions that have only keyboard access like 'Copy' and 'Paste' for - textual controls, or standard functions like 'Forward' and 'Backward - in case of navigation. -- Use context menus for well known functions only. -- Do not use context menus as the only way to start a function. Always - have a redundant access. - -Behavior -~~~~~~~~ - -- Do not put more than 10 items within a single level of a menu. Add - separators between logical groups within a menu. Organize the menu - items into groups of seven or fewer strongly related items. -- If appropriate, use an access button to make contextual menu - functionality easier to access. -- Place the most frequently used items at the top of the menu. -- Avoid combining actions and attributes in the same group. -- Use submenus cautiously. Submenus add complexity to the interface and - are physically more difficult to use, so you should take care not to - overuse them. -- Do not change labels of menu item dynamically. - -Appearance -~~~~~~~~~~ - -- 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 completely if they are permanently unavailable on the - user's system (e.g. due to missing hardware capabilities or missing - optional dependencies). -- Assign :doc:`shortcut keys ` to the most frequently used menu items - (Ctrl+). 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). -- 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. -- Prefer verb-based menu names; Avoid generic, unhelpful verbs, such as - 'Change' and 'Manage'. -- Use singular nouns for commands that apply to a single object, - otherwise use plural no +- Provide a context menu for any item with actions that can be performed on it. +- Provide a context menu for common actions like 'Copy' and 'Paste' for + textual controls, or navigation actions like 'Forward' and 'Backward. +- Do not use context menus as the only way to access functionality. Every item + in a context menu must be available via a method that is somehow visible by + default--typically the app's main :doc:`menu bar `, but also + via toolbar buttons. + +Behavior & Appearance +~~~~~~~~~~~~~~~~~~~~~ +See the guidelines for :doc:`menu bars `. diff --git a/source/components/navigation/menubar.rst b/source/components/navigation/menubar.rst index 5aeded0..288a99a 100644 --- a/source/components/navigation/menubar.rst +++ b/source/components/navigation/menubar.rst @@ -1,74 +1,82 @@ Menu bar ======== Purpose ------- -A *menu bar* appears at the top of the main window of applications with -a :doc:`very complex command structure `. It provides access to all commands -and most of the settings available in an application. It contains of a -list of functions or options (respectively menu items), submenus or -cascading menus that is a secondary menu displayed on demand from within -a menu, and separators to organize the content for easy recognition. +A *menu bar* appears at the top of an application's main window. It provides +access to all commands and most of the settings available in an application. Users refer frequently to the menu bar, especially when they are seeking -a function for which they know of no other interface. Ensuring that -menus are well organized, are worded clearly, and behave correctly is -crucial to the user’s ability to explore and access the functionality of -the application. +a function for which they know of no other interface. Ensuring that menus are +well organized, are worded clearly, and behave correctly is crucial to the +user’s ability to explore and access the functionality of the application. Examples -------- Guidelines ---------- Is this the right control ~~~~~~~~~~~~~~~~~~~~~~~~~ -- Provide a menu bar in the main window of applications with a - :doc:`very complex command structure ` -- Do not display a menu bar in secondary or internal windows. +- A menu bar is mandatory for applications that have a + :doc:`very complex command structure `, such as + those used for content creation or editing, file manipulation, or other + productivity work. +- Menu bars are optional for simple apps that are able to expose all + functionality using visible buttons and toolbars. If any functionality is + not visible by default, err on the side of providing a menu bar. +- Do not display a menu bar in secondary or internal windows, like the + settings dialog or file dialog. Very small main windows are likewise usually + poor candidates for menu bars. +- Do not include a menu bar in a convergent application's mobile user + interface. Behavior ~~~~~~~~ - Do not have more than nine menu categories within a menu bar. Too many categories are overwhelming and makes the menu bar difficult to use. +- At the minimum, all windows should have File, Edit, Settings, and Help menus. + If they apply, the window can also have View, Insert, Format, Tools and, + Window menus. - Do not put more than 12 items within a single level of a menu. Add separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items. -- Use these standard menu categories if they apply to your application: - File, Edit, View, Insert, Format, Tools, Settings, Window, Help. -- If an application would not have any items options under one of the standard - menu categories, do not include that category 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. - Assign shortcut keys to the most frequently used menu items. Use `KStandardAction `_ and `KStandardShortcut `_ items for common functions, which will result in menu items automatically receiving consistent names, icons, and - shortcut keys. -- Any tool or function that is accessible using a keyboard shortcut must have - an item in the menu bar so that people can discover the shortcut. + shortcut keys. Any tool or function that is accessible using a keyboard + shortcut must have an item in the menu bar so that users can discover it. - Do not hide the menu bar by default. If this is configurable, users should easily be able to make the menu bar viewable again. +- Use submenus cautiously. Submenus add complexity to the interface and + are physically more difficult to use, so you should take care not to + overuse them. Appearance ~~~~~~~~~~ -- Follow the general :doc:`label-writing guidelines ` - for menu item labels. +- Place the most frequently used items at the top of the menu. +- Provide icons for all menu items. Do not re-use the same icon for multiple + items. +- For your menu items' text, follow the + :doc:`general label guidelines `. +- Do not change menu items' labels dynamically. - 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. -- For menu items that toggle some state on or off, always use the positive form - and do not change the text. For example, use the text 'Show hidden files' - instead of 'Hide hidden files', and do not change the text when hidden files - are shown. -- Do not change menu items' labels dynamically. -- Do not use compound words (e.g. ToolOptions) or hyphens (e.g. Tool-Options) - in label names; they make words harder to read and recognize. -- Provide icons wherever possible, but do not re-use the same icon for multiple - menu items. +- Disable menu items that don't apply to the current context instead + of removing them from view. **Exception:** It is acceptable to hide menu + items completely if they are permanently unavailable on the user's system + due to missing hardware capabilities. +- Assign :doc:`shortcut keys ` to the most frequently used menu items + (Ctrl+). 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). +- For menu items that toggle some state on or off, always use the positive + form. For example, use the text 'Show hidden files' instead of 'Hide hidden + files', and do not change the text when hidden files are shown. +