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.

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.

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

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

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:

Replacing the File menu:

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

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

Table 1. File Menu Choices

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

Table 3. Edit Menu Choices

Table 4. Help Menu Choices in CDE

Table 5. Attachment Menu Choices in CDE

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.

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

Table 6. Pop-Up Menu Choices in CDE

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

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

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

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.

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

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

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

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

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.

Table 8. Dialog Box Title Conventions

Table 9. Dialog Box Choices

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.

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.

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.

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.

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.

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.

That minimum set should be:

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.

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

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.

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.

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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

Display the busy pointer within 0.5 seconds of execution of the command.

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.

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.