Common Desktop Environment: Style Guide and Certification Checklist

Informational Messages

Use informational messages in the window footer to present progress, status, or helpful information to the user. Informational messages should not be used to present crucial information, because informational messages are deliberately designed to be nonobtrusive and many users may not notice them.

Guidelines for Informational Messages



Your application uses footer messages only to communicate status, progress, or information (help) messages. It does not use the footer to present error messages. 

Motif provides a message area at the bottom of the main window, but this is rather clumsy and ugly. A more elegant approach is to provide a wider margin below the data area of the main window where status information can be unobtrusively displayed, as shown in Figure 8-2. For other examples of the use of informational messages, see the status message area in the Common Desktop Environment Mailer.

Figure 8-2 An informational message in the lower margin of a window.


The text "Loading earth.gif..." is displayed at the start of the load and the text "Done" is added when the load completes. The entire message is removed 5 seconds later.

Informational messages in the footer area should be left-justified and displayed in a light font in keeping with their unobtrusive nature. Note that the margin where informational messages are displayed should not accept mouse focus. Progress messages in the footer area should normally be displayed only while the operation is in progress. Notices and other information that is no longer valid should be removed within a few seconds to avoid confusion about whether the information is current.

Other Message Dialogs



Your application uses the appropriate style dialog box for the display of messages to the user. 



An information dialog box is used to display status, completion of activity, or other informative types of messages to which the user need not necessarily respond other than to acknowledge having read the message. 

Minimally, information dialog boxes should have an OK button so that the user can dismiss the dialog box. If there is additional information available about the situations under which the message is displayed or other references for the topic to which the message relates, then a Help button should be included. 



A question dialog box is used to ask questions of the user. The question is clearly worded to indicate what a Yes response or a No response means. The buttons displayed are Yes, No, and Help. Help provides additional information as to what the application will do in response to a Yes or No choice. 

Where possible, you should replace the label for the Yes and No buttons to make it clear what action will be performed as a result of choosing either option. For example, if the user has made changes to a document and has not saved these but has chosen the application's Exit option, you might display a question dialog box that asks, "Changes have not been saved. Do you want to save these before exiting?" The buttons should be Save, Discard, Cancel, and Help. These labels allow the more experienced user to click the correct button without having to carefully read the question and relate it to the button labels. 



A warning dialog box is used to communicate the consequences of an action requested by the user that may result in the loss of data, system or application accessibility, or some other undesirable event. The dialog box is presented before the action is performed and offers the user the opportunity to cancel the requested operation. The buttons displayed are Yes, No, and Help, or Continue, Cancel, and Help. Help provides additional information on the consequences of performing the action requested. 

The use of Yes and No or Continue and Cancel depends on the wording of your message. The labels for Yes and No should be replaced as suggested previously. Continue may be replaced with a label more specific to the action that will be performed. 



A working dialog box is used to display in-progress information to the user when this information is not displayed in the footer of your application's window. The dialog box contains a Stop button that allows the user to terminate the activity. The operation is terminated at the next appropriate breakpoint, and a confirmation might be displayed asking whether the user really wants to stop the activity. The confirmation message might state the consequences of stopping the action. 

Work-in-Progress Feedback



If any command chosen by the user is expected to take longer than 2 seconds to complete, but less than 10 seconds, your application displays the standard busy pointer as feedback that the command is executing. 

The user must receive assurance that your application has "heard" the request and is working on it. If the results of the request cannot be displayed immediately, some feedback must be provided. The busy cursor should be displayed within 0.5 seconds of execution of the command. 



If any command chosen by the user is expected to take longer than 10 seconds to complete, your application displays a working dialog box or other feedback of similar character that indicates that the application is working on the request. The feedback should reveal progress toward completion of the activity. 

If an activity is expected to take a significant amount of time (10 seconds or more), your application should display feedback stronger than the busy pointer. Displaying the busy pointer for long amounts of time may lead the user to conclude that the application has become "hung." A progress indicator should be displayed in these scenarios that indicates that the application is still functioning and is working on the user's request. The progress indicator should show how much of the activity has been completed and what amount remains. 



When your application displays work-in-progress feedback to the user, it does not block access to other applications and services within the desktop environment. 

Multitasking should always be supported and thus your application should allow the user to access other services while it is busy performing some activity. Preferably, the user is also able to access other features within your application even though it is currently working on another request. When this is supported, your application should display an enhanced busy pointer that indicates that the application is busy but still willing to accept input.