[kde-guidelines] Styleguide: Menu bar

[Thomas Pfeiffer]

On Thursday 19 September 2013 11:31:07 Heiko Tietze wrote:
> Viewing and Navigation > Access functions
> * Apply a menu bar to every standard application.
> http://techbase.kde.org/Projects/Usability/HIG/Menu_Bar
> 
> == Purpose ==
> A ''menu bar'' appears at the top of the main window and 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.
> 
> 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.
> 
> == Examples ==
> [[File:Menu_bar.png]]
> 
> == Guidelines ==
> === Is this the right control ===
> * Provide a menu bar in the main window of every standard application.
> * Do not display a menu bar in secondary or internal windows.
> 
> ===  Behavior ===
> * Do not have more than nine menu categories within a menu bar. Too many
> categories are overwhelming and make the menu bar difficult to use.
> * 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 standard items for categories: File, Edit, View, Insert, Format,
> Tools, Settings, Window, Help.

I'm not sure if I understand this one correctly. Does it mean that these 
common categories should be labeled with these names? In that case, my wording 
suggestion would be:
Use these names for common menu categories: File, Edit, View, Insert, Format,
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.
> * Do not make the menu bar hideable, users may not easily be able to make
> the menu bar viewable again.

This point is open for discussion. I agree that menus should not be hidden by 
default and they must not be hidden in a way that they can only be re-
displayed with a keyboard shortcut or context menu (like e.g. Amarok does it), 
even if instructions on how to show it again are given when users hide it.
However, menu buttons like in Dolphin make it quite easy to re-show the menu: 
Click the button, check "Show Menu", done. I know you find even the menu button 
a bad idea, but I don't see a serious usability problem in this way.

> * 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.

What do you mean by "not apply at all" in contrast to "don't apply to the 
current context"? If a menu item does not make any sense in an application, it 
should not be hidden, but completely removed (I don't think that people would 
implement a menu item which just does nothing in the first place though, would 
they?)

> * 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 ==
> * [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]

Everything else gets a +1 from me. Thanks for another great guideline!