Windows Interface Components - Secondary Windows

Message Boxes

A message box is a secondary window that displays a message about a particular situation or condition. Messages are an important part of the interface for any software product. Messages that are too generic or poorly written frustrate users, increase support costs, and ultimately reflect poorly on the quality of the product. Therefore, it is worthwhile to design effective message boxes.

It is even better to avoid creating situations that require you to display such a message. For example, if the user does not have sufficient disk space to perform an operation, you can check for available disk space before the user attempts the operation and disable the command if necessary. You can use a balloon tip or status bar message to notify the user about why the command is unavailable.

Title Bar Text

Use the title bar of a message box to appropriately identify the source of the message — usually the name of the object. For example, if the message results from editing a document, the title text is the name of that document, optionally followed by the application name. If the message results from a non-document object, then use the application name.

Providing an appropriate identifier for the message is particularly important in the Windows multitasking environment, because message boxes might not always be the result of current user interaction. In addition, because objects supported by different applications can be embedded in the same document, different application code may be running when the user activates the object for editing. Therefore, the title bar text of a message box plays an important role in communicating the source of a message.

Do not use descriptive text — such as "warning" or "caution" — for message box title text. The message symbol already conveys the nature of the message. Also, never use the word "error" in the title text. The word "error" provides no useful information.

Follow the same conventions as for other secondary window title bar text. For example, use book title capitalization.

Message Box Types

Message boxes typically include a graphical symbol that indicates what kind of message is being presented. Most messages can be classified in one of the categories shown in the following table.

Message Types and Associated Symbols
Symbol	Message type	Description
	Information	Provides information about the results of a command. Offers no user choices; the user acknowledges the message by clicking the OK button.
	Warning	Alerts the user to a condition or situation that requires the user's decision and input before proceeding, such as an impending action with potentially destructive, irreversible consequences. The message can be in the form of a question — for example, "Save changes to MyReport?"
	Critical	Informs the user of a serious problem that requires intervention or correction before work can continue.

The system also includes a question mark message symbol, as shown in Figure 9.19. This message symbol was used in earlier versions of Windows for cautionary messages that were phrased as a question.

Figure 9.19 Inappropriate message symbol

However, the question mark message icon is no longer recommended, because it does not clearly represent a specific type of message and because the phrasing of a message as a question could apply to any message type. In addition, users can confuse the message symbol question mark with Help information. Therefore, do not use this question mark message symbol in your message boxes. The system continues to support its inclusion only for backward compatibility.

You can include your own graphics or animation in message boxes. However, limit your use of these types of message boxes and avoid defining new graphics to replace the symbols for the existing standard types.

More Information

For more information about how to use the taskbar to notify the user when the application may not be active, see Chapter 11, "Integrating with the System."

Because a message box disrupts the user's current task, it is best to display a message box only when the window of your application is active. If your application's window is not active, then use your application's button entry on the taskbar to alert the user. After the user activates the application, you can display the message box. Display only one message box for a specific condition. Displaying a sequential set of message boxes tends to confuse users.

You can also use message boxes to provide information or status without requiring direct user interaction to dismiss them. For example, message boxes that provide a visual representation of the progress of a particular process automatically disappear when the process is complete, as shown in Figure 9.20.

Figure 9.20 A progress message box

Similarly, product start-up windows that identify the product name and copyright information when the application starts can be removed automatically after the application has loaded. In these situations, you do not need to include a message symbol. Use this technique only for noncritical, informational messages, because some users may not be able to read the message within the short time it is displayed. If the window includes information that might be of value at other times, provide another way for users to access this information, such as an About dialog box.

Command Buttons in Message Boxes

Typically, message boxes contain only command buttons as the appropriate responses or choices offered to the user. Designate the most frequent or least destructive option as the default command button. Command buttons allow the message box interaction to be simple and efficient. If you need to add other types of controls, always consider the potential increase in complexity.

If a message requires no choices to be made but only acknowledgment, include an OK button — and, optionally, a Help button. If the message requires the user to make a choice, include a command button for each option. Include OK and Cancel buttons only when the user has the option of continuing or stopping the action. Use Yes and No buttons when the user must decide how to continue, as shown in Figure 9.21.

Figure 9.21 Yes and No buttons in a message box

If these choices are too ambiguous, label the command buttons with the names of specific actions — for example, Save and Delete.

You can include command buttons in a message box to correct the action that caused the message box to be displayed. For example, if the message box indicates that the user must switch to another application window to take corrective action, you can include a button that opens that application window. Be sure to clearly label the button and the results the user can expect from clicking it.

Note

When you include Cancel as a command button in a message box, remember that to users, Cancel implies restoring the state of the process or task that started the message. If you use Cancel to interrupt a process and the state cannot be restored, use Stop instead.

Some situations may require offering the user not only a choice between performing and not performing an action, but an opportunity to cancel the process altogether. In such situations, include a Cancel button, as shown in Figure 9.22. Be sure to clearly label the button and the results the user can expect from clicking it.

Figure 9.22 Message box choices

Enable the title bar Close box only if the message includes a Cancel button. Otherwise, the meaning of the Close operation may be ambiguous.

You can optionally include a Help button in a message box for messages that you want to provide more details about. This enables you to keep the message text succinct.

Message Box Text

The message text you include in a message box should be clear, concise, and written in terms that the user understands. This usually means using no technical jargon or system-oriented information. Try not to exceed two or three lines.

More Information

For more information about writing interface text, see Chapter 14, "Visual Design."

In addition, observe the following guidelines for your message text.

Presentation

• Use complete sentences with ending punctuation. For example, instead of "Date too far in future," say, "The date is too far in the future."

• Avoid contractions, especially in technical messages. Contractions may slow comprehension.

• State the problem, its probable cause (if known), and what the user can do about it, no matter how obvious the solution.

  Correct	Incorrect
  There is not enough disk space to save this file. Free additional space on this disk, or save the file to a different disk.	Insufficient disk space.

• Make messages as specific as possible. Avoid combining more than two or three conditions in a single message. For example, if a file cannot be opened for several reasons, provide a specific message for each condition.

• Consider making the solution an option offered in the message. For example, instead of "One or more lines are too long. The text can only be a maximum of 60 characters wide," you might say, "One or more lines are too long. Text can be a maximum width of 60 characters in Portrait mode or 90 characters in Landscape mode. Do you want to switch to Landscape mode now?" Offer Yes and No as the choices.

• Avoid multi-step solutions. Users have a hard time remembering more than two or three simple steps after a message box closes. If multiple steps are necessary, provide general instructions, or add a Help button that displays a relevant Help topic. Always present the steps in the order they should be completed.

  Correct	Incorrect
  Remove the floppy disk, and then shut down the computer.	Shut down the computer after you remove the floppy disk.

  More Information

  For more information about designing Help topics, see Chapter 13, "User Assistance."

• Provide only as much background information as necessary for the user to understand the message. Include enough information so that an advanced user or support person can help diagnose the problem. To balance the amount of content you include, you can add a command button that calls a Help topic with further information.

• Where possible, replace general system-supplied messages, such as MS-DOS® extended error messages, with your own specific messages.

• You can also include a message identification number as part of the message text for each message for support purposes. However, to avoid interrupting the user's ability to quickly read a message, place such a designation at the end of the message text and not in the title bar text.

• Avoid including support or country-specific information that may not be available to all users.

• Use confirmation messages, such as "Are you sure you want to…" judiciously. A more useful alternative is to describe to the user what the effect of the choice will be.

Terminology

• Use terminology that your audience understands. Avoid unnecessary technical terminology and sentences. For example, "picture" can be understood in context, whereas "picture metafile" is a technical concept.

• Use consistent words and phrasing for similar situations. For example, the following phrases have the same meaning:

  Not enough memory.

  There is not enough memory.

  There is not enough free memory.

  Insufficient memory.

  No memory was available.

  Your computer does not have sufficient memory.

  Memory resource is not enough.

  Ran out of memory.

  You may be out of memory.

The following messages are commonly used in Windows-based products. Consider using or adapting them in your application in similar scenarios.

• Avoid using please except in the following situations:
• When the user is asked to wait while the program completes an action. For example, "Please wait while Setup copies files to your computer."
• When the user is asked to retype information that is required before the user can continue. For example, "The password is incorrect. Please type the correct password."
• When the user is inconvenienced in some other way.
• Avoid phrasing that blames the user or implies user error. For example, use "Cannot find file name" instead of "File name error." Avoid the word "error" altogether.
• Do not anthropomorphize; that is, do not imply that programs or hardware can think or feel.

  Correct	Incorrect
  The node cannot use any of the available protocols.	The node does not speak any of the available protocols.

Fundamentals of Designing User Interaction

Windows Interface Components

Design Specifications and Guidelines

Appendixes and References