Projects/Usability/HIG/Toolbar: Difference between revisions

    From KDE TechBase
    < Projects‎ | Usability‎ | HIG
    Line 16: Line 16:
    * Execute operations immediately; do not require additional input from user.
    * Execute operations immediately; do not require additional input from user.
    * Do not use [[Projects/Usability/HIG/Buttons|menu buttons]] in tool bars. They do not fit well the concept of fast access.
    * Do not use [[Projects/Usability/HIG/Buttons|menu buttons]] in tool bars. They do not fit well the concept of fast access.
    * Try to avoid using split or [[Projects/Usability/HIG/Toggle_Buttons|toggle buttons]] in order to keep the interaction with all buttons in the tool bar consistent.
    * Try to avoid using [[Projects/Usability/HIG/Buttons|split buttons]] or [[Projects/Usability/HIG/Toggle_Buttons|toggle buttons]] in order to keep the interaction with all buttons in the tool bar consistent.
    * Do not hide tool bars by default.  If configurable, users should easily be able to make the tool bar viewable again.  
    * Do not hide tool bars by default.  If configurable, users should easily be able to make the tool bar viewable again.  
    * Disable buttons that do not apply to the current context.
    * Disable buttons that do not apply to the current context.

    Revision as of 17:14, 4 October 2013


    Purpose

    A tool bar is a graphical presentation of commands optimized for fast access. Typically, a toolbar contains buttons that correspond to items in an application's menu, providing direct access to application's most frequently used functions.

    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.

    Examples

    Guidelines

    Is this the right control

    • For standard applications, apply a tool bar by default.
    • Provide a tool bar in addition to the menu bar, but do not replace the menu bar.

    Behavior

    • 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. Not more than 3 of those sections should be implemented.
    • Do not abuse the tool bar to expose application's features. Only the most frequently functions should be add to the tool bar.
    • Execute operations immediately; do not require additional input from user.
    • Do not use menu buttons in tool bars. They do not fit well the concept of fast access.
    • Try to avoid using split buttons or toggle buttons in order to keep the interaction with all buttons in the tool bar consistent.
    • Do not hide tool bars by default. If configurable, users should easily be able to make the tool bar viewable again.
    • Disable buttons that do not apply to the current context.
    • Consider to provide customization for tool bars in respect to position and content.

    Appearance

    • Do not change the button style (QToolbar::toolButtonStyle) from the default. The default is currently text beside icons.
    • Use and design tool bar icons with special care. Users remember location of an object but rely as well on icon properties.
    • A distinct association between the underlying function and its visual depiction is crucial. Follow the advices for icon design.
    • Do not simulate Microsoft's ribbon controls. KDE stays plain and simple.

    Implementation