Common Desktop Environment: Style Guide and Certification Checklist

# 6 Application Design Principles

Contents of Chapter:

Component Layout Guidelines
  Main Window Layout
  Menu Bar Layout

Common Menu Types
  File Menu Contents
  <Object-type> and Selected Menu Contents
  Edit Menu Contents
  View Menu
  Options Menu
  Help Menu Contents
  Attachment Menu Contents
  Pop-up Menus

General Menu Design Rules

Tool Bars
  Tool Bar Guidelines
  Design Issues for Tool Bars
  Tool Bar Components

Window Titles

Work-in-Progress Feedback

General Application Design Rules

Application Installation

You 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. See link.

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

    Required

6-2:

  If your application has multiple main windows that serve the same primary function, each window closes and iconifies separately. See link.

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

  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.

    Required

be:

  Resize corners should be included in any main window that incorporates a scrolling data pane or list. See link.

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

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

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

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

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

## Common Menu Types

User actions fall into catagories 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. See link .

  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.

  - N ew [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.

  - O pen... [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.

  - S ave [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 A s...[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.

  - P rint [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.

  - C lose [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.

  - E x it [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. See link .

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

  - N ew... [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.

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

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

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

  - D elete [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.

  - P roperties [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: See link .

  - U ndo [RECOMMENDED]
    Reverses the most recently executed action. The mnemonic is U.

  - Cu t [RECOMMENDED]
    Removes the selected portion of data from the client area and puts it on the clipboard. The mnemonic is t.

  - C opy [RECOMMENDED]
    Copies the selected portion of data from the client area and puts it on the clipboard. The mnemonic is C.

  - Copy Lin k [OPTIONAL]
    Copies a link of the selected portion of data from the client area and puts it on the clipboard. The mnemonic is k.

  - P aste [RECOMMENDED]
    Pastes the contents of the clipboard into the client area. The mnemonic is P.

  - Paste L ink [OPTIONAL]
    Pastes a link of the data represented by the contents of the clipboard into the client area. The mnemonic is L.

  - Cl e ar [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.

  - D elete [RECOMMENDED]
    Removes a selected portion of data from the client area without copying it to the clipboard. The mnemonic is D.

  - S elect All [RECOMMENDED]
    Sets the primary selection to be all the selectable elements in the client area. The mnemonic is S.

  - Dese l ect All [RECOMMENDED]
    Removes from the primary selection all the selectable elements in the client area. The mnemonic is l.

  - Select P a sted [OPTIONAL]
    Sets the primary selection to the last element or elements pasted into a component of the client area. The mnemonic is a.

  - R eselect [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.

  - Pro m ote [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. See link .

### 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. See link .

### 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. See link.

### 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 supercede those listed for Motif 1.2. See link .

  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.

  - Over v iew [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.

  - I ndex [OPTIONAL]
    Provides an index listing topics for all help information available for your application.The mnemonic is I.

  - Table of C ontents [RECOMMENDED]
    Provides a table of contents listing topics for all help information available for your application.The mnemonic is C.

  - T asks [RECOMMENDED]
    Provides access to help information indicating how to perform different tasks using your application.The mnemonic is T.

  - R eference [RECOMMENDED]
    Provides access to reference information. The mnemonic is R.

  - Tutoria l [OPTIONAL]
    Provides access to your application's tutorial.The mnemonic is l.

  - K eyboard [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.

  - M ouse [OPTIONAL]
    Provides information about using a mouse with your application.The mnemonic is M.

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

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

  - U sing Help [REQUIRED]
    Provides information on how to use the Common Desktop Environment Help Facility.The mnemonic is U.

  - A bout 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. See link.

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

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

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

    Optional

cd:

  Choices within your pop-up menus are organized in the following manner: See link.

  <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 cc: for supplemental guidelines. See link .

  - P roperties
    Displays a properties dialog box that the user can use to set the properties of the component. The mnemonic is P.

  - U ndo
    Reverses the last executed action. The mnemonic is U.

  - Primary Mo v e
    Moves the contents of the primary selection to the component. This action is available only in editable components. The mnemonic is v.

  - Primary Cop y
    Copies the contents of the primary selection to the component. This action is available only in editable components. The mnemonic is y.

  - Primary Li n k
    Places a link to the primary selection in the component. This action is available only in editable components. The mnemonic is n.

  - Cu t
    Cuts elements to the clipboard. If the menu is popped up in a selection, cuts the entire selection to the clipboard. The mnemonic is t.

  - C opy
    Copies elements to the clipboard. If the menu is popped up in a selection, copies the entire selection to the clipboard. The mnemonic is C.

  - Copy Lin k
    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. The mnemonic is k.

  - P aste
    Pastes the contents of the clipboard to the component. This action is available only in editable components. The mnemonic is P.

  - Paste L ink
    Pastes a link of the contents of the clipboard to the component. This action is available only in editable components. The mnemonic is L.

  - Cl e ar
    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. The mnemonic is e.

  - D elete
    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. The mnemonic is D.

  - S elect All
    Sets the primary selection to be all of the elements in the collection with the pop-up menu. The mnemonic is S.

  - Deselect Al l
    Deselects the current selection in the collection with the pop-up menu. The mnemonic is l.

  - Select P a sted
    Sets the primary selection to be the last element or elements pasted into the collection with the pop-up menu. The mnemonic is a.

  - R eselect
    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. The mnemonic is R.

  - Pro m ote
    Promotes the current selection to the primary selection. It is available only in components that support persistent selections. The mnemonic is m.

    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 6-11: See link .

  - M ove 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. The mnemonic is M.

  - C opy 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. The mnemonic is C.

  - Pu t in Workspace
    Allows the user to put a link for the selected objects onto the Common Desktop Environment desktop in the current workspace. The mnemonic is t.

  - D elete
    Deletes the selected object. A confirmation is displayed to the user before actually removing the object. The mnemonic is D.

  - H elp...
    Displays a help window pertaining to objects of the type selected. The mnemonic is H.

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

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

  The use of an ellipsis helps set the user's expectation for the behaqvior 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. See link.

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

  Submenus may be used to group like items into a single secondary cascading menu where putting the items into the primary cascadingd menu would make it too long. However, if your submenu contains only two options, you should strongly look at removing the secondary cascadingd menu and putting the options into the primary cascadingd 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. See link.

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

    Optional

cj:

  Provide keyboard accelerators where appropriate. See link.

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

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

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

## 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. See link.

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

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

    Recommended

fg:

  Give users the option to hide the tool bar. See link.

### 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. See link.

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

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

#### 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. See link .

#### 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. See link.

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

## 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. See link.

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

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

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

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

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

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

    Optional

bm:

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

## 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. See link .

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

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

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

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

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

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

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

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

Generated with CERN WebMaker