Commit a462c5a5 authored by Nate Graham's avatar Nate Graham 🔩

Revamp menu guidelines

Summary:
Revamp the pages about menubars and context menus:
- Reduce redundancy
- Update guidelines according to generally accepted best practices
- Fix minor errors

Test Plan: Deploy locally and read through it

Reviewers: fabianr, #kde_human_interface_guidelines, #vdg

Reviewed By: fabianr, #kde_human_interface_guidelines, #vdg

Tags: #kde_human_interface_guidelines

Differential Revision: https://phabricator.kde.org/D16827
parent f61a5997
...@@ -4,14 +4,14 @@ Context menu ...@@ -4,14 +4,14 @@ Context menu
Purpose Purpose
------- -------
A *context menu* is a list of functions or options (respectively menu A *context menu* displays a list of actions applicable to the current context.
items) available to users in the current context. A submenu or cascading It is normally hidden from view (except :doc:`menu bars <menubar>`) and drops
menu is a secondary menu displayed on demand from within a menu. down when the user right-clicks on something.
Menus are normally hidden from view (except :doc:`menu bars <menubar>`) and drop down Context menus should be considered accelerators for advanced desktop users.
when users right-click an object or window region that supports a Many mouse users don't think to right-click on things. The right-click gesture
context menu. They are an efficient means of conserving screen space, required to show a context menus can be difficult to perform on many laptops,
therefore. and it is flat-out impossible on a touch device.
Examples Examples
-------- --------
...@@ -22,54 +22,14 @@ Guidelines ...@@ -22,54 +22,14 @@ Guidelines
Is this the right control Is this the right control
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
- Provide a context menu for inherent functions. For instance, - Provide a context menu for any item with actions that can be performed on it.
functions that have only keyboard access like 'Copy' and 'Paste' for - Provide a context menu for common actions like 'Copy' and 'Paste' for
textual controls, or standard functions like 'Forward' and 'Backward textual controls, or navigation actions like 'Forward' and 'Backward.
in case of navigation. - Do not use context menus as the only way to access functionality. Every item
- Use context menus for well known functions only. in a context menu must be available via a method that is somehow visible by
- Do not use context menus as the only way to start a function. Always default--typically the app's main :doc:`menu bar <menubar>`, but also
have a redundant access. via toolbar buttons.
Behavior Behavior & Appearance
~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
See the guidelines for :doc:`menu bars <menubar>`.
- 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 <shortcuts>` 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
...@@ -4,18 +4,13 @@ Menu bar ...@@ -4,18 +4,13 @@ Menu bar
Purpose Purpose
------- -------
A *menu bar* appears at the top of the main window of applications with A *menu bar* appears at the top of an application's main window. It provides
a :doc:`very complex command structure </patterns/command/index>`. It provides access to all commands access to all commands and most of the settings available in an application.
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.
Users refer frequently to the menu bar, especially when they are seeking Users refer frequently to the menu bar, especially when they are seeking
a function for which they know of no other interface. Ensuring that a function for which they know of no other interface. Ensuring that menus are
menus are well organized, are worded clearly, and behave correctly is well organized, are worded clearly, and behave correctly is crucial to the
crucial to the user’s ability to explore and access the functionality of user’s ability to explore and access the functionality of the application.
the application.
Examples Examples
-------- --------
...@@ -26,9 +21,18 @@ Guidelines ...@@ -26,9 +21,18 @@ Guidelines
Is this the right control Is this the right control
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
- Provide a menu bar in the main window of applications with a - A menu bar is mandatory for applications that have a
:doc:`very complex command structure </patterns/command/index>` :doc:`very complex command structure </patterns/command/index>`, such as
- Do not display a menu bar in secondary or internal windows. 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 Behavior
~~~~~~~~ ~~~~~~~~
...@@ -36,39 +40,43 @@ Behavior ...@@ -36,39 +40,43 @@ Behavior
- Do not have more than nine menu categories within a menu bar. Too - Do not have more than nine menu categories within a menu bar. Too
many categories are overwhelming and makes the menu bar difficult to many categories are overwhelming and makes the menu bar difficult to
use. 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 - 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 separators between logical groups within a menu. Organize the menu
items into groups of seven or fewer strongly related items. 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 - Assign shortcut keys to the most frequently used menu
items. Use `KStandardAction <https://api.kde.org/frameworks/kconfigwidgets/html/namespaceKStandardAction.html>`_ items. Use `KStandardAction <https://api.kde.org/frameworks/kconfigwidgets/html/namespaceKStandardAction.html>`_
and `KStandardShortcut <https://api.kde.org/frameworks/kconfig/html/namespaceKStandardShortcut.html>`_ items for common functions, which will and `KStandardShortcut <https://api.kde.org/frameworks/kconfig/html/namespaceKStandardShortcut.html>`_ items for common functions, which will
result in menu items automatically receiving consistent names, icons, and result in menu items automatically receiving consistent names, icons, and
shortcut keys. shortcut keys. Any tool or function that is accessible using a keyboard
- Any tool or function that is accessible using a keyboard shortcut must have shortcut must have an item in the menu bar so that users can discover it.
an item in the menu bar so that people can discover the shortcut.
- Do not hide the menu bar by default. If this is configurable, users should - Do not hide the menu bar by default. If this is configurable, users should
easily be able to make the menu bar viewable again. 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 Appearance
~~~~~~~~~~ ~~~~~~~~~~
- Follow the general :doc:`label-writing guidelines </style/writing/labels>` - Place the most frequently used items at the top of the menu.
for menu item labels. - 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 </style/writing/labels>`.
- Do not change menu items' labels dynamically.
- Choose single word names for menu categories. Using multiple words - Choose single word names for menu categories. Using multiple words
makes the separation between categories confusing. makes the separation between categories confusing.
- Disable menu items that don't apply to the current context instead of - Disable menu items that don't apply to the current context instead
removing them. of removing them from view. **Exception:** It is acceptable to hide menu
- For menu items that toggle some state on or off, always use the positive form items completely if they are permanently unavailable on the user's system
and do not change the text. For example, use the text 'Show hidden files' due to missing hardware capabilities.
instead of 'Hide hidden files', and do not change the text when hidden files - Assign :doc:`shortcut keys <shortcuts>` to the most frequently used menu items
are shown. (Ctrl+). For well-known shortcut keys, use standard assignments. Use
- Do not change menu items' labels dynamically. function keys for commands that have a small-scale effect (F2 =
- Do not use compound words (e.g. ToolOptions) or hyphens (e.g. Tool-Options) Rename) and ctrl key for large-scale effect (Ctrl+S = Save).
in label names; they make words harder to read and recognize. - For menu items that toggle some state on or off, always use the positive
- Provide icons wherever possible, but do not re-use the same icon for multiple form. For example, use the text 'Show hidden files' instead of 'Hide hidden
menu items. files', and do not change the text when hidden files are shown.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment