Application Design Principles (CDE)

Reference

Description

Application design principles govern window, menu, and dialog layout within CDE.

Guidelines

Required

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.

Required

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

Required

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

Required

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

Required

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

Optional

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.

Optional

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

Optional

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

Optional

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).

Optional

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

Recommended

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.

Optional

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).

Optional

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

Required

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.

Required

The menu bar should contain only cascading buttons.

Recommended

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:

File Edit View Options Help

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:

1. The File menu, if present, is located in the first menu position on the left.

2. The Help menu is located on the far right.

3. If File and Edit are present, they should be next to each other.

Recommended

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:

1. Replacement1 <app-label> Selected

2. Replacement2 <app-label><obj-type>

3. Replacement3: <obj-type>

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:

<app-label> Selected Edit <category1> View <category2>
 
Help

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:

<app-label><category1><category2> Selected Edit
 
<object-type> Options Help

Recommended

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

Required

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.

Required

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

Table 1. File Menu Choices

Mnemonic	Menu Choice	Function
N	New...	Creates a new file. If the current client area will be used to display the new file, clear the existing data from the client area. If changes made to the current file will be lost, display a dialog box asking the user about saving changes.
O	Open...	Opens an existing file by prompting the user for a file name with a dialog box. If changes made to the current file will be lost, display a dialog box asking the user about saving changes.
S	Save	Saves the currently opened file without removing the existing contents of the client area. If the file has no name, display a dialog box prompting the user to enter a file name.
A	Save As...	Saves the currently opened file under a new name by prompting the user for a file name with a dialog box. If the user tries to save the file with an existing name, display a dialog box that warns the user about a possible loss of data. Do not remove the existing contents of the client area.
P	Print (recommended)	Schedules a file for printing. If your application needs specific information to print, it displays a dialog box requesting the information from the user. In this case, the menu entry is followed by an ellipsis (Print...).
C	Close (recommended)	Closes the current primary window and its associated secondary windows. If your application uses only a single primary window or multiple dependent primary windows, this action is not supplied
X	Exit	Ends the current application and all windows associated with it. If changes made to the current file will be lost, displays a dialog box asking the user about saving changes.

Recommended

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

Table 2. <object-type> / Selected Menu Choices

Menu Choice	Function
New...	Creates a new instance of the object type. If appropriate, a dialog box is presented allowing the user to specify the values for settings associated with that object.
Move To...	Allows the user to move the selected objects into a folder. Display a file selection dialog box allowing the user to select the desired folder.
Copy To...	Allows the user to copy the selected objects into a folder. Display a file selection dialog box allowing the user to select the desired folder.
Put in Workspace	Allows the user to put a link for the object onto the CDE desktop in the current workspace.
Any of the preceding menu choices should be provided only if the objects managed by your application are able to reside as separate entities outside of your application's main window. For example, a printer object created by a printer management application might be able to be placed in a Folder window and function as an application by itself. Your application should also support drag and drop as a method for performing any of these actions.
Delete	Removes the selected objects. A confirmation dialog box should be presented to the user before the object is actually deleted.
Properties	Displays a Properties window that shows the current values for settings associated with the selected object.
<default action>	This choice should enact the default action for the selected object. The Open choice is a typical default.

Optional

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

Table 3. Edit Menu Choices

Mnemonic	Menu Choice	Function
U	Undo	Reverses the most recently executed action.
t	Cut	Removes the selected portion of data from the client area and puts it on the clipboard.
C	Copy	Copies the selected portion of data from the client area and puts it on the clipboard.
k	Copy Link	Copies a link of the selected portion of data from the client area and puts it on the clipboard.
P	Paste	Pastes the contents of the clipboard into the client area.
L	Paste Link	Pastes a link of the data represented by the contents of the clipboard into the client area.
e	Clear	Removes a selected portion of data from the client area without copying it to the clipboard and does not compress the remaining data.
D	Delete	Removes a selected portion of data from the client area without copying it to the clipboard.
S	Select All	Sets the primary selection to be all the elements in a component of the client area.
l	Deselect All	Removes from the primary selection all the elements in a component of the client area.
a	Select Pasted	Sets the primary selection to the last element or elements pasted into a component of the client area.
R	Reselect	Sets the primary selection to the last selected element or elements in a component of the client area. This action is available only in components that do not support persistent selections and only when the current selection is empty.
m	Promote	Promotes to the primary selection the current selection of a component of the client area. This action is available only for components that support persistent selections.

Recommended

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.

Recommended

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.

Recommended

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

Required

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

Table 4. Help Menu Choices in CDE

Mnemonic	Menu Choice	Function
V	Overview	Provides general information about the window from which help was accessed or about the application overall. Place a separator after this choice.
I	Index (optional)	Provides an index that lists the topics for all help information available for your application.
C	Table of Contents (recommended)	Provides a table of contents that lists the topics for all help information available for your application.
T	Tasks (recommended)	Provides access to help information that indicates how to perform different tasks within your application.
R	Reference (recommended)	Provides access to reference information.
L	Tutorial (optional)	Provides access to your application's tutorial.
K	Keyboard (optional)	Provides information about your application's use of function keys, mnemonics, and keyboard accelerators. Also provides information on general CDE use of such keys.
M	Mouse (optional)	Provides information about using a mouse with your application.
M	Mouse and Keyboard (optional)	Provides information about your application's use of function keys, mnemonics, keyboard accelerators, and using a mouse with your application. Also provides information on general CDE use of such keys. Use, rather than separate, mouse and keyboard choices if this information is best presented together.
O	On Item (recommended)	Initiates context-sensitive help by changing the shape of the pointer to the question mark pointer. When the user moves the pointer to a component and presses the SELECT button, any available context-sensitive help for the component is presented. Set off with separators on both sides.
U	Using Help	Provides information on how to use the CDE Help Viewer. Set off with separators on both sides.
A	About application name	Displays a dialog box that indicates, minimally, the name and version of your application, and displays its icon or some other signature graphic for your application.

Recommended

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

Table 5. Attachment Menu Choices in CDE

Menu Choice	Function
Add File...	Selects files and other items to be attached. Display a file selection box that allows the user to select the desired files to attach. The default button in the file selection box is Attach.
Save As...	Saves the currently selected attachments. The user is prompted with a file selection dialog box for indicating where in the file system the attachments are to be saved. When multiple attachments are selected, the name field is inactive and the current names of the attachments are used as the name of the new file. This menu item is active only when one or more attachments are selected.
Rename...	Renames the attachment icon. The application should provide in-line renaming of attachment icons, such as File Manager uses. If the application cannot provide in-line renaming, then Rename allows the user to rename an attachment by displaying a dialog box that requests the name from the user. This menu item is active only when a single attachment is selected.
Delete	Deletes attachments from the attachment list. This menu item is active only when an attachment is selected.
Select All	Selects all the attachments in the attachment list.

Recommended

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.

Recommended

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.

Recommended

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.

Recommended

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.

Recommended

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.

Optional

If your application uses any of the common pop-up menu actions, the actions should function according to the specifications in Table 6 .

Table 6. Pop-Up Menu Choices in CDE

Menu Choice	Function
Properties	Displays a Properties dialog box that the user can use to set the properties of the component.
Undo	Reverses the most recently executed action.
Primary Move	Moves the contents of the primary selection to the component. This action is available only in editable components.
Primary Link	Places a link to the primary selection in the component. This action is available only in editable components.
Cut	Cuts elements to the clipboard. If the menu is popped up in a selection, cuts the entire selection to the clipboard.
Copy	Copies elements to the clipboard. If the menu is popped up in a selection, this action copies the entire selection to the clipboard.
Copy Link	Copies a link of elements to the clipboard. If the menu is popped up in a selection, copies a link to the entire selection to the clipboard.
Paste	Pastes the contents of the clipboard to the component. This action is available only in editable components.
Paste Link	Pastes a link of the contents of the clipboard to the component. This action is available only in editable components.
Clear	Removes a selected portion of data from the client area without copying it to the clipboard. If the menu is popped up in a selection, deletes the selection.
Delete	Removes a selected portion of data from the client area without copying it to the clipboard. If the menu is popped up in a selection, deletes the selection.
Select All	Sets the primary selection to be all of the elements in the collection with the pop-up menu.
Deselect All	Deselects the current selection in the collection with the pop-up menu.
Select Pasted	Sets the primary selection to be the last element or elements pasted into the collection with the pop-up menu.
Reselect	Sets the primary selection to be the last selected element or elements in the component with the pop-up menu. This action is available only in components that do not support persistent selections and only when the current selection is empty.
Promote	Promotes the current selection to the primary selection. It is available only in components that support persistent selections.

Recommended

Pop-up menus for selectable objects should include the set of choices in Table 7, with the specified functionality, when the actions are actually supported by your application.

Table 7. Pop-Up Menu Choices For Selectable Objects in CDE

Menu Choice	Function
Move To...	Allows the user to move the selected objects into a folder. A file selection dialog box is displayed that allows the user to select the desired folder.
Copy To...	Allows the user to copy the selected objects into a folder. A file selection dialog box is displayed that allows the user to select the desired folder.
Put in Workspace	Allows the user to put a link for the selected objects onto the CDE desktop in the current workspace.
Delete	Deletes the selected object. A confirmation is displayed to the user before actually removing the object.
Properties (recommended)	Displays a dialog box that indicates the current settings for attributes associated with the selected object.
Help (recommended)	Displays a help window that pertains to objects of the type selected.

Optional

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>

Required

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.

Required

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.

Recommended

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.

Recommended

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.

Optional

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.

Recommended

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.

Optional

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.

Optional

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.

Recommended

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.

Required

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.

Recommended

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.

Required

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

Recommended

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.

Required

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

Required

Make all menus wide enough to accommodate their widest elements.

Recommended

The title of dialog boxes used within your application should adhere to the conventions listed in Table 8.

Table 8. Dialog Box Title Conventions

Window Usage	Window Title Format
Message	<app or object name>: <action or situation>
Progress	<app or object name> : <action> in Progress
Action (Command)	<app name>: <action>
Object Properties	<app name>: <object-type> Properties
Application Options	<app name>: <type> Options

Required

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.

Recommended

If your application uses common dialog box actions, include the specified functionality and labels listed in Table 9.

Table 9. Dialog Box Choices

Dialog Choice	Function
Yes	Indicates an affirmative response to a question posed in the dialog box.
No	Indicates a negative response to a question posed in the dialog box.
OK	Applies any changes made to components in the dialog box and dismisses the dialog box.
<command>	Applies any changes made to components in the dialog box, performs the action associated with the <command>, and dismisses the dialog box. <command> should be used in lieu of OK, Yes, or No as a button label when it provides more meaning to the user as to the action that will be performed when that button is clicked.
Apply	Applies any changes made to components in the dialog box and does not dismiss it.
Retry	Causes the task in progress to be attempted again.
Stop	Ends the task in progress at the next possible break point.
Pause	Causes the task in progress to pause.
Resume	Causes a task that has paused to resume.
Save As Defaults	Saves the current settings as the default settings that will appear the next time the window is displayed. The settings are not applied to any selected object and the dialog box is not dismissed. A Save As Defaults button should be provided if it is expected that a user would want to use different default values for a set of controls within a dialog box than those that you provide as the factory settings. For example, a Save As Defaults button might be provided in a New <object-type> window, allowing the user to indicate that whenever a new instance of that object type is created, the current values should be displayed as the default settings instead of the values given by the application.
Reset	Cancels any changes that have not yet been applied by your application. The controls within the dialog box are reset to their state since the last time the dialog box action was applied. If no changes have been applied within the current invocation of the dialog box, the controls are reset to the state when the dialog box was first displayed.
Reset to Factory	Cancels any changes that have not yet been applied. Components in the dialog box are reset to their default state and value as specified by the vendor that delivered the application (that is, the controls are restored to the original factory settings).
Cancel	Dismisses the dialog box without performing any actions not yet applied.
Help	Provides help for the dialog box.

Recommended

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.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Required

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.

Required

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.

Recommended

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.

Recommended

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:

OK	Applies any changes made to components in the dialog box and dismisses it. OK may be replaced by a more appropriate label, for example, Add. The alternate label should be a verb phrase.
Apply (Optional)	Applies any changes made to components in the dialog box and does not dismiss it.
Reset	Cancels any changes that have not yet been applied by your application. The controls within the dialog box are reset to their state since the last time the dialog box action was applied. If no changes have been applied within the current invocation of the dialog box, the controls are reset to the state when the dialog box was first displayed.
Reset to Factory (Optional)	Cancels any changes that have not yet been applied. Components in the dialog box are reset to their default state or value as specified by the vendor that delivered the application (that is, the controls are restored to the original factory settings).
Cancel	Dismisses the dialog box without performing any actions not yet applied.
Help	Provides help for the dialog box.

Recommended

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.

Optional

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.

Recommended

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.

Recommended

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.

Recommended

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.

Required

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.

Optional

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:

1. Application name

2. Version number

3. Release date

4. Copyright

Required

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

Recommended

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

Optional

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

Optional

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.

Required

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.

Required

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.

Optional

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.

Recommended

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.

Recommended

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.

Recommended

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.

Required

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

Recommended

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

Recommended

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.

Recommended

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.

Required

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

Required

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

Optional

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.

Recommended

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.

Required

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

Required

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.

Required

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

Recommended

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).

Recommended

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

Recommended

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.

Required

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

Recommended

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

Recommended

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.

Recommended

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.

Recommended

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.

Recommended

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:

The folder "My.Stuff" cannot be attached because it is a folder.
 
Only documents, applications, and scripts can be
 
attached.

Required

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.

Required

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.

Required

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.

Recommended

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.

Required

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.

Optional

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.

Optional

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

Optional

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

Required

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.

Required

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.

Required

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.

Recommended

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.

Recommended

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.

Recommended

Use icons to represent only objects and applications.

Recommended

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.

Recommended

Design icons for international use.

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

Recommended

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

Recommended

Center 48x48 icons in the bounding box.

Required

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

Required

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.

Required

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.

Recommended

Give users the option to hide the tool bar.

Required

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.

Recommended

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.

Recommended

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

Recommended

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

Recommended

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.

Recommended

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.

Recommended

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.

Required

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.

Recommended

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.

Recommended

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.

Recommended

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

Required

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

Required

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.

Required

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

Required

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.

Optional

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.

Recommended

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.

Required

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.

Required

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.

Recommended

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.

Recommended

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

Recommended

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

Optional

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

Optional

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.

Recommended

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

Optional

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.

Recommended

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

Recommended

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

Recommended

Use the appropriate dialog box style to display messages.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Optional

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.

Recommended

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.

Recommended

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.

Recommended

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.

Essential Related Topics

For more information, see the Control, Menu (Control), Menu Bar (Menu Type), Message, Object, View, and Window Navigation reference pages.

Supplemental Related Topics

For more information, see the Warning Signal reference page.