Projects/Usability/HIG/Labels: Difference between revisions

    From KDE TechBase
    < Projects‎ | Usability‎ | HIG
    No edit summary
    Line 46: Line 46:
    * {{qt|QLabel}}
    * {{qt|QLabel}}
    * [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKSqueezedTextLabel.html KSqueezedTextLabel]
    * [http://api.kde.org/4.10-api/kdelibs-apidocs/kdeui/html/classKSqueezedTextLabel.html KSqueezedTextLabel]
    [[Category:Usability]][[Category: Presentation]][[Category:Text]]

    Revision as of 13:38, 9 January 2014

    Purpose

    Common controls should behave ‘common’ and look like everyday controls. Therefore, it is much recommended to use standard font. Bold or italic font should not be applied to control labels.

    Guidelines

    • Keep labels short; be aware that translated English text can expand up to 30% in some languages.
    • Do not shorten your labels to the point of losing meaning, however. A three-word label that provides clear information is better than a one-word label that is ambiguous or vague. Try to find the fewest possible words to satisfactorily convey the meaning of your label.
    • When the label is associated with another control, like a line edit, be sure to set the the line edit as the buddy of the label.

    Dialogs

    • If a dialog is user initiated, identify it using the command or feature name.
    • If it is program or system initiated (and therefore out of context), label it using the program or feature name to give context.
    • Do not use the title to explain what to do in the dialog – that's the purpose of the main instruction.

    Menus

    • Prefer verb-based names; Avoid generic, unhelpful verbs, such as Change or Manage.
    • Use singular nouns for commands that apply to a single object, otherwise use plural nouns.
    • For pairs of complementary commands, choose clearly complementary names. Examples: Add/Remove, Show/Hide, or Insert/Delete.
    • Choose menu item names based on user goals and tasks, not on technology.
    • Assign access keys to all menu items (Alt+Letter).

    Buttons

    • Label command buttons with an imperative verb.
    • Do not use ending punctuation for labels.
    • Describe the action that the button performs in a tooltip.
    • End the label with an ellipsis if the command requires additional information to execute.
    • Assign access keys to all buttons (Alt+Letter).

    Links

    • Choose a concise, self-explanatory label that clearly communicates and differentiates what the command link does.
    • Do not use ellipses.

    Tabs

    • Label tabs based on their pattern. Use nouns rather than verbs, without ending punctuation.
    • Do not assign an access key. Tabs are accessible through their shortcut keys (Ctrl+Tab, Ctrl+Shift+Tab).

    Check boxes and Radio buttons

    • Label every check box or radio button.
    • Assign a unique access key to each label.
    • Write the label as a phrase or an imperative sentence, and use no ending punctuation.
    • Write the label so that it describes the selected state.
    • For a group, use parallel phrasing and try to keep the length about the same for all labels.
    • For a group, focus the label text on the differences among the options.
    • Use positive phrasing. Don't phrase a label so that selecting means not to perform an action.
    • Describe just the option with the label. Keep labels brief so it's easy to refer to them in messages and documentation.

    Group box

    • Use the group label to explain the purpose of the group, not how to make the selection. End each label with a colon.
    • Do not assign an access key to the label.
    • For a selection of one or more dependent choices, explain the requirement on the label.

    Implementation