Design Specifications and Guidelines - Visual Design

User Interface Text

User interface text in your application is text that appears on screen in both primary windows and secondary windows, such as dialog boxes, property sheets, wizards, message boxes, or controls. Clear, consistent, informative, and well-written text in these elements is essential for a usable interface. This section provides guidelines for writing and displaying interface text.

Font and Size

The default system font is a key element in the presentation of visual information. The default font used for interface elements in the U.S. releases of Windows 98 and Windows NT 4.0 is MS®Sans Serif 8 point. For applications that will run on Windows 2000, it is recommended you use Tahoma 8 point. For compatibility reasons, this font is not set by default in Windows 2000; you must explicitly select it. The Tahoma 8 point font offers improved readability and globalization support; in Windows 2000, it is the default font used by most of the interface elements in the operating system.

More Information

The GetSystemMetrics (for standard window elements), SystemParametersInfo (for primary window fonts), and GetStockObject (for secondary window fonts) functions provide current system settings. The WM_SETTINGCHANGE message notifies applications when these settings change. For more information about these APIs, see the Microsoft Platform SDK on the MSDN Online Web site.

The menu bar titles, menu items, control labels, and other interface text in each operating system use one of these two fonts. The title bar text also uses the bold setting for these fonts, as shown in Figure 14.23. However, because the user can change the system font, make sure you check this setting and adjust the presentation of your interface appropriately rather than assume a fixed size for fonts and other visual elements. Also adjust the presentation when the system notifies your application that these settings have changed.

Figure 14.23 Default font usage in windows (click to enlarge image)

The system provides settings for the font and size of many system components including title bar height, menu bar height, border width, title bar button height, icon title text, and scroll bar height and width. When you design your window layouts, take these settings into account so that your interface will scale appropriately. In addition, use the standard system settings to determine the size of your custom interface elements.

Except for title bars, avoid using bold or italic for interface text. In menus, bold text implies that the command is a default action.

The Basics of Writing Interface Text

The wording you use in your interface is a primary form of communication with the user. This section provides basic guidelines for writing effective user interface text.

More Information

For more information about text conventions for particular interface elements, see Chapter 7, "Windows," Chapter 8, "Menus, Controls, and Toolbars," and Chapter 9, "Secondary Windows." The Microsoft Manual of Style for Technical Publications is also a useful resource for terminology guidelines.

Abbreviations

Avoid using abbreviations unless the abbreviated form is as familiar to your users as the full word or phrase. If you use an abbreviation, follow these guidelines:

• Always use the spelled-out term the first time it appears in any part of the user interface and include the abbreviation in parentheses. Use the abbreviation alone in subsequent references within the same screen, on subsequent pages of a wizard, or in nested dialog boxes that the user can get to only after seeing the screen, page, or dialog box where the term is spelled out.
• Avoid using abbreviations in headings.
• Do not abbreviate product or feature names without approval from your legal and marketing representatives.

Access Keys

Always define an access key for the label of any control or menu item. The only exceptions are the OK and Cancel buttons because the ENTER and ESC keys typically serve as the access keys to these buttons. Also, avoid having the same access key used by more than one control in a single context or more than one item on the same menu.

Acronyms

You can use an acronym for a term that is not trademarked or for a well-known industry standard. At its first mention, if a term is an industry standard acronym — for example, HTTP — there is no need to spell it out. But for the first mention of most other acronyms, spell out the full term with the acronym in parentheses directly following — for example, Internet Control Message Protocol (ICMP). You can then use just the acronym in subsequent references on the same screen, on subsequent pages of a wizard, or in nested dialog boxes that the user can get to only after seeing the screen, page, or dialog box where the term is spelled out.

If you use an acronym in a heading, do not spell out its meaning. Instead, use and spell out the full term in the first sentence after the heading, if it hasn't been spelled out previously. You may be able to link to a separate glossary entry or spell out the term in the status bar instead of using the spelled-out term in the text.

Check with your marketing and legal representatives before you create acronyms specific to your product. Also, search your intranet and the Internet for the acronym to make sure it isn't already used for another purpose in your customers' industry.

Capitalization

Correct capitalization helps readers identify important words and breaks in text, as shown in Figure 14.24. Two styles of capitalization are used for interface text: book title capitalization (also referred to as title caps) and sentence-style capitalization (also known as sentence caps).

Figure 14.24 Capitalization and punctuation of user interface text (click to enlarge image)

For book title capitalization, capitalize the first letter of the first and last words. Also capitalize all words in between, with the exception of articles (such as a, an, and the); coordinate conjunctions (such as and, but, for, not, or, so, and yet); and prepositions of four letters or fewer (such as at, for, with, and into). For example:

Insert Object
Paste Link
Save As
Go To
Always on Top
By Name

Use book title capitalization for the following elements:

• Column headings
• Command button labels
• Icon labels
• Menu names and menu commands
• Palette titles
• Tab titles
• Title bar text
• Toolbars and toolbar button labels
• ToolTips
• Web page titles and Web navigational elements (unless otherwise defined by your page design)

For sentence-style capitalization, capitalize only the first letter of the initial word and other words normally capitalized in sentences, such as proper nouns. For example:

Working folder
Print to
Use Postscript driver

Use sentence-style capitalization for the following elements:

• Alternate text (alt text) used to describe images on Web pages
• Check box labels
• File names
• Group box labels
• List box entries
• Messages
• Option (radio) button labels
• Status bar text
• Text box labels

If the user supplies a name for an object, always display the name as the user specifies it, regardless of case, wherever the name appears, including in the title bar for a window.

Contractions

Contractions lend an often-desirable informal tone to the user interface and also save space. However, never form a contraction from a subject and its verb:

Ellipses

If a command requires additional information to complete its intended action, and you use a dialog box to supply that information, follow the command with an ellipsis (…). The ellipsis provides a visual cue that the command requires additional information.

Here are examples of when to use an ellipsis as part of a command's text:

• Include an ellipsis for a Save As command because the command is not complete until the user supplies or confirms a file name. Similar common examples include Browse, Open, Find, Add, and Customize.
• Include an ellipsis for a Print command when it opens the Print dialog box, where the user must confirm the print settings before printing.

However, not every command that results in the display of a window should include an ellipsis. Do not include an ellipsis for commands that simply display a window or view or change the existing view within a window. Similarly, do not use ellipses for commands that display a collection of objects or options, unless the intended action requires that the user select or confirm the selection of one or more elements of the collection. Also, do not include an ellipsis for commands that may result in a confirming message box.

Here are examples of when not to use an ellipsis as part of the command's text:

• Do not include ellipses for commands such as Cut, Copy, Paste, Undo, or Refresh. These commands perform direct actions; the user is not required to supply any information.
• Do not include ellipses for viewing commands such as Details, Outline, Print Preview, and Show Toolbar. Even if these views offer options, the intended action is complete when the view changes.
• Do not include ellipses for Help commands such as Index or Contents. The user can use these commands to select a Help topic, but the intended action is to display the HTML Help Viewer using a particular view.
• Do not include an ellipsis for an About command. This command typically displays copyright and version information about an application. Therefore, its intended action is complete when the window containing this information is displayed.
• Do not include an ellipsis for a Properties command. The user does not have to indicate what object to show properties for or what property to show. Even though the user can use this command to change options, the command's intended primary action is to display those options. Similar common examples include Options, Settings, Advanced, and Preferences.
• Do not include ellipses for commands such as Macros, Help Topics, and Fonts. The dialog boxes that display these collections may support additional actions, but the primary intended action of the command is to display the collection.
• Do not include an ellipsis for a Toolbox command or similar commands that display a palette of tools or options. The command's intended action to display the palette window is complete when the window appears.
• Do not include an ellipsis for a Close command, even though it may result in the display of a message box that prompts the user whether to save changes.

Keep in mind that the decision about whether or not to use an ellipsis can depend on the context of the command. You must take into consideration the command's intended action, the wording of the command, or, for menu items, the wording of the command's parent menu item. For example, a Print command that prints a document without displaying the Print dialog box should not include an ellipsis. A Font command on a Format menu should include an ellipsis because its intended action is to format the current selection with specific font settings, and the user must use the dialog box to define those settings.

If the object of the intended action is already defined, the Open command typically does not take an ellipsis. Contrast the command for a selected file icon in a standard folder window with the same command for the File menu in Notepad. In the first case, the user's selection before choosing the command supplies the necessary parameter of what to open, so no ellipsis is used. However, in the second case, the user must type or select the file to open, so an ellipsis should appear with the command. As a general rule, include an ellipsis if a command requires the user to supply "what," "where," or "how" information for the command to complete its intended action.

You can also use ellipses in other forms of interface text. For example, you can use ellipses to abbreviate path names or other information that may extend beyond the size of the field. Do not use an ellipsis in the title bar text of a window when the command that opened it included an ellipsis. Use an ellipsis in the title bar text only when you need to truncate the text. Whenever you use an ellipsis to abbreviate interface text, try to display as much information as possible to still enable the user to identify the item. Also, use other techniques such as ToolTips to display the full text.

Introductory or Instructional Text

Introductory or instructional text helps reduce or eliminate the text for online Help. Use introductory or instructional text in dialog boxes, Web views, and wizard pages to provide additional information about the task that the user wants to accomplish. Follow these guidelines for writing useful introductory or instructional text:

• Write text that is brief and to the point.
• Complement and expand on informative control labels but don't duplicate them.
• Position the text so that any relationship with a particular control is clear.
• Use sentence-style capitalization and ending punctuation.

More Information

For more information about instructional text for specific controls, see Chapter 8, "Menus, Controls, and Toolbars." For information about designing wizard pages, see Chapter 13, "User Assistance."

Numbers

Align numbers at the decimal point (or imaginary decimal point). Right-align a block or column of whole numbers or of whole numbers and text, as shown in Figure 14.25.

Figure 14.25 Right-alignment for block or columns of numbers

Punctuation

Follow normal rules of punctuation for your interface text. End a question with a question mark, but avoid phrasing control labels as questions. Separate sentences with one blank space, not two.

More Information

For more information about punctuating text for specific types of controls, see Chapter 8, "Menus, Controls, and Toolbars."

In a bulleted or numbered list, introduce the list with a sentence or sentence fragment that ends with a colon. Begin each entry in the list with a capital letter. End each entry with ending punctuation if all entries are complete sentences or complete the introductory phrase, as shown in Figure 14.26. Entries in a list should be parallel (have the same grammatical structure).

Figure 14.26 Punctuation for bulleted lists (click to enlarge image)

Writing Style

Before you begin writing, research your audience to determine the most useful writing style. For example, text in a program intended for novice users should be different from text in a program designed for network administrators. Style, which includes brevity, language, parallel construction, sentence structure, and voice, affects the readability and comprehensibility of text.

Brevity

Keep text in the user interface as brief as possible. Usability studies indicate that users are more likely to read short blocks of text than long ones. Review your work to eliminate wordiness, and keep user interface text short without sacrificing clarity and ease of localization:

• Focus on what the user must know. Do not include extraneous or optional information.

• Use simple and direct words and phrases, especially for the most prominent and often-used interface elements. Introduce more specific and advanced technical terms in dialog boxes.

• Use specific verbs. Watch for helping verbs, such as "make" and "be." These terms may indicate that a more specific verb is available. For example, instead of "…to make the window appear," say "…to display the window."

• Try to limit instructions for correcting an error to three simple steps.

• Replace several words with one whenever you can. Some examples are shown in the following table.

• Eliminate words that do not add value. For example:

  Actually
  Basically
  More or less
  To a certain degree
  Various

Language

Clear and consistent use of language can improve usability and ease localization. Use good, standard grammar. Grammar provides important clues to the meaning of terms in a sentence. Keep the following guidelines in mind:

• Write positive statements. Avoid using negative words, such as problem, bad, wrong, fail, error, fatal, terminate, and trouble. Instead, tell the user what the problem is, what to do, and why.

• Avoid redundancy. For example:

  Surrounding environment
  Absolutely complete
  Exactly identical
  Repeat again
  Final conclusion
  Basic and fundamental
  Knowledge and awareness
  Each and every
  Complete overview
  Advance planning
  Full and complete
  Informative message

• If you state the correct condition, do not also state that the incorrect condition should not exist. For example, if you say "The computer must be running," do not also say "It must not be shut off."

• Use consistent phrasing for similar situations. This avoids users assuming that a different meaning may be intended by a change in wording.

• Use the plural form of a word rather than using "(s)" (or use both the singular and plural forms).

Parallel Construction

Use the same grammatical structure for elements of sentences or phrases that provide the same kind of information. For example, use parallel construction for items in lists and groups of check box labels or option button labels. In the following example, all the items in the Correct list begin with verbs in the active voice and are phrased in the imperative mood. Items in the Incorrect list are in a mix of voice and mood.

Sentence Construction

Use sentences in the interface to explain concepts, introduce features, and discuss controls. Follow these guidelines when writing sentences:

• Write short, simple sentences. Break long sentences into two or more shorter sentences.
• Use lists or tables to break up text.
• Use the present tense.

  Correct	Incorrect
  Windows cannot find the file.	Windows could not find the file.

• Write affirmative statements, telling the user what to do rather than what to avoid (unless there is a reason the user should not perform a particular action).

  Correct	Incorrect
  To restart your computer, click Restart.	Do not use CTRL+ALT+DEL to restart your computer.

• When a sentence describes a sequence of actions, describe the actions in the order in which the user performs them.

  Correct	Incorrect
  Reinstall the program and then restart your computer.	You'll need to restart your computer after you reinstall the program.

• Avoid using a control within a sentence or phrase if the text will be localized. Instead, place it at the end of the sentence or phrase.

  Correct	Incorrect
  Number of concurrent connections per server: Control	Per server for Control concurrent connections.

For more information about localization, see Chapter 15, "Special Design Considerations."

Voice

Use the active voice to clarify who or what is performing the action in a sentence.

Terminology

You can help users learn your product more quickly by using terminology that is familiar to them and by using the same terminology for a particular concept throughout the interface. If your product will be localized, create a list of defined terms to localize.

Use familiar wording on menus, commands, control labels, and toolbars. Avoid technical jargon. Write so that the least skilled user of the application will understand.

Define terms that are unfamiliar or are used more narrowly or broadly in your product than in common use. For example, you can sometimes use descriptors to identify a term's meaning or purpose. This can help users understand the context of the term.

In general, use "click" to describe selecting command buttons, option buttons, hyperlinks, tabs, menus, and menu items. Use "select" to describe selecting items in a list box or gallery.

Use "press" to describe pressing a key on the keyboard. Use "type" when referring to typing words.

Use "select" and "clear" in instructions for a check box.

However, use "click to remove the check mark" rather than "clear" to describe removing a check mark from a menu item.

More Information

For the correct usage of Microsoft trademarks, copyrights, and product names, see the Microsoft Copyright Permission Web site at https://www.microsoft.com/permission.

Take care to avoid using words or phrases that may offend some users. The following guidelines can help writers and editors recognize terms that may inadvertently cause offense or convey an inappropriate message.

• In general, consider the person first, not the label. Use "a person with [kind of disability], not "the disabled person."
• When you refer to a user interface element or command, use "unavailable" or use "make unavailable" rather than "disabled" or "disable." The word "disable" is acceptable in technical documentation in the context of a programmer setting the guidelines for making a command unavailable.
• Use the following terms to describe people with disabilities or the disabilities themselves.

  Use these terms	Instead of
  Blind, has low vision, visually impaired	Sight-impaired, vision impaired
  Deaf or hard-of-hearing	Hearing-impaired
  Has limited dexterity, has motion disabilities	Crippled, lame
  Without disabilities	Normal, able-bodied, healthy
  One-handed, people who type with one hand	Single-handed
  People with disabilities	The disabled, disabled people, people with handicaps, the handicapped
  Cognitive disabilities, developmental disabilities	Slow learner, retarded, mentally handicapped
  TTY/TDD (to refer to the telecommunication device)	TT/TTD

Title Bars

Include a title for all primary and secondary windows. The only exceptions are as follows:

• Windows that automatically remove themselves at start-up, such as application title or splash screens
• Windows that time-out to avoid obscuring user interaction, such as balloon tips and pop-up windows for context-sensitive Help
• The volume control window that appears when a user clicks the volume icon in the taskbar notification area

Use book title capitalization unless you are displaying a user-defined name. In that case, use the capitalization that the user provides.

More Information

For more information about title bars, see Chapter 7, "Windows" and Chapter 9, "Secondary Windows."

The following table summarizes title bar text usage guidelines.

* If the application does not explicitly store user data (such as Calculator), then use just the application's product name. If the application is not the primary viewer of user data (such as QuickView) or the object more logically presents itself as a tool rather than as a representation of the user data (such as Find File), then display the program's name, followed by the data file.

Fundamentals of Designing User Interaction

Windows Interface Components

Design Specifications and Guidelines

Appendixes and References