Text Style Guidelines

Text is prevalent throughout the OS X interface for such things as button names, menu labels, dialog messages, and help tags. Using text consistently and clearly is a critical component of UI design.

In the same way that it is best to work with a professional graphical designer on the icons and images in your app, it’s best to work with a professional writer on your app’s user-visible text. A skilled writer can help you develop a style of expression that reflects your app’s design, and can apply that style consistently throughout your app.

For guidance on Apple-specific terminology, the writer should refer to the Apple Style Guide. That document covers style and usage issues, and is the key reference for how Apple uses language.

For issues that aren’t covered in the Apple Publications Style Guide, Apple recommends three other works: The American Heritage Dictionary, The Chicago Manual of Style, and Words Into Type. When these books give conflicting rules, The Chicago Manual of Style takes precedence for questions of usage and The American Heritage Dictionary for questions of spelling.

Inserting Spaces Between Sentences

If any part of your app's user interface displays two or more sentences in a paragraph, be sure to insert only a single space between the ending punctuation of one sentence and the first word of the next sentence.

Although much of the text in an app's user interface is in the form of labels and short phrases, app help, alerts, and dialogs often contain longer blocks of text. You should examine these blocks of text to make sure that extra spaces don't appear between sentences.

Using the Ellipsis Character

When it appears in the name of a button or a menu item, an ellipsis character (…) indicates to the user that additional information is required before the associated operation can be performed. Specifically, it prepares the user to expect the appearance of a window or dialog in which to make selections or enter information before the command executes.

Because users expect instant action from buttons and menu items (as described in “Buttons” and “Menu Appearance and Behavior”), it's especially important to prepare them for this alternate behavior by appropriately displaying the ellipsis character. The following guidelines and examples will help you decide when to use an ellipsis in menu item and button names.

Use an ellipsis in the name of a button or menu item when the associated action:

Don't use an ellipsis in the name of a button or menu item when the associated action:

An ellipsis character can also show that there is more text than there is room to display in a document title or list item. If, for example, the name of an item is too long to fit in a menu or list box, you should insert an ellipsis character in the middle of the name, preserving the beginning and the end of the name. This ensures that the parts of the name that are most likely to be unique are still visible.

Using the Colon Character

Use the colon character (:) in text that introduces and provides context for controls. The text can describe what the controls do or a task the user can perform with them. The combination of introductory text, colon, and controls forms a visually distinct grouping that helps users find the controls that apply to a particular task and understand what the controls do.

Because a colon implies a direct connection between the descriptive text and a particular control or set of controls, it does not belong in the text that appears in a control, such as a push button name or a command pop-down menu title. Similarly, you should not use a colon in the text that appears in the following user interface elements:

Although the colon is a good way to associate introductory text with related controls, be aware that you can depict this connection in other ways. For example, you might use a tab view to display different groups of related controls (for guidelines on how to use this control, see “Tab View”).

Don’t use a colon in the text that serves as a group box title. In these cases, the group box itself takes the place of the colon and makes explicit the relationship of the introductory text to the controls that follow it.

../art/tx_groupboxtitle_2x.png

If you choose to use a colon to show the relationship between introductory text and controls, the following guidelines and examples will help you use it appropriately.

Use a colon in introductory text that precedes a control or set of related controls. The text can be a noun or phrase that describes either the target of the control or the task the user can perform. The following examples illustrate some variations on this arrangement of text and controls:

A colon is optional before a control that is part of a sentence or phrase. This guideline is flexible because it depends on how much of the text follows the control and how the sentence or phrase can be interpreted. Consider the specific combination of text and controls and the overall layout of your window as you decide whether to use the colon in the following situations.

If, for example, none of the text follows the control, then the control's value supplies the end of the sentence or phrase. A colon is recommended in this case, because this is another variation of the guideline to include a colon in text that precedes a control. For example, the term “Genie effect” completes the sentence that begins “Minimize windows using:”

../art/tx_colonendofphrase.jpg

If, on the other hand, a substantial portion of the sentence or phrase follows the control a colon is optional.

../art/tx_nocoloninsentence.jpg

Similarly, if there is some text following the control, but that text does not represent a substantial portion of the sentence or phrase, the colon is optional. To help you decide whether a colon is appropriate in these cases, determine if the presence of a colon breaks the sentence or phrase (including the value of the control) in an awkward or unnatural way.

Labeling Interface Elements

Make labels for interface elements easy to understand and avoid technical jargon as much as possible. Try to be as specific as possible in any element that requires the user to make a choice, such as radio buttons, checkboxes, and push buttons. Although it’s important to be concise, don’t sacrifice clarity for space.

When the context of a label is clear, it’s usually best to avoid repeating the context in the label. For example, within the context of an extended Save dialog, it’s clear that the dialog acts upon a file or document, so there’s no need to add the words “File” or “Document” to the Format pop-up label. Similarly, users understand that the items in an app’s Edit menu act upon the current editing context, so there is seldom a need to make this explicit in the menu item names.

The capitalization style you should use in the label for an interface element depends on the type of element. For information on the proper way to capitalize the words in labels for different types of interface elements, see “Capitalizing Labels and Text.”

The names of menu items and buttons that produce a dialog should include an ellipsis (…). For details on when to use an ellipsis, see “Using the Ellipsis Character.” The dialog title should be the same as the menu command or button label (except for the ellipsis) used to invoke it.

Capitalizing Labels and Text

All interface element labels should use either title style capitalization or sentence style capitalization.

Title style capitalization means that you capitalize every word except:

In title style, always capitalize the first and last word, even if it is an article, a conjunction, or a preposition of four or fewer letters.

Sentence style capitalization means that the first word is capitalized, and the rest of the words are lowercase, unless they are proper nouns or proper adjectives. If the text forms a complete sentence, end the sentence with proper punctuation; otherwise, don't add ending punctuation.

Table 9-1 lists several examples of ways to capitalize text within UI elements.

Table 9-1  Proper capitalization of onscreen elements

Element

Capitalization style

Examples

Menu titles

Title

Highlight Color

Number of Recent Items

Location

Refresh Rate

Menu items

Title

Save a Version

Add Sender to Contacts

Log Out

Make Alias

Go To…

Go to Page…

Outgoing Mail

Push buttons

Title

Add to Favorites

Don’t Save

Set Up Printers

Restore Defaults

Set Key Repeat

Toolbar item labels

Title

Reading List

Zoom to Fit

New Folder

Reply All

Get Mail

Labels that are not full sentences (for example, group box or list headings)

Title

Mouse Speed

Total Connection Time

Account Type

Options that are not strictly labels (for example, radio button or checkbox text), even if they are not full sentences

Sentence

Enable polling for remote mail

Cache DNS information every ___ minutes

Show displays in menu bar

Maximum number of downloads

Dialog messages

Sentence

Checking for new software…

Are you sure you want to quit?

Using Contractions

When space is at a premium, such as in pop-up menus, contractions can be used, as long as the contracted words are not critical to the meaning of the phrase. For example, a menu could contain the following items:

In each case, the contraction does not alter the operative word for the item. If a contraction does alter the significant word in a phrase, such as “contains” and “does not contain,” it is clearer to avoid the contraction.

You should also avoid using uncommon contractions that may be difficult to interpret and localize. In particular, you should:

Using Abbreviations and Acronyms

Abbreviations and acronyms can save space in a user interface, but they can be confusing if users don't know what they mean. Conversely, some abbreviations and acronyms are better known than the words or phrases they stand for, and an app that uses the spelled-out version can seem out-of-date and unnecessarily wordy.

To balance these two considerations, you should gauge an acronym or abbreviation in terms of its appropriateness for your app's users. Therefore, before you decide which abbreviations and acronyms to use, you need to define your user audience and understand the user's mental model of the task your app performs. (For more information about this concept, see “Mental Model.”)

To help you decide whether or not to use a specific abbreviation or acronym in your app's user interface, consider the following questions:

If you use a potentially unfamiliar acronym or abbreviation in the user help book for your app, be sure to define it when you first use it. In addition, you should enable searching on your help book so users can easily find definitions of unfamiliar terms. For an overview of help technologies, see “User Assistance”; for details on working with Apple Help, see Apple Help Programming Guide.