Difference between revisions of "Projects/Usability/HIG/Buttons"

< Projects‎ | Usability‎ | HIG
Jump to: navigation, search
(Is this the right control)
(HIG moved to community)
 
(5 intermediate revisions by 3 users not shown)
Line 1: Line 1:
__NOTOC__
+
{{ Moved To Community | KDE_Visual_Design_Group/HIG/Buttons }}
 
+
== Purpose ==
+
A ''push button'' initiates an action when the user clicks it.
+
 
+
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.
+
** Do not use the delayed menu button pattern.
+
* 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.
+
* 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.
+
* 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 [[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]
+
 
+
[[Category:Usability]][[Category:Behavior]][[Category:Viewing_and_Navigation]][[Category:Access_functions]]
+

Latest revision as of 11:26, 4 August 2016

This page is now on the community wiki.


This page was last modified on 4 August 2016, at 11:26. Content is available under Creative Commons License SA 3.0 as well as the GNU Free Documentation License 1.2 unless otherwise noted.