Libreoffice Human Interface Guidelines: Context Menu and Sidebar

We started the work on Libreoffice human interface guidelines (HIG) this year and published so far two parts: the foundation with statements about the vision, persona, and our manifesto and guidelines for the menu bar and tool bar. In this posting we put the context menu and sidebar up for discussion.

Context Menus

A context menu is a list of functions or options (respectively menu items) available to users in the current context. Menus are normally hidden from view (except menu bars) and drop down when users right-click an object or window region that supports a context menu.

Context menus basically intends to give alternative access to modify the focused element and to access context specific functions. They are an efficient means of conserving screen space.

Both persona will refer to the context menu but Eve might individualize her app in order to heavily rely on the context menu.

General

• Use context menus for well-known and frequently used functions only.
• Provide items in the context menu for modification purpose and context sensitive functions but not to insert elements or for view options, for instance.
• Do not use context menus as the only way to start a function. Always have a redundant access.
• Always 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. Disable those functions when not applicable.

Organization

• Do not put more than 10 items within the default level of a menu added by not more than 5 context sensitive items after right clicking an element. Add separators between logical groups within a menu. Organize the menu items into groups of seven or fewer strongly related items.
• Sort context menus so that
  • More important contextual entries groups appear at the top (e.g. table features before character/paragraph/page item section)
  • Entries requiring little to no additional user input (non-dialog entries) should be at the top of the group
  • Same functions have the same position (copy/paste is always on top).
• Avoid combining actions (such as delete, insert, print) and attributes (for instance bold formatting, double spacing, center alignment) in the same group.
• Features available in the toolbar should ideally not be available in the context menu, except for special cases (e.g. clipboard functions).

Text

• Do not change labels of menu items dynamically.
• Indicate a function that needs additional information (including a confirmation) by adding an ellipsis at the end of the label (e.g. Save as…).
• Use a verb-action combination for the label (e.g. Show ruler, Format image) but adopt this rule for localization.
• Standardize the verbs used – Show and Hide, Enable and Disable. Refer to the LO [terminology] (remark: It would be good to include advices from the l10n and i18n team into the HIG. Apache OpenOffice has a pretty good UI Text Style Guide that could be the basis for us too.)

Sidebar

A sidebar is a graphical presentation of context-sensitive properties optimized for fast access. Typically, the sidebar contains panes with simple controls that provide quick and task-oriented access to the most frequently changed properties such as font size, line spacing, paragraph alignment, etc. The primary reason of the sidebar is an enhancement to the toolbar in the way that it deals with properties instead of functions.

LibreOffice sidebar contains of a tab bar that offers access to panes each with a titlebar and a deck that containing a variable number of sections each with a content panel title and content panel. Panes are switched via tab buttons that should appear horizontally at the top of the sidebar when it is open rather than the right side. The tab buttons appear vertically on the right side when the sidebar pane is hidden.

The primary user of the sidebar is Benjamin, so the panes have to provide a simple but comprehensive overview of and access to properties.

General

• Provide access to properties in sidebars. Select the most relevant features from dialogs in order to have fast access.
• Define a fixed size for the sidebar width. Do not make the width depending on the selected deck. This eliminates the problem of having tabs that can be smaller than others and when switching to other tabs causing cropping of content.
• Avoid vertical scrolling by having content fit into pane height (in respect to LibreOffice’ default resolution of 1280×768 pixels). In the case of too many options, consider splitting them into different panes.

Organization of Content

• Prefer controls where the setting is just one click away (e.g. list box rather than drop down or direct access to the recently used colors in addition to the widget).
• Prefer graphical widgets in favor of controls that require the input of the exact value (e.g. an image’s transparency with discrete steps via sliders).
• Hide advanced features by default but offer easy means to access to these properties within the sidebar.
• Consider to introduce presets of properties comprising of the most relevant settings. For instance, one page margins with all four values.

Appearance and Text

• Use a grid layout with one or two columns.
• Align elements to fit the pane width. Left align labels and place the input control right of the (localized) label. Do not place the label above the input control.
• Label control groups in the sidebar, preferably when the section name is not clear enough or when many controls are included.
• Use indentation to indicate the organization for labeled sections.

Discussion

In the first presentation to team members the question came up whether we talk about sidebars in general or just the right sidebar (see as well the Apache OpenOffice wiki on sidebar how-to). Basically the HIG should be generic enough to address all embodiments of a certain type of control or a pattern. On the other hand, Libreoffice has pushed the right sidebar forward to some very specific control with a unique workflow. Perhaps it makes sense to rename it therefore, e.g. Properties Board. What do you think?

Please read the proposed guidelines carefully. It should reflect the current status and drive the future development on a generic level. That means we predefine for instance the fix size, but the idea to have more than one sidebar each of them with a different layout, e.g. a large one with the full feature set and a smaller one with a limited set plus space-saving controls, is not part of the HIG. The same is true for the advice to have easy access by default and advanced on demand. That’s not what we have right now but it is the intention for future UI design.

We are looking forward your comments.