Common Desktop Environment: Style Guide and Certification Checklist

Part I Style Guide

Chapter 1 Introduction to the Common Desktop Environment

The Common Desktop Environment is a graphical user interface for UNIX® in its various flavors (AIX, HP/UX, Solaris^TM, UnixWare, and so forth). UNIX is a powerful and portable operating system. The desktop now brings unparalleled ease of use to UNIX.

The desktop has been jointly developed by Hewlett-Packard, IBM, Novell and Sun Microsystems. It is being adopted as a standard operating environment by these companies and many others in the UNIX workstation market.

Advantages of a Common User Interface

The desktop interface brings greater ease-of-use and a consistent interface to UNIX. This provides many advantages to both end users and application developers. Among these advantages are:

An easier to use interface enables users to learn the system quickly and use it efficiently.
Consistency between UNIX platforms enables users to move from one computer to another with minimal difficulty. It also enables programmers to write a single application that can be compiled for each platform, significantly reducing development effort.
The desktop provides as much consistency as possible with the Microsoft Windows and IBM OS/2 environments. This enables users to easily move between these environments and the desktop.
Unlike many competing operating systems, several built-in productivity applications enable the desktop user to be productive before buying application software.
The desktop specifications have been submitted to the X/Open standards organization, ensuring that desktop is "open" and will not tie the user to proprietary solutions.

Relationship to the Open Group's Motif Style Guides

The desktop user interface follows the Motif guidelines. Motif, however, does not define a desktop, only the basic behaviors for applications and widgets. The Style Guide and Certification Checklist defines the guidelines that enable an application to integrate well with the desktop. Thus, to write a desktop-conforming application, you should follow both the CDE 2.1/Motif 2.1 Style Guide and Glossary and the Common Desktop Environment: Style Guide and Certification Checklist.

Compliance with the desktop interface guidelines is voluntary and self-regulated. There is no formal certification process. Applications that meet all the required guidelines in this style guide and the CDE 2.1/Motif 2.1 Style Guide and Glossary can be considered desktop compliant.

Note -

CDE 2.1/Motif 2.1 Style Guide and Glossary is part of a set of style guides for Motif that are available from The Open Group (www.opengroup.com). This book set replaces the OSF/Motif Style Guide, although there are few differences in the actual guidelines.

In this book, priorities have been assigned to each guideline: Required, recommended, and optional.

Chapter 2 Input, Navigation, Selection, and Activation

Input devices have different actions depending on which part of the interface the user is interacting with. Usually, mouse users can access windows and controls more easily than keyboard users, due to the inherent flexibility in mouse manipulation. Keyboard users must use specific keys to move the cursor in the application.

Users have to move pointers and cursors within the interface to indicate where actions should occur. To do so, users employ navigation methods that vary, depending on the cursor's location in the interface. Therefore, navigation refers to how users move pointers and cursors within the interface.

Users often need to indicate which element of the interface they want to interact with. Selection enables users to identify individual or multiple elements for subsequent interaction.

Activation refers to using controls to perform actions. When a user chooses a button or chooses an item from a menu, for example, the user is activating those controls.

The following sections outline Common Desktop Environment requirements for input, navigation, selection, and activation.

Input Guidelines

Virtual keys are names for generic operations that the user can perform through the interface. They may be mapped to one or more physical key combinations. Application developers are strongly urged to provide support for Help, Properties, Undo, Cut, Copy, and Paste if their application has functions corresponding to these virtual keys. Other virtual keys may be supported as appropriate.

Required

Components and applications that have functions corresponding to the Motif/Common Desktop Environment virtual keys must support those keys.

See the checklist item for a list of the virtual keys and their mappings.

Navigation

The desktop allows either BSelect or BMenu to be used to display menus. This capability has been added for users familiar with environments that provide a dedicated mouse menu button.

For mouse-based navigation of text fields, the desktop has added a requirement that the text cursor be placed at the mouse cursor position, rather than at the beginning or the end of the text field.

Mouse-Based Navigation

Optional	b:	BMenu Press or BMenu Click on a menu bar item displays the menu.
Required	c:	BMenu Press or BMenu Click on an option button displays the option menu.
Required	d:	BSelect Press on a text field causes the text cursor to be inserted at the mouse cursor position.

Keyboard-Based Navigation

The requirement to support Tab as a navigation key within groups of push buttons has been added to make keyboard navigation easier for users who have difficulty with the standard keyboard. This change is intended to reduce the number of side-to-side traversals of the keyboard (from Tab to arrow keys and back) that a user must perform to navigate within a single dialog box.

Optional	e:	Each time a new window is opened, keyboard focus is placed in the first field or location within the window or in a default location, if this is appropriate for the particular window.
Required	f:	The Tab key moves input focus between push buttons within a group. The arrow keys also move the selected focus per the OSF/Motif Style Guide, Revision 1.2.
Required	g:	Use the Control, Shift, and Alt keys only to modify the function of other keys or key combinations.
Optional	h:	Use the Alt key only to provide access to mnemonics.

Selection

The desktop has incorporated two significant changes to selection in Motif. The first is that users may elect to have either Adjust or Transfer capability on the middle mouse button. In addition, the desktop integrates drag and select on the first mouse button.

On a three-button mouse, button 2 is typically used for the BTransfer (or BSelect) function. However, in a Common Desktop Environment environment, the user may change an environment setting indicating that mouse button 2 should be used for the BAdjust function instead. BAdjust can be used to toggle the selection state of elements under the multiple selection model.

The following guidelines describe the BAdjust behaviors.

Mouse-Based Multiple Selection

Required	i:	If your application contains collections that follow the multiple selection model, BAdjust is supported and behaves just like BSelect, when the BTransfer button is currently configured to behave as BAdjust.
Required	j:	In a collection that uses multiple selection, clicking BSelect or BAdjust on an unselected element adds that element to the current selection. Clicking BSelect or BAdjust on a selected element removes that element from the current selection. Clicking BSelect or BAdjust moves the location cursor to that element.

Mouse-Based Range Selection

Required	m:	If your application contains collections that follow the range selection model, BAdjust is supported and behaves just like Shift+BSelect, when the BTransfer button is currently configured to behave as BAdjust.
Required	n:
		Reselect	The extended range is determined by the anchor and the current pointer position, in exactly the same manner as when the selection was initially made.
		Enlarge Only	The selection can only be enlarged. The extended range is determined by the anchor and the current pointer position, but then is enlarged to include the current selection.
		Balance Beam	A balance point is defined at the midpoint of the current selection. When the user presses Shift+BSelect or BAdjust on the opposite side of the balance point from the anchor, this model works exactly like the reselect model. When the user presses Shift+BSelect, BAdjust, or starts a navigation action modified by Shift on the same side of the balance point as the anchor, this model moves the anchor to the opposite end of the selection and then works exactly like the reselect model.
		When the user releases BSelect or BAdjust, the anchor does not move, all the elements within the extended range are selected, and all the elements outside of it are deselected.

Mouse-Based Discontiguous Selection

Required

In a collection that uses discontiguous selection, BAdjust can be used to extend the range of a discontiguous selection. The extended range is determined in exactly the same way as when BAdjust is used to extend a range selection.

Component Activation

The following guidelines have been provided to clarify double-click timing and mnemonics, to explain changes in activation of specific components, and explain behaviors of components that are new in CDE Motif.

Basic Activation

Required

The time allowed to detect a double click (*doubleClickTime: 500) should be no less than 500 milliseconds.

Mnemonics

Required

Mnemonic characters must be chosen for ease-of-location within the text of a label. Wherever possible, use the first character of the label. If that is not possible, try to use the last character of the label, or if there is more than one word, the first character of the second word. After that, go through the label from the second character on until a unique mnemonic is found.

CheckButton

Required

7-1:

Your application uses check buttons to select settings that are not mutually exclusive. A check button graphically indicates its state with the presence or absence of a check mark.

A check button is used to select settings that are not mutually exclusive. The user needs to know whether the button is set or not.

OptionButton

Required

7-23:

When the user presses BSelect or BMenu in an option button, the associated option menu is posted.

BSelect Press is a consistent way of activating an option button.

Required

7-24:

When the user releases BSelect or BMenu within the same option button that the press occurred in, the associated option menu is posted if it was not posted at the time of the press. When the user releases BSelect or BMenu outside of the option button, the associated option menu is unposted.

BSelect Release or BMenu Release posts or unposts an option menu, depending on whether the release occurs inside the option button and whether the option menu was posted at the time of the press.

Gauge

Required	ib:	A gauge is similar to a scale except that a gauge is a display-only device with no user interactions. The appearance of a gauge is similar to a scale, but the gauge lacks a scale slider.
Optional	ic:	Despite being a display-only device, a gauge should get keyboard focus so that the user can access Help or Settings for that control.

Chapter 3 Drag and Drop

Drag and drop enables the user to directly manipulate objects in the computing environment. This chapter discusses and provides guidelines for incorporating drag and drop into your application. If you plan to use drag and drop or attachments in your application, then you should read this chapter.

You should be familiar with the description of Motif 1.2 drag and drop as covered in the OSF/Motif Style Guide, Version 1.2. If you are not, read Section 4.3.4, "Drag Transfer," in that book. Where differences occur, this chapter supersedes the OSF/Motif Style Guide, Version 1.2.

Drag-and-Drop User Model

Direct manipulation of objects in the computing environment helps the user feel in control of the computer, which in turn helps the user feel more comfortable about trying new operations and about computers in general. It is also a more efficient method for performing many operations.

To understand the drag-and-drop user model, you must understand the following terms:

drop zone: An area of the workspace that accepts a dropped icon. Drop zones are usually represented by the control or icon graphic, such as the Trash Can or the Print Manager control.
drag icon: The composite cursor used during the drag. See "Parts of a Drag Icon" for details.

In the Common Desktop Environment, the user can select and drag icons in File Manager, mail messages and attachments in Mailer, appointments in Calendar, and text from text editors or text fields. These items can be dropped onto any drop zone that accepts them. For example, a document icon from File Manager can be dropped onto a folder icon in File Manager, onto the Print Manager icon on the Front Panel, or on the attachment list in Mailer.

When an item is dropped, some action happens with the dropped item. For example, the document might get printed, moved, or attached. The action taken depends on the object being dragged and where it is dropped.

Recommended

dq:

You should provide a drag-and-drop (DND) method for all objects represented as icons. Provide a DND method for all elements that the user can directly manipulate.

Recommended

dr:

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

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

Drag-and-Drop Feedback

Visual feedback to the user is one of the critical elements for making drag and drop work. Without clear visual feedback, it is difficult for the user to predict the results of a drag-and-drop operation. Visual feedback must also be timely.

The user should be able to identify visually the following items during a drag-and-drop operation:

Type of item being dragged -- The drag icon should show the user what type of item is being dragged.
Drop zone -- The drop zone should visually indicate when the dragged item is over the drop zone, and whether the drop zone is valid or invalid for that item.
Resulting activity -- The drag icon should visually indicate what action will take place when the item is dropped.
Success or failure -- When the item is dropped, transition effects should indicate the success or failure of the drop.

Type of Item Being Dragged

The visual feedback for drag and drop is based on the concept that what you see is what you drag. For example, if the user selects a folder icon in File Manager and starts dragging it, the drag icon should show the folder icon as part of the drag icon, as illustrated in Figure 3-1.

Figure 3-1 Drag icon showing the object being dragged

Required	dt:	During a drag operation, your application changes the current pointer to a drag icon.
Recommended	du:	During a drag operation, your application changes the current drag cursor to include a source indicator.

While this may seem like an obvious behavior, it is critical to give users feedback showing exactly what they are dragging. Providing this kind of consistency makes drag and drop more predictable to the user. Text drags are the exception in that the actual text is not dragged. Figure 3-1 shows a text drag icon.

Figure 3-2 Example of a text drag icon

Applications are responsible for supplying a graphic to be used in the drag icon. This graphic is usually one of the icons already supplied with the application, such as the 32x32 icons used in File Manager to represent documents. The graphic used depends on what is being dragged.

In cases where the user does not select an icon to start a drag, it is still appropriate to show a relevant graphic in the drag icon especially if that graphic will be used by the destination application upon drop. For example, in Calendar Appointment Editor, the user can select an appointment from the scrolling list, which does not show icons. An appointment icon is used as part of the drag icon. If the appointment were dropped on File Manager, File Manager would display the appointment using the same graphic.

Drop Zone

The user needs to know when the dragged item is over a valid drop zone. There are two pieces to this feedback; the drag icon and the drop zone. The drag icon changes from an arrow to a cannot pointer when the user moves the drag icon over anything but a valid drop zone. This behavior is sometimes referred to as drag over feedback. On the desktop, there is no differentiation between invalid drop zones and something that is not ever a drop zone. Figure 3-3 shows a sample cannot pointer drag icon.

Figure 3-3 Example of a cannot pointer drag icon

The drop zone feedback options (referred to as drag under feedback) indicate valid drop zones. The options include a solid line drawn around the site, a raised or lowered surface with a beveled edge around the drop zone, or drawing a pixmap over the drop zone. The beveled edge effect is used to make the drop zone look recessed. Figure 3-4 shows the recessed appearance. On the desktop, most drop zones use the recessed appearance when a drag icon is over the drop zone to indicate it is a valid drop zone.

Figure 3-4 Example of drop zone feedback from the Front Panel.

Recommended	dw:	During a drag operation, your application changes the drop zone feedback to indicate a valid drop zone.
Recommended	dv:	During a drag operation, your application changes the current drag cursor to indicate invalid drop zones. It uses the standard Common Desktop Environment cannot pointer.
Optional	dz:	Any cursor change or drag-over effect your application uses occurs within .2 seconds of the mouse pointer reaching the target area and does not interfere, in any noticeable way, with the interactive performance of the drag operation.

Resulting Activity

In the Common Desktop Environment, there are three operations that can be associated with the drag icon. These operations are explained in "Parts of a Drag Icon". The drag icon has alternate graphics, supplied as part of the desktop, used to indicate to the user when the operation is a copy or link. The default operation, move, requires no alternate icon graphics.

Success or Failure

The user needs an indication that the drag-and-drop operation either succeeded or failed. You should use transition effects to indicate the success or failure of the drop.

There are two kinds of transition effects: melt and snap back. The melt effect is used when the user drops a drag icon on a valid drop zone. The effect looks like the drag icon melts into the drop zone. The drag icon goes away and is replaced by whatever is appropriate for the destination application. Dropping a drag icon on the Print Manager control on the Front Panel may show nothing other than the melt in effect. Dropping a drag icon on the File Manager control would show the melt in effect followed by the icon appearing in File Manager.

The snap back effect is used when the drop fails. Drops can fail in two ways: because the drop zone is invalid, or because the data transfer fails. If the user drops a drag icon over an invalid drop zone, one that shows the cannot pointer drag icon, then the drag icon snaps back to the source application.

Once a drop occurs, the source and destination applications have to transfer the data. If the data transfer fails, there are two things that the destination application should do. The first is to indicate to the API that the drop failed so that the dropped item will get snapped back to the source application. The second is to put up an error notice to the user that clearly indicates why the drop failed and what, if anything, the user can do to correct the situation.

Sometimes the transition effect does not take place immediately. The icon appears where it is placed until the transfer is done. During this time, applications should set the cursor to the busy state. The icon cannot be moved or selected by the user until the transfer is complete; the busy cursor tells the user the transfer is in process.

Recommended	ea:	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 indicates whether a single object or multiple objects are being manipulated.
Required	eb:	After a successful transfer, the data is placed in the drop zone, and any transfer icon used by your application is removed.
Required	ec:	If your application removes data upon the completion of a drag and drop, it does so only if the drag-and-drop transfer has completed successfully.
Required	ed:	After a failed transfer, the data remains at the drag source and is not placed in the drop zone. Any transfer icon used by your application is removed.
Recommended	ee:	If the user drops an object at an inappropriate drop zone within your application's window, your application participates in the display of a snap back effect and also posts an error dialog box indicating the reason the drop was disallowed.
Required	6-17:	If your application provides any drag-and-drop help dialog boxes, they contain a Cancel button for canceling the drag-and-drop operation in progress.

Parts of a Drag Icon

The drag icon is composed of three parts, as shown in Figure 3-5. Starting from the left, the drag icon is composed of the state indicator plus the operation indicator plus the source indicator (here shown as a folder icon). On the right is the composited drag icon.

Figure 3-5 Example drag icon showing the three parts

State Indicator

The state indicator is really a pointer for positioning combined with a valid or invalid drop zone indicator. The valid state indicator should resemble an arrow pointer with a hot spot so users can position the cursor in a predictable manner. The invalid state indicator, a cannot pointer (illustrated in Figure 3-3), appears when users are over an invalid drop zone.

Operation Indicator

The second part of the drag icon is the operation indicator. A drag operation can be a move, copy or link.

move: The item being dragged is moved to the destination.
copy: The item is copied to the destination.
link: A connection is retained between the destination and the source. This operation is defined to some extent by the application and is not commonly used.

See "Actions"to see how move, copy, and link map to user actions.

The operation indicator gives the user feedback on what operation is occurring during the drag. Figure 3-6shows the copy and link feedback. Because most drags are move operations, an operation indicator is added to the drag icon only for copy or link operations.

Figure 3-6 Examples of copy (left) and link operation indicators

Note -

Operation feedback is drawn on top of the state and source feedback. This is basic Motif behavior.

The user can force a drag to be a move, copy or link by pressing certain keys during a drag (Shift = move, Control = copy, and Shift+Control = link).

The source application can also force a copy. When the user forces an operation, the drop zone should match that operation for the drop to succeed; otherwise the drop zone should indicate the operation is invalid.

Required	4-36:	If the move, copy, or link operation the user requests is not available, the transfer operation fails.
Required	4-55:	In a collection that supports selection, Shift+BTransfer Release or Shift+BSelect Release forces a drag move operation. If a move is not possible, the operation fails.
Required	4-56:	In a collection that supports selection, Control+BTransfer Release or Shift+BSelect Release forces a drag copy operation. If a copy is not possible, the operation fails.
Required	4-57:	In a collection that supports selection, Control+Shift+BTransfer Release or Shift+BSelect Release forces a drag link operation. If a link is not possible, the operation fails.
Recommended	s:	In a collection that supports selection, if BTransfer Motion (or BSelect Motion) results in the start of a drag operation, feedback is presented to the user that indicates that a copy, move, or link operation is in progress. Whether the operation is a copy, move, or link depends on the type of object created at the drop zone and whether the source object is removed.
Recommended	t:	In a collection that supports selection, if Control+BTransfer Motion or Control+BSelect Motion results in the start of a drag operation, feedback is presented to the user that indicates that a copy operation is in progress.
Recommended	u:	In a collection that supports selection, if Control+Shift+BTransfer Motion or Control+Shift+BSelect Motion results in the start of a drag operation, feedback is presented to the user that indicates that a link operation is in progress.

Source Indicator

The source indicator is a representation of the selection (or the thing being dragged). It comes in several versions depending upon whether the selection represents single or multiple items and what kind of thing the selection is representing. Table 3-1 shows examples of drag icons.

Note -

Since the drag icons are dynamically composited as cursors, screen shots cannot be taken; therefore, Table 3-1is an approximation of what is seen on the screen and may not be completely accurate.

The hot spot is located on the top left corner (1,1) for the text drag icons. The hot spot for the single and multiple drag icons is located at the top left pixel of the invalid icon (3,3). Each drag icon has been tuned to increase user accuracy at targeting and positioning.

Table 3-1 The possible drag icons shown with generic source indicators.


Operation	Text Selection	Single Selection	Multiple Selection
Valid Move
Valid Copy
Valid Link
Invalid Move None
Invalid Copy
Invalid Link

Drag-and-Drop Mechanics

There are several areas of the underlying application architecture that are useful to understand when designing drag and drop.

What type of object is being dragged.
What action takes place when the object is dropped.
How to match operations between source and destination applications.

Types

In the Common Desktop Environment, there are three types of dragable objects: files, buffers, and text selections.

Each application has its own objects that can be dragged and dropped. For example, Calendar uses appointments, Mailer uses mail messages, and File Manager uses folders and files. The folder and file icons in File Manager exist as separate entities in the underlying file system and are, therefore, treated as files when dragged and dropped. However, Calendar appointments and Mailer messages do not exist as separate entities in the file system. When these objects get dragged they are treated as buffers.

This difference can lead to some conflicts for the user. The user sees both of these types of objects as the same -- both can appear as icons and both can be manipulated separately from other similar objects. Yet, due to the implementation, the user may see different results from a drag-and-drop operation based on which type of object is being manipulated.

Text selections fall into a different category because selecting a piece of text is very different to the user than selecting an icon. The user selects a range of text in a document window; the text does not represent the whole document, it only represents a piece of a document. Rarely does a user see the piece of text as a distinct object and the user does not expect a piece of text to behave like an icon when dropped. For this reason, the drag-and-drop model for text mirrors the cut, copy, and paste operations available from the Edit menu.

Actions

There are two actions that can take place when an object is dropped: insert or load.

The insert action inserts the dropped object into the destination, adding it to the current data in the application or document. The object is inserted when a user schedules an appointment, prints a document, attaches a document, pastes text, or appends a mail message. Such an action is a move or copy operation depending on the destination and the user. The user might decide to copy a piece of selected text, as opposed to moving it. The drag icon should indicate whether the operation is a copy or move.

The load action operates the same as if the user had chosen Open from the File menu, selected a file, and clicked the Open button. The dropped object gets loaded into the application. The user can edit it and save changes back to the original file. Load only works with files at this time, not with buffers or text. The user should see the copy drag icon when dragging an object over a drop zone that supports the load action.

Load does work with buffers; however, buffers are loaded as read-only. See the section on "Attachment User Model"for more details.

Matching Operations

When designing how drag and drop works in an application, you must understand how Motif figures out what operation gets done when the source and destination of a drag and drop don't match.

For each drag source, an application advertises which drag-and-drop operations are possible and on what destinations it can be dropped. For each drag destination, the application advertises the possible sources and the types of operations. If a source and its destination have two or more operations in common, Motif follows a specific order to determine which operation to use. That order is move, copy, link. The application cannot change the operation that is accepted based on the type of thing being dragged.

For example, application A might advertise that an element can be moved or copied. Application B advertises that the destination accepts copy or link. The intersection in this example is copy. If the destination in application B accepts move or copy, then the source is moved because the move operation comes first in the operation order.

In this example, the user could override the move operation by holding down a modifier key, for example the Control key to make the operation a copy. This will work if the copy operation is in the common set of operations. If the copy operation is not in the common set, then the drag becomes an invalid drag.

The only time matching operations may be a consideration is when you have a destination that could accept moves but prefers copies. In that case, the destination is better off only accepting copies.

It is wise to always accept copy. Accepting copy broadens the scope of acceptable drops. In most cases where a move is accepted, a copy would work just as well. Remember, move is implemented as a copy followed by a delete.

Determining Drag Sources

When you decide to use drag and drop in an application, you must decide what control elements can be dragged and how that element is to be represented. Typically, the user selects something like text or a file to drag, but the application may have other elements for which drag and drop may make sense, such as mail messages or appointments.

This section provides general guidelines for determining drag sources and then talks about specific elements that can be dragged.

Note -

Drags are only sourced from human interface elements that have selectable components or items. Drags cannot be sourced from static labels like those on buttons or menus.

Before you decide on a drag source from your application, you must consider how the drag is to be integrated into the selection mechanism of your application. The user must be able to select or drag without any confusion as to the result of that action.

Required	4-58	When a drag move operation moves a selection within the same component, the selection moves along with the elements selected. In other words, when selected elements are moved with a drag operation, they should stay selected after the move.
Required	4-59	In text-like collections, initiating a drag within a selected region drags the entire text selection.
Required	4-60	In list-like and graphics-like collections, initiating a drag with either BSelect or BTransfer on a selected element drags the entire selection.
Required	4-61	In list-like and graphics-like collections, initiating a drag with BTransfer or BSelect on an unselected element drags just that element and leaves the selection unaffected.
Required	4-62	When a drag is initiated in an unselected region and the pointer is over two possible dragable elements, the drag uses the dragable element highest in the stacking order.
Required	4-67	When BTransfer (or BSelect) is released, the drop operation ordinarily occurs at the location of the hot spot of the drag icon pointer and into the highest drop zone in the stacking order. However, if a drop occurs within a selection and pending delete is enabled, the transferred data replaces the contents of the entire selection.

Scrolling Lists

In the Common Desktop Environment, items in a scrolling list are text objects by default. They can be buffer objects, but they cannot be both text and buffers. For example, the Calendar Appointment Editor has a scrolling list of appointments that the user can select and drag. When the user drags an appointment, they are manipulating a buffer and the drag icon shows an appointment icon as the source indicator, as shown in Figure 3-7. A Mailer container window has a list of mail messages in the upper portion of the window. Users can select and drag one or more messages from this list. These messages are actually buffers and the drag icon shows a mail message as the source indicator. If multiple mail messages are dragged, then the drag icon shows the multiple source indicator.

Figure 3-7 Example of a scrolling list with an item selected for dragging

If your application uses a scrolling list to show mail message headers or list other kinds of objects, then you need to integrate dragging with extended selection. this behavior can be seen in the Mailer application.

Required	k:	In a collection that uses range selection, pressing BSelect on an unselected element sets an anchor on the element, or at the position where BSelect was pressed, and deselects all elements in the collection. If BSelect is released before the drag threshold has been exceeded, then the element under the pointer should be selected. If BSelect Motion exceeds the drag threshold, then a new selection should begin. The anchor and the current position of the pointer determine the current range. As BSelect is dragged through the collection, the current range is highlighted. When BSelect is released, the anchor does not move, and all the elements within the current range are selected.
Required	l:	In a collection that uses range selection, pressing BSelect on an currently selected element should not cause all other elements in the selection set to be deselected. If BSelect is released before the drag threshold is exceeded, then, at that point, all other elements should be deselected and the element under the pointer should remain selected. If BSelect Motion exceeds the drag threshold, then no element should be deselected and a drag operation should begin.

Dialog Boxes

Sometimes an application needs to be able to drag from inside a dialog box. For example, in the Calendar Appointment Editor, there are a series of text fields on the left side where the user enters information about an appointment. Allowing drags from this area lets the user drag text from the appointment description.

Figure 3-8 Example Calendar Appointment Editor dialog box

The recommended method for indicating that something can be dragged is to include an icon graphic in the dialog box. The icon graphic should be dragable. This icon graphic must be the same icon used to represent the data in File Manager. In Calendar, the appointment icon is shown just as it would appear in File Manager (see Figure 3-8), with a label under it. This is the same icon used in the drag icon source indicator.

Place the icon graphic in the dialog box adjacent to the information to be dragged. The upper right corner of the dialog box or window is the default position, but it can be changed depending on the application. In Calendar Appointment Editor, the icon is placed near the main text field to indicate that you can drag the text fields.

Recommended

ds:

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 dragable object in File Manager. Place the icon adjacent to any display of the contents of the object, if such 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.

Windows

In some applications, you may want to allow the user to drag the entire document or file. For example, in Icon Editor, it might make sense to allow the user to drag the file for the icon currently in the editor. The application should indicate to the user that the document or file can be dragged by incorporating an icon graphic in the window of the application. The icon graphic should be dragable. In the case of Icon Editor, one of the icons used for displaying the contents of the icon file could be used for the drag. The icon should follow the guidelines for an icon used in dialog boxes; that is, it should be the same icon used to represent the document in File Manager, be 32x32 pixels, have a label, be placed adjacent to the data being dragged, and be used as the source indicator in the drag icon.

Dragging and Dropping a Multiple Selection

When the user selects more than one item to be dragged, the drag icon should change to indicate there is more than one item selected.

Some drop zones may be able to accept only a single item. It is not possible for a drop zone to differentiate between a single and a multiple set of items being dropped. The drop icon does not display the cannot pointer; instead the items should melt in and then be snapped back by the destination application. The snap back should be followed by an error notice that tells the user why the drop failed.

Recommended

ef:

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

There is no consistent method to determine which of the selected items the user really wants to drop.

Standard Supported Drop Zones

The standard supported drop zones in the Common Desktop Environment are Front Panel controls, open windows, and folder, action, and certain other icons in File Manager. Dropping on minimized icons and on File Manager icons that do not support drops are not supported in the Common Desktop Environment.

The Front Panel

The Front Panel is a collection of controls and other functions put together for easier and faster access for users. As a consequence, its drag and drop behaviors are heavily dependent upon the context of the destination. For example, if the destination is a printer, then print it. If the destination is a subpanel, then install it. Most applications will not vary in behavior quite as broadly as the Front Panel.

File Manager

File Manager for the Common Desktop Environment allows users to drop icons on the desktop. The icon on the desktop becomes a reference. The creation of the reference and resulting behaviors are not consistent with the future user model for the Common Desktop Environment. Until the user model and architecture are further specified, developers are not encouraged to do any drops onto the desktop or to copy the File Manager behavior.

Within File Manager windows, File Manager allows dropping onto icons other than folders and action icons for the Common Desktop Environment 1.0. For example, dropping a mail message icon onto a mail container icon appends the mail message.

When mail messages or calendar appointments, or other buffers are dragged from the source application and dropped onto File Manager, they must be named. The underlying API supports a name field for the item being dragged. This name should be used as the name of the buffer. The name should be determined in a manner consistent with the application from where it came. If there is no appropriate name, as in dropping a text selection in File Manager, File Manager should name the resulting file "unnamed". If there is a name conflict, File Manager should put up a dialog box and ask the user to rename the dropped file.

No Drop-Only Targets

The Common Desktop Environment does not support the concept of a specific control or graphical target used only for drops. Any control in the human interface that has selectable items can be dropped upon and should provide drop zone feedback. This includes data panes, scrolling lists, and text entry fields. The operation that takes place upon the drop should be consistent with the users expectations for that application type.

Mouse Button Usage

In the Common Desktop Environment, the user can modify mouse mappings to accommodate different working styles. BSelect has been modified to support drag and drop in addition to BTransfer, which has been used historically for Transfer operations in Motif.

Users can set up their systems to use Bselect or BTransfer to perform drag and drops, or use BSelect only. Consider this when you design your application. Check how the user has set the mouse button mappings and use those mappings.

Required

Your application supports the use of mouse button 1 to perform drag-and-drop operations.

In Motif 1.2, drag and drop is typically performed using button 2 on a three-button mouse (BTransfer). However, in the Common Desktop Environment environment, mouse button 1 (BSelect) should be supported for drag and drop to support mouse usage compatible with other graphical user interface (GUI) environments. A drag can be initiated with either mouse button 1 or mouse button 2.

Required

When button 2 of a three-button mouse is configured to operate as BAdjust, your application does not perform any BTransfer operations when clicking mouse button 2.

On a three-button mouse, button 2 is typically used for the BTransfer function. However, in a CDE environment, the user may change an environment setting indicating that mouse button 2 should be used for the BAdjust function instead. BAdjust can be used to extend the selection set in the same manner as Shift+BSelect.

Required

BSelect should always initiate a drag if the drag is started on a selected item. The drag starts once the drag threshold has been reached. This is true for text regions, scrolling lists, and other similar elements.

Placement Upon Drop

From the user's point of view, the placement of the dropped item is dependent on the task the user is doing and the application or context the task is in.

In File Manager, if the default is set to As Placed, then icons are placed where they are dropped. If the default is set to Sorted Grid, then a dropped icon is automatically sorted and then placed, which means it may not be placed where the user drops it.

In some cases, where the dropped item gets placed is not a criteria. For example, Front Panel controls require only that the dragged item be over the control to activate the drop zone.

In the Compose window in Mailer, the placement depends on what is being dropped. If the user is dragging a piece of text, then the text is inserted at the drop point. From user testing, this is what users expect. If the user drops an icon, a file, or a buffer, then the contents are included at the insertion point. This mirrors the behavior the user gets when the user selects a file from the Include File Selection Box.

You should determine appropriate behavior for your application based on what type of tasks the user is doing.

Required

4-37

If a collection does not have a fixed insertion point or keep elements ordered in a specific way, the insertion position for transferred data is determined as follows:

For BTransfer-based (or BSelect) primary and drag transfer operations, excepted as noted below for text collections, the insertion position is the position at which the user releases BTransfer (or BSelect).
In a text-like collection, when the user drops selected text, the insertion position is the position at which the user releases BTransfer (or Bselect). When the user drops an icon, the insertion position is the text cursor and the data is pasted before it.
In a list-like collection, the insertion position for other transfer operations is the element with the location cursor, and the data is pasted before it.
The insertion position is the position in the destination where transferred data is placed. Some mouse-based transfer operations place data at the pointer position if possible. Other operations, including keyboard-based transfer, generally place the data at the location cursor.

Ending a Drag

The following two items allow users to stop a drag operation without any data loss or other negative result.

Required	dx:	Pressing Cancel ends a drag-and-drop operation by canceling the drag in progress.
Required	dy:	Releasing BTransfer (or BSelect) when not over a drop target ends a drag-and-drop operation.

Performance Guidelines

There are several points during a drag-and-drop operation that the timing and response to the user is critical. The responsibility for ensuring optimal performance belongs to the source and destination applications, as well as the Motif Drag-and-Drop API and Drag-and-Drop Convenience API.

The following time line explains the individual user steps and system responses in a drag-and-drop operation. The suggested guideline for interaction timing is noted after the relevant step.

The user makes a selection. The pointer is over the selected object. The user presses and holds down the mouse button.

The user starts to move the pointer. The user should be able to move the pointer 10 pixels before a drag is initiated. If the user is pressing BTransfer, there is no drag threshold.

The pointer changes to a drag icon when the drag is initiated.

Movement Latency: The latency from hand movement to drag icon display should be less than 50 ms with a maximum limit of 70 ms.

The user drags over a drop zone, crossing the boundary line with the hot spot on the drag icon.

The drag icon changes to the cannot pointer if it is not over a valid drop zone. The drop zone becomes highlighted if it is a valid drop zone.

Movement Latency: The latency from hand movement to drag icon display should be less than 50 msec. with a maximum limit of 70 msec.

The user drops the drag icon on the drop zone.

If the drop zone is not valid, the drag icon is snapped back to the source using the snap back transition effect.

If the drop zone is valid, the drag icon is melted into the destination using the melt in transition effect.

Echo Latency: The display latency from mouse button release to feedback echo should be less than 50 msec. with a maximum limit of 120 msec.

Snappy Transitions: Transitional animations should run from 200 to 350 msec. with a maximum limit of 500 msec. The animation should run at the same speed regardless of hardware conditions.

The destination application starts the data transfer.

A message is displayed to the user indicating data transfer has started.

Progress is indicated by further messages.

The completion of the data transfer is indicated to the user.

If the data transfer fails, it is up to the destination application to provide the user with appropriate feedback as to why it failed.

Command Latency: The latency from command invocation (drop occurred) to completion should be in the range of 0.3 to 1 second with a maximum of 2 seconds.

Busy Feedback: When a command may run longer than 2 seconds, display a busy cursor whenever the cursor is over the busy object. When possible, display partial results. The progress indicator or busy cursor should be displayed in less than 0.5 second.

Progress Indicators: A status message or an In Progress *messagebox* should be displayed upon completion of the transitional animation indicating the data transfer is taking place. For example: Data transfer is 10% complete. This message can then be updated every 2 to 3 seconds until the transfer is 100% complete.

Notice: If the data transfer fails, a message should appear, either in the status area or in an In Progress *messagebox*, indicating why the drop failed and what the user can do about it, if anything.

Using Attachments in Your Application

This section discusses the user model and guidelines for attaching documents to documents in the Common Desktop Environment 1.0. This functionality can be seen in the Mailer software application. If you plan to include an attachment list in the interface of your application, then you should read this section.

Note -

This set of guidelines is not a description of an embedded document architecture.

For the Common Desktop Environment, attachment and attachment list are defined as follows:

attachment: Suppose you had two documents called A and B. If a document, A, is attached to another document, B, then A continues to exist as a separate document that is "carried" by B. A is shown as an icon within B. A can be opened and viewed independently and can be detached from B at a later time, as if never attached at all.
attachment list: The area in which attachments are displayed. Should be scrollable and include room for showing icon labels.

Note -

Users do not think of a document that has several attached documents as a container. Containers are an implementation concept that should not appear in the attachments human interface. For that purpose, the term container should not be used to describe attachments to the user. (It may be an appropriate term elsewhere.)

Attachment User Model

Attachments are shown as icons where they are attached. These icons are the same icons as those used in File Manager and other places in the Common Desktop Environment. The basic rule of behavior is that if the same icon is used in File Manager as in an attachment, then every effort should be made to make the two behave the same in every situation.

There are three levels of functionality for attached documents:

Ability to attach and detach documents
Ability to open, view, and quit an attached document in a separate window
Ability to edit the attachment in a separate window and save changes back to the attached document

The goal is to provide Level 3 functionality whenever possible. If an attachment cannot provide this level, then it should degrade its level of functionality in the steps shown. This section is written assuming Level 3 functionality.

If a document provides significantly different functionality as an attachment from that provided as a File Manager icon, then provide a different icon for the attachment to clearly indicate to the user the difference in functionality.

Attachment Functionality

To incorporate attachments into an application, several issues should be considered.

What Can Be Attached?

You should determine for each application what items it can attach. For example, Mailer can attach documents, scripts, and applications, but not folders.

What is the Method for Attaching?

There are two methods of attachment, through the file selection dialog box that comes up when you choose Add File from the Attachment menu, and through drag and drop from File Manager or another application.

Recommended

eh:

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

Recommended

el:

When the user chooses something to attach from the file selection dialog box that is not an attachable item, then the user receives 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.

Recommended

ej:

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

What Happens When Something Is Attached?

The act of attaching document A to document B copies the bits of document A into document B. There is no further connection with the original file. If the user opens the attached document and makes changes, the changes are saved back to the attached document only, not back to a file in the file system.

Attachments in Attachments

Users can attach messages or text files that have attachments inside them. This is sometimes referred to as "nesting". The user reading the text file would perhaps see a mail message icon that the user could then open, which may have a text message and more attachments.

Editing and Saving Attachments

The user should be able to open an attachment, edit it, and save the changes back to the attachment. If the attachment does not have the ability to do this, then the Open action should not appear in the Actions portion of the menu when that attachment is selected and double-clicking should not open the attachment.

Recommended	ei:	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	ek:	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.

Executing Attachments

If the user tries to open or double-click on an executable attachment, then there may be times when the user should be asked to confirm this operation. Both the name of the attachment and the name of the action being taken on the attachment should be variables. An example error message follows:

"Invitation" is an executable attachment. Do you want to Run it?
 Buttons: Run, Cancel, Help

Read-Only Attachments

Read-only attachments can be opened for reading only. This state should be indicated to the user by inactivating the menus in the attachment application, inactivating the selection cursor, or some other obvious method. At a minimum, the Save menu item in the attachment application should be dimmed.

Drag Load and Attachments

Drag load can be accomplished in two ways. In applications that directly support drag load, users can drag an icon, from File Manager, over the open window for that application and drop it which loads the file represented by that icon. The same result can be accomplished by dropping an icon onto an action icon. The action starts an editor, which then loads the file represented by the icon. When an icon from File Manager is drag loaded, it is equivalent to choosing Open from the File menu. The open file can be edited and saved.

In the case of attachments, users can drag and drop an attachment onto editors or actions that support drag load but any edits made are not saved back to the attachment. Attachments, which are implemented as buffers, are loaded as read only data.

When the user tries to save changes to a loaded attachment, the editor displays a file selection dialog box and asks the user to confirm the name and to choose a place in the file system to save the file. The name used in the file selection dialog box is the same as the attachment name. If the editor (command line application) cannot bring up a file selection dialog box, then it should clearly and visibly indicate to the user that the loaded file is read-only.

If the user wants to edit the attachment directly, the user must select the attachment in the attachment list, choose Open from the Attachment menu or double-click on the attachment. This opens the attachment in a manner that allows for editing and saving changes.

Another option is to drag load an attachment, edit it, save it to a new file name, and replace the old attachment with the new one manually.

Attachment Menu Contents

Recommended	bw:	If your application uses an attachment menu, it contains the following choices, with the specified functionality, when the actions are actually supported by your application.
Recommended	Add File...	Selects files and other items to be attached. A file selection box is displayed allowing the user to select the desired files to attach. The default button in the file selection box is Attach.
Recommended	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.
Recommended	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, requesting the name from the user. This menu item is active only when a single attachment is selected. It is not active when multiple attachments are selected.
Recommended	Delete	Deletes attachments from the attachment list. This menu item is active only when an attachment is selected.
Recommended	Select All	Selects all the attachments in the attachment list.

Chapter 4 Visual Design

The Common Desktop Environment is a visually rich environment. This chapter provides information on designing icons and other visuals consistent with the desktop style. It discusses some of the design philosophy behind the desktop, and some useful hints to help you successfully create icons in the desktop.

Icons are graphics that represent the objects (that is, applications, files, and devices) present in a graphical user interface (GUI). Fitting your application into the desktop means designing icons to represent your application and the data files it creates. These icons should be created in several sizes and color depths.

This chapter discusses the desktop components where icons are used, the requirements of the environment, and discusses the design process. A series of examples have been provided that may parallel your own implementation situation.

Color Philosophy

In most other GUIs, the color is applied in a localized and specific sense, either in individual icons or specific control areas, such as window borders or title bars. In the desktop, color is pervasive, as virtually everything is drawn with colors, with a notable absence of black lines.

Most of the icons in this environment use color sparingly, preferring grays instead. This limited use of colors keeps the number of colors used from the palette in the desktop to a minimum and works well visually. Because the icons, being largely colorless, always appear in the context of colored backgrounds, they stand out more.

What Is an Icon?

An icon can be defined as a specific graphical element, one that can be moved, copied, deleted, opened, and so on, usually through direct manipulation.

Numerous graphical elements in the desktop are not manipulable and, therefore, not technically icons, but may still be needed in your application. This book discusses the entire range of graphical elements you may need to provide.

Figure 4-1 Screen shot of the desktop environment

Icons can serve to:

Identify data and application objects
Facilitate direct manipulation of objects
Indicate an object's state (selected, and others)
Convey a recognizable product identity
Show the relationships between the objects of a product

All of these purposes for an icon serve as guidelines for designing icons. The visual designer has more responsibility for some of these requirements than for others. For example, the direct manipulation of objects and the indication of an object's state and location are done by the desktop system, while identifying and conveying product identity and object relationships fall mainly under the responsibility of the visual designer.

Recommend

ey:

Icons should be used to represent only objects and applications.

Icons provide a visual representation for objects and facilitate direct manipulation. If icons are used for other purposes (for example, as illustrations) where the user can't drag them, select them, and so on, it creates a confusing inconsistency.>

Applying a set of design guidelines, like the ones here, should be considered during icon design. A new product on the user's desktop means adding a new set of icons to the ones already present. Conforming to these guidelines ensures the new icons do not clash with the user's expectations.

Icon-Centric Components

File Manager

File Manager is the tool that provides for the presentation and organization of the user's file structure. The basic types of iconic objects displayed in File Manager are files, directories (folders), executables and actions. In this chapter, these objects are referred to as documents, folders, and applications. File Manager displays the icons in two sizes, called Icon and Small Icon views in the Set View Properties dialog box. Icon is size 32x32 and Small Icon is size 16x16.

Figure 4-2 Collection of icons at sizes 32x32 and 16x16 as used in File Manager

Documents, folders, and applications are represented by three different shapes. Documents are vertical rectangles meant to look like pieces of paper. Folders are horizontal rectangles with a tab to look like a file folder. Applications can be any shape and use the entire icon square. All objects in File Manager should indicate to the user that they can be manipulated, that is, dragged and dropped.

Application Manager

This window is similar to File Manager, but its focus is on holding applications rather than documents. All network-accessible applications in the desktop are placed here in containers, called application groups, rather than folders.

Application Manager is like a "network store." This is the place users go to find the latest applications available on their system.

Figure 4-3 Examples of application group icons from Application Manager

Application group icons, as illustrated in Figure 4-3, are like folders in that they represent a collection of objects, in this case related objects. If your application requires support files or comes with sample files, for example, you can design your own application group icon that represents where a user can get the related files for your application.

Front Panel and Subpanels

The Front Panel is the "control" panel for the desktop and usually appears at the bottom of the screen. Front Panel icons provide quick access to the user's most commonly used applications.

Figure 4-4 Partial screen shot of Front Panel with the Personal Applications subpanel open

The Front Panel also has subpanels of icons that can be accessed through the arrow buttons on the Front Panel. The concept of the subpanel is that it is an extension of that Front Panel icon. For example, Figure 3-4 shows the Personal Applications subpanel open. Users can add applications to this subpanel by dropping them on the Install drop site. Users can choose to promote icons in the subpanel to the Front Panel via the pop-up menu.

Minimized Window Icons

Minimized window icons appear on the desktop when a window is minimized. The icon should represent the application that controls the minimized window (see Figure 4-5). These icons are different from the icons used in the Front Panel in that they represent running applications, although they are the same size.

Figure 4-5 Minimized window icons for Terminal, Text Editor, Calendar, and File Manager

Other Graphics

The dominant elements in this category include button graphics, tool bar graphics (see figure below), and graphics used as labels. A tool palette in a paint program is one example. A document orientation button (landscape or portrait) in a printer dialog box is another. These are graphics that you create for use in your application and are not used elsewhere.

Figure 4-6 Example of a tool bar used in the Calendar application

Color Usage in Icons

When designing icons for a desktop application, you must be aware of the available color palette and the dynamic mapping of colors.

Icon Color Palette

The icons in the desktop use a palette of 22 colors:

Eight static grays
Eight static colors: white, black, red, blue, green, cyan, magenta, and yellow
Five dynamic colors: Foreground, Background, TopShadow, BottomShadow, and Select
A transparent "color" which allows the background to show through

These colors are the default colors in the Icon Editor, which is the recommended tool for creating desktop icons (see Figure 4-7). This set of colors provides a reasonable palette with which to create icons. This limited palette was chosen to maximize the attractiveness and readability of icons without using an unnecessary number of colors.

If you use colors other than the ones listed here, then your icons may experience color flashing effects that can make the icon unreadable. The best way to ensure predictability of appearance of your icons is to use only the 22 colors in the desktop palette.

Recommended

ez:

Icons should use only the palette of 22 colors.

Figure 4-7 Icon Editor, showing the 22 Common Desktop Environment colors available for icons

Dynamic Colors

It is important to understand the limited role of the dynamic colors. These represent the colors used to display the user interface elements on which your icon appears. If your icon appears in File Manager, File Manager determines what the background color is. If the user changes the color palette in Style Manager, the colors in the user interface change to match, and the background color the icons are displayed on changes.

In general, these colors have little use in most icons. There are two ways they are used:

If your icon does not fill the entire bounding box, then fill the unused area with the transparent color.
You can draw a shadow under your icon. This is only recommended for Front-Panel-style icons. Do not use this for File Manager icons. See "Optional Front Panel Icon Style"for more detail.

Figure 4-8 Example of dynamic color shadows

Design Philosophy and Helpful Hints

The visual designer must approach the design of icons both individually and globally. Each icon should be individually designed according to the metaphor for that object. Pay careful attention to the visual effect produced by the entire set of icons for an application; they should work together as a family of icons.

Icon design is an iterative process. It is useful to save as many of the iterations as possible whether they are done on paper or computer. When icons are tested with users, it helps to have a varied set of choices to work with.

The philosophy behind the graphic language of the desktop is that users benefit if the computer world more closely resembles the real world. This extends from the three-dimensional appearance of windows and controls, such as push buttons and menu bars, to the general appearance of icons.

Your application icon can range from a logo to an object like the paint bucket in Figure 4-12. An icon that looks "real" looks more like something that can be dragged and dropped and manipulated in other ways.

Designing with Color

Your icon should primarily use the eight static grays with the eight static colors used mostly as accents. The eight static colors are very strong and can easily be overused. Using mostly the static grays allows icons to blend gracefully with the already colorful desktop environment. The static colors can be dithered with the static grays to tone the colors down for coverage of larger areas. The grays can also be used to smooth the edges of icons, this is sometimes referred to as "anti-aliasing".

It is recommended not to use the dynamic colors in File Manager icons, because the appearance of the icon will change when the user changes color palettes. Such a change could be inappropriate as well as unpredictably ugly.

Icon Styles

Icons run the gamut of graphical styles. From the earliest GUI days, the favorite has been a simple black outline style. As color has been added, the style has been that of coloring books, adding color within the black lines. This is a natural drawing style, especially when done on white backgrounds. Many icons are pictographic, while others are abstract.

Figure 4-9 Calendar icon in black and white outline style on left and the desktop gray style on right

The desktop, with its pervasive use of colored and medium-value backgrounds, uses both lighter and darker shades to create fairly realistic images. You are encouraged to explore this rendered style.

Figure 4-10 Examples of three-dimensional icons in the desktop

Another element of style is the point of view taken in portraying the object. The Common Desktop Environment uses a head on view, as can be seen in Figure 4-10, usually from slightly above if the object in question is a three-dimensional one, such as a printer. It is best to use a treatment that gives the icon a slight dimensional quality, as this reinforces the perception that the icon can be dragged and dropped.

Figure 4-11 Outline style converted to Common Desktop Environment style, in XPM and XBM formats

Designing Your Application Icon

The application icon is the most important icon for you to design. This is the place for your product identity, as well as a clear indication to the user of what your application does. The application icon is what the user opens to run your application.

There are no shape conventions for application icons. They can fill the entire icon bounding box or they can be irregular in shape. It is recommended that your icon have a three-dimensional style to it. The icons shown in Figure 4-12 are application icons used in the desktop that you can also use as templates when designing your own icons.

Figure 4-12 Examples of application icons used in the desktop

Designing Your Application Group Icon

The application group icon represents the container in which users find your application, as well as any other files you may choose to include, such as ReadMe or sample files. Design the icon in such a way that users know it is a container, such as a folder or box.

Figure 4-13 Examples of application group icons

The concept used in Application Manager is that of an icon based on accordion-style folders, as seen in Figure 4-13. This icon is large enough that images can be stamped on the front of it to indicate to the user what kind of things can be found inside.

Designing Your Document Icons

A document icon should help the user understand what kind of data is stored in that document icon and what application is associated with the document. Figure 4-14shows a number of document icons used in the desktop that you can use as templates when designing your own document icons.

Figure 4-14 Examples of document icons used in the desktop

Applications that support multiple file formats need different document icons for the different output formats. Rather than creating a distinctively different graphic for each format, you might use the same graphic for the basic file and add a "tag" to delineate the format.

In the case of the document icon, the basic rectangle of the document is left- aligned in the icon square. If the tag approach is used, place the tag on the right side of the icon, half on and half off the basic icon, but not obliterating the descriptive graphic, as illustrated in Figure 4-14.

International Icons

If your program will be used in more than one country, you should either design your icons for worldwide use or create separate icons for each country.

Worldwide icons are ones that are universally understood. For example, a document icon can be understood around the world because it represents paper, which is used everywhere. Icons for things like a mailbox or trash can are not universal because these objects look different in different countries.

Humor usually does not translate well. Text and symbols are also country-specific and should not be used in icons. Avoid the use of animals or body parts (heads, hands, and so on) because these have varying meanings and may be offensive in some cultures.

Recommended

fa:

Icons should be designed for international use.

Differences with Other Platforms

The desktop is different from the application spaces you may be familiar with in the following ways:

The desktop requires the larger 48x48 size to accommodate higher resolution displays.
The desktop has a different color space for icons. You may be able to reuse icons from other environments, but if they have color in them, chances are some of the colors will need to be changed to map onto the desktop palette. The basic design should still work. See Table 4-1for aid in translating colors.
Perhaps the most significant difference is that, in most cases, desktop icons appear against a background color other than white, which seems to be the norm in other environments. This can make your icon appear unreadable if you simply copy it from another environment. You should test any icons from other environments before using them on the desktop.

Table 4-1 RGB Values for Common Desktop Environment Icon Colors


Color	RGB Values Decimal	RGB Values Hex	Grays	RGB Values Decimal	RGB Values Hex
Black	0, 0, 0	#00	Gray1	222, 222,222	#de
White	255 ,255, 255	#ff	Gray2	189, 189,189	#bd
Red	255, 0, 0	#ff0000	Gray3	173, 173,173	#ad
Green	0, 255, 0	#00ff00	Gray4	148, 148,148	#94
Blue	0, 0, 255	#0000ff	Gray5	115, 115,115	#73
Yellow	255, 255, 0	#ffff00	Gray6	99, 99, 99	#63
Cyan	0, 255, 255	#00ffff	Gray7	66, 66, 66	#42
Magenta	255, 0, 255	#ff00ff	Gray8	33, 33, 33	#33

Implementation of Required Icons

This section discusses the details you need to know to create icons that display correctly in the desktop environment, such as formats, resolutions, sizes, naming, and so on.

Formats

The desktop runs in both color and monochrome modes, so you must create your icons in two formats: XPM for color, and XBM for monochrome. The Icon Editor saves icon files to both formats.

Note -

The monochrome icons generated by the Icon Editor usually need some further refinement. For example, when converting the colors and greys to black and white, parts of the icon may disappear altogether or appear too thick.

In the desktop, buttons and palettes can use either the XBM or XPM formats. It is strongly recommended that you use XPM format wherever possible for your button, palette, and tool bar graphics.

The XBM file format has only two colors: foreground and background. In the desktop, the foreground color is not fixed, but varies according to the background color. In one color scheme, the background color might be a dark gray causing any text or graphics to appear in white. However, a color scheme with a light gray background will cause text and graphic to appear in black.

This inverting of the foreground color will have strange effects on certain icons. For something simple, like an arrow shape, there is no adverse consequence. But for other images, the "negative" version created by the inverting of the foreground color might be illegible and, therefore, unusable.

For example, an ice cream cone graphic, with white as the foreground color to create a solid white scoop of ice cream on top of an outlined cone, will look quite different when the ice cream cone becomes a black outline with a black scoop of ice cream. If your application lets users choose the flavor of ice cream, a confusing message will be sent to your user when the color changes.

Figure 4-15 Monochrome (XBM) bitmaps, with foreground reversal consequences

Resolutions

The desktop accommodates three display resolutions: low resolution (640x480), medium resolution (800x600), and high resolution (mega-pixel). The size of the Front Panel and some of the icons change automatically depending on the display resolution. For this reason, your application must provide different sized icons.

Recommended

ew:

Any icons or graphics displayed by your application are designed to be distinguishable on low- (640x480), medium- (800x600), and high- (mega-pixel) resolution displays. Alternatively, your application provides different sized visuals for low-, medium-, and high-resolution displays.

Sizes

There are three sizes of the desktop icons: 16x16, 32x32, and 48x48, referred to as 16, 32, and 48. (They have suffixes of .t, .m and .l respectively.) If your application comes from the PC domain, then the size 16 and 32 icons used in the desktop should be familiar sizes. Table 4-2defines where each size is used.

Table 4-2 Icon Sizes and Usage


Component	Low Resolution	Med. Resolution	High Resolution
File Manager	32, 16	32, 16	32, 16
Application Manager	32, 16	32, 16	32, 16
Front Panel	32	48	48
Subpanels	16	32	32
Front Panel Controls	16	16	16
Minimized Window	32	48	48

Note -

24x24 icons (suffixes of .s) are used for internal application graphics like toolbar graphics and are not part of the standard set of desktop icons.

Table 4-3 lists the icons you need to create for an application. A total of 16 icon files are needed, assuming one of each type and size. Figure 4-16shows an example set of icons.

Table 4-3 Minimum Required Icon Set


Type of Icon	Color	Color	Color	Mono.	Mono.	Mono.
	16	32	48	16	32	48
Application Icon	✓	✓	✓	✓	✓	✓
Document or File Icon	✓	✓		✓	✓
Application Container Icon	✓	✓		✓	✓
Minimized Windows			✓			✓

Recommended

ex:

Any icons or graphics displayed by your application are designed to display well on black-and-white and gray-scale monitors. These visuals also display well on low-color (16) systems.

Icon Naming Conventions

The basic name for the icon must be no more than seven characters. The size and color suffixes are appended to the name, as shown in Table 4-4.

Table 4-4 Icon Name Conventions


Size	COLOR	B&W	B&W Mask
48	Iconame`.l.pm`	Iconame`.l.bm`	Iconame`.l_m.bm`
32	Iconame`.m.pm`	Iconame`.m.bm`	Iconame`.m_m.bm`
24	Iconame`.s.pm`	Iconame`.s.bm`	Iconame`.s_m.bm`
16	Iconame`.t.pm`	Iconame`.t.bm`	Iconame`.t_m.bm`

The suffix .pm is for the color XPM format. The suffix .bm is for the XBM format. The suffix _m refers to the mask for the black and white icon.

Please note that you do not have to provide icons in all these configurations. Table 4-3 lists the required icons. For example, the .s icons are used primarily for things like tool bars, which your application may not have.

Figure 4-16 Example of a minimum required set of icons for Mailer

Alignment

Depending on the graphic you use for your icon, the bits may not take up the entire space allocated for the icon. The recommended rules for where the empty space goes in a desktop icon are shown in Figure 4-17. Following these rules ensures your icons visually line up with other icons when used in File Manager or on the Front Panel.

Recommended	fb:	16x16 and 32x32 icons are left-aligned; any empty bits are on the right side of the bounding box.
Recommended	fc:	48x48 icons are centered in the bounding box.

Figure 4-17 Example of a left-aligned 32x32 icon with a tag on the right side

Optional Icons Sizes

There is no 48 requirement for the document or application group icons because neither are expected to be used for a minimized window icon (the tool's icon is used instead) or on the Front Panel. But it is possible that a user might promote one of these icons to the Front Panel.

When a size 48 icon is not available, the Front Panel uses the size 32 icon instead. If you think your icons might be used in the Front Panel, you can supply size 48 icons.

Optional Front Panel Icon Style

The icons that appear by default in the Front Panel have a slightly different appearance from File Manager icons. They appear to be etched into the surface. This gives the icons a more permanent look, because they cannot be dragged and dropped.

You do not have to provide size 48 icons with an etched appearance like the default icons in the desktop. It is not easy to determine if and when your icons will be used in the Front Panel; therefore, it is recommended you not design specifically for this usage, rather design for File Manager usage which will be more common.

If you decide to design Front Panel icons, the following are instructions on developing the etched look. It is strongly recommended that you work with a visual designer to implement this style.

Achieving the Etched Look

You must be familiar with dynamic colors to apply etching. Start with a size 48 icon that does not use the entire 48x48 space. The artwork should leave a few pixels on all sides for the etching.

Figure 4-18 Example of an icon lighted from the top left edge

The icon has to be rendered with both light and dark colors, preferably grays. The icon must be lit from above and to the left. The upper and left edges must be light in color, while the lower and right edges must be dark in color. Figure 4-18 shows the desktop Text Editor icon before any etching has been applied.

Figure 4-19 Applying the `bottomShadow` and `topShadow` colors

The etched effect is applied by drawing a single-pixel line of the bottomShadow color just outside the upper and left edges of the icon artwork, and by drawing a single-pixel line of topShadow color just below and to the right of the artwork.

The lighting model of the icon and of the etched shadow must be consistent or the effect does not work. If your icon is drawn with black lines, the etched look will be flawed by doubling the dark lines on the top and left edges.

The style of the icon is critical to making the etched effect look right and to making your icon blend in with other Front Panel icons. Study the Front Panel icons supplied with the desktop for guidance. Icons with perspective scenes, icons with black outlines, and icons on raised "slabs" will not work.

Evolving the Etched Look

Etching is a way of making the icon appear to be part of the surface it is etched on. Not all the parts of an icon have to be etched into the surface. You can apply selective etching, making part of the object anchor itself in the panel and some of it lie on the panel or protrude from it slightly.

Figure 4-20 Example of anchoring page while letting pencil protrude from surface

The Help icon, for example, takes away the etch, made with the topShadow color, under and next to the right-hand book, and replaces it with a select color shadow. This makes it appear that one book is protruding slightly from the shelf. The printer icon has a protruding paper tray. In the Style Manager icon, the palette, letters, and mouse are above the etched-in window frame. The File Manager icon has gone the furthest, as only the edge of the opening is etched, while the drawer front and the cocked folder protrude and even have a shadow.

The principle is to have something in the artwork anchored, yet let the 3-D nature of the objects come out as well. The variable content in an icon, like the printer page or the mail envelopes in the Mailer icon, should not be anchored.

Chapter 5 Window and Session Control

Your application is presented to the user as a series of windows. Some of these windows present the main portion of the application. Others are dynamic, only appearing to the user when needed to accomplish certain tasks. All of these windows should contain menus, border decorations, and behavior styles appropriate to their function. The following chapter describes the guidelines that should be applied when designing the windows in your application.

Window Control Guidelines

The specifics of the appropriate window borders and decorations are outlined in "Window Decorations", and the different window management behaviors are specified in "Window Management Actions".

The fundamental user-visible characteristic of primary windows is that stacking, workspace placement, and minimization can be independent of other primary windows. Secondary window stacking, workspace placement, and minimization must be tied to the associated primary window.

Required

aa:

Application windows should be clearly distinguishable as primary or secondary windows based on appearance and behavior.

Window Management Actions

Required	aq:	Windows should follow Common Desktop Environment window management functionality conventions, as shown in Table 10-2. Primary windows should provide Close, Move, Lower, and Minimize as the minimum set of capabilities. They should allow Resize and Maximize as appropriate. Secondary windows should be designed so that resizing and maximizing are neither necessary nor appropriate. Most secondary windows should only include the Close, Move, and Lower capabilities. In extraordinary cases, a secondary window may provide the Resize and Maximize capabilities. Secondary windows do not provide Minimize capability - they are minimized with the associated primary window.
Required	as:	Windows that have form factor constraints need to set Window Manager hints for minimum size, maximum size, aspect ratio, and resize increment as appropriate.
Required	at:	Maximizing a window should show more content (objects or controls) if appropriate (as opposed to scaling up the sizes of objects and controls).
Required	au:	Windows that have Close or Exit functionality need to support the window management protocol for Close if there is a window menu. In the case of dialog boxes, the Close item on the window menu corresponds to the Cancel functionality or dialog box dismissal with no further action taken.

Window Decorations

Window decorations are the user-visible controls in the frame of an application window. The Figure 5-1shows some sample decorations typically associated with a primary window.

Required

ab:

Windows that support particular window management functionality must request the corresponding window decoration (for example, a window that can be minimized should request the minimize button).

In addition, windows that support any window management functionality (move, resize, minimize, maximize, close, and others) must have a window menu with the appropriate items for that functionality.

Figure 5-1 Example primary window decorations

Required

ad:

Follow Common Desktop Environment window decoration conventions, as shown in Table 10-1.

Primary windows should have the following window decorations: Border, Title, Menu, and Minimize. If appropriate, primary windows should also include Maximize and Resize decorations.

Secondary windows should be designed so that resizing and maximizing are neither necessary nor appropriate. Most secondary windows should only include the Border, Title, and Menu decorations. If your secondary window allows resizing or maximizing, however, it must also include the appropriate decoration. The Figure 5-2shows a typical secondary window decoration.

Figure 5-2 Example secondary window decorations

Window Menus

Windows have a menu that allows the user to perform various operations that affect the size and placement of the application window. Developers should use the following standard window menu items in their applications.

Required

ae:

Follow Common Desktop Environment window menu conventions. Items should appear in the window menu if they are applicable to the window or its minimized window icon.

Figure 5-3 Sample window menu

The following items are valid English-language choices in the window menu (the mnemonics for each choice are listed in parentheses). They should be added to the menu in the order listed. Unless otherwise noted, the functionality of these menu items is as described in the OSF/Motif Style Guide, Revision 1.2.

Restore (R)
Move (M)
Size (S)
Minimize (n)
Maximize (x)
Lower (L)
separator
Occupy Workspace ... (O)
Allows a user to specify which workspaces the application occupies.
Occupy All Workspaces (A)

Enables the user to place the application in all available workspaces.
Unoccupy Workspace (U)

Removes the application from the current workspace. If the application is only occupying one workspace, the item should be made insensitive.
separator
Close (C)

Recommended	at:	Applications should not add items to the window menu. If an extraordinary requirement has an application add items to the window menu, the items should be appended to the end of the menu with a separator between Close and the application items.
Optional	ag:	Accelerators, aside from Alt+F4 for Close, should not be used in the window menu (to minimize conflict with other uses of the Alt key for application accelerators, localization, and others).

Window Icons

Applications should use icons to represent themselves to the user when minimized on the desktop.

Optional	ah:	Applications should provide unique window icons for their primary windows. The window icon image should have a similar appearance to the associated file or Front Panel icon image.
Optional	ai:	The window icon label should contain the same text as the title of the corresponding primary window, or an abbreviated form of it. Refer to "Layout" on page 240 for window title guidelines.
Optional	aj:	The window icon image should have a similar appearance to the associated file or Front Panel icon image. Refer to "Design Philosophy and Helpful Hints" on page 50.

Window Placement

Window positioning should be left to the Window Manager or to user control.

Recommended	ak:	Applications should not require or force windows or window icons to be positioned at a particular screen location.
Recommended	al:	A secondary window is placed by the application relative to the associated primary window. It should be placed close to, but not obscuring, the component that caused it to be displayed and the information that is necessary to interact with the dialog box.
Recommended	an:	If a secondary window is allowed to be stacked below its associated primary window (not constrained to stay on top of the primary window), it should be placed such that it is not completely covered by the primary window. This recommendation takes precedence over other placement recommendations.
Recommended	ao:	If a menu or dialog box is already on display, reinvoking the command that caused it to be displayed automatically brings that window or menu to the front of the window stack without changing its position on the screen.

Workspace Management Guidelines

Desktop applications appear in one of several work areas called workspaces. A user may have several workspaces active on the desktop. The application should behave in certain ways in relation to those workspaces.

Recommended	av:	When your application creates a new window, it should come up in the user's current workspace and only occupy that single workspace.
Recommended	aw:	Application windows that are related to a particular task should move together between workspaces.

For example, a spreadsheet application may have one or more secondary windows open that allow the user to change the properties of data cells in the main window. If the user moves the main window to a different workspace, the properties windows should move with it.

On the other hand, a word processor may have several windows open, where each is used to edit a different document. In this case, when a user moves one of the windows to a different workspace, the other windows may remain where they are.

Session Management Support

When you design a desktop application, you must consider the following guidelines for session management.

Required	ax:	Applications should support Interclient Communications Conventions Manual (ICCCM) mechanisms for session management of their primary windows and key properties. The ICCCM defines important relationships and behaviors between applications and the window manager, including protocols for saving and restoring application state across invocations.
Required	ay:	Applications should support ICCCM mechanisms for session management of all associated windows (that is, secondary windows that may include help windows). Associated windows include multiple primary windows and secondary windows, such as online help windows.
Optional	az:	Applications should accept messages from the Common Desktop Environment Session Manager that inform them the user is logging out and should save their state at that time.
Optional	ba:	Applications that have a single primary window that is open at the time the user logs out should restore the primary window, in the workspace last occupied, when the user logs in again.
Optional	bb:	Save user context wherever possible. For example, applications that support the editing of files should save the state of the file at logout and should restore the file in the application window when users log in again.
Optional	bc:	Applications that have multiple primary windows that are open at the time the user logs out should restore all primary windows, in their respective workspaces, when the user logs in again.

Chapter 6 Application Design Principles

Your application should present its components to the user in a logical and task-organized manner. Menus should follow a common organization and naming convention to enable users to use the same rules and practices across the desktop. The following sections outline the Common Desktop Environment application design and menu structure requirements.

Component Layout Guidelines

When you design the physical organization of the controls within your application, you should use the following guidelines to ensure that users are presented with a consistent interface throughout the desktop.

Main Window Layout

Required	6-1:	Your application should be composed of 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 use of a main window ensures interapplication consistency.
Required	bd:	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	6-2:	If your application has multiple main windows that serve the same primary function, each window closes and iconifies separately. For example, a text editor might allow the user to edit multiple documents, each in its own main window. Each window is then treated as a separate application and can be closed or iconified when it is not being used.
Required	6-3:	If your application has multiple main windows that serve different primary functions, each window should be able to iconify independently of the other windows. For instance, a debugger might provide separate main windows for editing source code, examining data values, and viewing results. Each window can be iconified when it is not being used, but it is up to the application to decide whether each window closes separately or whether closing one window closes the entire application.
Required	be:	Resize corners should be included in any main window that incorporates a scrolling data pane or list. Any changes to the overall size of the window should result in a corresponding increase or decrease in the size of the scrollable portion. Additionally, your application might reorganize elements within the window based on the increased or decreased amount of space (for example, it might reorganize a row of buttons into two rows).

Menu Bar Layout

Note -

These requirements apply only in a left-to-right language environment in an English-language locale. You must make the appropriate changes for other locales.

Required	6-4:	If your application has a menu bar, it is 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 containing commands that are grouped by common functionality. The use of a menu bar yields consistency across applications. A menu bar organizes the most common features of an application. It contains a list of menu topics in buttons; each button is associated with a distinct pull-down menu containing commands that are grouped by common functionality. The use of a menu bar is not required, but it is strongly recommended.
Required	6-5:	The menu bar for your application contains only cascading buttons. The use of other types of buttons in the bar precludes user browsing of the menu structure.
Recommended	bn:	There are several common menu operations that should be considered "standard". The standard menu bar entries are File, Edit, View, Options and Help. If your application provides that functionality to the user, it should be included in the menu bar under the appropriate name. The contents of these menu entries are discussed below in more detail. Standard menu bar entries should be presented 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: The File menu, if present, is located in the first menu position on the left. The Help menu is located on the far right position. If File and Edit are present, they should be next to each other. For example, your application may have: File Edit <category1> <category2> View Options <category3> Help
Recommended	bo:	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. Possible replacements for the File menu: Replacement1: <app-label> Selected Replacement2: <app-label><obj-type> 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 menubar guidelines that apply to File-oriented applications also apply to non-File-oriented applications. Thus, the following menubar would be valid: <app-label> Selected Edit <category1> View <category2> Help Applications that are complex or are extremely 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	bp:	Exit or Close should be located on the first (leftmost) menu of your menubar.

Common Menu Types

User actions fall into categories that are similar across a wide range of applications. Your application should use the following standard menus when possible to enable the user to easily locate desired functionality.

File Menu Contents

Note -

These requirements apply only in a left-to-right language environment in an English-language locale. You need to make the appropriate changes for other locales.

Required	6-7:	If your application uses a File menu, it contains the following 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 below. In all cases where a dialog is recommended to be displayed to the user, and the dialog has functionality outlined in Chapter 7, "Common Dialogs", your application should use a dialog box. New [REQUIRED] Creates a new file. If the current client area will be used to display the new file, your application clears the existing data from the client area. If changes made to the current file will be lost, your application displays a dialog, asking the user about saving changes. The mnemonic is N. Open... [REQUIRED] 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, your application displays a dialog asking the user about saving changes. The mnemonic is O. Save [REQUIRED] Saves the currently opened file without removing the existing contents of the client area. If the file has no name, your application displays a dialog prompting the user to enter a file name. The mnemonic is S. Save As... [REQUIRED] 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 using an existing name, your application displays a dialog that warns the user about a possible loss of data. Does not remove the existing contents of the client area. The mnemonic is A.
		Print [RECOMMENDED] Schedules a file for printing. If your application needs specific information in order to print, it displays a dialog, requesting the information from the user. In this case, the menu entry is followed by an ellipsis (Print...). The mnemonic is P. Close [RECOMMENDED] Closes the current primary window and its associated secondary windows. This action does not terminate the application - Exit should be used for that purpose. If changes made to the current primary window will be lost, your application displays a dialog, asking the user about saving those changes. If your application uses only a single primary window or multiple dependent primary windows, this action is not supplied. The mnemonic is C.
		Exit [REQUIRED] Ends the current application and all windows associated with it. If changes made to the current file will be lost, your application displays a dialog, asking the user about saving changes. The mnemonic is x.
Required	bq:	If the user chooses Exit, or in any other manner indicates that the application should be terminated, but there are changes to the current file that have not been saved, your application displays a dialog box asking whether the changes should be saved before exiting. The user must always be given the opportunity to explicitly state whether unsaved changes should be saved or discarded. A dialog box similar to the one described should also be displayed if the user chooses Open from the File menu, but has not saved changes to the current file.

<Object-type> and Selected Menu Contents

The <object-type> menu contains controls that allow the user to create instances of the object-type. Both the <object-type> and Selected menus allow the user to manipulate object instances. Additional items should be added to the <object-type> or Selected menus if they relate solely to the manipulation of objects managed by the application (as opposed to more generic services that the application might provide).

Recommended

br:

If your application uses an <object-type> menu or a Selected menu, it contains the following 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 below.

New... [RECOMMENDED]

Creates a new instance of the object-type. A dialog box is presented allowing the user to specify the values for settings associated with that object. The mnemonic is N.
Move To... [OPTIONAL]

Allows the user to move the selected objects into a folder. A file selection dialog box is displayed allowing the user to select the desired folder. The mnemonic is M.
Copy To... [OPTIONAL]

Allows the user to copy the selected objects into a folder. A file selection dialog box is displayed allowing the user to select the desired folder. The mnemonic is C.
Put in Workspace [OPTIONAL]

Allows the user to put a link for the object onto the Common Desktop Environment desktop in the current workspace. The mnemonic is t.

Any of the preceding three 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 unto itself. Your application should also support drag and drop as a method for performing any of these actions.

Delete [OPTIONAL]

Removes the selected objects. A confirmation dialog box should be presented to the user before the object is actually deleted. The mnemonic is D.
Properties [RECOMMENDED]

Displays a Properties window that shows the current values for settings associated with the selected object. The mnemonic is P.
<Default Action> [RECOMMENDED]

This choice should enact the default action for the selected object. "Open" is a typical default.

Edit Menu Contents

Note -

These requirements apply only in a left-to-right language environment in an English-language locale. You must make the appropriate changes for other locales.

Required	6-8:	If your application uses an Edit menu, it contains the following choices, with the specified functionality, when the actions are actually supported by your application: Undo [RECOMMENDED] Reverses the most recently executed action. The mnemonic is U. Cut [RECOMMENDED] Removes the selected portion of data from the client area and puts it on the clipboard. The mnemonic is t. Copy [RECOMMENDED] Copies the selected portion of data from the client area and puts it on the clipboard. The mnemonic is C. Copy Link [OPTIONAL] Copies a link of the selected portion of data from the client area and puts it on the clipboard. The mnemonic is K. Paste [RECOMMENDED] Pastes the contents of the clipboard into the client area. The mnemonic is P. Paste Link [OPTIONAL] Pastes a link of the data represented by the contents of the clipboard into the client area. The mnemonic is L. Clear [RECOMMENDED] Removes a selected portion of data from the client area without copying it to the clipboard. The remaining data is not rearranged to fill in the gap left by the Clear operation. The mnemonic is E.
		Delete [RECOMMENDED] Removes a selected portion of data from the client area without copying it to the clipboard. The mnemonic is D. Select All [RECOMMENDED] Sets the primary selection to be all the selectable elements in the client area. The mnemonic is S. Deselect All [RECOMMENDED] Removes from the primary selection all the selectable elements in the client area. The mnemonic is l. Select Pasted [OPTIONAL] Sets the primary selection to the last element or elements pasted into a component of the client area. The mnemonic is a.
		Reselect [OPTIONAL] 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. The mnemonic is R. Promote [OPTIONAL] 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. The mnemonic is m.
Recommended	bs:	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 it provides a Properties ... choice as the last item in the Edit menu.

View Menu

Recommended

bt:

If your application provides a View menu, it only contains functions that affect the way the current data is presented. It does not contain any option that alters the data itself.

Options Menu

Recommended

bu:

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

Help Menu Contents

Note -

These requirements apply only in a left-to-right language environment in an English-language locale. You must make the appropriate changes for other locales.

Recommended	bv:	If your application includes a Help menu, it contains the following set of choices, with the specified functionality, when the actions are actually supported by your application. The Help choices included here supersede those listed for Motif 1.2. This is the Common Desktop Environment-recommended Help menu and should be used instead of the Motif 1.2 Help menu. Items should be presented to the user in the order listed. Overview [REQUIRED] Provides general information about the window from which help was accessed or about the application overall. The mnemonic is v. Place a separator after. Index [OPTIONAL] Provides an index listing topics for all help information available for your application. The mnemonic is I. Table of Contents [RECOMMENDED] Provides a table of contents listing topics for all help information available for your application. The mnemonic is C. Tasks [RECOMMENDED] Provides access to help information indicating how to perform different tasks using your application. The mnemonic is T. Reference [RECOMMENDED] Provides access to reference information. The mnemonic is R. Tutorial [OPTIONAL] Provides access to your application's tutorial. The mnemonic is l. Keyboard [OPTIONAL] Provides information about your application's use of function keys, mnemonics, and keyboard accelerators. Also provides information on general Common Desktop Environment use of such keys. The mnemonic is K.


		Mouse [OPTIONAL] Provides information about using a mouse with your application. The mnemonic is M. Mouse and Keyboard [OPTIONAL] Provides information about your application's use of function keys, mnemonics, keyboard accelerators and mouse operations. Also provides information on general Common Desktop Environment use of such keys. The mnemonic is M. On Item [OPTIONAL] 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 BSelect, any available context-sensitive help for the component is presented. The mnemonic is O. Using Help [REQUIRED] Provides information on how to use the Common Desktop Environment Help Facility. The mnemonic is U. About applicationname [REQUIRED] Displays a dialog box indicating, minimally, the name and version of your application, and displaying its icon or some other signature graphic for your application. The mnemonic is A. The Overview, Using Help and About items are required. The Table of Contents, Tasks and Reference items are recommended. You can choose to have separate Mouse and Keyboard topics, or have a single combined Mouse and Keyboard topic. You should not use all three items.

Attachment Menu Contents

See Chapter 3, "Drag and Drop" for information on menu recommendations your application should use if it supports attachments.

Pop-up Menus

Note -

These requirements apply only in a left-to-right language environment in an English-language locale. You must make the appropriate changes for other locales.

Pop-up menus provide access to frequently used functions and should be used pervasively throughout the Common Desktop Environment 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	by:	Your application should provide a pop-up menu for any element that is selectable within its data pane.
Recommended	bx:	If your application provides functions that apply to a data pane and not any specific element therein, then a pop-up menu is provided that contains the frequently used data pane functions and is accessible by pressing BMenu when the mouse pointer is over the background of the pane or a nonselectable element within the pane.
Recommended	cb:	The functions accessible from within your application's pop-up menus are also accessible from buttons displayed within the window or menus accessed through the menu bar.
Recommended	ca:	Every pop-up menu in your application has a title that indicates the function the menu performs or the element on which it operates.
Optional	cd:	Choices within your pop-up menus are organized in the following manner: <choices that manage the object such as Open, Save, and Properties> ----------- separator ---------------- <standard edit menu choices such as Cut, Copy and Paste> ----------- separator ---------------- <other choices>
Optional	6-11:	If your application uses any of the common pop-up menu actions, the actions function according to the following specifications. See item for supplemental guidelines. Properties Displays a properties dialog box that the user can use to set the properties of the component. Undo Reverses the last executed action. Primary Move Moves the contents of the primary selection to the component. This action is available only in editable components. Primary Copy Copies 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, 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	cc:	Pop-up menus for selectable objects contain the following set of choices, with the specified functionality, when the actions are actually supported by your application. These guidelines supplement item . Move To... Allows the user to move the selected objects into a folder. A file selection dialog box is displayed allowing 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 allowing the user to select the desired folder. Put in Workspace Allows the user to put a link for the selected objects onto the Common Desktop Environment desktop in the current workspace. Delete Deletes the selected object. A confirmation is displayed to the user before actually removing the object. Help... Displays a help window pertaining to objects of the type selected.
Required	6-12:	When a pop-up menu is popped up in the context of a selection, any action that acts on elements acts on the entire selection. In the context of a selection, pop-up menu actions affect the entire selection.

General Menu Design Rules

As you design your application-specific menu panes, follow these guidelines to ensure maximum usability and accessibility.

Recommended	ce:	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 they select an item without an ellipsis, they know that they can expect an immediate result.
Recommended	cf:	Menus accessed from within your application contain at least two menu items. No menu should contain only one item. If your application provides a menu with only one item, you should consider moving that item into another menu or making 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	cg:	Submenus accessed from within your application 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, you should strongly look at 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.
Optional	ci:	If your application contains a menu that is expected to be accessed frequently, then a tear-off menu option is provided in that menu. The user should be able to tear-off frequently accessed menus so that these can remain posted on the desktop as the user uses your application.
Required	6-14:	If your application uses a tear-off button in a menu, the tear-off button is the first element in the menu.
Optional	cj:	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 your application provides keyboard accelerators for these items and displays the keyboard accelerators in the associated menu to the right of the item to which they relate. You should not use accelerators that have already been defined for system functions - refer to Appendix A, Keyboard Functions, for a list of pre-defined key assignments.
Recommended	ck:	The labels used for items in the menu bar do 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	cl:	Any menu choice that is not currently an appropriate selection is dimmed (insensitive). 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), the control should be removed from the menu rather than be dimmed.
Required	6-15:	All menus are wide enough to accommodate their widest elements.

Tool Bars

Tool bars are a method used to provide quick access to things that are already user-accessible in an application by other methods. For example, an application can provide access to frequently used features from its menus through its tool bar. Some common usages of tool bars are navigation, changing data views, accessing frequently used tools or editors, simplifying the number of steps to complete a common operation, and providing a fast path to frequently used menu items.

Figure 6-1 Example from Common Desktop Environment Calendar.

Tool Bar Guidelines

Required	fd:	If you use a tool bar, it should be used only in windows with a menu bar.
Required	fe:	Tool bars should contain only operations that are already available to the user in your application menus. All items in a tool bar should be redundant. Items in a toolbar are meant to provide quick access to operations that are already accessible to the user by other methods.
Required	ff:	When an action represented by a tool bar icon is unavailable to the user, that icon should be made insensitive, with the associated stippled appearance. Whenever a menu item is made insensitive, the corresponding tool bar item must be made insensitive as well.
Recommended	fg:	Give users the option to hide the tool bar.

Design Issues for Tool Bars

When designing your application and an associated tool bar, consider the following issues.

Would the usability of the application be improved by placing these items on the tool bar?

Tool bars should only be used when they improve or enhance user access to common operations, such as in an application with several large menus.
What kinds of operations are being placed on a tool bar? How are they grouped?

Tool bars should present a natural organization of actions. Grouping items that are dissimilar can confuse users because they do not expect to find the item they are looking for in that context.
Is the tool bar too crowded?

Placing too many items in the tool bar can cause the user to have to search for the item they are looking for, rather then being able to quickly find it and use it. Keep the number of buttons to a minimum so that you don't increase the difficulty of your application when using a tool bar.
Are the icons clearly representative of their associated action?

Cryptic icons add to user confusion. Keep the pixmaps as simple as possible. Remember that all graphics must be international in scope. When designing a graphic to represent a command, such as Save, remember that the icon has to represent a verb, as opposed to a noun like most other icons. This can make the icon more confusing to users.

Tool Bar Components

A tool bar is typically constructed using the following Motif components.

Tool Bar Container

The tool bar uses a container component to provide a layout mechanism for the drawn buttons that make up a tool bar. You may choose most any container for the tool bar, as long as it allows for the specified behavior.

Required

fh:

The tool bar container is placed directly under the menu bar and should be the same width as the window, as well as similar height to the menu bar.

Recommended

fi:

If you use a tool bar in your application, then you should 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

fj:

You may provide labels under tool bar icons. These labels should serve to explain the purpose of the icon.

Tool Bar Button

The Motif DrawnButton provides an appropriate medium for the graphic buttons in tool bars.

Recommended

fk:

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.

Pixmap

The pixmap for the drawn button is the graphic that conveys the functionality to be expected by pushing a particular button.

Recommended

fl:

All pixmaps in the tool bar should be the same size.

This ensures that all the buttons will be the same size.

Recommended

fm:

The recommended size of the pixmap is 24x24. The default for the drawn button is to resize itself according to the size of its label type, which, in this case, would be a pixmap.

Window Titles

The following guidelines should be followed when defining titles for your primary and secondary windows.

Optional	bf	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, but remember that without the title users might have difficulty telling which pop-up windows belong with the originating primary window.
Optional	bg:	Use initial capital letters for each word in the title (in languages that support capitalization).
Optional	bh:	Follow the application name for each property window, as a minimum, with the title Properties and the name of the object it affects.
Optional	bi:	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 readibility. Pop-up windows should always indicate which primary window they are associated with (which primary window invoked that pop-up).
Optional	bj:	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	bk:	Follow the application name for each command window with the same title that is on the window button or window item users choose to display that window.
Optional	bl:	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	bm:	An abbreviated name for the application may be used on other windows, so long as it is done on all windows.

Work-in-Progress Feedback

Recommended

gt:

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

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

Recommended

gu:

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

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

Recommended

gv:

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

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

General Application Design Rules

Required	ep:	There is always 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. If any window within your application has focus, some control within that window must have focus. The user should not have to explicitly set focus to a control within the window.
Optional	eq:	When a text field within your application does not have the input focus, the text cursor is not displayed 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	er:	Your application provides keyboard mnemonics for all buttons, menus, and menu items displayed within the application. Once the user becomes adept at using your application, keyboard mnemonics provide the user a quick way to access functionality. Mnemonics also facilitate access to functionality from within keyboard-centric applications or windows. The user need not frequently switch between use of the mouse or use of the keyboard. Mnemonics should be provided pervasively throughout the user interface.
Optional	es:	Your application provides keyboard accelerators for those functions that are expected to be used frequently by the user. Keyboard accelerators provide the user who has become expert at using your application a quick way to access application functionality without having to go through menus and dialog boxes.
Required	ev:	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 your application provides 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. These settings are controlled by the user through the Common Desktop Environment Style Manager. If you choose to ignore these settings and specify your own settings, then your application will be have inconsistently with other applications in the Common Desktop Environment desktop. If you nevertheless choose to provide your own values, then you must provide the user a way to make your settings consistent with the rest of the desktop.

Application Installation

Required

em:

Applications should be installed to folders in the Application Manager not directly to the Front Panel or subpanels. For consistency, only Common Desktop Environment desktop components will install to these locations. Users may choose to rearrange their Front Panel, but applications should not do this without user consent.

Chapter 7 Common Dialogs

Use dialog boxes (secondary windows) to support user tasks that require detailed interaction from the user and that do not lend themselves well to direct manipulation in the main window. For example, you may not require a dialog box to support the task of setting a margin if the task can be performed by directly moving a margin stop on a ruler. On the other hand, you might require a dialog to support formatting a document if the task requires that the user specify several formatting options.

Dialog Box Design and Layout

Optional	ct:	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	cu:	Avoid complexity in your dialog boxes. If your dialog box must support many functions, consider using an expandable dialog box (see "Expandable Windows" on page 291), or use more than one dialog in a nested fashion.
Optional	cv:	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.
Recommended	cp:	The title of dialog boxes used within your application adheres to the conventions listed in Table 10-3.
Required	cq:	Every dialog box in your application has at least one button that either performs the dialog box action and dismisses it or dismisses the dialog box without taking any action.
Recommended	cr:	If your application uses common dialog box actions, the actions have the following specified functionality and labels:
		Label	Functionality
		Yes	Indicates affirmative response to a question posed in the dialog box.
		No	Indicates 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 the components in the dialog box, performs the action associated with <command>, and optionally dismisses the dialog box.
		The <command> button 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	cs:	Any visible control that is not currently active or whose setting is currently invalid is dimmed. 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), the control should be removed rather than dimmed.
Optional	cw:	Every dialog box in your application has 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 out or otherwise manipulated.
Optional	cx:	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. 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 very 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 (see the section on Expandable Windows and Dialog Boxes).

Figure 7-1 An example of using a Category option menu in a dialog

Optional	dl:	Controls within your dialog box are placed 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. This assumes that your application is being designed for a left-to-right language environment. Alternate design approaches may be necessary for other locales.
Required	dm:	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, are located at the bottom of the dialog box. In general, there should only be one row of buttons at the bottom of a dialog box. If your application has dialog boxes that contain several global buttons, it may be necessary 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 instead, relate to a specific control within the dialog box, the buttons should be located near the control to which they relate.
Required	dn:	If your application provides an Apply button within a dialog box, it also provides an OK button or command button that performs the dialog box action then dismisses it.
Optional	do:	Your application does 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, cascade buttons should only be used within menus and menu bars. You should avoid their use in all other locations unless absolutely necessary.

Dialog Box Placement

Recommended	al:	A secondary window is placed by the application relative to the associated primary window. It should be placed close to, but not obscuring, the component that caused it to be displayed and the information that is necessary to interact with the dialog box. Some suggestions are given in section 6.2.4.3, "Determining Dialog Box Location and Size," of the OSF/Motif Style Guide, Revision 1.2. Additional or modified recommendations include:
Optional	am:	If a dialog box does not relate to specific items in the underlying window, it should be placed below the menu bar (if there is one) and centered (horizontally) over the work area.
Recommended	an:	If a secondary window is allowed to be stacked below its associated primary window (not constrained to stay on top of the primary window), it should be placed such that it is not completely covered by the primary window. This recommendation takes precedence over other placement recommendations.
Recommended	ao:	If a menu or dialog box is already on display, reinvoking the command that caused it to be displayed automatically brings that window or menu to the front of the window stack without changing its position on the screen.

Dialog Box Interaction

All of the navigation and selection guidelines that apply to applications in general should apply to your dialogs. In addition, as you design your application-specific dialog boxes, you should follow these guidelines to ensure maximum usability and accessibility.

Required	en:	When your application displays a dialog box, it places 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. The user should not be forced to set focus at the control most likely to be used when the window is displayed.
Recommended	eo:	As the user presses the Tab key within dialog boxes of your application, the input focus moves to different controls within the window in a left-right, top-down order. This assumes that your application is being designed for a left-to-right language environment. Alternate design approaches may be necessary for other locales.
Required	et:	Dialog boxes displayed by your application never block input to other applications within the desktop (that is, they are not system modal) unless it is absolutely essential that the user perform no other action in the desktop until the user responds to the dialog box. Applications must allow the user the freedom to access information and tools within the user's desktop environment. Only in the most dire circumstances should an application ever block access to other applications and services within the environment.
Recommended	eu:	Dialog boxes displayed by your application 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	6-18	A warning dialog box allows the user to cancel the destructive action about which the dialog box is providing a warning.

Expandable Windows and Dialog Boxes

This section describes a standard method for providing expandable windows or dialogs in Common Desktop Environment. Expandable windows allow users to selectively display advanced or application-specific functionality in a separate portion of the window that is normally not visible when the window is initially displayed. Users can choose to display the entire window, or only the core functionality, according to their own needs and preferences. Applications can implement expandable windows fairly easily using existing toolkit components.

Use expandable windows only when your application needs to present a limited set of additional dialog box options. Consider using an alternate method if your dialog would grow unmanageably large, for example, larger than a typical low-resolution display could handle. Keep in mind also how your dialog will expand when translated into other languages. An alternative method for expandable dialogs is to use a multipage dialog and provide a Category button for switching pages.

Guidelines for Expandable Windows and Dialog Boxes

Recommended	fn:	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	fo:	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	fp:	Command buttons are aligned along the bottom of the dialog box. When the window is expanded to show a secondary pane, then buttons are moved to the bottom of the secondary pane. See Chapter 6, "Application Design Principles" for information about layout of action buttons in dialog boxes.
Recommended	fq:	If important controls must be placed in the secondary pane, the application can specify that the window in question should be displayed in its expanded state by default. Users should still be able to shrink the window by pressing the Contract button.

Components of Expandable Windows

To create an expandable window or dialog box, use the standard Motif widgets in conjunction with state variables and some simple rules that govern its behavior. In addition to the application-defined controls and displays that make up the content of the window itself, use a primary and secondary pane in the following way.

Primary and Secondary Panes

The primary pane should contain the core or base functionality required by nearly all end-users of the application. The primary pane is a standard Motif container that is the main component of the window or dialog. Only the primary pane is visible when the expandable window is initially displayed. An "expand button" allows the user to display a secondary pane providing access to the full functionality of the window or dialog. (See Figure 7-2.)

Figure 7-2 Calendar Appointment Editor primary pane with Expand button (More)

Expanding the Secondary Pane

The secondary pane provides space for additional options or advanced functionality without increasing the difficulty of the core functionality in the primary pane. The secondary pane can be expanded in a vertical or a horizontal direction. To determine the appropriate direction in which to expand, consider the following questions:

What are the reading patterns in the countries that will be using the applications?
What makes the most sense based on the information in the dialog?

Recommended

fr:

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

Recommended

fs:

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

Required

ft:

A separator should be used to separate the primary pane from the secondary pane.

The user needs to have clear visual feedback as to which elements are part of the primary pane and which elements are part of the secondary pane of the expandable window.

Resizing the Expanded Window or Dialog

Required

fu:

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

Figure 7-3 Calendar Appointment Editor with expand button (Less) and primary and secondary panes

Expand Button

The expand button is used to display the secondary pane. The expand button is a standard Motif drawn button with a label that changes depending on the state of the window. The button labels for the two states should tell the user what will happen. For example, the button might say Options when the window is closed and Basic when the window is open. Clicking the Options button displays the bottom pane; clicking the Basic button hides the bottom pane. Labels should be opposites such as Expand and Contract, More and Less, or Basic and Options.

Required

fv:

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

Required

fw:

The expand button should have two labels that reflect the two states of the expandable window accurately. The current label should indicate 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

fx:

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.

Placing the Expand Button

Recommended	fy:	The button should appear 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	fz:	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.

Window State

Required

ga:

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

gb:

Applications should remember the state of each expandable window or dialog box across sessions, so that users don't have to manually configure the expandable windows each time the application is run.

If appropriate, applications can provide a mechanism to allow users to set the state of an expandable window on a global basis in the application. This would be part of the application's Options.

File Selection Dialog Boxes

The Common Desktop Environment file selection dialog box is a subclass of the Motif file selection dialog box that has enhancements for improved usability. As long as your application uses the standard Motif file selection dialog box calls, the Common Desktop Environment enhanced version will appear in the Common Desktop Environment environment. There are additional guidelines to follow to make your dialog consistent and easy to use. Use the file selection dialog box whenever your application supports a task that involves choosing a file or directory. Examples are: Open, Include, Save As, and Copy To.

required

7-10:

If your application uses a file selection dialog box, it contains the following components:

A directory Text component showing the current directory path. The user can edit the directory Text component and press <Return> or <Enter> to change the current directory.
A group of push buttons, including a command button, and Update, Cancel, and Help buttons. The command button is typically labeled Open or Save, but if there is another label that better describes the resulting action (such as Include), that label should be used. Activating the command button carries out the corresponding action and dismisses the file selection dialog box.
For applications that allow saving to different formats, an option button allowing users to specify the format when saving a file.
A file name Text component for displaying and editing a file name. This component is optional when the file selection dialog box is used to choose an existing file or directory.

Figure 7-4 Example of an Open file selection dialog box

Required	7-17:	The file selection box displays the contents of a directory in the contents list when the file selection box is initialized, when the user presses Enter or Return in the directory text component, and when the user opens a directory in the contents list. The contents list is updated each time the contents of the directory changes. This specification ensures the consistent operation of a directory and file search in a file selection dialog box.
Optional	ht:	Directory and file name lists should be presented alphabetically, case insensitive. The first item on the directory list should be the parent directory and it should be labeled "..".
Recommended	de:	The file selection dialog box should not display hidden (dot) directories or files, unless your users depend on using these types of files. If your application does support displaying hidden files, you should supply a check box allowing users to toggle between showing and not showing hidden files, or else allow users to toggle between showing and hiding files at a global level in your application.
Recommended	df:	The file selection dialog box should not show the full path names for files and directories, but should only show the relative names, except for the directory text field The global Common Desktop Environment setting should be: `XmFileSelectionBox.fullPathMode: false` Unless your application overrides this behavior, your file selection dialog box should not show full path names in the list boxes.
Required	dg:	In general, 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`. This information, however, should not be recalled once the user has closed the primary window, but should resort to the default directory. If your application supports multiple primary windows, each window should recall the directory location that was set for that window.

File Selection Dialog Box Behavior

Optional	hq:	The file selection dialog box should come up in a directory that makes sense for the task. For example, when saving a new file from an editor, the file selection box should come up in the user's home directory. If the user navigates to some other directory within the file selection box, the application should remember that directory the next time it is brought up.
Optional	hr:	Users should never be allowed to overwrite an existing file through the file selection box without a warning dialog box prompt.
Optional	hs:	Keyboard focus should be placed in the file name field each time users bring up a file selection dialog box.

Labeling

Optional	hu:	Labels should be clear. In the English language, use the following labels for the file selection dialog box fields and lists:
		Component	Label
		Directory text field	Enter Path or Folder Name
		Filter text Field	Filter
		Directory list	Folder
		Contents list	Files
		File text field	Enter Filename:*
Optional	hv:	Optionally, application developers can make this label more instructive and specific, such as Enter File to Open for Open dialog boxes. (see following sections for specific recommendations). These labels should be the default labels. If they are not set by default, you need to set them via resources in your application's app-defaults file.
Recommended	he:	When the file selection box is used to specify an existing file (for example, to open a document), the command button is normally labeled Open and it should be the default action.
Required	hj:	When the file selection dialog box is used to specify a new file name (for example, a Save As dialog box), the command button is normally labeled Save and is the default action. This specification ensures the uniform appearance of a file selection box across applications.

Button Activation

Recommended	hf:	If the Update button is activated while a directory is selected in the contents list, the directory is opened, its contents are displayed in the contents list, and the directory text is updated.
Required	hg:	If the Open button is activated while the appropriate file is selected in the contents list, the file is utilized by the application and the file selection box is dismissed.

Selection and Navigation

Required	7-12:	Double-clicking BSelect on an item in the contents list selects that item and activates the default action. In all cases, double-clicking BSelect on a directory in the contents list opens that directory and displays its contents in the contents list (the default action is Open). When the file selection dialog box is used to choose an existing file, double-clicking BSelect on an appropriate file in the contents List chooses that file and dismisses the file selection dialog box (the default action is Open). When the file selection dialog box is used to choose an existing directory or to specify a new directory or file, the files list should not appear.
Required	7-13:	The normal text navigation and editing functions are available in the text components for moving the cursor within each text component and changing the contents of the text. These actions provide a convenient way to choose a directory or file name from the corresponding List while focus remains in the Text component.
Optional	7-15	Your application allows the user to select a file by scrolling through the list of file names and selecting the desired file or by entering the file name directly into the file selection text component. Selecting a file from the list causes that file name to appear in the file selection text area. This method for selecting a file needs to be consistent across applications.
Required	7-16	Your application makes use of the selection when one of the following occurs: The user activates the command push button while an appropriate item is selected in the contents List. The user double-clicks BSelect on an appropriate file in the contents list. The user presses Return or Enter while the file name text component has the keyboard focus and contains an appropriate item.

Guidelines for Specific File Selection Dialog Box Uses

The following guidelines apply for specific uses of the file selection dialog box, and should be observed in addition to the more general guidelines.

Open Dialog

Recommended

hm:

If the user has opened the application without supplying a file name argument, the Open dialog box should use the user's home directory as the default directory.

An exception to this rule might be made if a clearly more useful directory can be identified; for example, the icon editor might default to $HOME/.dt/icons. For applications that allow editing, never default to a directory in which the user does not have read and write permission, such as /usr/dt/bin.

Required

hn:

If the user has opened the application with a file name argument, the Open dialog box should default to the directory in which that file resides.

Save As Dialog

Optional

ho:

When using the file selection dialog box in Save As capacity, provide a default name of Untitled, place the location cursor in the file name field and highlight the file name text to create a "delete pending type-in" mode. If the current directory already has a file of that name, create a name Untitled2, and so forth.

Optional

hp:

When using the file selection dialog box in a Save As capacity, add a file name extension if the application supports file typing by extension, and make this extension visible in the file name field. Do not highlight the extension to create a "delete pending type-in" mode, but allow users to modify the extension or delete it explicitly.

After saving a file using "Save As", the application should use that newly saved file as the current file, and all subsequent edits and saves should apply to that newly created file.

The Save As dialog should use the same directory in which the current file resides.

Directory Selection Dialog

Recommended	hh:	When the file selection dialog box is used to choose an existing directory (for example, to install a set of files into the chosen directory) or to specify a new directory, the command button should be given an appropriate label, such as Install, Choose, Create, or OK. If this button is activated while the appropriate directory is selected in the contents list, the directory is utilized by the application and the file selection box is dismissed.
Required	hi:	When the file selection dialog box is used to choose an existing directory, there must also be an additional button, labeled Update, that is enabled whenever a directory is selected in the contents list, and opens the directory. This Update button is the default action.
Optional	hk:	When the file selection dialog box is used to choose an existing file, files are shown in the contents list but they are all disabled. Double-clicking BSelect on a disabled file name has no effect.

Print Dialog Box

These are guidelines for a common look and feel print dialog box, which may be used wherever a print action is available. The print dialog is not a widget. Developers are encouraged to use these guidelines as a starting point and to add functionality as appropriate for their applications. It is important, however, to remember that users expect consistency from one print dialog to another; therefore, the common area should be left as unchanged as possible. Use a print dialog box whenever users would want to select options for printing a file, a selection, or other type of object. If your application supports printing, you should use a print dialog box, and you may provide an optional nondialog method of printing directly, that is, "silent" printing.

Standard Print Menu Items for Applications

Print...: brings up a print dialog so the user can choose from the available options before printing the selected objects.

Print One: prints one copy of the selected objects, using the default print methods previously defined by the user. The user is not prompted for further information through a dialog.

Guidelines for Common Print Dialog Functions

Applications are expected to provide many different types of printing functions and capabilities. This section provides guidelines for the most commonly used types of print options so that appearance and behavior for these items is consistent across applications. These common items are grouped into a common area that is located in the top portion of the print dialog. Figure 7-5 shows a typical print dialog. The common area is the area above the separator line.

Figure 7-5 A basic print dialog. box

The common area contains the following components:

Dialog Title: Print
File: this is a noneditable field. It displays the file name (if available). If the user is printing a nonfile object, this field should display the object type if possible (for example, mail message, calendar appointment).
Printer: A combination box; could also be a text field. It contains the name of the printer destination. The default entry is labeled Default, that is, whatever printer is the default destination. The user may select or type any other valid printer name. If it is a combination box, the list of printers could reflect what is appropriate for that printing job. The dialog should retain the last user entry or selection made.
Copies: A spin box (numeric widget) where the user selects or types the number of output copies desired. Optionally, this could be a text field.
Banner Page Title: A text field where the user may enter the text the user wants to appear on the banner page (that is, cover page) of their output. This field should pick up the default banner title if the user has set it elsewhere. Optionally, you could add a check box to turn the banner page off completely.
Separator lines: Used between the common fields, the application-specific fields, and the buttons.
The print dialog contains the following standard buttons:
- Print: Accepts the user's choices in the dialog, prints the selected objects, and exits the dialog.
- Cancel: Ignores the user's choices in the dialog, prints nothing, and exits the dialog.
- Help: Brings up an associated Help window.
- Optional buttons could include Reset, Print Preview.

Guidelines for Application-Specific Print Dialog Box Functions

The standard print dialog application-specific area is the bottom half of the dialog box illustrated in Figure 7-6.

Depending upon the application or function, developers may choose to add more fields to the common Print dialog. The controls in the dialog are laid out horizontally; if more fields are needed, it is suggested that you add another separator line, then place the additional controls below it, as illustrated. If any additional push buttons are needed, they should go between the Print and Cancel buttons.

Optional Fields

Some possible optional fields include:

Print Page Numbers: This checkbox applies only when ASCII files are being printed. If the objects selected for printing are non-ASCII, this control should be dimmed. When turned on, output pages will be numbered.
Print Command Options: A text field where the user may type an lp command or script name to override the instructions in the other fields. If you want to provide print methods besides lp, rename this field (Print Method, Use Print Command, and so on).
Priority: This might be an option menu containing values for High, Medium, and Low, or might be a spin box containing numbers.
Orientation: An option menu containing the values Portrait and Landscape (see Figure 7-6).
Resolution: An option menu or a spin box containing numeric values, in dpi (see Figure 7-6).
Sides: An option menu containing the values Single and Double (see Figure 7-6).
Paper Size: An option menu containing the values Letter, Legal, and so on. (Figure 7-6).
Paper Source: An option menu containing the values Upper Tray, Lower Tray, and so on. (see Figure 7-6).

If the dialog box is to be used for an application, consider:

Page Range: Two text fields, from x to y (see Figure 7-7).
Reduce/Enlarge: A spin box containing values for percentages (see Figure 7-7).
Print Preview: A button that brings up a WYSIWYG representation of the output.

Some Sample Layouts

Figure 7-6and Figure 7-7show some example Print dialog box layouts.

Figure 7-6 Example print dialog box layout for general printing

Figure 7-7 Example print dialog box layout for printing from applications

The Properties Dialog

User a properties dialog if your application provides settings that control the behavior of an application or the characteristics of an object.

Guidelines

Recommended	cz:	If your application manages objects and allows the user to see or modify settings for these objects, these settings are displayed 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	da:	If your application provides access to a Properties or Options window, this window includes 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 DialogBox and dismisses it. OK may be replaced by a more appropriate label (for example, Add). The alternate label should be a verb phrase.
		Apply	Applies any changes made to components in the DialogBox and does not dismiss it.
		Reset	Cancels any changes that have not yet been applied by your application. The controls within the DialogBox are reset to their state since the last time the DialogBox action was applied. If no changes have been applied within the current invocation of the DialogBox, the controls are reset to their state as of when the DialogBox 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 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	db:	If your application provides a Properties window that displays settings for a selected object, the Properties window tracks the current selection and modifies the state of any controls to accurately reflect the properties of the currently selected object.

The About Dialog Box

The About dialog box is used to present version and other information about your application. Use as the dialog that comes up when the user chooses About <application name> from the Help menu.

Guidelines for the About Dialog Box

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:

Application name
Version number
Release date
Copyright

Required

di:

The About dialog box should contain a Close button. Other buttons are optional, such as Help and More.

The following information might also be contained in the About box:

Recommended	dj:	Information about the operating system or other aspects required to run the application, for example, Common Desktop Environment 1.0.
Optional	dk:	A More Information dialog box for additional information such as development team credits, licensing, client or xhost information.

Figure 7-8 Example About dialog box

Figure 7-9 About dialog box with a More button

Chapter 8 Application Messages

From time to time, an application needs to present feedback to keep the user informed about the progress of ongoing activities and to alert the user to situations that require intervention. The Common Desktop Environment Motif interface provides many ways to provide such feedback to the user. This section describes the use of error messages, informational messages, and other message dialog boxes.

Error Messages and Informational Messages

Error messages and informational messages are appropriate in different situations. Present an error message when it is crucial to bring the information to the user's attention because the intended action cannot be carried out without user intervention. Present informational messages to describe progress, indicate short-term status, or give helpful suggestions. Informational messages should be gentle and nondisruptive to the flow of activity. Therefore, you must assume that the user may not notice informational messages. If it is important that your users see a particular piece of information, present it in an error dialog box or in another type of message dialog box.

Error Messages

Use error messages to present crucial messages to the user when user intervention is necessary for the successful completion of an operation. Error messages are intended to bring a problem to the user's attention and to help the user resolve the problem.

Guidelines for Error Messages

Use a Motif error dialog box to present application error messages. Figure 8-1shows a typical error dialog box. Keep in mind the basic three-part structure for error messages. Whenever possible, each message should tell the user:

What happened
Why it happened
What should be done to correct the problem

Figure 8-1 An error dialog box.

The text describes the error, why it happened, and offers to retry the operation. A Help button in the lower right will bring up appropriate online documentation.

Recommend

gd:

Error messages displayed by your application indicate the possible cause of the error and indicate the possible actions the user can take in response.

Keep the information in the ErrorDialog clear and concise. The idea is to alert users to the problem, have them quickly understand the problem, and learn how to recover from it. A large amount of text makes it more difficult for the user to focus on the critical information.

Recommend

gc:

Messages displayed by your application do not assume that the user has any expert knowledge about computer systems in general, or the UNIX system in particular.

It is appropriate to assume that the user has knowledge about basic terms used within the desktop, such as files or programs. Such knowledge can be assumed to have been learned by the user through tutorials, online help and user documentation. However, terminology that is typically understood only by an expert or frequent computer user should be avoided unless the application is specifically targeted at computer professionals. Likewise, messages returned to your application by the underlying operating system should not be passed through to the user, but instead, should be "translated" into language that can be understood by the novice user.

Try to make the error message specific to the immediate situation and as helpful as possible. For example, if the user has entered an invalid name, the error message should not simply state that an invalid name was entered. Instead, tell the user which character was invalid. If the rules for valid names are simple, describe them in the error message; otherwise, describe the rules in the online help and give the user access through the Help button.

In many cases, the only user response to an error dialog box will be to click the OK button to dismiss the dialog box. However, often it may be possible to offer to resolve the problem for the user. If you have buttons for user actions, be sure to also include a Cancel button.

Optional

ge:

Your application uses audio feedback, in addition to any messages displayed, to signal error conditions and events.

Optional

gh:

Urgent conditions that require immediate attention by the user, no matter which application or desktop service the user is currently accessing, are brought to the user's attention using audiovisual notification. The alarm is signaled in the current workspace regardless of the workspace in which the application resides.

Some applications, such as network monitors or stock watch programs, may need to grab the user's immediate attention to some event. Both visual and audio alarms should be used to signal the user. The user should be able to acknowledge the alarm and cause it to cease.

Keep in mind that the user may be running several applications at once, and may be focused on another application while your application is running in the background and encounters an error. The application name should appear in the title bar, to help the user identify the source of the error message.

Once users have read an error message, they may need to access other parts of their system to resolve the problem. Whenever reasonable, posting an error dialog box should not block further interaction with your application and, if at all possible, it should not block other applications.

Optional

gq:

Your application writes error messages to the Common Desktop Environment 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.

You might also write error messages that are displayed to the user in the error log if it would be valuable to the user or an administrator to refer to these messages at some later time. Messages written to the error log should provide additional information about the error and should state the context in which the error occurred.

Access to Online Help

Recommended

gj:

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

Applications should be designed with both the expert and novice user in mind. The novice user must be able to access additional information clarifying the message, the circumstances under which it might have been displayed, and what the user should do in response to the message.

The brief description of the problem in the ErrorDialog should be sufficient for the experienced user, but may not contain enough information to enable less experienced users to resolve the problem. Rather than confusing the dialog with additional text, use the Help button to take the user directly to the online documentation for a more detailed description of the error, its causes, and methods for resolving the issue. Users who still need additional help can browse the general online help facilities from there. A few notices may not need Help buttons because the text of the message will cover the condition sufficiently.

For more information on how to access online help directly from the error dialog box see the Help System Author's and Programmer's Guide.

Helpful Hints

Optional

gh:

Applications should not send messages to command entry windows or to the UNIX console (that is, applications should not write to the default UNIX files stdout or stderr). Applications are often launched by double-clicking icons in the File Manager, Front Panel, or Application Manager, which means users will not see messages that are written to stdout or stderr. Even if the application is launched from a terminal window, the user may subsequently close the terminal window, and messages appearing there will often not be seen. Worse, if the user does not have a console window running (the console window is difficult to launch in Common Desktop Environment), messages intended for the console may blast across the screen and make everything look ugly.

Informational Messages

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

Guidelines for Informational Messages

Recommended

gi:

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

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

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

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

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

Other Message Dialogs

Recommended	gk:	Your application uses the appropriate style dialog box for the display of messages to the user.
Optional	gl:	An information dialog box is used to display status, completion of activity, or other informative types of messages to which the user need not necessarily respond other than to acknowledge having read the message. Minimally, information dialog boxes should have an OK button so that the user can dismiss the dialog box. If there is additional information available about the situations under which the message is displayed or other references for the topic to which the message relates, then a Help button should be included.
Optional	gn:	A question dialog box is used to ask questions of the user. The question is clearly worded to indicate what a Yes response or a No response means. The buttons displayed are Yes, No, and Help. Help provides additional information as to what the application will do in response to a Yes or No choice. Where possible, you should replace the label for the Yes and No buttons to make it clear what action will be performed as a result of choosing either option. For example, if the user has made changes to a document and has not saved these but has chosen the application's Exit option, you might display a question dialog box that asks, "Changes have not been saved. Do you want to save these before exiting?" The buttons should be Save, Discard, Cancel, and Help. These labels allow the more experienced user to click the correct button without having to carefully read the question and relate it to the button labels.
Optional	go:	A warning dialog box is used to communicate the consequences of an action requested by the user that may result in the loss of data, system or application accessibility, or some other undesirable event. The dialog box is presented before the action is performed and offers the user the opportunity to cancel the requested operation. The buttons displayed are Yes, No, and Help, or Continue, Cancel, and Help. Help provides additional information on the consequences of performing the action requested. The use of Yes and No or Continue and Cancel depends on the wording of your message. The labels for Yes and No should be replaced as suggested previously. Continue may be replaced with a label more specific to the action that will be performed.
Optional	gp:	A working dialog box is used to display in-progress information to the user when this information is not displayed in the footer of your application's window. The dialog box contains a Stop button that allows the user to terminate the activity. The operation is terminated at the next appropriate breakpoint, and a confirmation might be displayed asking whether the user really wants to stop the activity. The confirmation message might state the consequences of stopping the action.

Work-in-Progress Feedback

Recommended

gt:

Recommended

gu:

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

Recommended

gv:

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

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

Chapter 9 Designing for Accessibility

This chapter provides guidelines for making software applications accessible to people with disabilities.

Accessibility

Accessibility means removing barriers that can prevent people with disabilities from participating in substantial life activities, including the use of services, products, and information.

Removing barriers to access often results in benefits for a wide range of people--not only those with disabilities. For example, until curb cut ramps were placed on sidewalks, it was difficult or impossible for people in wheelchairs to cross a street. In addition to providing a wheelchair solution, curb cuts have benefited people on bicycles, as well as those pushing shopping carts and baby carriages.

Designing accessible software has similar beneficial consequences for a wide range of users. Solutions that allow use of the keyboard instead of the mouse aid users involved in keyboard-intensive tasks. Users of portables or those in open offices with telephones ringing may not be able to use or hear sounds. Providing visual cues to augment or replace audible cues assists these users, in addition to assisting hearing impaired users.

There is a growing market for accessible computer products. Approximately 40 million Americans have a disability of some type, and as the population ages, more and more people will develop age-related disabilities (25% by age 55, jumping to 50% at age 65).

Like all computer users, users with disabilities vary in age, computer experience, interests, and education. When barriers are removed, the computer gives them a tool to compete with all other users on an equal basis. Users with disabilities are engineers, artists, scientists, designers, lawyers, administrative assistants, and software engineers. The common thread among these diverse users is that computers play an important role in their daily work.

Not only does providing access provide benefits for a wide range of users, but it is also a requirement in all current federal contracts under section 508 of the Federal Rehabilitation Act. In the commercial sector, the Americans with Disabilities Act (ADA) calls for similar considerations when reasonably accommodating current and prospective employees.

Access and the Style Guide

Many users with disabilities can use application software without any adjunct adaptive software or hardware, while others may use additional technology such as screen readers or speech recognition. In either case, it is important to follow required style guidelines because those guidelines provide standard methods that make it possible for users with disabilities to access applications either directly or through adaptive software and hardware.

The easiest way to ensure accessible applications is to follow the style guidelines, and to read and follow the advice offered in this chapter.

Physical Disabilities

Physical disabilities can be the result of congenital conditions, accidents, or excessive muscular strain. Examples include spinal cord injuries, degenerative nerve diseases, stroke, and repetitive stress injuries.

While physical capabilities vary greatly between and within the disability examples cited, they have a common requirement for keyboard access to all controls, features, and information in application software. Providing comprehensive keyboard access is essential to ensure that the user who cannot utilize a mouse can productively use Motif applications.

Full keyboard access to an application is necessary, but not sufficient to make applications accessible. The other central requirement is to follow the key mapping guidelines found throughout this style guide. Consistent use of these mappings not only provides more usable applications for all users by reducing learning across applications, but also increases the effectiveness of alternate I/O technology such as speech control and screen reading software.

Guideline

Recommended

id:

All application functions are accessible from the keyboard.

Visual Disabilities

Visual disabilities may require use of tools ranging from reading glasses, to large-sized displays and fonts, to screen reading software that enables completely blind users to navigate and hear what is on the screen.

Reading small fonts can be challenging for users with low vision. All fonts, including those in text panes, menus, labels, and information messages should be easily configurable by the user--font size and type should never be hard coded.

Interpreting information that depends upon color (for example, red = stop, green = go) can be difficult for people with visual impairments. A significant number of people are color blind and are unable to see differences between some colors. For these reasons, never use color as the only source of information.

In addition to being difficult to interpret, some background and text color combinations can result in text that is difficult to read for users with visual impairments. Again, the key is to provide choice. Never hard code color choices. Users should always have the capability to override default colors, so they can choose the colors that work best for them.

Provide meaningful names for every widget instance. Meaningful names help screen reading software give useful information to users with visual impairments. Rather than naming an eraser graphic widget5, for example, call it eraser or some other such descriptive name.

Without such descriptive information, blind or low-vision users cannot interpret unlabeled, graphically labeled, or custom widgets. Providing this information is a requirement for access in such cases. As an added bonus, meaningful widget names make for code that is easier to debug.

Finally, remember that many users with visual disabilities depend upon keyboard navigation and control, and they will not be using a pointing device.

Guidelines

Recommended	ie:	Colors should not be hard coded.
Recommended	if:	Graphic attributes, such as line, border, and shadow, should not be hard coded.
Recommended	ig:	Font sizes and styles should not be hard coded.
Recommended	ih:	All application code uses descriptive names for widgets. Such descriptive names for widgets using graphics instead of text (for example, palette items and icons) allow screen reading software to provide descriptive information to blind users.

Hearing Disabilities

People with hearing disabilities either cannot detect sound or may have difficulty distinguishing audio output from typical background noise.

Never assume that users will hear an auditory notice. Remember that users sitting in airplanes, in noisy offices, or in other public places where sound must be turned off need the same types of visual notification as hearing impaired users. Additionally, some users are able to hear audible cues only at certain frequencies or volumes. Volume and frequency of audio feedback should be easily configurable by the user. Never hard code these parameters.

Sounds unaccompanied by visual notification, such as a beep indicating that a print job is complete, are of no value to users with hearing impairments or others who are not using sound. While such sounds can be valuable, never create a design that assumes sounds will be heard.

On the other hand, it would be intrusive for most users to see a warning window whenever a printout is ready. Visual notices can take the form of changing an icon, posting a message in an information area, or providing a message window as appropriate. Anyone using a system in a public area will benefit from the option of choosing to see rather than hear such notices.

The key point is to provide users with a choice. When appropriate, provide visual as well as audio notification. If visual notification does not make sense as the default behavior, then be sure to provide it as an option.

Guidelines

Recommended	ii:	Interactions do not depend upon the assumption that a user will hear an audible notification.
Recommended	ij:	Where appropriate, users can choose to receive cues as audio or visual information.
Recommended	ik:	The application does not overuse or rely exclusively on audible information.
Recommended	il:	Users can choose to configure the frequency and volume of audible cues.

Language, Cognitive, and Other Disabilities

The access guidelines outlined for visual, hearing, and physical disabilities typically benefit users with cognitive, language, and other disabilities by allowing them to choose effective means of communication, sometimes through the use of adaptive technology.

Guidelines

Recommended

im:

Tear-off menus and user configurable menus for key application features may be provided for users with language and cognitive disabilities.

Existing Keyboard Access Features

When designing CDE Motif applications, be aware of existing system-level key mappings used by access features in the X Window System server. These server features, known as AccessX, provide basic workstation accessibility, typically used by people with mobility impairments. AccessX became a supported part of the X Windows server in version X11R6.

The built-in, server-level access features include:

StickyKeys: Provides locking or latching of modifier keys (for example, Shift, Control) so that they can be used without simultaneously pressing the keys being modified. StickyKeys allow single-finger operation of multiple key combinations.
RepeatKeys: Delays the onset of key repeat, allowing users with limited coordination time to release keys before multiple characters are sent.
SlowKeys: Requires a key to be pressed and held for a set period before keypress acceptance. This allows users with limited coordination to accidentally press keys without sending keypress events.
MouseKeys: An alternative to the mouse which provides keyboard-based explicit control of cursor movement and all mouse button press and release events.
ToggleKeys: Indicates locking key state with a tone when pressed; for example, Caps Lock.
BounceKeys: Requires a delay between keystrokes before accepting the next keypress so users with tremors can prevent the system from accepting inadvertent keypresses.

Guideline

Recommended

in:

Application keymappings do not conflict with existing system-level key mappings reserved for access features in the X Windows server as shown in Table 10-6.

Resources for More Information on Accessibility

For more information about software accessibility, consult the following organizations, conferences, and books.

Organizations

Clearinghouse on Computer Accommodation (COCA)

18th & F Streets, NW

Room 1213

Washington, DC 20405

(202) 501-4906

A central clearinghouse of information on technology and accessibility. COCA documentation covers products, government resources, user requirements, legal requirements, and much more.

Sensory Access Foundation

385 Sherman Avenue, Suite 2

Palo Alto, CA 94306

(415) 329-0430

A nonprofit organization that consults on application of technology "to increase options for visually and hearing impaired persons." Publishes newsletters on adaptive technology.

Special Needs Project

3463 State Street

Santa Barbara, CA 93105

(805) 683-9633

Vendor of books for professionals and families on a wide variety of disability issues.

Trace Research and Development Center

S-151 Waisman Center

1500 Highland Avenue

Madison, WI 53528

(608) 262-6966

A central source for the current information on assistive technologies as well as a major research and evaluation center. Trace distributes databases and papers on adaptive technology and resources.

Conferences

CSUN

Conference on Technology and Persons with Disabilities

Every spring in Los Angeles, California

(818) 885-2578

Closing the Gap

Conference on Microcomputer Technology in Special Education and Rehabilitation

Every fall in Minneapolis, Minnesota

(612) 248-3294

Bibliography

Brown, Carl. Computer Access in Higher Education for Students with Disabilities, 2nd Edition. George Lithograph Company, San Francisco. 1989.

Cornsweet, T.N. Visual Perception. Academic Press, New York. 1970.

Edwards, A., Edwards, E., and Mynatt, E. Enabling Technology for Users with Special Needs (InterCHI '93 Tutorial). 1993.

Johnson, M, and Elkins, S. Reporting on Disability. Advocado Press, Lousville, KY, 1989.

Managing Information Resources for Accessibility, U.S. General Services Administration Information Resources Management Service, Clearinghouse on Computer Accommodation, 1991.

Vanderheiden, G.C., Thirty-Something Million: Should They Be Exceptions?, Human Factors, 32(4), 383-396. 1990

Vanderheiden, G.C. Making Software More Accessible for People with Disabilities, Release 1.2. Trace Research & Development Center, 1992.

Walker, W.D., Novak, M.E., Tumblin, H.R., Vanderheiden, G.C. Making the X Window System Accessible to People with Disabilities. Proceedings: 7th Annual X Technical Conference. O'Reilly & Associates, 1993.