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
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 <menubar>`) and drops
down when the user right-clicks on something.
Menus are normally hidden from view (except :doc:`menu bars <menubar>`) 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
--------
......@@ -22,54 +22,14 @@ 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 <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
- 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 <menubar>`, but also
via toolbar buttons.
Behavior & Appearance
~~~~~~~~~~~~~~~~~~~~~
See the guidelines for :doc:`menu bars <menubar>`.
......@@ -4,18 +4,13 @@ Menu bar
Purpose
-------
A *menu bar* appears at the top of the main window of applications with
a :doc:`very complex command structure </patterns/command/index>`. 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
--------
......@@ -26,9 +21,18 @@ Guidelines
Is this the right control
~~~~~~~~~~~~~~~~~~~~~~~~~
- Provide a menu bar in the main window of applications with a
:doc:`very complex command structure </patterns/command/index>`
- 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 </patterns/command/index>`, 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
~~~~~~~~
......@@ -36,39 +40,43 @@ 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 <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
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 </style/writing/labels>`
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 </style/writing/labels>`.
- 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 <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).
- 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.
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