Provide a meaningful, distinctive symbol that gives your product an identity and that allows users to readily identify your application and its corresponding custom data files, if any.

Keep your design fairly simple because desktop icons can be displayed at very small sizes.

Make sure that your icon can be identified across the range of viewing sizes.

Color most of your icon using the icon color predefined by IconSmith so that your icon's state is easy to detect.

Use two or more areas of accent colors to help your icon stand out against user-customized background colors.

Avoid small areas of color (2-4 pixels) because they're difficult to see against patterned backgrounds.

Include an outline around your custom symbol, and use the outline color supplied by IconSmith.

Avoid or use sparingly intense, strongly saturated colors and the specific colors used by the IRIX Interactive Desktop—bright yellow, dim yellow, royal blue, light gray-green, cadet blue, and Navajo white. These colors make it difficult to distinguish between certain icon states and to find your icon against the background colors of many desktop tools.

Orient your icon so that it displays a three-quarter view that faces the lower right corner of the screen.

Include the magic carpet, the generic executable symbol, with your application's symbol.

Indicate the state of the application (not running vs. running) by moving the magic carpet from a horizontal (not running) to vertical (running) position, or by providing two different application symbols and moving the magic carpet from a horizontal to vertical position. Remember that your application symbols should resemble a progressive animation when viewed in succession.

Make sure that your application symbols do not obscure the magic carpet in either its horizontal or vertical position.

Application icons that have two separate symbols for the not running and running states should make sure that the main part of the symbol remains in the same location during both states, so that the symbol appears stationary to the user.

Design a unique data file format symbol that is readily associated with your application icon design and also indicates how the data is used.

If your application is document-based, include the generic data file symbol (stack of papers) in your design.

If your data file icon does not use the generic data file symbol, create an appropriately shaped shadow for your file icon and use the predefined shadow color supplied by IconSmith.

Provide a CMD OPEN rule that launches the application. This allows the user to open your application either by selecting your application icon and then choosing “Open” from the corresponding Selected menu, or by double-clicking your application icon.

Provide a CMD ALTOPEN rule that opens the Launch dialog box shown in Figure 2-12 with the path to your executable displayed in the text field of this window. This allows the user to open the Launch dialog box by double-clicking your application icon while holding down the Alt key.

Provide a CMD DROP rule that launches your application with the file specified by the dropped icon. If your application doesn't understand the type of file represented by the icon dropped on it, your application should provide an appropriate error message to the user rather than launching. This allows the user to launch your application with a specific file by dragging the file icon and dropping it on your application icon.

Provide a CMD OPEN rule that launches your application and automatically opens the file represented by the file icon. This allows the user to open a file created by your application either by selecting the file icon and then choosing “Open” from the corresponding Selected menu, or by double-clicking the file icon.

Provide a CMD PRINT rule that sends the file represented by the file icon to the specified printer. This allows the user to send your application's data files to the default printer by selecting the file icon and then choosing “Print” from the corresponding Selected menu. It also allows the user to send your application's data files to any printer by dragging the file icon and dropping it on an icon that represents the specific printer.

Place your application icon on the Applications page in the Icon Catalog. If you produce a suite of software applications, consider creating your own page.

In your documentation, refer users to the appropriate page in the Icon Catalog after they've installed your application.

When naming your executable, use the product name or choose a name that's strongly associated with the product.

When naming your executable, use only lowercase letters. Don't use numbers, spaces, or special characters such as underlines or periods. Don't use an abbreviation of the product name.

Make sure that a link to your executable (preferred method) or the executable itself resides in a directory in the user's default search path. Ideally, place a link to your executable in the /usr/sbin directory. This helps ensure that users can quickly find your application icon using the Find an Icon tool.

Use the IRIX Interactive Desktop look rather than the standard IRIS IM look.

Use the pre-packaged color and font schemes supplied by Silicon Graphics rather than designing your own colors and fonts.

Determine which category (main, co-primary, support, or dialog) each application window belongs to and assign characteristics appropriately.

Include a Window menu button for all windows.

Include resize handles only if the window contains resizable components such as work areas, scrolling lists, and text input fields.

Include a Minimize button for all primary windows. Do not include this button on support windows or dialogs.

Include a Maximize button only if the window contains resizable components.

Include “Restore Alt+F5” for all primary windows. Include it for support windows and dialogs only if the menu contains a “Maximize” entry.

Include “Move Alt+F7” for all windows.

Include “Size Alt+F8” and resize handles for windows that contain resizable components such as works areas, scrolling lists, and text input fields.

Include “Minimize Alt+F9” and the Minimize button for all primary windows. Do not include the Minimize entry for support windows or dialogs.

Include “Maximize Alt+F10” for windows that are resizable, that is, they have a “Size Alt+F8” entry.

Include “Raise Alt+F2” for all windows.

Include “Lower Alt+F3” for all windows.

Include “Close Alt+F4” for all windows except the main primary window.

Include “Exit Alt+F12” for the main primary window. Include “Exit Alt+F12” for those co-primary windows from which users can quit the application. “Exit” always has the same behavior, that is, it quits the application, no matter how it's activated. Don't include “Exit” for support windows or dialogs.
(To see the above Window menu requirements arranged according to window type, see Table 3-1.)

Always use the default behaviors for the Window menu entries except for “Exit.” Don't add functionality to these commands. When users choose “Exit,” your application must perform any necessary clean up, such as prompting the user to save unsaved changes before quitting.

Don't add application-specific entries to this menu. Users don't expect application-specific entries in the Window menu.

Don't add a title to the Window menu.

Don't use the keyboard accelerators <Alt-F2>, <Alt-F3>, <Alt-F4>,
<Alt-F5>, <Alt-F7>, <Alt-F8>, <Alt-F9>, <Alt-F10>, or <Alt-F12> for other functions in your application. They are reserved for the 4Dwm Window menu entries.

For all categories of windows, limit the length of each title bar label such that the entire label displays when the window is viewed at its default size.

Don't include application-critical information or general status information in the title bar such as the current page number or whether a file is in view-only mode.

For main windows, first determine if your application uses document files. If it is not document-based, use the application name only. If it is document-based, use the application name followed by a colon and the filename (or Untitled if new file) in the format AppName : filename and update the label whenever the filename changes. Don't use the full pathname unless that information is required for users to distinguish one window from another. If your application is displaying remotely, add the host name followed by a colon at the beginning of the title bar label in the format Host : AppName ... .

Don't include full pathnames unless that information is required by users to distinguish one window from another. For remote applications, don't include domain information.

For co-primary windows used in multiple document models, use the format AppName : Filename (or AppName : Untitled if a new file). For co-primary windows used in the “single document, multiple primaries” model, use the format AppName : Function. Make sure that the function matches the menu entry or the label on the button that invokes it.

For support windows, use the application name and function in the format: AppName : Function. Make sure that the function closely matches the menu entry or the label on the button that invokes it.

For dialog windows, use the application name, followed by the type of dialog in the format: AppName : DialogType, where DialogType is “Prompt,” “Error,” “Warning,” “Question,” “Information,” “Working,” or “File Selection.”

Leave spaces between strings and colons in a label.

Display the “Exit” option with the right mouse button.

Allow users to resize the window with the left mouse button.

Specify a default size for each window.

If the window is resizable, specify a minimum size at which all controls and work areas will be visible and large enough to be usable. If the window is not resizable, set the minimum size equal to the default size.

If the window is resizable, specify a maximum size such that your application window doesn't expand to fill screen space unnecessarily. If the window is not resizable, set the maximum size equal to the default size.

Set a preferred window position for all primary windows. Don't set a required window position for primary windows.

Try to anticipate other application windows that may be displayed with your application and set your preferred default position appropriately.

Make sure that your application works well under implicit focus across windows.

Don't have your application move the pointer to another location on the screen. Always allow the user to control the position of the pointer on the screen.

If the user is always going to specify the data to capture with a single action such as a single mouse click or a single mouse drag, use the single-action pointer grab model; otherwise use the multiple-action pointer grab model.

Display a standard or modified sighting pointer whenever your application window grabs keyboard focus. This indicates that the keyboard focus belongs to your application's window and that the pointer isn't currently following implicit focus across windows.

Use a color image rather than a two-color bitmap.

Design your images to look best at the default size of 85x67 pixels.

If your application is based on a single document model, create separate images for each of the primary windows. If your application is based on a multiple document model, create one image for the main window and a second image to use for all co-primary windows.

Choose images that clearly identify the window that is minimized. If you have multiple images, make sure that the separate images work well together.

Make sure that the images you use for minimized windows will be understood by an international audience.

Don't use a snapshot of the desktop icon for the image. This could be confused with the real icon.

Limit the label to approximately twelve characters. If you need a few more characters than this, check that your label will fit with the default size and font for minimized windows.

If your application is not document-based, use the application name as the minimized window label for the minimized main window. Use the label Function for minimized co-primary windows where Function is the same function as in the co-primary window's title bar.

If your application is document-based and follows one of the single-document models, use Filename (or “Untitled” for new files) for the minimized main window label. Use Function for minimized co-primary window labels where Function is the same function as in the co-primary window's title bar.

If your application is document-based and follows one of the multiple-document models, use the application name as the label for the main window (if it is visible). The co-primary windows in these models represent the multiple documents and should have the minimized window label Filename (or “Untitled” for new files).

Decide which operations should and should not continue to be processed while the window is minimized.

Indicate status with the minimized window label if your application is typically minimized during long processes.

Use the default screen locations supplied by 4Dwm for the minimized window. Don't specify your own screen location.

Make sure that all windows with associated support or dialogs are visible and mapped to the screen so that the support windows and dialogs appear only on the desk where their parent window displays.

Don't design your application to manage the screen background.

Have your application create a command line that will launch the application and restore its current state. This current state should minimally include reopening any files that are currently open under the application and opening any primary or support windows that are currently open.

Update this command line as the state of the application changes.

If your application allows users to create and edit data files, have 4Dwm notify your application when the user chooses “Log Out.”

Save these changes into another file and name it something logical such as original_file_name.save. When the application is restarted at login, post a dialog that tells the user that this file with unsaved changes exists and query the user to determine whether to open the original file or the file with the unsaved changes.

If you cannot implement the preferred strategy described above, ignore the user's unsaved changes. Do not automatically save the user's changes by default.

Make sure that users can install and remove your application through the Software Manager, an IRIX Interactive Desktop utility.

Provide access in each window of your application from either a Help menu if the window has a menu bar or a Help button if the window doesn't have a menu bar.

Use SGIHelp. This provides users with a familiar viewer and familiar navigation techniques when reading the online help for your application.

Provide context-sensitive help, overview information, task-oriented help, a list of keyboard shortcuts, product information, and an index of help topics.

Provide context-sensitive help for all primary and support windows.

Enable context-sensitive help mode when the user either chooses the “Click for Help” entry in a Help menu (if the window has a menu bar) or presses <Shift>-<F1> (whether or not the window has a menu bar). Change the pointer to a question mark when context-sensitive help mode is enabled.

At a minimum, provide separate context-sensitive help for each control area, work area, status area, and menu in the window. This help should describe the purpose of the corresponding area and should include cross-references to task-oriented help topics which describe tasks which use this area.

Provide overview information for all main windows whether help is provided from a menu or a button. This overview should briefly describe the functionality of the entire application.

For co-primary and support windows that include a menu bar, provide overview information that describes the functionality of that specific window.

Provide task-oriented information for all windows. This information should include step-by-step instructions for how to accomplish all of the tasks available in the current window.

For windows with a menu bar, provide access to an index of help topics. This index should list all available help topics for the application including those that are generated using the context-sensitive help mode and those that are available directly from the Help menu. In addition, users should be able to browse the index and select topics for reading.

Provide keyboard shortcut information for all main windows (whether help is provided from a menu or a button) and for co-primary and support windows that include a menu bar. This information should include the mnemonics, accelerators, and function keys available for the entire application and not just for the current window.

Provide product information for all main windows (whether help is provided from a menu or a button) and for co-primary and support windows that include a menu bar. This information should minimally include the product name and version number. It might also include other general product information such as copyright and trademarking, licensing, and customer support access.

Display product information using an Information dialog so that users who don't install an application's online help can still access version number and customer support information.

Include a “Click for Help” entry to enable context-sensitive help mode with the keyboard accelerator <Shift>-<F1>.

Include an “Overview” entry for main windows. For co-primary and support windows, include an entry labeled “Overview for <window name>”.

Include entries that represent a list of tasks that users can accomplish in the current window. If this list of tasks is more than ten or twelve entries, use cascading menus. These entries shouldn't have mnemonics or keyboard accelerators.

Include an “Index” entry that allows the user to access the help index.

Include a “Keys & Shortcuts” entry to display all keyboard shortcuts for the application.

Include a “Product Information” entry.

Provide a Help button for all windows that don't have a menu bar.

For main windows, provide overview, task-oriented, keyboard shortcuts, and product information when the user clicks this button.

For co-primary and support windows, provide overview and task-oriented information when the user clicks this button.

For dialogs, provide help that focuses on the main purpose of the dialog and describes how to use the dialog.

For primary and support windows that include a Help button, also provide access to context-sensitive help when the user presses <Shift>-<F1>. Dialogs typically don't support context-sensitive help mode.

Create separate help “cards” for each help topic.

Limit each help card to no more than three viewer windows full of information.

Write a descriptive heading for each help card.

If a particular help topic needs supplemental information, provide links to that information rather than repeating it in the current card.

Use language your users will understand.

Use figures when appropriate. SGIHelp allows users to view graphics inline with the help text.

Begin by listing the individual controls and areas of your application windows that you need to describe.

At a minimum, provide separate help cards for each group of controls and areas in that window.

Provide descriptions in terms of the user tasks the components support.

Don't include procedural, task-oriented information with the context-sensitive information—include links to the appropriate task-oriented topics instead.

Restrict the content to information about what the product does, not how to use it.

Limit the text to one or two viewer windows of information.

Use the heading “Overview” for the main window's overview help card and “Overview of <window name>” for co-primary and support windows with overview help cards.

Begin by listing the tasks that users will want to accomplish with your application.

For each task, list the step-by-step instructions users will need to accomplish that task. If these instructions span more than three or four viewer windows, try to divide this topic into several smaller help topics.

Provide a brief summary paragraph at the beginning of the help card, followed by the step-by-step information.

Include all shortcuts for your application in a single card—mnemonics, keyboard accelerators, and function keys.

Match the titles in the index as closely as possible to the titles of the help cards.

Place the topics in the index in the following order—overview, list of tasks, context-sensitive topics, and keyboard shortcuts.

For the main application window, the help card should contain an overview of your application, task-oriented information, a list of all keyboard shortcuts, and product information.

For Help buttons not on the main application window of your application, present only the help information for the specific window.

If the amount of information on this one help card spans more than three or four viewer windows of information, after the overview or summary information at the beginning of the help card, place links which take users directly to the other chunks of help information contained in that card.

Have reviewers examine your help content online rather than reviewing a printed copy. Help topics will “read” differently depending on which paths readers (reviewers) traveled to get there.

Have reviewers check the titles of the help topics to make sure they are descriptive and appropriate.

Have reviewers test out all links to make sure they are appropriate.

Always honor the user's desktop customization settings. Never override or ignore them.

Use the pre-packaged color and font schemes supplied by Silicon Graphics rather than designing your own.

Set a preferred window position for all primary windows. Don't set a required window position for primary windows.

Try to anticipate other application and tool windows that may be displayed with your application and set your preferred default position appropriately.

Check the value of the default language each time your application is launched. Don't reset this value while the application is running.

Check the value of the double-click speed each time your application is launched. Don't reset this value while the application is running.

Make their preferred editor (specified in the Desktop control panel) available for use on text files.

Check the value for the preferred editor each time your application is launched, but don't reset this value while your application is running.

If users can only browse the ASCII text files, launch the editor in read-only mode.

If your application needs to stay in sync with the state of any part of the file system, use FAM. Don't have your application directly poll the file system to detect changes.

Support the Clipboard Transfer Model using the “Cut,” “Copy,” and “Paste” entries in the Edit menu. In this model, the clipboard is a global entity that's shared by all applications. Your application shouldn't use these entries to refer to a clipboard that's private to your application.

When supporting the Clipboard Transfer Model, don't select or highlight newly pasted data after a “Paste” operation.

Support the Primary Transfer Model. Assert ownership of the primary selection when the user begins to make a selection. Insert data at the location of the pointer when the user clicks the middle mouse button (which isn't necessarily at the insertion cursor).

When supporting the Primary Transfer Model, don't select or highlight newly transferred data after a transfer operation.

Use persistent always selection highlighting (keep the current selection highlighted even when your application loses the primary selection), unless the only action that can be performed on the selection is to copy the data using primary data transfer. In this case, use nonpersistent selection highlighting—that is, remove the selection highlight when the selection is no longer the primary selection.

When supporting the Primary Transfer Model, if the current active window has a selection that isn't the primary selection, reinstate this selection as the primary selection if the user presses <Alt-Insert>. Additionally, you can include a “Promote” entry in the Edit menu to perform the same function.

When supporting the Primary Transfer Model, when the user begins to modify a selection, such as adding elements to it, reassert ownership of the primary selection if your application does not currently own it.

When supporting both Clipboard Transfer and Primary Transfer, keep the primary selection independent from the clipboard. When the user begins to make a selection in your application, assert ownership of the primary selection but do not change the ownership of the clipboard. When the user chooses “Cut” or “Copy” from an Edit menu in your application, assert ownership of the clipboard but do not change the ownership of the primary selection.

Choose an appropriate application model for combining the different types of windows in your application.

Use only the allowable parent-child window relationships and keep your application window hierarchy shallow.

Use a menu bar unless all of the window's functionality is available through pushbuttons. Don't use a “floating” menu bar in a separate window.

Support keyboard accelerators for Close (Ctrl-W) and Exit (Ctrl-Q) as appropriate, even if the window doesn't have a menu bar.

Use a vertical scrollbar on the right side of the work area when the data being displayed in the work area may not fit in a vertical direction. Use a horizontal scrollbar directly below the work area when the data may not fit in a horizontal direction. Don't use scrollbars if you're certain the data will fit.

Disable the appropriate scrollbar when all the data is visible in a given direction. Don't remove the scrollbar.

Make each scrollbar span the entire height or width of the work area. Don't include controls or status information in the scrollbar region.

Place controls below horizontal scrollbars or to the left of work areas.

Provide pushbuttons for the most frequently accessed application-specific functions from the pull-down menus. Don't use pushbuttons for standard menu entries such as Open, Save, Close, Exit, Cut, Copy, Paste, and Help.

Use pushbuttons only for functions that appear in menus, unless the pushbuttons are part of a tool palette.

Provide an area for command-line input, if appropriate, in addition to (not in place of) pushbuttons.

Use a status area along the bottom of a primary window if your application needs to post frequent messages about its status. Provide vertical scrollbars for this area so that users can view previously displayed messages.

Use a status area to display messages that the user doesn't have to respond to rather than posting this noncritical information in dialogs. However, don't put critical warning or error messages in the status area (use a dialog instead).

Don't use the status area to display help information.

Divide panes using separator lines. If users might need to resize the pane, also include a sash control.

Try to limit the number of panes in a single window to four with no more than three sash controls.

If certain panes are optional, allow users to hide or show these individual panes using entries in the “View” menu.

Use them to provide access to sets of related controls.

Allow users to access them either through entries in the Tools menu or through pushbuttons in a tool palette in the parent primary window.

Be sure that each support window has a visible parent primary window that's mapped to the screen.

Make the layout simple and static. Don't include multiple panes of information.

Include a response area for standard actions that's similar to the one dialogs have.

Don't include a menu bar in most cases, but do support the keyboard accelerator for Close (Ctrl-W).

Avoid overlapping the work area of the parent window.

Bring them up as modeless secondary windows.

Use the IRIX Interactive Desktop color chooser whenever you want to offer the user an unrestricted choice of colors. For a restricted choice of colors, use a palette of colors to choose from, a list, an option button, or a set of radio buttons, depending on the number of choices available.

Always allow the user to control the location of the pointer; your application shouldn't change the position of the pointer.

Don't change the gain or acceleration characteristics of the pointer. If your application requires fine manipulation, provide a zoom feature in the View menu.

Use explicit focus for navigating among components within a window.

Support at least the minimum required functionality from the keyboard, such as navigating to and entering data into editable text fields, using mnemonics and keyboard accelerators to access menu entries, and scrolling any scrollable component. Keep in mind that some users use alternate input devices that rely on having functions available from the keyboard.

When the window becomes active for the first time, give focus to the component that the user is most likely to want to interact with using the keyboard. When a user returns the keyboard focus to a window that was previously the active window, return the keyboard focus to where it was when the user moved the focus out of that window.

Put each component that requires the use of arrow keys to control it in its own field. The following components are by default put in fields of their own: editable text fields, lists, scrollbars, and sashes.

Don't use the default keyboard navigation keys for other purposes. These keys are <Tab>, <Ctrl>-<Tab>, <Shift>-<Tab>, <Ctrl>-<Shift>-<Tab>, the arrow keys, <F10>, <Shift>-<F10>, and <Ctrl> in combination with a left mouse button click.

Use one of the four recommended selection models—single selection, browse selection, range selection, or discontiguous selection. Don't use the multiple selection model.

Automatically scroll the data as the user drags the pointer out of the scrollable data display region.

Determine if your users will need to create or modify a selection using the keyboard. If so, then support the keyboard actions defined in Section 4.1.6 of the OSF/Motif Style Guide. (These actions are automatically supported if you use the IRIS IM list or text components.)

Update the highlighting continuously as the user initiates and extends the selection.

Use persistent always highlighting, unless the only reason a user can select this data is to transfer it using the primary transfer model. In this case, use nonpersistent highlighting.

Deselect the previous selection whenever the user makes a new selection in any of the collections for cases where the user can select data in only one collection at a time.

Apply the operation to the collection that most recently had a selection made in it when the user can select data in more than one collection at a time and there are mouse, keyboard, or menu commands that can be applied to more than one of the collections.

Cancel a drag and drop operation if the user presses <Esc>, and leave both the object and the target as they were before the operation was initiated.

Use the left mouse button for both selecting and dragging non-text objects. Use the standard cursor in this case.

Use the middle mouse button for dragging text, and replace the cursor with a drag icon when the text is being dragged.

Allow users to activate and traverse the menus using the default IRIS IM behaviors for mouse and keyboard actions.

If a user closes a menu by clicking somewhere outside of the menu, the application should ignore this click so that users don't lose selections they've made in the window just because they display and close menus.

Allow users to display and close popup menus using the key combination <Shift><F10>. When <Shift><F10> displays a popup menu, the location cursor should be on the first available menu entry. When <Shift><F10> closes the menu, the keyboard focus should be returned to where it was before the menu was displayed.

Be sure that users can access most of your application's functionality from the menu entries. At a minimum, make sure that the core functionality can be accessed from the menus.

Don't include more than a 10-12 entries in a menu and make sure that all of your entries can fit on the screen at one time.

Provide mnemonics for all menus and menu entries. In most cases, the mnemonic should be either the first character of the name or, if there's a conflict, a character that's strongly associated with and included in the name. Use standard mnemonics for standard menus and entries.

Limit the use of tear-off menus. Instead, use support windows for groups of controls that users might want to use continuously.

Use the standard menus and menu entries as the basis for the overall design of the menu structure. Include all standard menus and entries that are applicable to your application.

Include a Help menu as the rightmost menu.

Include an “Undo” menu entry, particularly if users can perform actions that destroy or significantly change their dataÞ.

Include an “Exit” menu entry for all main windows and for co-primary windows if users will want to completely exit the application from that co-primary window.

Include a “Close” menu entry for all co-primary windows and support windows that have menu bars. Don't provide a “Close” entry for main windows.

Include menu entries that repeat the functionality of any pushbuttons on the primary window.

Include menu entries for actions that are accomplished using a direct manipulation method or a mouse shortcut such as double-clicking.

Include menu entries for accessing all primary and support windows that are children of the current window.

Don't include entries for functions that aren't available for the current version of your application.

Use entire one-word titles for menus rather than abbreviations.

Use the standard titles for menus (for example, File and Edit) if they're applicable, but change the standard title if this will make the function more clear.

Don't use a standard menu title if you're changing the standard definition.

Use the standard names for standard menu entries, but don't use a standard name for a menu entry that doesn't support the standard behavior.

Each entry name should be an action word, the value of a parameter, an attribute name, the name of a cascading menu, or the name of a co-primary, support, or dialog window. Don't use more than two words (except for task-oriented Help menu entries), and avoid using graphic labels for menus entries unless the graphics make the functionality more clear.

Choose descriptive names that help users learn the functionality of the application. For cascading menus, choose a name that clearly implies the contents of the menu.

Add a word if necessary to be sure the entry clearly indicates what entity will be acted upon. For example, you might use “New object” such as “New Folder” or “New Page” rather than just “New.”

If a menu entry toggles its state, use a checkbox and leave the menu entry name the same for the different states (“Italics”). If this won't be clear, toggle the name so that it indicates what action will be taken if the menu entry is selected (“Show Grid,” “Hide Grid”).

Capitalize the menu entry using the same rules as capitalizing book titles.

Use entire words rather than abbreviations.

Display an ellipsis (...) after menu entries that bring up a dialog that requests more information from the user. Don't use ellipses if the dialog simply brings up information that the user requested (for example, a Help dialog).

Place the standard menus in the standard order (File, Selected, Edit, View, Tools, Options, Help), even if you have renamed any of these menus. Place any new menus between the View and Tools menus.

Place standard menu entries in the standard order. “Close” and “Exit” are always at the end of the leftmost menu whether or not this menu is named File.

Group menu entries logically. If a new menu entry is related to one of the standard menu entries, place it near that standard menu entry.

Place items in the menu first according to the order they will be used, and second according to their frequency of use (with more frequently used items closer to the top of the menu).

Alphabetize entries that can be determined only when the user launches the application. If this alphabetized group appears in a menu that contains other entries, place the group at the end of a menu and use a separator between it and the preceding entries.

Use radio buttons for mutually exclusive menu entries, and checkboxes for a group of related menu entries, any number of which can be selected at any one time.

Use separators when necessary to group items—for example, to set off a group of related entries that use radio buttons or checkboxes.

Limit the use of cascading menus. Never use more than one level of cascading menus.

Use standard keyboard accelerators for standard menu entries; don't use any of the standard accelerators for your own entries, even if you're not using those standard entries.

Provide keyboard accelerators for the most frequently used menu entries. Don't provide accelerators for all menu entries.

Use the key combination <Ctrl>character. Don't use the key combination <Alt>character because this conflicts with mnemonics.

For pairs of menu entries where one entry reverses the results of the other entry (“Undo” and “Redo”), use <Ctrl>character for the most frequently used entry and <Shift><Ctrl>character for the other entry where character is the same for both accelerators.

Display all characters in keyboard accelerators as uppercase (for example, display <Ctrl>s as “Ctrl+S”). For keyboard accelerators that involve uppercase characters, show the <Shift> key as part of the keyboard accelerator (for example, display <Ctrl>S as “Shift+Ctrl+S”).

If selecting the menu entry in the current context would give the user an error message, show the menu entry as disabled (dimmed).

Avoid using dynamic entries. Rather than removing an entry when it's temporarily unavailable, include it and disable it as appropriate.

At most, provide a different popup menu for each main area (that is main field or main pane) of the window. Don't change the availability of a popup menu based on what graphical element the pointer is over or based on the selection state of any of the graphical elements.

Include entries for the most commonly used functions from the pull-down menus, and use the same names in the same order as they're displayed in the pull-down menus.

Avoid entries that require checkboxes or radio buttons. These are typically not the most commonly used menu functions.

Don't make menu entries the sole access to these functions.

Don't change the content of the menu based on what graphical element the pointer is over, or based on the selection state or contents of this element. Instead, put all entries in the popup menu for the main area of the window, then enable and disable entries as appropriate.

Don't include cascading menus and don't use tear-off menus.

Include a title that's either the name of the application, or if the application has more than one popup menu, that describes the purpose of the menu.

Use only one separator, which goes between the title and the individual menu entries.

Show ellipses and keyboard accelerators if these are shown in the corresponding pull-down menu entry, but don't show mnemonics.

If selecting the menu entry in the current context would give the user an error message, show the menu entry as disabled (dimmed). Don't remove the menu entry when it's temporarily unavailable.

If your application is based on presenting a page at a time and the user model is that tabs are used to move through the pages, then bind Page Up and Page Down to the tabs. In this case, <Ctrl><up arrow> and <Ctrl><down arrow> moves the vertical scrollbar a window at a time, allowing the user to pan around the current page.

If the user model is that a tab moves to another “document,” and the scrollbar is used to view various pages in the current document, then bind Page Up and Page Down to the scrollbar. In this case, no keyboard accelerator exists for moving to the next/previous tab.

In windows with menu bars, use pushbuttons to provide easy access to the most frequently used application-specific functions in the pulldown menus. For primary windows, these pushbuttons appear in the control area of the window.

In windows without menu bars, use pushbuttons to access help and to close the window.

Use pushbuttons to create tool palettes, either in support windows or in primary windows.

Use pushbuttons in the response area of a dialog for the standard actions for that dialog.

Always have the pushbutton perform the same operation (although the input to that operation may vary based on what data is currently selected). Don't use the same pushbutton to perform different tasks based on some mode of the application.

Use pushbuttons to perform an action; don't use them merely to set state, such as a parameter value in a dialog box. Use checkboxes, radio buttons, or option menus for this purpose.

Use either a text or graphic label that describes the action associated with the button. With text labels, use an active verb describing the operation the button performs. Each text label should be a single, capitalized word. Don't use abbreviations in labels.

Center the label on the button.

If the pushbutton opens a dialog to collect more information from the user before the action represented by the pushbutton can be completed, place an ellipsis after the button label. Don't use an ellipsis if the button opens a dialog simply to display some information to the user as an end result of the operation. This use of ellipses is the same as that described for menu entries in the section “Naming Menu Entries in the Pull-Down Menus” in Chapter 8.

If the action associated with a button is temporarily unavailable, disable the button rather than remove it.

Don't resize pushbuttons when the window is resized.

Don't use dynamic buttons whose labels change to indicate different functionality depending on the current context. Instead, use multiple buttons and disable buttons that represent functionality that's currently unavailable. With multiple buttons, the functionality is obvious even if some of the buttons aren't currently active. With dynamic buttons, the user has to put the application intothe proper context to discover some of the functionality. The one exception to this guideline is the Cancel/Close button used in Dialogs with the Apply button. See “Standard Dialog Actions” in Chapter 10 for information on this special case.

Use an option button when you want to offer the user about 5-12 mutually exclusive options; use a list for more than 12 choices. If there's enough space, use radio buttons for fewer than 5 choices.

Don't put radio buttons or checkboxes in an option menu.

Don't use an option button if the user can select several options at the same time—use a list or a set of checkboxes instead.

Don't put actions (such as zoom or rotate) in the option menu—use pulldown menus or pushbuttons instead.

Don't add or delete the choices in the option menu. If the choices must change, use a list.

Don't use cascading menus in the option menu. If there are so many items that they don't fit conveniently into an option menu, use a scrolling list instead.

Don't use a tear-off entry in an option menu.

Use the default label for the option button itself, which is the current value of the parameter.

Use a second label that describes the parameter that the option button controls. This parameter label should be to the left of the option button and should be followed by a colon (:) and a space (see Figure 9-2). This label is typically a noun and is not abbreviated.

Use nouns that indicate the possible values of the parameter being set.

Use entire words for the entries rather than abbreviations.

If one of the entries in an option menu is unavailable for selection in the current context, disable the menu entry. Don't remove the entry from the menu. Note that the user should always be able to display the contents of an option menu even if all of the menu entries are currently disabled.

Don't include a title in option menus.

Use checkboxes for single attributes or states that can be turned on and off, or for groups of items where multiple items in the group can be selected independently. (Also see “Using Radio Buttons and Checkboxes in Pull-Down Menus” in Chapter 8.)

Use checkboxes for groups of less than about six items. When dealing with more than a handful of items, use a list that allows multiple elements to be selected at the same time.

Don't use checkboxes for mutually exclusive options. If only one item in a group of items can be selected at a time, use radio buttons instead.

Don't use checkboxes for actions; use pushbuttons instead.

Don't change the choices in the group based on the current context. If you want to offer a dynamic set of choices, use a list.

Give each checkbox a label that describes the attribute, state, or option it controls.

Create a group label for each group of checkboxes, and indent the checkboxes below the label. This group label should be a noun that describes the function of the group.

Don't use abbreviations for either the checkbox labels or the group label.

Keep checkboxes updated to reflect the current state of the application and the settings of the current selection (if the settings of the checkboxes relate to the current selection). For example, if you have a checkbox for turning underlining on and off and the user selects some text, the checkbox should be updated to reflect whether or not the selection is underlined.

Disable checkboxes representing choices that aren't currently available. Don't remove the checkboxes.

Use radio buttons in groups, never as single buttons. If you need to use a single button that shows an on/off state, use a checkbox instead. (Also see “Using Radio Buttons and Checkboxes in Pull-Down Menus” in Chapter 8.)

Use radio buttons for mutually exclusive options. If more than one item in the group can be selected at a time, use checkboxes or a list instead.

Use radio buttons when you want to offer the user fewer than six options. If you have more than six options, or if screen space is extremely limited, use an option button instead. If you have more than 12 options, you should consider using a list where only a single element can be selected at a time.

Don't use radio buttons for actions; use pushbuttons instead.

Don't change the choices in a group of radio buttons based on the current context. If you want to offer a dynamic set of choices, use a list because users expect the elements of a list to change occasionally, but they don't expect radio buttons to change.

Give each radio button a label that describes the attribute or option it controls.

Create a group label for each group of radio buttons, and indent the radio buttons below the label. This group label should be a noun that describes the function of the group.

Don't use abbreviations for either the radio button labels or the group label.

Keep radio buttons updated. If the settings of the radio buttons depend on the current selection, they should be updated when the user makes a new selection so that they reflect the settings of the new selection.

Disable radio buttons representing options that aren't currently available. Don't remove the radio buttons.

Use LED buttons for single attributes or states that can be turned on and off, or for groups of items where multiple items in the group can be selected independently. (Also see “Using Radio Buttons and Checkboxes in Pull-Down Menus” in Chapter 8.)

Don't use LED buttons for actions; use pushbuttons instead.

Don't change the choices in the group based on the current context. If you want to offer a dynamic set of choices, use a list.

Label each LED button with a term that describes the attribute, state, or option it controls.

If there is a group of LED buttons, create a group label for the group, and indent the LED buttons below the label. Use a noun that describes the function of the group.

Don't use abbreviations for either the LED button labels or the group label.

Use a list when you want to allow the user to choose a single option from a large list (that is, more than 15 options). If you have fewer than 15 options, use either an option button (best for 5-15 options; or a set of radio buttons (best for 2-5 options).

Use a list when you want to allow the user to choose several options from a list of six or more elements. If you have fewer options, use checkboxes.

If you want to allow the user to choose elements from a dynamic list of options, use a list regardless of the number of options. (Option menus and groups of checkboxes or radio buttons should represent static lists of options.)

Label the list with a noun that indicates the function of the elements in the list. Don't use abbreviations in the label.

Place the label directly above and either left-aligned with or slightly to the left of the first element of the list.

If the elements in the list represent operations to perform, they should be active verbs. Otherwise, they should be nouns. In either case, use entire words rather than abbreviations.

When a window using a list is first opened, the currently selected list elements should be highlighted and the list should be scrolled to display these. If multiple elements are selected, scroll the list so that the first selected one appears at the top of the viewing area. See “Selection” in Chapter 7.

Allow users to select elements in the list according to the selection guideline discussed in “Selection” in Chapter 7.

Disable list elements that aren't currently available.

Allow the list to autoscroll (the default behavior) if the user is making a selection and the selection goes outside the range of the displayed elements. See “Selection” in Chapter 7.

Use single-line, editable text fields to display values of parameters that users can edit.

Use single-line, noneditable text fields to display values of parameters that users can't edit, whenever these values either change over time or might need to be selected by the user. If the value doesn't change and the user doesn't need to select it, use a label.

Don't use a text field if you need to display and edit pathnames; use the IRIX Interactive Desktop File Finder instead.

Use text fields for values that change over time; don't use labels.

Label each editable or noneditable text field, unless the field represents the bulk of a window and the field's function is clear. Use entire words in labels rather than abbreviations.

For single-line text fields, place the label to the left of the text field, and follow the label with a colon (:) and a space. The label should be vertically centered within the text field.

Use the default selection and highlighting discussed in “Selection” in Chapter 7.

Allow the user to cancel a text edit in progress by pressing <Esc>. That is, once the user has selected text and started to replace it with new text, <Esc> should cancel any changes that the user has made.

Keep text fields updated. When a window using a text field is first opened, the default or current setting (if either exists) for the text field should be shown.

Make the text automatically scroll if the user is making a selection and the selection goes outside the range of the displayed elements.

When an editable text field can't be edited in the current context but the information is still useful to the user, change it to a noneditable text field. If the information isn't useful to the user (that is, the user doesn't need to know the value and won't need to select it), disable the text field.

Use scrollbars to pan an associated view.

Use scrollbars with components that can be resized such that all of the available information contained in the component can't be displayed at one time. Typical scrollable components include work areas in primary windows, lists, multiple line text fields, and data display areas in primary or support windows.

Use scrollbars with a list when the number of elements in the list doesn't fit in the viewing region (vertical scrollbar), when the elements are too wide to fit in the viewing region (horizontal scrollbar), or when the window containing the list can be resized such that either of these situations can occur.

Use scrollbars with multi-line text regions when the data can't all be displayed vertically or horizontally or when the window can be resized such that this is true.

Don't use scrollbars with single-line text fields.

Don't use scrollbars for zooming or for rotation. Use an IRIX Interactive Desktop thumbwheel instead.

Don't use scrollbars to choose a value in a range; use the IRIX Interactive Desktop scale instead.

Place vertical scrollbars along the right of the element being scrolled, and place horizontal scrollbars along the bottom of the element being scrolled.

Keep scrollbars updated. When a window using a scrollbar is first opened, the scrollbar should reflect the current area being displayed in the scrolled region.

Update the data in the scrolled area continuously as the user drags the slider along the scroll region. This gives the feeling of direct, continuous control. Don't wait until the user has released the slider to update the data, because users often use the current view of the data to determine when to stop dragging the slider.

When a component is being scrolled, don't scroll it beyond the first or last elements. That is, there should be no extra white space before the first element or after the last element. The exception to this rule is scrolling text elements that represent physical pages (for example, in a desktop publishing application).

Make all components that use scrollbars automatically scroll when the user makes a selection that goes outside of the data currently being displayed. Also, make the component automatically scroll if the user performs an operation that moves the cursor outside of the current view (for example, if the user inserts or deletes text that moves the cursor outside of the current view). In this case, the view should be automatically scrolled so that the cursor is shown when the operation is finished.

When using the <Page Up>, <Page Down>, <Ctrl>-<Page Up>, or <Ctrl>-<Page Down> key sequences to scroll a page at a time, leave one unit of overlap from the previous page to make it easier for the user to preserve the current context. This unit is application-specific; it might be a line of text, an item in a list, a row of icons, or a specfic number of pixels (for example, in a drawing region). By default, this behavior is automatic for IRIS IM list and text components.

Remove the slider from the scrollbar when all of the data is currently being displayed. Don't remove the scrollbar or disable it in some other fashion.

Allow the user to cancel scroll actions by pressing <Esc>. By default, if the user presses the <Esc> key while dragging the slider along the scroll region, the scroll action is canceled, and both the data and the slider are returned to the position they had before the user initiated the scroll action.

Use scales to allow users to change a value in a given range. Use scales in display-only mode to display values that the user can't control. For example, use a display-only scale as a percent-done indicator to show progress in a Working dialog. (See “Working Dialogs” in Chapter 10.)

Don't use scales for scrolling.

Label it with the current value for the scale.

If the function of the scale isn't immediately apparent, give the scale an additional label that indicates its purpose. Don't use abbreviations in this label.

Keep scales updated. When a window using a scale is first opened, the slider of the scale should show the current setting for the scale control.

For sliders where the user can change the value, update the value being manipulated as the user moves the slider. It should give the impression of direct, continuous manipulation. For sliders that also manipulate an object, update the object continuously as well. For sliders that are used only to display values, the slider should be immediately updated to reflect the new value as the value changes.

Allow the user to cancel a scale operation by pressing <Esc>. If the user presses the <Esc> key while manipulating the scale, the action should be canceled, and the scale should return to the position it had before the user initiated the action.

Use entire words in labels rather than abbreviations.

Use labels for displaying text information that the user won't need to edit or select.

Use labels for labeling controls as described under the individual controls in this chapter.

Use labels for labeling groups of controls. When used to label a group of controls, the label should be followed by a colon (:) and a space, and should be placed either to the left of the item in the upper left corner of the group or above and slightly to the left of the item in the upper left corner of the group.

Use labels for simple instructions when necessary. Before adding instructions to any of your application windows, however, first try to design some alternatives that might make the instructions unnecessary. For example, if these instructions are necessary because the user interface works in a nonstandard way, redesigning the interface to be more standard is likely to make the instructions unnecessary.

Place labels on the background of the window (that is, the part of the window that isn't recessed).

Don't change the text or graphic on a label. If this information will change, consider putting it in a noneditable text field instead; users don't expect label text to change.

Disable labels when the controls they represent are disabled. Don't disable group labels.

Use the File Finder when the user needs to enter the pathname of a directory or file. This allows the user to drag and drop desktop icons to specify the file and to navigate the file hierarchy.

When a window using a file finder is first opened, the text field in the file finder should show the default or current value of the pathname, if any. This value should also be placed in the history list under the history button.

Use thumbwheels to change the values of continuous variables (that is, variables that don't have discrete values). For discrete values, consider a scale or dial instead.

Use thumbwheels with finite ranges for zooming operations and thumbwheels with infinite range for rotating objects.

When a thumbwheel is used to change a value that has a clear default, provide a home button. For example, a Directory View window has a thumbwheel that allows the user to set the size of the desktop icons. Pressing the home button on this thumbwheel sets the icons to their default size.

Use thumbwheels when screen real estate is extremely limited.

Don't use a thumbwheel for panning; use a scrollbar instead. A scrollbar gives the user much more information about the object being scrolled than a thumbwheel could.

Update the object or value being manipulated as the user moves the thumbwheel. The thumbwheel should give the impression of direct, continuous manipulation.

Use dials as an alternative to scales for setting parameters. Dials are best for numeric parameters where the range of allowable values is small and the values are discrete.

Place a label either directly below or directly above the dial, specifying the parameter that the dial controls.

When you have a group of dials, place each dial label in the same position relative to its dial (that is, either all the labels should be below the dials or all the labels should be above the dials).

Use entire words in the label rather than abbreviations.

When a window using a dial is first opened, the dial should show the current setting.

As a dial is rotated, update the value being manipulated to reflect the new value on the dial. The dial should give the impression of direct, continuous manipulation. Also, if the dial is controlling an object, continuously update the object as the dial is manipulated.

Use a Prompt dialog to ask users for specific information. This dialog can be modeless or modal.

Use an application-modal Error dialog to tell users about an error they've made in interacting with your application.

Use an application-modal Warning dialog when there's an action pending that will cause users to lose data.

Use an application-modal Question dialog to ask users a specific question that they must respond to before continuing to interact with the application.

Use a Working dialog when an operation takes more than 5 seconds to complete. This dialog can be modeless or modal.

Use a modeless Information dialog to give users information that's of immediate importance. Use this type of dialog sparingly.

Use the modeless IRIX Interactive Desktop File Selection dialog to allow users to navigate the file hierarchy and choose a file.

Don't use system-modal dialogs.

Use modal dialogs to show static information, and update modeless dialogs dynamically as the current state changes.

Associate every dialog with a primary or support window (its parent) that's mapped to the screen.

Use the window decorations and Window menu entries listed in Table 3-1 and described in “Window Decorations and the Window Menu” and “Rules for Labeling the Title Bar in Windows Other Than Main” in Chapter 3.

Have the default size large enough to allow all of the components and information to be displayed in their entirety.

Place the dialog on the screen either near (but not overlapping) any related information in the parent window, or in the center of the parent window if the contents of the dialog aren't related to the contents of the parent window.

Locate the initial keyboard focus in the field with which the user is most likely to want to interact.

Be sure the information being displayed in the dialog matches the current state of the application. If the dialog is modeless, update this information dynamically.

Include a response area that contains standard dialog actions (pushbuttons) tailored to the type and purpose of the dialog. Also include an input area that consists of whatever controls are necessary for selecting objects or setting application parameters in Prompt dialogs. Include a message area in Error, Warning, Question, Working, and Information dialogs.

Don't include secondary work areas; if you need additional work areas, use a support window instead.

Don't include menus. If the dialog includes so much functionality that menus are necessary, you should probably use a support window.

Use a subset of the standard dialog actions (Yes, No, OK, Close, Apply, Retry, Stop, Pause, Resume, Clear, Reset, Cancel, and Help), and have them appear in that order. If you include additional buttons, they should appear after the OK and Apply buttons but before the Cancel and Help buttons.

Include a Help button unless the situation is explained thoroughly in the dialog.

Avoid using both OK and Apply on the same dialog.

To decide between OK and Apply, determine whether users are more likely to use the dialog to make one set of changes at a time (if so, use OK), or whether they're more likely to want to make and apply changes repeatedly before closing the dialog (in this case, use Apply).

Include a Cancel/Close button on any dialog that has an Apply button.

Include a Cancel button on Working dialogs and, if possible, a Pause button (with the option of later resuming).

Whenever appropriate, choose one of the actions to be the default action.

Have OK be the default action for Information dialogs (which typically have buttons only for OK and Help).

Have the response that users are most likely to select be the default action for Question, Warning, Error, and any other dialogs that contain buttons but no text fields.

Have the response that users are most likely to select after entering a text string be the default action for dialogs that have only one text field. Use no other controls than the buttons in the response area (such as the File Selection and Prompt dialogs).

Don't have a default action for dialogs that contain multiple text fields.

Replace the “Yes” and “No” labels in Warning and Question dialogs with button names that clearly indicate the specific action that will occur if the button is clicked.

Replace the “OK” or “Apply” labels in Prompt or Warning dialogs with button names that clearly indicate the specific action that will occur if the button is clicked, unless the button is used for more than one purpose, or in the rare instance that “OK” and “Apply” are used together in a Prompt dialog.

In all other cases, use the OSF/Motif standard names.

Use Prompt dialogs to collect information in related chunks—that is, avoid collecting unrelated pieces of information in the same dialog, and don't launch multiple dialog boxes sequentially to collect several pieces of information if these pieces are frequently collected at the same time.

Include a description of the error, step-by-step instructions for how to recover from it, and a pointer to more information in Error dialogs. If the error involves a specific entity (for instance, a file, user, or host), name the entity in the error message.

Invoke Error dialogs only when they're directly relevant to the user; for example, don't tell the user that the printer is out of paper until the user has a job in the queue.

State what data is likely to be lost and why, and give the user a chance to cancel the action in Warning dialogs.

Limit your use of Question dialogs to those situations where the user couldn't have provided the information in advance.

Don't use Question dialogs for questions that relate to a pending destructive action—for these cases, use Warning dialogs instead.

Dynamically indicate how much of the operation is complete with the IRIX Interactive Desktop scale used as a percent-done indicator in Working dialogs.

Switch from the general-purpose pointer to the watch pointer in the parent window of a modal Working dialog.

Limit the use of dialogs to those cases when they're absolutely necessary. Don't use dialogs to provide general status information—use a status area in the associated primary or support window instead.

Invoke a dialog whenever users choose a menu entry that includes an ellipsis.

Display the IRIX Interactive Desktop File Selection dialog when the user chooses “Open...” from the File menu. The first time this dialog is opened, it should show the current working directory and no specific file. Subsequently, it should come up in the state it was last in when the user dismissed it.

Display the IRIX Interactive Desktop File Selection dialog when the user chooses “Save As...” from the File menu. If the file being saved doesn't exist yet, the dialog should show the current working directory and no specific file. If the file exists, the dialog should show that file's directory, and the current name of the file should be selected.

When users open, close, or save changes to files, prompt them with a Warning dialog whenever these actions will cause data to be lost:

In an application that allows only one document to be open at a time, when the user chooses to open another (new or existing) document and there are unsaved changes in the currently opened document. (For example, the user chooses “New,” “Open,” or “Reopen” from the File menu.)

When the user chooses “Close” from the File menu in a co-primary window, and the co-primary window contains data that will be lost if the window is closed.

When the user chooses “Exit” from the File menu, and at least one open co-primary window contains data that will be lost if the application is exited. For applications that support multiple open documents, prompt the user with a separate dialog box for each file that's currently open and has unsaved changes.

Prompt users with the File Selection dialog when they choose Save from the File menu and the current file is untitled. The behavior is the same as the “Save As...” entry in this situation.

Prompt users with a Warning dialog when they're interacting with the File Selection dialog and they choose a filename that already exists.

Prompt users with a Warning dialog when they choose “Revert” from the File menu and the file currently has unsaved changes.

Display an Information dialog when a user chooses the “Product Information” entry from the Help menu.

Display the Working dialog when users initiate an operation that takes more than five seconds to complete. Note that you might have to choose one of several different platforms as your standard for estimating times of operations.

Provide graphic feedback with appropriate desktop icon designs, by using the IRIX Interactive Desktop look, by changing pointer shapes appropriately, and by highlighting selected text.

Be sure your application displays up-to-date information—in controls and components (display the settings that correspond to the currently selected object or the current values), and in information displays (such as directory views). If the information being displayed can't be dynamically updated, choose a design that looks static.

Provide textual message to the user through dialogs, through status areas on your primary windows, and by changing the label of your minimized window when appropriate.

Use the standard pointers when possible.

Use the upper-left pointing arrow as a general-purpose pointer; this pointer should be red with a white outline.

Use the upper-right pointing arrow when a menu is pulled down from a menu bar, popped up from the right mouse button, or displayed from an option menu button.

Use the watch pointer for operations that take more than 3 seconds. (For less than 3 seconds, maintain the current pointer; for more than 5 seconds, also use a work-in-progress dialog.)

Use the I-beam pointer to indicate that your application is in a text-editing mode, but don't use it to indicate implicit focus over a text object within a window.

Use the question mark to indicate that the user is in context-sensitive help mode.

Use the sighting pointer (crosshair) to make fine position selections.

Use resize pointers to indicate positions when resizing an area.

Use the 4-directional arrow to indicate that either a move operation or a resize operation is in progress.

Don't use the hourglass pointer; use the watch pointer instead.

Don't use the X pointer (it's reserved for the window manager).

Don't assign new functionality to the standard pointer shapes; instead, design your own new pointer shape.

Create a pointer shape that gives a hint about its purpose.

Make the shape easy to see.

Make the hotspot easy to locate.

Avoid shapes that would create visual clutter.

Assign primary functionality to the left mouse button.

Use modifier keys in conjunction with the left mouse button to make additional functionality available.

Reserve the middle mouse button for primary copy and paste operations and to provide access to advanced user shortcuts that are also accessible via a more obvious user interface.

Reserve the right mouse button for popup menus.

Use the <Shift> key to constrain or unconstrain the default behavior of the left mouse button.

Use the <Ctrl> key to allow alternate behaviors that aren't thought of as constraining or unconstraining the default behavior assigned to the left mouse button.

Use <Shift> and <Ctrl> together where it makes sense to provide alternate behavior that's also constrained or unconstrained.

Reserve the <Alt> key for a view overlay (see “View Overlay” in Chapter 13).

Reserve the <Esc> key for mode switches, for example, switching from view mode to edit mode.

Use the standard pointer shapes to indicate specific 3D functionality. Display these pointers whenever the user accesses that functionality.

Use the standard pointers used in 2D applications as needed (for example, the watch pointer to indicate an operation is in progress).

If the user resizes the window and keeps its same aspect ratio, make the scene in the viewing area of the window proportionally bigger or smaller based on the resize action.

If the user resizes the window and changes its aspect ratio during the resize operation, display more or less of the scene being displayed based on the resize action, but don't change the size of the objects in the scene.

Provide a viewing interface regardless of other capabilities of the application (for example, editing).

Decide whether your application will support inspection, navigation, or both, then provide the appropriate viewing functions. If your application supports both inspection and navigation, choose one as the primary mode for viewing.

Use standard pointer shapes to indicate the current 3D viewing function.

Support the user model that users are manipulating a scene as though it were a single object they are holding in their hand (not the user model that users are manipulating a camera). From the user's perspective, all controls appear to manipulate the object or scene while the camera remains stationary.

Support tumbling as the default inspection function to allow users to view all sides of the scene.

Assign tumbling to dragging with the left mouse button.

Display the tumble pointer while the user accesses the tumble function.

Support dollying to allow users to move the scene closer or farther away.

Assign dollying to dragging with the left and middle mouse buttons pressed simultaneously.

Display the dolly pointer while the user accesses the dolly function.

Support panning to allow users to move the scene left, right, up, or down.

Assign panning to dragging with the middle mouse button.

Display the pan pointer while the user accesses the panning function.

Support seeking to allow users to change the look-at point and center the object of interest and to bring the object incrementally closer.

Support seeking as follows:

If your application needs to reserve clicking with the left mouse button for a more critical or useful function, allow users to seek by first activating a seek tool, then clicking with the left mouse button in the scene. Otherwise, support seeking without the use of a tool.

In either case, the user seeks by clicking on a part of the scene with the left mouse button. The application centers that part of the scene in the viewing window and moves the scene closer by half the distance between the camera and the object.

With each subsequent click on the same part of the scene, the scene again moves closer.

If your application needs to reserve clicking with the left mouse button for a more critical function, allow users to seek by first activating a seek tool, then clicking with the left mouse button in the scene.

Display the seek pointer while the user accesses the seek function.

Support the user model that the scene is stationary and the user is moving through this fixed, immovable world. From the user's perspective, all navigation controls appear to manipulate the camera (user's view into the world) while the scene remains stationary.

Support roaming as the default navigation function. In roaming, the user can move forward and backward, turn left and right, and turn to move in a new direction.

Assign roaming to dragging with the left mouse button.

Display the roam pointer while the user accesses the roaming function.

Support tilting to allow users to change their view of the scene by tilting their head up and down. Tilting doesn't move the user forward or backward.

Assign tilting to dragging with the left and middle mouse buttons pressed simultaneously.

Display the tilt pointer while the user accesses the tilting function.

Support sidling to allows users to sidestep left and right and to move up and down as if on an elevator.

Assign sidling to dragging with the middle mouse button.

While the user accesses the sidling function, display the sidle pointer.

Support seeking to allow users to move closer to an object in the scene by clicking instead of dragging.

Support seeking as follows:

The user clicks on an object in the scene with the left mouse button when the application is in view mode. The application automatically moves the user through the scene and closer to that object.

With each subsequent click on the same object in the scene, the user moves closer to that object.

Display the seek pointer while the user accesses the seek function.

Always provide ready access to viewing no matter what the user is doing (for example editing).

Display the appropriate pointer depending on the task the user is performing:

While the user is accessing editing functions, display the edit pointer.

While the user is accessing viewing functions, display the appropriate view pointer based on the user's current viewing function (for example, the roaming pointer if the user is currently navigating a scene).

Provide a modal interface to viewing and editing whenever possible.

Provide an obvious mechanism for changing between the view and edit modes, such as buttons in a tool palette or entries in a pull-down menu.

Reserve the <Esc> key for switching between the view and edit modes.

Always provide a view overlay for quick access to viewing. That is, when the primary task is editing, the user can at any time temporarily enter a view mode by pressing and holding the <Alt> key. The user can release the <Alt> key to return the application to edit mode.

Reserve the <Alt> key for providing access to a view overlay. If the user is already in view mode, the <Alt> key has no effect.

Display the appropriate pointer for the current viewing function (for example, the tumble pointer or the roaming pointer) while the user is accessing a view overlay.

Optionally provide additional ways to access viewing, for example, offer viewing fixtures or split viewing and editing input across separate dedicated input devices.

Use a single viewport if the user doesn't need to do much editing, performance or screen real estate is critical, you need a simple user model, or if several of these conditions are met.

Support multiple viewports if the user needs two or more views of the data simultaneously (such as when editing complex objects or working on scene composition) and performance isn't a critical issue.

Use the perspective view of the scene as the default view.

Update the single-viewport view with a new view as the user selects different cameras.

Support a minimum frame rate of 8 fps when the user is interacting with the view.

Ideally, support a minimum rate of 10-12 fps for editing and a minimum frame rate of 15 fps for a realistic interactive experience.

If the frame rate drops below 8 fps, provide at least one of the following solutions:

Automatic adaptive rendering, where the application always maintains an acceptable frame rate at the expense of scene fidelity.

User-controlled adaptive rendering, where the user explicitly chooses between adaptive rendering (acceptable frame rate but loss of detail) and fully rendering the contents of the scene (at a possibly unacceptably low frame rate).

If users sometimes need fully rendered, high-fidelity scenes and the frame rate is likely to drop below 8 fps, provide user-controlled adaptive rendering.

If you application only provides automatic adaptive rendering, provide users ready access to fully rendered scenes. At a minimum, this should happen when the user stops interacting with the view.

Follow the object-action paradigm of direct manipulation: The user first selects an object (or group of objects), then chooses an action to perform on it.

For actions that apply to objects, apply the action to all the objects in the current selection and only to those objects.

Provide one current selection for each application at any time. The current selection may be empty (that is, no selection). Note that each window of your application can maintain a separate selection, but there is only one current selection.

Support direct selection as the primary selection mechanism. Using the left mouse button, the user either clicks directly on an object to select it or sweeps out an area to select multiple objects.

Support indirect selection if your users need it. For example, allow users to select an indirect representation of an object such as an item in a list, or provide a “Select All” menu item.

If your application lets users select more than one object in a hierarchy of objects, provide at a minimum a method for selecting the highest and lowest object in the hierarchy and a method for adjusting the selection up and down the hierarchy.

If your application allows users to select only one object at a time, support the OSF/Motif single selection model as follows:

Users directly select an object by moving the pointer over it and pressing the left mouse button. Any previously selected object is deselected.

Users deselect an object by clicking outside the selection in an empty area.

If your application allows users to select more than one object at a time, support the OSF/Motif discontiguous selection model as follows. Ideally, support the entire OSF/Motif discontiguous selection model.

Users directly select an object by moving the pointer over it and pressing the left mouse button. Any previously selected objects are deselected.

Users <Ctrl>-click an unselected object to add it to the current selection, and <Ctrl>-click an already selected object to remove it from the current selection. That is, <Ctrl>-click toggles the selection state of the object.

If users are accustomed to using the <Shift> key in other applications to toggle the selection state of an object, allow them to add and remove objects by <Shift>-clicking an object in addition to <Ctrl>-clicking an object. In that case, <Shift>-clicking an object performs the same selection actions as <Ctrl>-clicking an object.

Users deselect all objects by clicking outside the selection in an empty area. In addition, a “Deselect All” menu item may be useful for some applications.

Optionally, allow users to use sweep selection to select multiple objects, allowing either rectangle-drag or lasso-drag. At the end of a sweep action, the only objects selected are those inside the sweep area.

Optionally allow users to <Ctrl>-sweep through a collection of objects to toggle the selection state of all objects inside the sweep area. That is, objects inside the sweep area that were previously selected are deselected, and objects inside the sweep area that were previously deselected are selected. The selection state of objects outside the sweep area doesn't change.

If your application supports the optional <Ctrl>-sweep selection action and users are accustomed to using the <Shift> key in their other applications to toggle the selection state of an object, allow users to use <Shift>-sweep in addition to <Ctrl>-sweep to toggle the selection state of all objects inside the sweep area.

Provide clear feedback on each object as it is selected.

When using a bounding box for selection feedback, make sure that it is differently shaped or larger than the object itself so that it is readily visible. Using a distinct color for the bounding box is also highly recommended.

If users don't typically select objects in your application to manipulate them (translate, rotate, scale) or can't manipulate the selected objects, use bounding boxes to indicate the selected objects.

If users typically select objects in your application to manipulate them, use the manipulator as selection feedback. If your application allows more than one object to be selected at a time, consider displaying the manipulator only on a lead object and bounding boxes on the other selected objects.

If your application needs to always present a realistic “experience-oriented” representation of objects in the scene, highlight selected objects in some way rather than cluttering the scene with bounding boxes or manipulators.

If your application allows users to select more than one object at a time, consider identifying one of those objects as the lead object.

Clearly distinguish the lead object from other selected objects:

If users typically select objects to manipulate them, consider making this distinction by displaying the manipulator only on the lead object and a bounding box on all other selected objects.

Otherwise, if there are manipulators or bounding boxes on all selected objects, distinguish the lead object another way (color, full manipulator instead of partial, and so on.).

If the user clicks to define a selection or <Ctrl>-clicks to add to a selection, make the lead object the last object selected. This allows users to change the lead object using click or <Ctrl>-click on an object that's currently not selected, or using <Ctrl>-click twice on a currently selected object.

If the user employs a single action such as a sweep selection to select multiple objects at the same time, make the lead object the one that is closest to the camera and closest to the middle of the viewport.

When the user deselects the lead object, move back through the previous lead objects making the most recent lead object that is still selected the new lead object.

If the user groups a collection of objects, make the group the new lead object.

When the user ungroups a grouped collection of objects, each object that was in the group becomes selected, and the object from the group that is closest to the camera and closest to the middle of the viewport becomes the new lead object.

Let users manipulate objects directly whenever possible.

If an intermediary, such as a dialog box, yields more precise results for an action and your users need precise manipulations, provide an intermediary method in addition to direct manipulation.

Provide manipulators to allow users to use direct manipulation when editing objects.

Use the standard manipulators provided by Silicon Graphics for translation, rotation, and scaling.

Make sure users can readily identify a manipulator's controls and how to interact with those controls. Also, make sure the controls allow users to precisely manipulate an object.

Provide immediate feedback on available actions during the different stages of manipulation as follows:

Display phase—Display the manipulator in its neutral state.

Approach phase—As the pointer passes over a control on the manipulator, locate highlight the control to show that it's a live, functional control.

Grab phase—Provide selected feedback if there is no additional choice to make; otherwise provide choice feedback. Provide guide feedback as appropriate to facilitate user interaction.

Drag phase—If the user was presented with a choice in the grab phase, resolve it when the user begins the drag, and replace the choice feedback with selected feedback.

Release phase—Return the manipulator to its neutral state.

Use clearly distinguishable feedback styles as follows:

Provide neutral feedback using a style that stands out from the scene; for example, use the color green or white.

Provide locate highlight for manipulator controls. That is, the controls brighten (often to an orange color) as the pointer passes over them.

Provide selected feedback using a style that stands out strongly; for example, use the color yellow.

Provide choice feedback using a style that stands out, but not as strongly as selection feedback; for example, use the color orange.

Provide guide feedback using a style that recedes but is distinct from the other styles; for example, use the color purple.

Provide continuous feedback on the status of an object while the user is manipulating it. For example, as the user translates an object, the object should move in the scene in a smooth and continuous fashion to keep the user updated on the location of the object. Use adaptive rendering if necessary.

Make commonly used and critical manipulation techniques immediately available on the manipulator via the left mouse button. Make less commonly used techniques available on a secondary level, for example, though modifier keys used in conjunction with the left mouse button.

Decide which manipulators to display by default based on the functional requirements of your users and their most common tasks.

Allow users to change which subset of manipulators are currently displayed. At a minimum, allow users to specify this subset using entries in the Edit menu.

Use the standard translation manipulator either alone or in combination with the other standard manipulators. This manipulator is a set of translation planes arranged to define a bounding box around the object.

Allow users to perform translation in the planes of the object's bounding box. These planes may or may not be aligned with the world (scene) coordinate space.

Don't allow users to translate objects that are part of a scene into unusable locations, such as behind the camera or so far back along the z axis that they vanish from view.

Provide planar translation as the default translation method (see Table 15-2).

Provide access to constrained translation along only one axis of a plane (see Table 15-3).

Provide access to axial (constrained) translation along the normal to a plane (see Table 15-4).

Allow users to switch from planar translation to constrained translation and back at any point in a translation. For example, if the user is performing planar translation by dragging a translation plane and then presses the <Shift> key, switch to axial translation along the plane until the <Shift> key is released.

Display the appropriate translation feedback as the user switches between unconstrained and constrained translation.

Don't allow users to select objects or controls through the translation planes.

Use the standard rotation manipulator either alone or in combination with the other standard manipulators. This manipulator is a set of handles that emanate from the center of rotation. Typically, the default center of rotation is the center of the object (the center of the object's bounding box).

Provide constrained rotation around an axis as the default rotation method (see Table 15-5).

Provide access to free rotation around a point (see Table 15-6).

Allow users to switch between constrained and free rotation at any point in a rotation. For example, if the user is performing constrained rotation by dragging along a ring and then presses the <Shift> key, switch to free rotation and interpret pointer movements as following the virtual trackball until the <Shift> key is released.

As the user switches between constrained and free rotation, display the appropriate rotation feedback. For example, if the user is performing free rotation and then releases the <Shift> key, switch to constrained rotation and display the appropriate rotation feedback. Determine the direction and axis for rotation based on the next pointer movement. Once the direction and axis have been determined, display the appropriate arrow and ring feedback for this direction and remove the virtual trackball.

Use the standard scaling manipulator either alone or in combination with the other standard manipulators. The manipulator consists of cube-shaped handles at the vertices of the bounding box.

Scale objects around the center of scaling, by default the center of the object (the center of the object's bounding box).

Provide uniform scaling as the default scaling method (see Table 15-7).

Provide access to axial scaling (stretching) as defined in Table 15-8.

Allow the user to switch between uniform and axial scaling at any point in a scaling operation. For example, if the user is performing axial scaling then releases the <Shift> key, switch to uniform scaling.

As the user switches between uniform and axial scaling, display the appropriate scaling feedback. For example, if the user is performing uniform scaling then presses the <Shift> key, switch to axial scaling and display the appropriate scaling feedback. Determine the single axis for stretching based on the next pointer movement. Once this axis has been determined, remove the two axes that were not selected and display the selected axis until the <Shift> key is released.

Allow users to perform uniform scaling around a specific corner as an alternative to scaling around the center of scaling (see Table 15-9).

Allow users to perform axial scaling around a specific side of the object's bounding box as an alternative to axial scaling around the center of scaling (see Table 15-10).

Allow the user to switch between scaling around a corner or side and scaling around the center of scaling at any time during a scaling operation. For example, if the user is performing uniform scaling around the center of scaling then presses the <Ctrl> key, switch to scaling around the corner opposite to the selected handle.

As the user switches between scaling around a corner or side and scaling around the center of scaling, display the appropriate feedback. For example, if the user is performing uniform scaling around a corner then releases the <Ctrl> key, switch to scaling around the center of scaling and display the appropriate guide feedback for this type of scaling.

If necessary, allow users to change the center of rotation and scaling using the standard rotation manipulator.

As users move the center of rotation and scaling, make sure that they can always identify the current center.

Allow users to change the center of rotation and scaling along a plane (see Table 15-11).

Allow users to change the center of rotation and scaling along an axis (see Table 15-12).

At any time while dragging a rotation handle, allow users to switch among constrained rotation, free rotation, changing the center of rotation and scaling along a plane, and changing the center of rotation and scaling along an axis. For example, if the user is performing constrained rotation then presses the <Ctrl> and <Shift> keys, switch to changing the center of rotation and scaling along an axis.

As the user switches among constrained rotation, free rotation, changing the center of rotation and scaling along a plane, and changing the center of rotation and scaling along an axis, display the appropriate feedback. For example, if the user is moving the center of rotation and scaling along a plane then presses the <Shift> key, switch to moving this center along an axis and display the appropriate feedback. Determine the single axis for movement based on the next pointer movement. Once this axis has been determined, remove the axis that was not selected and display the selected axis until the <Shift> key is released.

Assign one object as the key object for the manipulations. Typically, only the lead object displays the manipulators so this object is by default the key object. If your application instead displays manipulators on all selected objects, the object associated with the manipulator the user is currently interacting with is the key object.

For translation, translate all selected objects along the chosen translation plane for the key object, regardless of the orientation of the other selected objects. Don't change the relative positional relationships of the selected objects.

For rotation, rotate all selected objects around the center of rotation for the key object.

For uniform scaling, scale all selected objects the same amount as the key object and about the same center of scaling as the key object.

For axial scaling (stretching), scale only the key object (the object being manipulated) rather than all selected objects. This prevents shearing of objects that are not aligned with the key object.