[kde-guidelines] Styleguide: Toolbar

[David Edmundson]

On Wed, Oct 2, 2013 at 12:05 PM, Heiko Tietze
<heiko.tietze at user-prompt.com> wrote:
> Viewing and Navigation > Access functions
> * Provide a toolbar for frequently used functions.
> http://techbase.kde.org/Projects/Usability/HIG/Toolbar
>
> == 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.
> * Avoid using menu-, split-, and toggle

What's a split button?
I

> [[Projects/Usability/HIG/Buttons|buttons]] in tool bars. They do not fit
> well the concept of fast access.
> * 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 ===
> * By default, represent tool bar buttons with icons only: Visual design
> should stay for itself. But consider to show captions as well in case of
> unusual functions or if users configure it.

This could be just:
Do not change the QToolbar::toolButtonStyle from the default.

Also this is not the default currently. The default is text beside icons.

If this spec doesn't match what goes into Oxygen, we'll have two
conflicting rules.
People will take this as just "someone's vision on what KDE should be
like" and not an agreed upon specification. If that happens this all
becomes wasted, which we don't want.

> * 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
> [[Projects/Usability/HIG/IconDesign|icon design]].

> * Use small icons in standard applications and larger icons for tool
> windows.

Do we do this?
With my programmer hat on, again this should be left up to the QStyle
and left alone by developers. The HIG will then be "don't change the
icon sizes"


> * Do not simulate Microsoft's ribbon controls. KDE stays plain and simple.
> ==  Implementation ==
>
> [[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Access_functions]]
>
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>