Your application should supply feedback to users so that they know it's working and what it's doing. This chapter covers the following topics:
“Types of Feedback” briefly describes various types of feedback users expect your application to provide; it also tells you where to look in this guide for more information about each type of feedback.
“Pointer Shapes and Colors” discusses when to use each of the standard pointer shapes and provides guidelines for designing your own pointer shapes.
Your application should provide feedback to users using the techniques described in this section. Note that most of these techniques are covered in other chapters of this guide, as indicated; these other chapters also include the explicit checklist guidelines to follow, so they're not repeated here. Topics include:
Appropriate desktop icons for your application's executable and data files allow users to readily identify your application, files that were created using your application, and the current state of the application (that is, running or not running). Design executable and data file icons to provide this sort of graphic feedback, as discussed in Chapter 2, “Icons.”
The IRIX Interactive Desktop look includes graphic modifications that were made to standard IRIS IM in order to improve the level of user feedback. For instance, locate highlight visually indicates which components are live functional objects and which are passive graphics. In addition, scrollbars were redesigned to keep track of their initial positions, and radio buttons and checkboxes show their state more emphatically. Your application should use the IRIX Interactive Desktop look, which is discussed in “The IRIX Interactive Desktop Look: Graphic Features and Schemes” in Chapter 3.
Users expect the pointer to change shape to reflect the current state of the window—for example, when the application is busy processing and can't accept keyboard or mouse input, the pointer changes to a watch. Guidelines for pointer shapes are discussed later in this chapter, in “Pointer Shapes and Colors.”
As users select data in a window, highlight that data to show what's included in the current selection. The data should remain highlighted even when the window isn't the currently active window. See “Highlighting a Selection” in Chapter 7 for more information about highlighting selections.
As users set particular values in components such as radio buttons, check boxes, lists, and option menus, your application should always indicate the current values so that the user knows what they are. For example, the Language control panel highlights the current values for “Locations” and “Keyboards” in the two corresponding lists. Radio buttons, checkboxes, lists, and option menus are discussed in more detail in Chapter 9, “Controls.”
Even if users can change values or data without using an explicitly provided component, your application should still endeavor to display the current information. For instance, users can change the file hierarchy using the shell; if your application displays information affected by such a change (such as a directory view), the display should update dynamically as the user makes the change. If it's impossible or if it would have a significantly adverse effect on your application's performance to make the display dynamic, choose a design that looks static. For example, you might use label text, which looks like it's a permanent part of the background, rather than text fields, which look like they should be updated constantly. The desktop uses this strategy for the “business cards” that are displayed when a user double-clicks a person icon.
When component settings apply to a specific object, the displayed components should reflect the values for the currently selected object (if there is one). For example, if you select some text in an IRIS Showcase file, the “Font Family,” “Font Size,” Bold/Italic/Underline, and color options in the Master Gizmo are updated to display the characteristics of the selected text.
In addition to providing immediate graphic feedback through your application's icons, components, and pointers, provide textual messages that describe your application's status. Keep in mind that by default the window manager for the IRIX Interactive Desktop, 4Dwm, sends stdout and stderr messages to the Console window, which users typically keep minimized. (Users can choose to have stderr messages appear in a dialog box by using the Desktop Settings control panel available from the Desktop->Customize cascading menu in the Toolchest, and they can of course un-minimize the Console window.) Because of these default settings, you can't be sure that users will notice messages sent to stdout and stderr; therefore, use dialogs or status areas in your application instead.
In particular, use dialogs to provide warning messages, error messages, and work-in-progress feedback, as discussed in Chapter 10, “Dialogs.” Also define an area on primary windows for status messages in the cases discussed in “Status Areas in Primary Windows” in Chapter 6. Finally, change the label (or possibly the image) of your application's minimized window when appropriate to provide feedback; “Minimized Windows” in Chapter 3 discusses when to use this technique.
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.
Your application should use different pointer shapes to indicate when it's busy or in a particular mode, or when one of its windows isn't accepting input. This section describes:
The OSF/Motif Style Guide defines several standard pointer shapes. Your application should use these standard shapes for the purposes described in Table 11-1; the table also notes any additions and exceptions to the OSF/Motif policies for using these pointers. If your application requires functionality beyond what's described below, design your own new pointers, as described in “Designing New Pointer Shapes,” rather than extend the functionality of these standard ones.
Table 11-1. Standard Pointer Shapes and Colors
Pointer | Name | Purpose | Additions and Exceptions to OSF/Motif Style | |
|---|---|---|---|---|
| General-purpose pointer, used for selecting data, setting the values of controls, and initiating actions (for example, by clicking on a button). | In the IRIX Interactive Desktop environment, this pointer should be red with a white outline (rather than black with a white outline) so that it's easier to see against most typical user-customized background colors and patterns. | ||
| Indicates that a menu is being displayed and that the application is waiting for the user to select a menu item or remove the menu. | This is the default pointer when a menu is pulled down from a menu bar, popped up from the right mouse button, or displayed from an option menu button. (See Chapter 8, “Menus,” for details on the various types of menus.) | ||
| Indicates that an operation is in progress in the area, and that all mouse-button and keyboard events are ignored in the area. | Use this pointer instead of the hourglass because the watch is a more universally recognized symbol for time. Also, use this pointer if you estimate that the operation generally takes more than 3 seconds. (Note that you might have to choose one of several different platforms as your standard for estimating times of operations.) For less than 3 seconds, maintain the current pointer shape to avoid distracting users. For more than 5 seconds, use a work-in-progress dialog in addition to the watch pointer. (See Chapter 10, “Dialogs.”) | ||
| Indicates that your application is in
text-editing mode. (Note that this | OSF/Motif allows this pointer to be used for indicating that the pointer is over an editable text component in a window that uses implicit focus. Since you should use explicit focus when moving within a window, you don't need the I-beam pointer for this purpose. However, you can use it to indicate that your application is in text-editing mode; this might be useful if your application can edit both text and graphics, for example. | ||
| Indicates that the user is in context-sensitive help mode and needs to click on an area of the screen to specify the exact help information requested. | none | ||
| Used to make fine position selections; for example, to indicate a pixel to fill in a drawing program, or to select the endpoint of a line. | none | ||
| Indicates positions when resizing an area. | none | ||
| Indicates that either a move operation or a resize operation (before the resize direction has been determined) is in progress. | none |
The OSF/Motif Style Guide defines a few pointers that you shouldn't need to use:
OSF/Motif also defines a caution pointer to be used for indicating that all mouse and keyboard events are ignored in the area until the user performs an expected action in a primary modal or application modal dialog. You can use this pointer in your application if you want; note that many IRIX Interactive Desktop applications don't use it because at this time there's no automatic support for it in IRIS IM. (See “Dialog Modes” in Chapter 10 for more information on primary and application modal dialogs.)
You might find it necessary to design new pointer shapes that represent functionality specific to your application, particularly if your application has modes. In these cases, the pointer shape can be used to indicate the current mode. For example, a paint program typically has different tools or modes that the user can select; the pointer shape might resemble a specific brush style, spray paint can, eraser, or I-beam pointer, depending on the tool selected. When you design new pointer shapes, follow the guidelines listed in the reference page on Pointer Shapes in the OSF/Motif Style Guide: create a pointer shape that gives a hint about its purpose and is easy to see, avoid shapes that create visual clutter, and make its hotspot easy to locate. (The hotspot identifies where mouse actions occur.)
When deciding which pointers to use in your application . . .
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.
When designing new pointer shapes . . .
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.