C H A P T E R 1 0

Text

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. Figure 10-7 shows an example of this type of text.

Figure 10-7 A colon is recommended in a sentence that is completed by a control's value

If, on the other hand, a substantial portion of the sentence or phrase follows the control, as shown in Figure 10-8 a colon is optional.

Figure 10-8 A colon is optional if the text following the control forms a substantial part of the sentence

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.

Labels for 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. It’s important to be concise, but don’t sacrifice clarity for space. See “Capitalization of Interface Element Labels and Text” (page 131) for information on the proper way to capitalize the words in interface element labels.

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

Capitalization of Interface Element Labels and Text

All interface element labels should be capitalized in either title style or sentence style. See Table 10-2 (page 132) for examples of how to do this.

Title style means that you capitalize every word except:

■Articles (a, an, the)

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.

C H A P T E R 1 0

Text

■Coordinating conjunctions (and, or)

■Prepositions of four or fewer letters, except when the preposition is part of a verb phrase, as in “Starting Up the Computer.”

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 means that the first word is capitalized, and the rest of the words are lowercase, unless they are proper nouns or proper adjectives. Use periods in dialogs only after complete sentences.

132 Style

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.

C H A P T E R 1 0

Text

Using Contractions in the Interface

When space is at a premium, such as in pop-up menus, contractions may 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:

Don’t Allow Printing

Don’t Allow Modifying

Don’t Allow Copying

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:

■Avoid forming a contraction using a noun and a verb, such as in the sentence "Apple's going to announce a new computer today."

■Avoid using less common contractions, such as "it'll" and "should've."

Using Abbreviations and Acronyms in the Interface

Abbreviations and acronyms can save space in a user interface, but they can be confusing if users do not know what they mean. Conversely, some abbreviations and acronyms are better known than the words or phrases they stand for, and an application 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 application'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 application performs. For more information on these concepts, see “Know Your Audience ” (page 25) and “Reflect the User’s Mental Model” (page 39)

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

■Is this an acronym or abbreviation that your users understand and feel comfortable with? For example, almost all users are used to using CD as the abbreviation for compact disc, so even applications intended for novice users can use this abbreviation.

On the other hand, an application intended for users who work with color spaces and color printing can use CMYK (which stands for cyan magenta yellow key), even though this abbreviation might not be familiar to a broader range of users.

■Is the spelled-out word or phrase less recognizable than the acronym or abbreviation? For example, many users are unaware that Cc originally stood for the phrase carbon copy, the practice of using carbon paper to produce multiple copies of paper documents. In addition, the meanings of Cc and carbon copy have diverged so that they are no longer synonymous. Using carbon copy in place of Cc, therefore, would be confusing to users.

For some abbreviations and acronyms, the precise spelled-out word or phrase is equivocal. For example, DVD originally stood for both digital video disc and digital versatile disc. Because of this ambiguity, it's not helpful to use either phrase; it's much clearer to use DVD.

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.

C H A P T E R 1 0

Text

If you use a potentially unfamiliar acronym or abbreviation in the user help book for your application, 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. See “User Assistance” (page 80) for an overview of help technologies and Apple Help Programming Guide for details on working with Apple Help.

Developer Terms and User Terms

Don’t use technical jargon or programming terms in interface elements or user documentation. Table 10-3 shows a few examples; more are in Apple Publications Style Guide (available at the Mac OS X developer documentation website).

Table 10-3 Translating developer terms into user terms

134 Style

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.