Projects/Usability/HIG/Buttons: Difference between revisions

From KDE TechBase
< Projects‎ | Usability‎ | HIG
(Reword a bit, add Implementation section)
No edit summary
Line 1: Line 1:
= Purpose =
__NOTOC__


A button initiates an action when the user clicks it.
== Purpose ==
A ''push button'' initiates an action when the user clicks it.


= Guidelines =
Buttons are graphical controls that provides the user a simple way to initiates an action. A button indicates it's functionality by changing the frame corresponding to system’s theme on mouse hover. Buttons become active when user tabs to it. Active buttons are indicated as those by a frame. When the user clicks or presses the button the shading is changed.
* Use [[Projects/Usability/HIG/Capitalization|title style capitalization]] for the label.
 
* Buttons are not dynamic: their icon and label should not change depending on the context. [[Projects/Usability/HIG/Toggle_Buttons|Toggle buttons]] are a special case where a button has a state.
Buttons have the benefit of affordance, i.e. their visual properties (they look like they can be pushed) suggest how they are used.
 
== Guidelines ==
=== Is this the right control ===
Buttons are available in several flavors:
* Command button
** Use a command button to initiate an immediate action.
** Do not use a command button for navigation to another page (prefer a [[Projects/Usability/HIG/Links|link]] in this case).
** Do not use a command button embedded in a body of text.
** Do not use command buttons for a group of actions. Consider to use radio buttons with one 'Apply' option or a menu button.
* Menu button
** Use a menu button when you need to execute one action out of a small set of related functions.
** Indicate the menu by a single downward-pointing triangle.
** Clicking the button will drop down the menu only.
* Split button
** Apply a split button when one of the commands is used by default.
** Clicking the left part (or right in case of RTL alignment) of a split button starts the default action; clicking the split area opens the menu.
** Change the default item to the last action when the user is likely to repeat the command.
* Toggle button
** A toggle button is not a push button. Guidelines can be found [[Projects/Usability/HIG/Toggle_Buttons|here]].
===  Behavior ===
* Buttons are not dynamic: their icon and label should not change depending on the context (except special split buttons).
* Do not initiate an action on right-click or double-click.
* Do not initiate an action on right-click or double-click.
* Provide feedback when user is not aware to results or when results are not available instantaneous. Display a busy pointer or present a progress bar to users (see [[Projects/Usability/HIG/ProgressIndicator|progress indicator]]).
* Denote the relationship between buttons with other controls by placing them logically together.
===  Appearance ===
* Indicate a command that needs additional information (including confirmation) by adding an ellipsis at the end of the button label.
* Buttons have an elevated appearance; do not make buttons flat (except in toolbars).
* Prefer using icons on buttons only for OK, Apply or Cancel like actions. Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons.
* Prefer using icons on buttons only for OK, Apply or Cancel like actions. Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons.
 
* If icons are applied (or not), this style should be used consistently for a group of buttons.
= Implementation =
* For buttons with text labels, use a minimum button width of 96px and the standard button height. Don't use narrow, short, or tall buttons with text labels.
[http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKPushButton.html KPushButton]
* If the same button appears in more than one window, use the same label and access key. Locate them in approximately the same place in each window.
* Use [[Projects/Usability/HIG/Capitalization|title style capitalization]] for the label.
* Use a verb or verb phrase for the title of a push button.
=Implementation ==
* [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKPushButton.html KPushButton]

Revision as of 10:21, 20 September 2013


Purpose

A push button initiates an action when the user clicks it.

Buttons are graphical controls that provides the user a simple way to initiates an action. A button indicates it's functionality by changing the frame corresponding to system’s theme on mouse hover. Buttons become active when user tabs to it. Active buttons are indicated as those by a frame. When the user clicks or presses the button the shading is changed.

Buttons have the benefit of affordance, i.e. their visual properties (they look like they can be pushed) suggest how they are used.

Guidelines

Is this the right control

Buttons are available in several flavors:

  • Command button
    • Use a command button to initiate an immediate action.
    • Do not use a command button for navigation to another page (prefer a link in this case).
    • Do not use a command button embedded in a body of text.
    • Do not use command buttons for a group of actions. Consider to use radio buttons with one 'Apply' option or a menu button.
  • Menu button
    • Use a menu button when you need to execute one action out of a small set of related functions.
    • Indicate the menu by a single downward-pointing triangle.
    • Clicking the button will drop down the menu only.
  • Split button
    • Apply a split button when one of the commands is used by default.
    • Clicking the left part (or right in case of RTL alignment) of a split button starts the default action; clicking the split area opens the menu.
    • Change the default item to the last action when the user is likely to repeat the command.
  • Toggle button
    • A toggle button is not a push button. Guidelines can be found here.

Behavior

  • Buttons are not dynamic: their icon and label should not change depending on the context (except special split buttons).
  • Do not initiate an action on right-click or double-click.
  • Provide feedback when user is not aware to results or when results are not available instantaneous. Display a busy pointer or present a progress bar to users (see progress indicator).
  • Denote the relationship between buttons with other controls by placing them logically together.

Appearance

  • Indicate a command that needs additional information (including confirmation) by adding an ellipsis at the end of the button label.
  • Buttons have an elevated appearance; do not make buttons flat (except in toolbars).
  • Prefer using icons on buttons only for OK, Apply or Cancel like actions. Passive actions like those in the "System Settings => Application Appearance => Fonts" do not have icons.
  • If icons are applied (or not), this style should be used consistently for a group of buttons.
  • For buttons with text labels, use a minimum button width of 96px and the standard button height. Don't use narrow, short, or tall buttons with text labels.
  • If the same button appears in more than one window, use the same label and access key. Locate them in approximately the same place in each window.
  • Use title style capitalization for the label.
  • Use a verb or verb phrase for the title of a push button.

Implementation