Pattern 50: Acceptable wording *
AKA:

You are providing CONTEXT-SENSITIVE HELP (17) or textual FEEDBACK (41). At the same time you want to FOLLOW STANDARDS (36), EXPLOIT CLOSURE (39), PRIMING AND INTERFERENCE (18), and have NO MODES (40). You know that AESTHETICS (16) must be considered.

There are ways of phrasing that are unacceptable to some users. Different wordings suit different groups. We must determine how to make the wording of instructions suit both the context and the user. Also, any dialogue that the user may have with the site requires designing.

Therefore

Understand who the users are. Look for a universally inoffensive form of words if there is one. Then design user-specific pages if a general wording cannot be found. Always include an Other option in drop-down lists. Design dialogues carefully based on the use cases. Use the user’s terminology. And avoid jargon.

Make sure that you have also allowed for THE HALT AND THE LAME AND THE STRANGER AT THE DOOR (51). N.B. This pattern is not to be confused with the antipattern POLITICAL CORRECTNESS.

Designers should be sensitive to and understand the idiosyncasies of possible visitors. They should not impose their predjudices on users or act like cultural imperialists. Nor should they irritate users with inappropriately chosen words.

Don’t assume that users know what is obvious to you about your business processes or that that know your jargon. Many sites have failed because of this.

Examples
Not allowing a user to live in Wales (a country) or Great Britain (an island), offering only UK (which is not a country but a – possibly short-lived – state!)

Printing APPLICATION ABORTED on a gynaecological site.

Insisting that Quakers (or anyone else for that matter) describe themselves as Mr something. It’s so old fashioned.

Good dialogue design requires consistency, informative feedback and simple error handling. Frequent users should be able to take shortcuts. The system should exploit and indicate the phenomenon of closure. Undo/redo facilities are often useful but can be problematic in cases where some actions cannot be consistently undone or redone. Dialogues should be user driven and not modal, when possible. The designer should attempt to reduce the load placed on the working memory of the user – exploiting priming, transfer effects, closure and other devices. The use of words and language itself can be important. Table 50.1 below illustrates this point.

Table 50.1 Use of language in error messages

Error message	Evaluation
ABORT: error 451	Bad
I’m tremendously sorry but I have discoveredthat a file you want to use is alreadyopen (error number 451).	Better but far too verbose
Error number 451. File already open. This error normally occurs when you forgot to close the fileat the end of a previous subroutine.	Better but tedious
Error number 451: File already open.Explain?<Y/N>:	Good-ish
Left as an exercise to the reader!	Perfect

Error messages should be consistent, friendly and constructive, informative, precise and use the users’ terminology. Multiple levels of message are often helpful. Hypertext help systems are a simple way to meet most of these requirements.

Command languages should exhibit uniform abbreviation rules, be consistent and follow standards. Old counter-examples from DOS include multiple ways of abbreviating directory commands (CHDIR, CD, DIR, etc.). Also, in different operating systems from the same manufacturer it used to be common to find several words being used for the same purpose; e.g. CATALOG/DIRECTORY or HELP/ASSIST/AID.

Lyardet and Rossi (2001) have a closely related pattern called SUBJECTIVE ACCESS.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites