Does anyone use a style guide for error messages?

Question

I noticed that error messages are usually written in several common styles. Either in full-length, random sentences, or in shortened passive sentences that do not always form a complete sentence. The last of the two seems to be more common - although perhaps not as often as randomly mixing styles that I see in many applications.

Does anyone include error messages in their style guide? I am more interested in the opinion about the consistent grammatical construction of these things than about the content of them, as already mentioned.

Answer 1

Both the iPhone Human Interface Guides and the Apple Human Interface Guides contain warning sections.

In addition, the Windows User Engagement Guide contains information for several types of dialogs, including error messages.

(iPhone)

When you create the required alert header:

• Keep the title short enough to display on a single line if possible. A long warning title is difficult for people to read quickly, and this can truncate or force an alert message to scroll.
• Avoid single-word names that do not provide any useful information, such as “Error” or “Warning”.
• Use a sentence snippet if possible. Short, informative is often easier to understand than a complete sentence.
• Feel free to be negative. People understand that most alerts tell them about problems or warn them about dangerous situations. it is better to be negative and direct than it should be positive but inclined.
• Do not use "you", "your", "I" and "mine" as much as possible. Sometimes, a text that identifies people directly can be ambiguous and can even be interpreted as an insult.
• Use capital letters without punctuation if:
• Title - sentence fragment
• The name consists of one sentence that is not a question.
• Use capital letters in the sentence style and the final question mark if the name consists of one sentence is a question. In general, consider a warning header if it allows you to not add a message.
• Use capitalization in sentence style and appropriate punctuation for each sentence if the title consists of two or more sentences. A two sentence warning header should rarely be necessary, although you might think if it allows you not to add a message.

If you provide an optional alert:

• Create a short, complete sentence that uses the capitalization sentence style and the corresponding ending punctuation marks.
• Avoid creating too long a message. If possible, keep the message short enough to display on one or two lines. If the message is too long it will scroll, which is not a good user experience.

Avoid lengthening your warning text with a description of which button to click , for example, "Click" View "to see the information." Ideally, a combination of a clear text of warnings and a logical button shortcut gives people enough information to understand the situation and their choice. However, if you must provide detailed recommendations, follow these recommendations:

• Be sure to use the word "tap" (not "touch" or "click" or "choose") to describe the selection action.
• Do not include the button title in quotation marks, but keep capitalization.

-

(Mac)

The text of the warning message. This text in highlighted (bold) system font provides a short, simple summary of the error or condition that caused the warning. This should be a complete offer; Often it is presented as a question. See "Writing Good Alert Messages" for more information.

Informative text. This text appears in a small system font and gives a more complete description of the situation, its consequences and ways out of it. For example, a warning that an action cannot be undone is an appropriate use of informational text.

A good warning message clearly states what caused the warning and what the user can do about it. Express all vocabulary.

To make the alert really useful, provide suggestions on what the user can do with the current situation. Even if the warning serves as a notification to the user and no further action is required, provide as much information as possible to describe the situation.

-

(Microsoft)

Characteristics of Good Error Messages

Unlike the previous bad examples, good error messages are:

• Problem. Reports that a problem has occurred.
• Cause. Explains why the problem occurred.
• Decision. Provides a solution that allows users to fix the problem.

In addition, good error messages are presented as follows:

• Appropriate. The message represents a problem that users care about.
• Feasible. Users must either perform an action or change the behavior as a result of the message.
• user-oriented. The message describes the problem from the point of view of the target user of actions or goals, and not from the point of view that the code is unhappy.
• Brief. The message is as short as possible, but not shorter.
• To clear. The message uses a simple language so that target users can easily understand the problem and solution.
• Specific The message describes the problem of using a particular language, giving specific names, locations, and values ​​of the objects involved.
• Polite. Users should not be blamed or made to feel stupid.
• Rare. It is displayed infrequently. Frequently displayed error messages are a sign of poor design.