Common Desktop Environment: Style Guide and Certification Checklist

Application Design Principles

Layout

Main Window

	y	n/a	n
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. Each application potentially must share the display with other applications. The default window size should not take up all the available screen space.
Required	_	_	_	be:	Resize corners should be included in any main window that incorporates a scrolling data pane or list. 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).
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 example, 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.

Window Titles

	y	n/a	n
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; however, without the title, users might have difficulty telling which pop-up window belongs 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
Optional	_	_	_	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.
Recommended	_	_	_	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.

Menu Bar

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.

	y	n/a	n
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.
Required	_	_	_	6-5:	The menu bar for your application contains only cascading buttons. When other buttons are included as topics in a menu bar, they inhibit menu browsing.
	_	_	_	6-6:	This item has been deleted. It is replaced by the following guideline.
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. Replacing 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.

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

	y	n/a	n
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 the Open from the File menu, but has not saved changes to the current file.
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.
Required	_	_	_		New	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 box, asking the user about saving changes. The mnemonic is N.
Required	_	_	_		Open ...	Opens an existing file by prompting the user for a file name with a dialog box. If changes made to the current file will be lost, your application displays a dialog box asking the user about saving changes. The mnemonic is O.
Required	_	_	_		Save ...	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 box, prompting the user to enter a file name. The mnemonic is S.
Required	_	_	_		Save As...	Saves the currently opened file under a new name by prompting the user for a file name with a dialog box. If the user tries to save the file using an existing name, your application displays a dialog box that warns the user about a possible loss of data. Does not remove the existing contents of the client area. The mnemonic is A.
Recommended	_	_	_		Print	Schedules a file for printing. If your application needs specific information to print, it displays a dialog box, requesting the information from the user. In this case, the menu entry is followed by an ellipsis (Print...). The mnemonic is P.
Recommended	_	_	_		Close	Closes the current primary window and its associated secondary windows. If your application uses only a single primary window or multiple dependent primary windows, this action is not supplied. The mnemonic is C.
Required	_	_	_		Exit	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 box, asking the user about saving changes. The mnemonic is X.
					The use of a File menu with these common file operations yields consistency across applications.

<Object-type> / Selected Menu Contents

	y	n/a	n
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. 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	_	_	_		New ...	Creates a new instance of the object-type. If appropriate, a dialog box is presented allowing the user to specify the values for settings associated with that object.
Optional	_	_	_		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.
Optional	_	_	_		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.
Optional	_	_	_		Put in Workspace	Allows the user to put a link for the object onto the Common Desktop Environment desktop in the current workspace.
			_		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.
Optional	_	_	_		Delete	Removes the selected objects. A confirmation dialog box should be presented to the user before the object is actually deleted.
Recommended	_	_	_		Properties	Displays a Properties window that shows the current values for settings associated with the selected object.
Recommended	_	_	_		<Default Action>	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.

	y	n/a	n
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:
Optional	_	_	_		Undo	Reverses the most recently executed action. The mnemonic is U.
Optional	_	_	_		Cut	Removes the selected portion of data from the client area and puts it on the clipboard. The mnemonic is T.
Optional	_	_	_		Copy	Copies the selected portion of data from the client area and puts it on the clipboard. The mnemonic is C.
Optional	_	_	_		Copy Link	Copies a link of the selected portion of data from the client area and puts it on the clipboard. The mnemonic is K.
Optional	_	_	_		Paste	Pastes the contents of the clipboard into the client area. The mnemonic is P.
Optional	_	_	_		Paste Link	Pastes a link of the data represented by the contents of the clipboard into the client area. The mnemonic is L.
Optional	_	_	_		Clear	Removes a selected portion of data from the client area without copying it to the clipboard and does not compress the remaining data. The mnemonic is E.
Optional	_	_	_		Delete	Removes a selected portion of data from the client area without copying it to the clipboard. The mnemonic is D.
Optional	_	_	_		Select All	Sets the primary selection to be all the elements in a component of the client area.
Optional	_	_	_		Deselect All	Removes from the primary selection all the elements in a component of the client area.
Optional	_	_	_		Select Pasted	Sets the primary selection to the last element or elements pasted into a component of the client area.
Optional	_	_	_		Reselect	Sets the primary selection to the last selected element or elements in a component of the client area. This action is available only in components that do not support persistent selections and only when the current selection is empty.
Optional	_	_	_		Promote	Promotes to the primary selection the current selection of a component of the client area. This action is available only for components that support persistent selections.
	_	_	_		The use of an Edit menu with these common editing operations yields consistency across applications.
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.
Required	_	_	_	6-9:	This item has been deleted.

View Menu

	y	n/a	n
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

	y	n/a	n
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.

	y	n/a	n
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.
Required	_	_	_		Overview	Provides general information about the window from which help was accessed or about the application overall. The mnemonic is V. Place a separator after.
Optional	_	_	_		Index	Provides an index listing topics for all help information available for your application. The mnemonic is I.
Recommended	_	_	_		Table of Contents	Provides a table of contents listing topics for all help information available for your application. The mnemonic is C.
Recommended	_	_	_		Tasks	Provides access to help information indicating how to perform different tasks using your application. The mnemonic is T.
Recommended	_	_	_		Reference	Provides access to reference information. The mnemonic is R.
Optional	_	_	_		Tutorial	Provides access to your application's tutorial. The mnemonic is L.
Optional	_	_	_		Keyboard	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.
Optional	_	_	_		Mouse	Provides information about using a mouse with your application. The mnemonic is M.
Optional	_	_	_		Mouse and Keyboard	Provides information about your application's use of function keys, mnemonics, keyboard accelerators, and using a mouse with your application. Also provides information on general Common Desktop Environment use of such keys. The mnemonic is M. Use rather than separate mouse and keyboard choices if this information is best presented together.
Optional	_	_	_		On Item	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. Set off with separators on both sides.
Required	_	_	_		Using help	Provides information on how to use the Common Desktop Environment Help Viewer. The mnemonic is U. Set off with separators on both sides.
Required	_	_	_		About applicationname	Displays a dialog box indicating, minimally, the name and version of your application, and displays its icon or some other signature graphic for your application. The mnemonic is A.

Attachment Menu Contents

	y	n/a	n
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.

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.

	y	n/a	n
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	_	_	_	by:	Your application should provide a pop-up menu for any element that is selectable within its data pane. Pop-up menus provide access to frequently used functions and should be used pervasively throughout the 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	_	_	_	bz:	When a pop-up menu is displayed over an unselected object, any action selected from the pop-up menu applies to that object only, and not to any other objects that might currently be selected. The preceding helps to protect the user from inadvertently applying an action to objects that the user may not realize are currently selected. Pressing the menu button invokes a pop-up menu pertinent to the object under the mouse cursor whether it is selected to not; if the object under the mouse cursor and other objects are selected, the pop-up menu is pertinent to the selected set.
Recommended	_	_	_	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.
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. Because pop-up menus are hidden, they should only provide redundant access to functions available from more visible controls within the application's windows.
Optional	_	_	_	6-11:	If your application uses any of the common pop-up menu actions, the actions function according to the following specifications.
Optional	_	_	_		Properties	Displays a Properties dialog box that the user can use to set the properties of the component.
Optional	_	_	_		Undo	Reverses the most recently executed action.
Optional	_	_	_		Primary Move	Moves the contents of the primary selection to the component. This action is available only in editable components.
Optional	_	_	_		Primary Copy	Copies the contents of the primary selection to the component. This action is available only in editable components.
Optional	_	_	_		Primary Link	Places a link to the primary selection in the component. This action is available only in editable components.
Optional	_	_	_		Cut	Cuts elements to the clipboard. If the menu is popped up in a selection, cuts the entire selection to the clipboard.
Optional	_	_	_		Copy	Copies elements to the clipboard. If the menu is popped up in a selection, this action copies the entire selection to the clipboard.
Optional	_	_	_		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.
Optional	_	_	_		Paste	Pastes the contents of the clipboard to the component. This action is available only in editable components.
Optional	_	_	_		Paste Link	Pastes a link of the contents of the clipboard to the component. This action is available only in editable components.
Optional	_	_	_		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.
Optional	_	_	_		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.
Optional	_	_	_		Select All	Sets the primary selection to be all of the elements in the collection with the pop-up menu.
Optional	_	_	_		Deselect All	Deselects the current selection in the collection with the pop-up menu.
Optional	_	_	_		Select Pasted	Sets the primary selection to be the last element or elements pasted into the collection with the pop-up menu.
Optional	_	_	_		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.
Optional	_	_	_		Promote	Promotes the current selection to the primary selection. It is available only in components that support persistent selections.
					The use of pop-up menus with these common actions yields consistency across applications.
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.
Optional	_	_	_		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.
Optional	_	_	_		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.
Optional	_	_	_		Put in Workspace	Allows the user to put a link for the selected objects onto the Common Desktop Environment desktop in the current workspace.
Optional	_	_	_		Delete	Deletes the selected object. A confirmation is displayed to the user before actually removing the object.
Optional	_	_	_		Properties ...	Displays a dialog box indicating the current settings for attributes associated with the selected object.
Optional	_	_	_		Help ...	Displays a help window pertaining to objects of the type selected.
Optional	_	_	_	cd:	Choices within your pop-up menus are organized in the following manner: <choices that manage the object such as Open, Save, or Properties> ----------- separator ---------------- <standard edit menu choices such as Cut, Copy, and Paste> ----------- separator ---------------- <other choices>
Required	_	_	_	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.

Dialog Boxes

n/a

Required

6-13:

Information dialog boxes do not interrupt the user's interaction with your application.

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

Menu Design

	y	n/a	n
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 look at 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.
Recommended	_	_	_	ch:	No menu in your application contains more than 15 choices. 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, you should look at breaking it up into two or more menus, or grouping some items into submenus.
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.
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.
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 rather than dimmed.
Recommended	_	_	_	cm:	If a menu item is used to indicate a selection state, use a checkbox or radio button to indicate the state of the item. Use a checkbox if a single item is used to represent on or off states, and use radio buttons for multiple adjacent menu items in which only one of the items may be selected.
Required	_	_	_	cn:	If radio buttons are used in a menu, use separators between each set of radio buttons and other menu items.
Recommended	_	_	_	co:	If a checkbox or radio button is used on a menu item, it should always be shown as either selected or not selected, and should not disappear when in the unselected state.
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. When a tear-off button is activated, the menu changes into a dialog box. The tear-off button needs to be the first item in the menu so that the entire contents of the menu are torn off.
Required	_	_	_	6-15:	All menus are wide enough to accommodate their widest elements. The ability to see the full label of each menu element allows the user to browse through a menu.

Dialog Box Design

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.

	y	n/a	n
Recommended	_	_	_	cp:	The title of dialog boxes used within your application adheres to the conventions listed in Table 10-3

Table 10-3 Dialog Box Title Conventions


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

	y	n/a	n
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:
Optional	_	_	_		Yes	Indicates an affirmative response to a question posed in the dialog box.
Optional	_	_	_		No	Indicates a negative response to a question posed in the dialog box.
Optional	_	_	_		OK	Applies any changes made to components in the dialog box and dismisses the dialog box.
Optional	_	_	_		<command>	Applies any changes made to components in the dialog box, performs the action associated with the <command>, and dismisses the dialog box. 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.
Optional	_	_	_		Apply	Applies any changes made to components in the dialog box and does not dismiss it.
Optional	_	_	_		Retry	Causes the task in progress to be attempted again.
Optional	_	_	_		Stop	Ends the task in progress at the next possible break point.
Optional	_	_	_		Pause	Causes the task in progress to pause.
Optional	_	_	_		Resume	Causes a task that has paused to resume.
Optional	_	_	_		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.
Optional	_	_	_		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.
Optional	_	_	_		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).
Optional	_	_	_		Cancel	Dismisses the dialog box without performing any actions not yet applied.
Recommended	_	_	_		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	_	_	_	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"), 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.
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 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).

Property Windows

	y	n/a	n
Required	_	_	_	cy:	If your application provides settings that control the behavior of the application, these settings are displayed in an application properties window that is accessible from an Options menu.
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.
Required	_	_	_		OK	Applies any changes made to components in the dialog box and dismisses it. OK may be replaced by a more appropriate label; for example, Add. The alternate label should be a verb phrase.
Optional	_	_	_		Apply	Applies any changes made to components in the dialog box and does not dismiss it.
Required	_	_	_		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.
Optional	_	_	_		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).
Required	_	_	_		Cancel	Dismisses the dialog box without performing any actions not yet applied.
Required	_	_	_		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.

File Selection Dialog Box

	y	n/a	n
Optional	_	_	_	dc:	If your application allows the user to open or save files, then it uses the standard Common Desktop Environment file selection dialog box to allow the user to select specific files and directories. All user interactions with the file system should be facilitated by providing a point-and-click style of choosing files and directories. The user should never be forced to memorize and type in file paths. The user must be able to explore the contents and structure of the file system using scrolling lists. The expert user, however, should be able to directly enter a complete file path, as well as be able to use relative paths and environment variables such as `$HOME`. The labels and contents of the standard file selection dialog box may be modified as appropriate to make clear the particular context in which it is being used within your application.
Recommended	_	_	_	dd:	If your application allows the objects it manages to exist as separate entities within folders or toolboxes within the desktop environment, a Copy To menu option or button is provided that displays a file selection dialog box that allows the user to select the desired folder in which an icon for the object should be placed.
Recommended	_	_	_	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.

About Dialog Box

n/a

Optional

dh:

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.

Other information contained in the about box might be:

	y	n/a	n
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.

Dialog Box Layout

	y	n/a	n
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. Note - This assumes that your application is being designed for a left-to-right language environment. Alternative 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 relate to a specific control within the dialog box, the buttons should be located with 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, cascading buttons should only be used within menus and menu bars. You should avoid their use in all other locations unless absolutely necessary.
Recommended	_	_	_	dp:	If your application needs to use cascading buttons outside of a menu pane, you should use the `DtMenuButton` widget.

Designing Drag and Drop

	y	n/a	n
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.
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 draggable 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.
Required	_	_	_	dt:	During a drag operation, your application changes the current pointer to a drag icon. A drag icon provides visual feedback that a drag operation is in progress.
Recommended	_	_	_	du:	During a drag operation, your application changes the current drag cursor to include a source indicator. A source indicator gives a visual representation of the elements being dragged.
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. The user must receive feedback as to where an object can and cannot be dropped. Minimally, feedback should be provided as to what are invalid drop zones. Preferably, feedback for valid drop zones is enhanced by use of animation, recessing of the target drop zone, and other such drag-over effects.
Recommended	_	_	_	dw:	During a drag operation, your application changes the drop zone feedback to indicate a valid drop zone. Preferably, feedback for valid drop zones is enhanced by use of animation, recessing of the target drop zone, and other such drag-over effects.
Required	_	_	_	dx:	Pressing Cancel ends a drag-and-drop operation by canceling the drag in progress. Cancel provides a consistent way for the user to cancel a drag operation.
Required	_	_	_	dy:	Releasing BTransfer (or BSelect) when not over a drop target ends a drag-and-drop operation. Releasing BTransfer (or BSelect) offers a consistent means of ending a drag operation.
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.
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. Feedback provided during the drag operation should ensure that the user feels confident that the desired set of objects is being dragged. The drag icon used for multi-object drag operations should integrate the feedback used to indicate whether the operation is a move, copy, or link.
Required	_	_	_	eb:	After a successful transfer, the data is placed in the drop zone, and any transfer icon used by your application is removed. A transfer icon can be used to represent the type of data being transferred during a drop operation. A successful drop operation results in the transfer of data.
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. If a drag-and-drop operation has been canceled or failed, the data or object that was the source of the drag must not be removed.
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. A failed drop operation does not result in the transfer of data.
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. The error message should state the context (for example, running action A on object B), what happened (for example, could not connect to system X), and how to correct the problem (for example, press the Help button to obtain information on diagnosing remote execution problems).
Recommended	_	_	_	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.
Recommended	_	_	_	eg:	If your application supports drag and drop as a means of loading a file into the application, the application responds to this operation in a manner similar to when the file is loaded through more conventional means such as choosing Open from the File menu. As an accelerator, drag-and-drop loading of files should provide the same kind of feedback and behavior as choosing Open from the File menu. For example, if changes to a currently loaded file have not yet been saved, your application should display a message dialog box asking whether the changes should first be saved before loading the new file.
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. The Cancel button in the help dialog box provides a convenient way for the user to cancel a drag-and-drop operation.

Attachments

	y	n/a	n
Recommended	_	_	_	eh:	Drag and drop should not be the only method for attaching objects.
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	_	_	_	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.
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.
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.`

Installation

	y	n/a	n
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.

Interaction

	y	n/a	n
Required	_	_	_	6-18:	A warning dialog box allows the user to cancel the destructive action about which the dialog box is providing a warning. The user needs to have a way to cancel an operation that can cause destructive results.
Required	_	_	_	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. Note - This assumes that your application is being designed for a left-to-right language environment. Alternative design approaches may be necessary for other locales.
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	_	_	_	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.
Required	_	_	_	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	_	_	_	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 behave 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.

Visuals

	y	n/a	n
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. Desktop system configurations are including more high-resolution monitors. The user must be able to discern any visuals used by your application on these type of monitors. The embedded base, however, still contains many standard VGA monitors. Your application's visuals must display well on these systems and should not appear overly large.
Recommended	_	_	_	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.
Recommended	_	_	_	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.
Recommended	_	_	_	ez:	Icons should use only the palette of 22 colors. The Common Desktop Environment icon palette was chosen to maximize attractiveness and readability without using an unnecessary number of colors. Use of additional colors may cause undesirable color shifting on the display.
Recommended	_	_	_	fa:	Icons should be designed for international use. Don't use text, symbols, humor, animals, and other items that may be interpreted differently in other cultures.
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.

Toolbars

	y	n/a	n
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.
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.
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.
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.
Recommended	_	_	_	fl:	All pixmaps in the tool bar should be the same size. This ensures that all the tool bar buttons are 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.

Expandable Windows

	y	n/a	n
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.
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 in the primary and which in the secondary panes of the expandable window.
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.
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.
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.
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, as an option, to allow users to set the state of an expandable window globally for the application. This would be part of the application's Options.

Messages

	y	n/a	n
Recommended	_	_	_	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.
Recommended	_	_	_	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.
Optional	_	_	_	ge:	Your application uses audio feedback, in addition to any messages displayed, to signal error conditions and events.
Optional	_	_	_	gf:	Don't rely on error messages from the kernel and library routines. Error messages from kernel and library routines are normally not seen by the user, and even when the user does see them, they are usually too low-level and cryptic to be understood by nonprogrammers. Applications should check for error conditions and use an error dialog box to present an appropriate error message in terms of the user's actions and intentions.
Recommended	_	_	_	gg:	Your application displays a confirmation or warning message dialog box to the user when an action instigated by the user will be irreversible and potentially destructive with respect to the information stored within the system or the operation of the system or desktop environment.
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.
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. The footer is a good location for prompt messages that help the user to determine how to choose options within a window or fill out a particular field. It should not be used to present error messages to the user or informational messages that are important for the user to notice. These should be presented in the appropriate style message dialog box.
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.
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	_	_	_	gm:	An error dialog box is used to display error messages to the user. The error dialog box displayed states what the error is and specifies why it occurred. The error dialog box contains a Help button so that the user may get additional information, unless the message is self-explanatory. The error dialog box contains an OK button that dismisses the dialog box. A Cancel button is not required for error dialog boxes unless the error resulted in the suspension of an activity that was in progress. In this case, the message should indicate whether the user has the option to continue the activity or stop it, and the buttons for the dialog box should be Continue, Cancel, and Help. In general, error dialog boxes should not be modal unless it is critical that the user not continue interacting with the application until the user has acknowledged having read the error message.
Optional	_	_	_	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 extend 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 extended 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.
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.
Optional	_	_	_	gr:	Informational messages should be left aligned and displayed in a light font in keeping with their unobtrusive nature. Note that the margin where informational messages are displayed should not accept mouse focus.
Optional	_	_	_	gs:	Progress messages 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 or not the information is current.

Work-in-Progress Feedback

	y	n/a	n
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 pointer 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.