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.
- 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.
- 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.
- 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.
- 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 flavours 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 exisiting Notebookbars must be compliant with the concepts as described below.
- 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, accompained 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 seeked 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.