Design/Guidelines/ToolBar
< Design | Guidelines(Redirected from Design/ToolBar)
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
A tool bar is a graphical presentation of commands optimized for fast access. Typically, a tool bar contains buttons that correspond to items in an application's menu, providing direct access to application's most frequently used functions for both novice users such as Benjamin who relies on this preselection and experts like Eve. A good menu bar is a comprehensive catalog of all the available top-level commands, whereas a good tool bar gives quick, convenient access to frequently used commands.
Organization
- A tool bar should contain only a few, frequently used operations.
- If the number of operations is above 5 they have to be grouped with separators.
- Limit the number of items so that it does not exceed a tool bar width of 1280 pixels with large icons.
- Use split buttons to group related features/actions into a single button.
- Start with generic functions at the first tool bar and put more application-specific stuff into the second tool bar. Do not stack more than two tool bars at once.
- Provide options for users to adjust the tool bar according to personal needs.
- Disable buttons that do not apply to the current context rather than hiding them.
- Do not stack tool bar items in case of small size but rather provide access to a menu via chevron control ( >> ). The menu should consists only of the wrapped items.
Text
- Do not add captions to tool bar buttons by default.
- Tooltips are essential for controls without labels and have to always get added and with special care for tool bar items. Tooltips should be written so that they are easily understood and informative. Use sentence-style capitalization for tooltips.
- Avoid overly verbose tooltips and rather move the explanatory part into the extended tooltip.
Notebookbar
- The Notebookbar is a blank canvas where UI controls can be placed freely in order to support migration from competitors, to cover varying scenarios and target users, and to provide specialized tools for different tasks.
- The classic toolbar will remain the default.
- Switching back to the default must always be possible and easy to find in the user interface.
- The Notebookbar respects the user configuration and adjusts in height, for instance, with larger icons.
- The number of Notebookbars delivered by default should be kept low. Ideally, Notebookbars can be shared and installed as an extension.
- It's encouraged to have Notebookbars that simulate alternative programs but "crazy" ideas with completely new UI approaches are also welcome.
- Not more than two flavors of a concept are accepted; ideally one for the Benjamins and the other for Eve.
- Whether additional concepts are accepted (or existing removed) is decided finally by the UX team.
- Changes to existing Notebookbars must be compliant with the concepts as described below.
Contextual Groups
- The major part has to remain static when changing the context. Functions at the static sections that are not relevant in the current context are still shown but disabled.
- Large buttons provide access to the most relevant functions, accompanied by medium and small sized buttons. Ideally, the large buttons get more attention by icons with more details, colors, or the like.
- All controls are labeled and the Notebookbar is grouped into logical sections, which are also labeled, both to support the quick location of the sought function.
- Only functions that execute a command (Save, Print etc.) and properties known to be in the toolbar (font style, size etc.) should be placed in this Notebookbar. Everything else is supposed to be done via sidebar.
- The total width must not exceed the defined maximum for the standard toolbar of 1280px.
Contextual Single
- to be removed
Tabbed / Tabbed Compact
- The Tabbed variants aim to provide a familiar interface for users coming from Microsoft Office. It's supposed to be used primarily without the sidebar.
- Functions are organized in tabs that support different workflows. The Home tab for core functions and several tabs depending on the module are accompanied by Contextual tabs, for example when a cursor is placed within a table.
- Functions are placed in two rows, or in case of the compact variant only one row.
- Functions are organized into logical groups starting with a big icon containing the most relevant function.
- The additional right-hand Menu group contains functions not directly related to the workflow.
- Labels are shown, if possible. For very common icons (e.g. alignment) or if the symbol is very clear (e.g. shapes) the label is omitted. Also, the Home tab contains only icons.
- Duplicate entries are intentionally added depending on the workflow.
- The maximum content size must not exceed a width of 1280px using small icons and English localization.
- On resizing, the overflow starts from right side group-wise; the first group icon will always be shown in the compact variant.
Groupedbar / Groupedbar Compact
- The design follows the mantra "Simple by default, powerful when needed".
- The basic principle is to access "first-level" functions with one click, and second-level functions with a maximum of two clicks
- Functions are not duplicated.
- The maximum width of the content is 1440px using small icons and English localization.
- The content is organized in groups with two rows containing the first-level functions (only one row in case of the compact variant) and another row with a dropdown menu containing the second-level functions. The dropdown label serves as caption for the group.
- The left groups containing File and Edit operations and the right-most Menu are static; everything else depends on the context.
References
- Gnome HIG Toolbars
- KDE TechBase: Toolbar
- Microsoft Windows Desktop Design Guidelines: Toolbars
- Apple macOS Human Interface Guidelines