Style Guide Is Not a UI Specification

Style guides are different from user interface specifications:

• A specification document details the functionality of a UI design for developers building an application. It is usually more descriptive and is often accompanied by wireframes that act as blueprints for the design. In contrast, a style guide is often a general outline of the elements of a UI design.

• Style guides have a longer shelf-life than specifications documents that are often tied to a project life-cycle. When an application is first created, some elements of the initial specification document might turn into the application style guide for long-term reference.

• Elements of a style guide may be referred to from a specification. For example, the functionality of a web application enhancement would be captured in a specifications document; but the operation of standard UI controls found throughout the website would be outlined in the website style guide and referred to by the specifications document.

Layout

Size controls and panes within a window to match their typical content. Avoid truncated text and their associated ellipses. Users should never have to interact with a window to view its typical content reserve resizing and scrolling for unusually large content. Specifically check:

• Control sizes. Size controls to their typical content, making controls wider, taller, or multi-line if necessary. Size controls to eliminate or reduce scrolling in windows that have plenty of available space. Also, there should never be truncated labels, or truncated text within windows that have plenty of available space. However, to make text easier to read, consider limiting line widths to 65 characters.

• Column widths. Make sure table view columns have suitable default, minimum, and maximum sizing. Choose table views default column widths that don't result in truncated text, especially if there is space available within the table view.

• Layout balance. The layout of a window should feel roughly balanced. If the layout feels left-heavy, consider making controls wider and moving some controls more to the right.

• Layout resize. When a window is resizable and data is truncated, make sure larger window sizes show more data. When data is truncated, users expect resizing windows to show more information.

Set a minimum window size if there is a size below which the content is no longer usable. For resizable controls, set minimum resizable element sizes to their smallest functional sizes, such as minimum functional column widths in list views.

Text

• Use ordinary, conversational terms when you can. Focus on the user goals, not technology. This is especially effective if you are explaining a complex technical concept or action. Imagine yourself looking over the user's shoulder and explaining how to accomplish the task.

• Be polite, supportive, and encouraging. The user should never feel condescended to, blamed, or intimidated.

• Remove redundant text. Look for redundant text in window titles, main instructions, supplemental instructions, content areas, command links, and commit buttons. Generally, leave full text in main instructions and interactive controls, and remove any redundancy from the other places.

• Use Headline style capitalization for menus, tooltip and all titles, including those used for windows, dialogs, tabs, column headings and push buttons. Capitalize the first and last words, and all nouns, pronouns, adjectives, verbs and adverbs. Do not include ending punctuation.

• Use Sentence style capitalization for all control labels in a dialog or window, including those for check boxes, radio buttons, group labels, and simple text fields. Capitalize the first letter of the first word, and any proper names such as the word Java.

• For feature and technology names, be conservative in capitalizing. Typically, only major components should be capitalized (using title-style capitalization).

• For feature and technology names, be consistent in capitalizing. If the name appears more than once on a UI screen, it should always appear the same way. Likewise, across all UI screens in the program, the name should be consistently presented.

• Don't capitalize the names of generic user interface elements,such as toolbar, menu, scroll bar, button, and icon.

  • Exceptions: Address bar, Links bar, ribbon.

• Don't use all capital letters for keyboard keys. Instead, follow the capitalization used by standard keyboards, or lowercase if the key is not labeled on the keyboard.

• Ellipses mean incompleteness.Use ellipses in UI text as follows:

  • Commands. Indicate that a command needs additional information. Don't use an ellipsis whenever an action displays another window---only when additional information is required. Commands whose implicit verb is to show another window don't take an ellipsis, such as Advanced, Help, Options, Properties, or Settings.

  • Data. Indicate that text is truncated.

  • Labels. Indicate that a task is in progress (for example, "Searching...").
    Tip: Truncated text in a window or page with unused space indicates poor layout or a default window size that is too small. Strive for layouts and default window sizes that eliminate or reduce the amount of truncated text. For more information, see #Layout.

• Don't use blue text that isn't a link, because users may assume that it is a link. Use bold or a shade of gray where you'd otherwise use colored text.

• Use bold sparingly to draw attention to text users must read.

• Use the main instruction to explain concisely what users should do in a given window or page. Good main instructions communicate the user's objective rather than focusing just on manipulating the UI.

• Express the main instruction in the form of an imperative direction or specific question.

• Don't place periods at the end of control labels or main instructions.

• Use one space between sentences. Not two.

Components

Interaction style

Error Handling

Language

Icons

Preferences

Help