Projects/Usability/HIG/Buttons: Difference between revisions

    From KDE TechBase
    < Projects‎ | Usability‎ | HIG
    (HIG moved to community)
     
    (3 intermediate revisions by 2 users not shown)
    Line 1: Line 1:
    __NOTOC__
    {{ Moved To Community | KDE_Visual_Design_Group/HIG/Buttons }}
     
    == Push Button ==
    A ''push button'' initiates an action when the user clicks it.
     
    [[File:Button-HIG.png]]
     
    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.
    * Do not use the delayed (menu) button pattern.
     
    ===  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.