[kde-guidelines] Styleguide: Context menu

Thomas Pfeiffer colomar at autistici.org
Thu Sep 19 17:56:40 UTC 2013


On Thursday 19 September 2013 11:31:58 Heiko Tietze wrote:
> Viewing and Navigation > Access functions
> * Provide a context menu for controls with implicit functions.
> 
> http://techbase.kde.org/Projects/Usability/HIG/ContextMenu
> 
> == 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.
> 
> Menus are normally hidden from view (except
> [[Projects/Usability/HIG/Menu_Bar| 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.
> 
> == Examples ==
> 
> == Guidelines ==
> === Is this the right control ===
> * Provide a context menu for implicit function, e.g. operations with list
> items.

What do you mean by "implicit function"?

> * 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 that not apply at all.

See my question in the menu bar HIG.

We should clearly forbid things like "Show advanced transcoding options if 
shoft key is pressed" in Amarok. Here is my suggestion: 

* Always show all menu items that apply. Do *not* show certain items only if 
the user does a certain action (like pressing the shift key)

> * Assign [[Projects/Usability/HIG/Keyboard_Shortcuts|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). * 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 ==

The rest is fine with me.


More information about the kde-guidelines mailing list