Application Design Principles (CDE)

Compose your application with at least one main window.

A main window contains a client area and, optionally, a menu bar, a command area, a message area, and scroll bars. The client area contains the framework of the application.

The default size of the application's main window must be large enough to accommodate a typical amount of data, but should not fill the entire physical display size to minimize visual conflicts with other applications.

Include resize corners in any main window that incorporates a scrolling data pane or list.

If your application has multiple main windows that serve the same primary function, close and iconify each window separately.

If your application has multiple main windows that serve different primary functions, each window should be able to iconify independently of the other windows.

The title of your primary window (the main window your application displays to the user) should be the name of your application. Note that this does not have to be the actual name of the executable invoked by the user.

Carefully consider how the title you choose for your primary window works when it is used in icons and pop-up windows. If the name of the pop-up window is too long, you may remove the application title; however, without the title, users might have difficulty telling which pop-up window belongs with the originating primary window.

Use initial capital letters for each word in the title (in languages that support capitalization).

Follow the application name for each property window, as a minimum, with the title Properties and the name of the object it affects.

Begin the title of each pop-up window with the application title followed by a colon, then the title of the pop-up window. The colon should have a space both before and after it for readability.

Pop-up windows should always indicate which primary window they are associated with (which primary window invoked that pop-up).

Use a hyphen to denote the current file name when the application has files that can be loaded or saved. The hyphen should have a space before and after it. Only the base name of the file should be displayed, not the entire path.

The hyphen is used to denote specific instances of a window or data. The colon serves to delimit general categories or commands. For example, a file manager might have the following title for a Properties dialog box:

File Manager: Properties - myfile

Follow the application name for each command window with the same title that is on the window button or window item that the user chooses to display that window.

In the case of multiple primary windows, include the application name at the beginning of each window title, and add a name that uniquely identifies that primary window. No separator should be provided for these names (for example, Calendar Manager Multibrowse, Catalog Search, Admintool Databases).

An abbreviated name for the application may be used on other windows, as long as it is done on all windows.

If your application has a menu bar, use a horizontal bar at the top edge of the application, just below the title area of the window frame. A menu bar organizes the most common features of an application. It contains a list of menu topics in cascading buttons; each button is associated with a distinct pull-down menu that contains commands that are grouped by common functionality.

The menu bar should contain only cascading buttons.

There are several common menu operations that are considered standard. The standard menu bar entries are File, Edit, View, Options and Help. If your application provides these functionalities, they should be included in the menu bar under the appropriate name.

Present standard menu-bar entries in the following order:

You should exclude from your menu bar any item shown in the preceding text if your application does not support the associated function. For example, if your application does not support the ability to display its data in different views, then you should not include a View menu.

You may add application-specific menus in between any of the standard menu items, with the following exceptions:

Applications that are not file-oriented in nature (or that manage files transparently, not exposing this activity to the user) should replace the File menu with one or more application-specific menus.

Replacing the File menu:

You may use Replacement1 if your application has more than one object type. Items on <app-label> would be used for global actions that are not specific to an object type. The items in Selected are actions that pertain to objects that are currently selected and may change, depending on what objects are selected. If nothing is selected, this menu should have a single item that says (none selected). If an item is selected, but there are no items that apply to that object, this menu should have a single item that says (none).

You may use Replacement2 if your application has a single object type. Actions that are global to the application are on <app-label>, and actions that are specific to the object type are on <obj-type>.

You may use Replacement3 if your application has a single object type and does not require an <app-label> menu. For example, a Print Manager might contain a Printer menu.

All other menu-bar guidelines that apply to File-oriented applications also apply to non-File-oriented applications. Thus, the following menu bar would be valid:

Applications that are complex or are domain-specific (for example, an application for medical imaging and diagnosis of cat-scan data) may require other approaches to their menu-bar design. For example:

Place Exit or Close on the first (leftmost) menu of the menu bar.

If the user chooses Exit, or in any other manner indicates that the application should be terminated, but if there are changes to the current file that have not been saved, display a dialog box that asks whether the changes should be saved before exiting.

If your application uses a File menu, it must include the choices in Table 1 “File Menu Choices” with the specified functionality.

If your application uses an <object-type> menu or a Selected menu, it may include the choices in Table 2 “<object-type> / Selected Menu Choices”, with the specified functionality, when the actions are actually supported by your application. Items should be presented to the user in the order listed.

If your application uses an Edit menu, it may include the choices in Table 3 “Edit Menu Choices” with the specified functionality, when the actions are actually supported by your application.

If your application does not provide an <object-type> or Selected menu, but allows the user to select data within the window and manage settings for the selected data, then provide a Properties... choice as the last item in the Edit menu.

If your application provides a View menu, include only those functions that affect the way the current data is presented. Do not include any option that alters the data itself.

If your application has global settings that control the way the application behaves, provide an Options menu from which these can be set.

If your application includes a Help menu, include the set of choices in Table 4 “Help Menu Choices in CDE” with the specified functionality, when the actions are actually supported by your application.

If your application uses an attachment menu, it may include the choices in Table 5 “Attachment Menu Choices in CDE” with the specified functionality, when the actions are actually supported by your application.

If your application provides functions that apply to a data pane and not any specific element therein, then provide a pop-up menu that contains the frequently used data pane functions and that is accessible by pressing the MENU button when the mouse pointer is over the background of the pane or a nonselectable element within the pane.

Your application should provide a pop-up menu for any element that is selectable within its data pane.

Pop-up menus provide access to frequently used functions and should be used pervasively throughout the CDE desktop environment. A pop-up menu may contain a collection of options that appear in different menus available from the menu bar. For example, it may contain items from both the File and Edit menus.

When a pop-up menu is displayed over an unselected object, apply any action selected from the pop-up menu to that object only, and not to any other objects that might currently be selected. This helps to protect the user from inadvertently applying an action to objects that the user may not realize are currently selected. Pressing the menu button invokes a pop-up menu pertinent to the object under the mouse cursor whether it is selected to not; if the object under the mouse cursor and other objects are selected, the pop-up menu is pertinent to the selected set.

Every pop-up menu in your application should have a title that indicates the function the menu performs or the element on which it operates.

Make the functions accessible from within your application's pop-up menus also accessible from buttons displayed within the window or menus accessed through the menu bar.

Because pop-up menus are hidden, they should provide redundant access only to functions available from more visible controls within the application's windows.

If your application uses any of the common pop-up menu actions, the actions should function according to the specifications in Table 6 “Pop-Up Menu Choices in CDE”

Pop-up menus for selectable objects should include the set of choices in Table 7 “Pop-Up Menu Choices For Selectable Objects in CDE” with the specified functionality, when the actions are actually supported by your application.

Organize choices within your pop-up menus in the following manner:

<choices that manage the object such as Open, Save, or Properties>

- separator

<standard edit menu choices such as Cut, Copy, and Paste>

separator -

<other choices>

When a pop-up menu is popped up in the context of a selection, any action that acts on elements should also act on the entire selection.

Display an information dialog box such that it does not interrupt the user's interaction with your application.

An information dialog box conveys information to the user that does not require immediate attention so it does not need to be modal.

If the selection of a menu item will result in the user being queried for more information, such as through the posting of a file selection dialog, the menu item should be followed by an ellipsis (...). This requirement does not apply to menu items that will result in a simple warning or confirmation dialog being displayed.

The use of an ellipsis helps set the user's expectation for the behavior of the interface. When selecting an item without an ellipsis, the user can expect an immediate result.

Menus accessed from within your application should contain at least two menu items.

No menu should contain only one item. If your application provides a menu with only one item, move that item into another menu or make it a button within the window. The longer the menu, the more effort is needed for the user to access choices near the bottom. If your menu has a lot of choices, break it up into two or more menus, or group some items into submenus.

Submenus accessed from within your application should contain at least three menu items.

Submenus may be used to group like items into a single secondary cascading menu where putting the items into the primary cascading menu would make it too long. However, if your submenu contains only two options, consider removing the secondary cascading menu and putting the options into the primary cascading menu since it takes more effort for the user to access options located in a submenu.

No menu in your application should contain more than 15 choices.

If your menu has many choices, consider breaking it up into two or more menus, or grouping some items into submenus.

If your application contains a menu that is expected to be accessed frequently, then provide a tear-off menu option.

The user should be able to tear off frequently accessed menus so that these can remain posted on the desktop.

Provide keyboard accelerators where appropriate.

If specific menu items within a menu are expected to be used frequently, not the menu as a whole, then provide keyboard accelerators for these items and display the keyboard accelerators in the associated menu to the right of the item to which they relate.

The labels used for items in the menu bar should not appear as options within the menus themselves.

The names of items in the menu bar serve as titles for the options the menu contains. The name of the menu bar item should provide a term that accurately describes the concept of the category relating all of the menu items and should not be used as the name of any item within the menu itself.

Dim (make insensitive) any menu choice that is not currently an appropriate selection.

Dimmed controls cannot be activated by the user and should appear only when the inactive state is short-term (that is, there is something the user can do within the application or the desktop environment to make the control become active). When the control is persistently inactive (because of the current configuration of the application or system, or a particular set of companion software is not currently installed), remove the control rather than dim it.

If a menu item is used to indicate a selection state, use a check box or radio button to indicate the state of the item. Use a check box if a single item is used to represent on or off states, and use radio buttons for multiple adjacent menu items in which only one of the items may be selected.

If radio buttons are used in a menu, use separators between each set of radio buttons and other menu items.

If a check box or radio button is used on a menu item, display it as either selected or not selected. It should not disappear when in the unselected state.

If your application uses a tear-off choice in a menu, make the tear-off choice the first element in the menu.

Make all menus wide enough to accommodate their widest elements.

The title of dialog boxes used within your application should adhere to the conventions listed in Table 8 “Dialog Box Title Conventions”

Every dialog box should have at least one button that either performs the dialog box action and dismisses it or dismisses the dialog box without taking any action.

If your application uses common dialog box actions, include the specified functionality and labels listed in Table 9 “Dialog Box Choices”

Dim any visible control that is not currently active or whose setting is currently invalid.

When the control is persistently inactive (because of the current configuration of the application or system, or a particular set of companion software is not currently installed), the control should be removed rather than dimmed.

Keep the size of your dialog boxes to a minimum. Remember that on low-resolution displays, dialogs may take up most of the screen real estate, and may even run off the edge of the screen if not designed correctly.

Avoid complexity in your dialog boxes. If your dialog box must support many functions, consider using an expandable dialog box, or use more than one dialog in a nested fashion.

Avoid the use of resize handles in your dialog box. However, you may use resize handles when resizing is useful in allowing users to see more information; for example, when your dialog contains a scrolling list that is likely to be quite long, and users will frequently need to search the list.

Every dialog box in your application should have exactly one default button that is activated when the Return key is pressed.

The default button should be associated with the most likely response from the user and should not be potentially destructive or irreversible. Some applications may have dialog boxes that do not reveal a default button until a specific set of fields has been filled or otherwise manipulated.

If a dialog box displayed by your application has controls that are considered to be advanced features, use an expandable dialog box, or use a multiple page dialog box that provides a <category> option menu that allows a user to navigate to each page.

If your application provides settings that control the behavior of the application, display these settings in an application properties window that is accessible from an Options menu.

Controls that relate to advanced features should not be displayed with the set of options initially displayed to the user. The typical user should be presented with only those options that are necessary to use the basic functionality of the application. Users looking to access advanced functionality within the dialog box may use the <Category> option button (see Figure 7-1). If the number of advanced controls is few, or the settings for these controls are highly related to the settings of basic controls displayed in the dialog box (that is, the settings of the advanced controls change when the user changes settings for basic controls), you might choose to provide an expandable dialog box.

If your application provides settings that control the behavior of the application, display these settings in an application properties window that is accessible from an Options menu.

If your application manages objects and allows the user to see or modify settings for these objects, display these settings in an object properties window that is accessible from a Properties... choice in the Edit, <object-type>, or Selected menus, as well as from the pop-up menu associated with the object.

If your application provides access to a Properties or Options window, include the following set of buttons in the order listed, with the specified functionality, when supported by your application:

If your application provides a Properties window that displays settings for a selected object, make the Properties window track the current selection and modify the state of any controls to accurately reflect the properties of the currently selected object.

If your application allows the user to open or save files, then use the standard CDE file selection dialog box to allow the user to select specific files and directories.

All user interactions with the file system should be facilitated by providing a point-and-click style of choosing files and directories. The user should never be forced to memorize and type in file paths. The user must be able to explore the contents and structure of the file system by using scrolling lists. The expert user, however, should be able to directly enter a complete file path, as well as able to use relative paths and environment variables such as $HOME.

The labels and contents of the standard file selection dialog box may be modified as appropriate to make clear the particular context in which it is being used within your application.

If your application allows the objects it manages to exist as separate entities within folders or toolboxes within the desktop environment, provide a Copy To menu option or button that displays a file selection dialog box that allows the user to select the desired folder in which an icon for the object should be placed.

The file selection dialog box should not display hidden (dot) directories or files, unless your users depend on these types of files. If your application does support displaying hidden files, supply a check box that allows the user to toggle between showing and not showing hidden files or to toggle between showing and hiding files at a global level in your application.

The file selection dialog box should not show the full pathnames for files and directories, but should show only the relative names, except for the directory text field.

The global CDE setting should be:

XmFileSelectionBox.fullPathMode: false

Unless your application overrides this behavior, your file selection dialog box should not show full pathnames in the list boxes.

The file selection dialog box should recall the directory location that was previously set by the user.

For example, if the user brings up Save As and navigates to /users/jay/letters to save the file, the next time the user brings up Save As, the file selection box should be in the directory /users/jay/letters. The directory, however, should not be retained once the user has closed the primary window. When the user brings up Save As for the first time, it should resort to the default directory.

The About dialog box should contain a minimum set of information about the application that is visible in a single text pane.

That minimum set should be:

Include a Close button in the About dialog box. Other buttons are optional, such as Help and More.

Include information about the operating system or other aspects required to run the application, for example, Common Desktop Environment 2.1.

Include a More Information dialog box for additional information such as development team credits, licensing, client, or xhost information.

Place controls within your dialog box in a left-right, top-down layout based on the order in which the user is expected to fill out or choose options within the dialog box.

Push buttons that affect the dialog box as a whole, either by modifying its contents or layout, invoking the action of the dialog box, or dismissing the dialog box, should be located at the bottom of the dialog box.

There should be only one row of buttons at the bottom of a dialog box. If your application has dialog boxes that contain several global buttons, you may need to create two or more rows of buttons at the bottom of the dialog box. The last row should contain the standard dialog box buttons (OK, Reset, Cancel, and Help). If a dialog box contains buttons that are not related to the dialog box as a whole, but relate to a specific control within the dialog box, the buttons should be located with the control to which they relate.

If your application provides an Apply button within a dialog box, also provide an OK button or <command> button that performs the dialog box action and then dismisses it.

Do not use cascading buttons within dialog boxes unless there is absolutely no other design alternative that can be used without a negative impact on the layout of your dialog box.

In general, use cascading buttons only within menus and menu bars. Avoid their use in all other locations unless absolutely necessary.

Provide a drag-and-drop method for all objects represented as icons. Provide a drag-and-drop method for all elements that the user can directly manipulate.

Any basic function that your application supports through drag and should also be supported drop through menus, buttons, or dialog boxes.

Drag and drop is considered an accelerator to functionality that is accessible through other user interface controls that your application supports. There should be no basic operation that is supported solely through drag and drop.

Use an icon graphic in a dialog box or window to indicate that objects within the dialog box or window can be dragged. Use the same icon graphic used to represent the draggable object in File Manager. Place the icon adjacent to any display of the contents of the object, if such a display exists. If there is no such display, place the icon in the upper right corner of the dialog box or window, unless a more suitable placement is determined. The icon should be 32x32 in size and have a label under it. The label should indicate what kind of object the icon graphic represents. The icon graphic should also be used as the source indicator in the drag icon.

During a drag operation, change the current pointer to a drag icon.

During a drag operation, change the current drag cursor to include a source indicator.

During a drag operation, change the current drag cursor to indicate invalid drop zones. Use the standard CDE cannot pointer.

The user must receive feedback as to where an object can and cannot be dropped. Minimally, you should provide feedback as to what are invalid drop zones. Preferably, feedback for valid drop zones is enhanced by use of animation, recessing of the target drop zone, and other such drag-over effects.

During a drag operation, change the drop zone feedback to indicate a valid drop zone.

Preferably, feedback for valid drop zones is enhanced by use of animation, recessing of the target drop zone, and other such drag-over effects.

When the user presses Cancel, end a drag-and-drop operation by canceling the drag in progress.

When the user releases the TRANSFER button (or the SELECT button) when not over a drop target, end a drag-and-drop operation.

Any cursor change or drag-over effect your application uses should occur within .2 seconds of the mouse pointer reaching the target area and should not interfere, in any noticeable way, with the interactive performance of the drag operation.

In a collection that supports copy, move, or link operations that can be performed by dragging, the feedback presented to the user during the drag operation should indicate whether a single object or multiple objects are being manipulated.

Feedback provided during the drag operation should ensure that the user feels confident that the desired set of objects is being dragged. The drag icon used for multiobject drag operations should integrate the feedback used to indicate whether the operation is a move, copy, or link.

After a successful transfer, place the data in the drop zone and remove any transfer icon.

If your application removes data upon the completion of a drag-and-drop operation, do so only if the drag-and-drop transfer has completed successfully.

If a drag-and-drop operation has been canceled or failed, do not remove the data or object that was the source of the drag.

After a failed transfer, keep the data at the drag source and do not place it in the drop zone. Remove any transfer icon.

If the user drops an object at an inappropriate drop zone within your application's window, your application should participate in the display of a snap-back effect and also post an error dialog box that indicates the reason the drop was disallowed.

The error message should state the context (for example, running action A on object B), what happened (for example, could not connect to system X), and how to correct the problem (for example, press the Help button to obtain information on diagnosing remote execution problems).

Applications that accept only single items should reject all multiple-item drops.

If your application supports drag and drop as a means of loading a file into the application, have the application respond to this operation in a manner similar to when the file is loaded through more conventional means, such as choosing Open from the File menu.

As an accelerator, drag-and-drop loading of files should provide the same kind of feedback and behavior as choosing Open from the File menu. For example, if changes to a currently loaded file have not yet been saved, display a message dialog box asking whether the changes should first be saved before loading the new file.

If your application provides any drag-and-drop help dialog boxes, include a Cancel button for canceling the drag-and-drop operation in progress.

Drag and drop should not be the only method for attaching objects.

Double-clicking is a shortcut for selecting the attachment and choosing the Open menu item for attachments and should never be the only way to access attachments.

When the user attempts to drop something into the attachment list that is not attachable, then the drop should fail and the item snaps back to its source.

When the user has one or more attachments open for editing and attempts to do any operation that would result in potentially losing the user's edits, the user should be clearly warned and given the opportunity to save changes.

When the user chooses something to attach from the file selection dialog box that is not an attachable item, display an error message explaining why the chosen item cannot be attached. For example:

Install applications in folders in the Application Manager, not directly on the Front Panel or subpanels. For consistency, only CDE desktop components will install in the Front Panel or subpanels. Users may choose to rearrange their Front Panel, but applications should not do this without user consent.

Display a warning dialog box that allows the user to cancel the destructive action about which the dialog box is providing a warning. The user needs to have a way to cancel an operation that can cause destructive results.

When your application displays a dialog box, place the input focus at the first text field into which the user is allowed to type an entry, or at the first control within the dialog box with which the user should interact.

Input focus should always be placed at a predictable and intuitive location. Do not force the user to set focus at the control most likely to be used when the window is displayed.

As the user presses Tab within dialog boxes of your application, move the input focus to different controls within the window in a left-right, top-down order.

There should always be exactly one control within any window of your application that has the input focus if the window in which it resides has the input focus.

When a text field within your application does not have the input focus, do not display the text cursor within that field.

Although use of inactive text cursors is allowed within the Motif style, it is better to hide the text cursor on focus out rather than display the inactive text cursor. This makes it easier for the user to quickly scan the screen or a window and determine which text field currently has focus.

Provide keyboard mnemonics for all buttons, menus, and menu items displayed within the application.

Provide keyboard accelerators for those functions that are expected to be used frequently by the user.

Dialog boxes should never block input to other applications within the desktop (that is, they are not system modal) unless it is essential that the user perform no other action on the desktop until the user responds to the dialog box.

Dialog boxes should never block access to other functionality within the application (application modal) unless it is essential that the state of the application remains unchanged until the user responds to the dialog box.

If your application does not use the values of global environment settings, such as multiclick timeout intervals, drag thresholds, window color settings, mouse left- or right-handedness, and so on, but instead uses its own values for these settings, then provide one or more Options dialog boxes that allow the user to change the values for these settings.

In general, you should not override the value of settings treated as global environment settings. The user controls these settings through the CDE Style Manager. If you choose to ignore these settings and specify your own settings, then your application will behave inconsistently with other applications in CDE. If you nevertheless choose to provide your own values, then you must provide the user with a way to make your settings consistent with the rest of the desktop.

Design any icons or graphics that your application displays to be distinguishable on low- (640x480), medium- (800x600), and high- (mega-pixel) resolution displays. Alternatively, provide different sized visuals for low-, medium-, and high-resolution displays.

Desktop system configurations are including more high-resolution monitors. The user must be able to discern any visuals that your application uses. The embedded base, however, still contains many standard VGA monitors. Your application's visuals must display well on these systems and should not appear overly large.

Design any icons or graphics that your application displays to display on black-and-white and gray-scale monitors, as well on low-color (16) systems.

Use icons to represent only objects and applications.

Use only the palette of 22 colors for icons.

The CDE icon palette was chosen to maximize attractiveness and readability without using an unnecessary number of colors. Use of additional colors may cause undesirable color shifting on the display.

Design icons for international use.

Do not use text, symbols, humor, animals, and other items that may be interpreted differently in other cultures.

Left-allign 16x16 and 32x32 icons; place any empty bits on the right side of the bounding box.

Center 48x48 icons in the bounding box.

If you use a tool bar, it should appear only in windows with a menu bar.

Tool bars should contain only those operations that are already available to the user in your application's menus. All items in a tool bar should be redundant.

When an action represented by a tool bar icon is unavailable to the user, make that icon insensitive, with the associated stippled appearance. If a menu item is made insensitive, make the corresponding tool bar item insensitive as well.

Give users the option to hide the tool bar.

Place the tool bar container directly under the menu bar. It should have the same width as the window, as well as similar height to the menu bar.

If you use a tool bar in your application, provide a status line in the same primary window as the tool bar.

This status line should provide immediate feedback to the user as to the purpose of the button that the mouse is currently over or that has the keyboard focus. When the arrow is over a tool bar icon, the status line should display a brief definition of what the icon represents or what will happen when the user clicks the icon.

Provide labels under tool bar icons. These labels should serve to explain the purpose of the icon.

All pixmaps in the tool bar should be the same size. This ensures that all the tool bar buttons are the same size.

Drawn buttons in the tool bar should be the same width and height. Similar or related items should be grouped, and groups should be evenly spaced across the tool bar.

The primary pane of the dialog box or window should contain all of the controls needed to complete the task. This should include all critical and frequently used functionality.

It is assumed that infrequently used features are placed in the secondary pane. The core functionality of the application should not depend on any controls placed in secondary panes.

Align command buttons along the bottom of the dialog box. When the window is expanded to show a secondary pane, then move the buttons to the bottom of the secondary pane.

If important controls must be placed in the secondary pane, specify that the window in question should be displayed in its expanded state by default. The user should still be able to shrink the window by pressing the Contract button.

The secondary pane should expand in the direction most consistent with the user's expectations, the reading pattern of the language in which it will be displayed, and the content of the information displayed.

If possible, the panes should have the same default width.

Separate the primary pane from the secondary pane with a separator.

If a window is resizable, allocate any sizing changes to the pane that contains scrolling lists or text fields whose displayed length is less than their stored length. If both panes contain scrollable controls, distribute size changes evenly between the two panes. If neither pane contains scrollable controls, the window should not be resizable.

The expandable window should have one button that changes its label based on the state of the window.

The expand button should have two labels that reflect the two states of the expandable window accurately. The current label indicates to the user what will happen if the user clicks the button.

Examples of possible labels are Basic and Options, Expand and Contract, and More and Less.

The expand button may contain a graphic in addition to the label. This graphic should indicate the direction in which the window will expand or contract.

Place the button in the lower left-hand corner of the window or dialog box for expansion in the vertical direction and in the lower-right hand corner for expansion in the horizontal direction.

If the window or dialog box contains a scrolling list positioned to the far right side of the pane, do not align the drawn button with the scroll bar. For example, the button should be aligned with the list, not the scroll bar.

Applications must remember the state of each window or dialog box (expanded or not expanded) independently (not collectively). The state should be changed only by the user and should always be preserved until explicitly altered by the user.

Applications should remember the state of each expandable window or dialog box across sessions so that the user does not have to manually configure the expandable windows each time the application is run.

If appropriate, provide a mechanism (as an option) to allow the user to set the state of an expandable window globally for the application. This would be part of the application's Options.

When creating messages, do not assume that the user has any expert knowledge about computer systems in general or the UNIX system in particular.

Error messages should indicate the possible cause of the error and indicate the possible actions the user can take in response.

Use audio feedback, in addition to any messages displayed, to signal error conditions and events.

Avoid relying on error messages from the kernel and library routines. Error messages from kernel and library routines are normally not seen by the user, and even when the user does see them, they are usually too low-level and cryptic to be understood by nonprogrammers. Applications should check for error conditions and use an error dialog box to present an appropriate error message in terms of the user's actions and intentions.

Display a confirmation or warning message dialog box when an action instigated by the user will be irreversible and potentially destructive.

Urgent conditions that require immediate attention by the user, no matter which application or desktop service the user is currently accessing should be brought to the user's attention with audiovisual notification. Invoke the alarm signal in the current workspace regardless of the workspace in which the application resides.

Use footer messages only to communicate status, progress, or information (help) messages. Do not use the footer to present error messages.

Provide a Help button in all message dialog boxes, except those that contain self-explanatory messages.

Use the appropriate dialog box style to display messages.

Use an information dialog box 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 or other references for the topic to which the message relates, include a Help button.

Use an error dialog box to display error messages to the user. State what the error is and specify why it occurred. Include a Help button so that the user can get additional information, unless the message is self-explanatory. Also include an OK button that dismisses the dialog box.

A Cancel button is not required for error dialog boxes unless the error resulted in the suspension of an activity that was in progress. In this case, the message should indicate whether the user has the option to continue the activity or to stop it, and the buttons for the dialog box should be Continue, Cancel, and Help. In general, error dialog boxes should not be modal unless it is critical that the user not continue interacting with the application until the user has acknowledged having read the error message.

Use a question dialog box to ask questions of the user. Clearly word the question to indicate what a Yes response or a No response means. Include the buttons Yes, No, and Help. Help should provide additional information as to what the application will do in response to a Yes or No choice.

Use a warning dialog box 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. Present the dialog box before the action is performed and offer the user the opportunity to cancel the requested operation. Include the buttons Yes, No, and Help, or Continue, Cancel, and Help. Help should provide additional information on the consequences of performing the action requested.

Use a working dialog box to display in-progress information to the user when this information is not displayed in the footer of your application's window. Include 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.

Write error messages to the CDE error log when it is not appropriate to display these to the user in a message dialog box, but when the message may nevertheless be useful in diagnosing problems.

Messages written to the error log should provide additional information about the error and should state the context in which the error occurred.

Informational messages should be left aligned 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 should normally be displayed only while the operation is in progress. Remove notices and other information that is no longer valid within a few seconds to avoid confusion about whether or not the information is current.

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

Display the busy pointer 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, display 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), 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 "hung." Display a progress indicator 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, do not block access to other applications and services within the desktop environment.

Multitasking should always be supported and, as such, 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.