From KDE-HIG_Wiki

Toolbars

Toolbars provide quick access to the application's commonly used actions. Toolbars mostly contain buttons, in some applications also drop-down menus or url bars.

Unlike dockers, toolbars do not provide complex input widgets used in dialogs such as radio buttons, sliders or the like.

Designing Toolbars

Guidelines

Selecting the right actions

• By default, only include frequently used/accessed actions.
• Make sure all actions on the toolbar are accessible via the menu, either directly or indirectly via a dialog.

Grouping the actions

• Group actions along their context of use, not by technical relations.
  If your menu structure is well designed, it may correspond to the groups in menus (see Designing Menus) - but make sure you only adopt the most important actions!
• Provide the major application actions in a main toolbar.
• Put additional categories of user actions in separate toolbars (e.g. Font styles, Search).
• Use button groups for groups of related user actions.
• Don't put more than 4 user actions into a button group.
• Don't put more than 12 actions into a toolbar.

Menu buttons, split buttons or checkable buttons?

• Use exclusive checkable buttons rarely, and only when their exclusive relation is inherently clear. (e.g. alignment: left, center, right).
• Don't use exclusive checkable buttons for more than 2-3 options.

• Otherwise use a menu button or split button.
• Don't put options directly onto the toolbar which are also in a toolbar menu, (e.g. "Icon view" is directly on the toolbar and in the "Views" toolbar menu).

Location and orientation

• By default, provide the toolbar horizontally below the menu bar.
• Allow the user to change these settings via the default KDE configuration options.
• Save modifications to the default settings and reload them after startup.
• Don't use vertical toolbars by default.

Text labels

• Provide toolbar names for each menu action.
• Toolbar names must be shorter than 2-3 words or 15 characters.
• Use as short and descriptive labels as possible, e.g. "Bigger Font" instead of "Enlarge Font", or simply "Bigger".

Context sensitive toolbars

Context sensitive toolbars show up automatically on certain user actions, e.g. when an image is selected in a text editor, an image properties toolbar shows up.

• Don't use toolbars for this purpose. Use dockers instead.

Standard Toolbars

Guidelines

Application Toolbars

Mail

Main toolbar:

• New Print | Check Mail[v] | Reply[v] Forward[v] | Previous Next | Trash | Spam Ham

Submenus:

• Check Mail >> Check all accounts | [account name] [account name]
• Reply >> Reply Reply all |
• Forward >> Forward inline Forward as attachment

Optionally:

• Tagging: [user-defined tags]

Web

Main toolbar:

• Previous[v] Next[v] Refresh Stop | Home Bookmark [location bar] | [web search bar]

(this assumes that the clear location bar button is integrated with the location bar)

Bookmarks toolbar:

• Only toolbar bookmarks, not not show all bookmarks here.

File

Main toolbar:

• Up Previous[v] Next[v] Refresh Stop | Icon view List view Column view | Locations[v] [location bar]

Image Viewer

Main toolbar:

• Previous Next Refresh | Fit Smaller Larger | RotateL RotateR [opt: Crop] | [Location]

Toolbar Components

Todo:

• Zoom
• Navigation in Documents

Rationale

Implementation Suggestions

Todo:

• Toolbar names
• Button groups
• Standard toolbars as classes (?)

Accessibility Notes

Keyboard Access

Note: This is currently not possible, but should be in the future!!

• Integrate toolbars with the application's tab order in a meaningful manner.

See Also

Related To

• Dockers: Another way to provide comfortable access to important functions.
• Status Bar: If you plan to offer actions in the status bar, make sure you do not duplicate functionality from the toolbar.
• Sidebars