| JavaTM Look and Feel Design Guidelines: Advanced Topics > Part I: General Topics > 4: Behavior > Modes | |
In some applications, the effects of a user's actions differ in different situations, or modes, defined in the application. Often, a mode lets users perform only certain actions. For example, in one mode of a drawing application, clicking one object after another might select those objects. In a different mode of the same application, clicking one object after another might draw a line between those objects. In other words, the same action would have a different effect in different modes.
By limiting users' potential actions, modes make it easier for software developers to translate those actions into code. Applications with modes can be hard to use because:
Sometimes, modes can help users, typically by preventing users from accidentally performing unwanted actions--for example, activating a command button in a graphical user interface while trying to lay out the interface.
Avoid defining modes in your application, especially if users are likely to
be hurried, as when responding to alarms.
A modal secondary window prevents users from interacting with other windows of an application until that modal window is closed. (In contrast, a modeless secondary window does not prevent users from interacting with that application.) Among the types of modal secondary windows are modal dialog boxes and modal alert boxes. Chapter 8 of Java Look and Feel Design Guidelines, 2d ed. describes modal and modeless dialog boxes as well as alert boxes, which can also be modal or modeless.
Modal secondary windows can make it harder for users to complete their current task. For example, a modal dialog box prevents users from copying information from outside that dialog box--even if the information is needed to fill in fields of the dialog box.
Use modeless secondary windows whenever possible. If your application uses modal secondary windows, keep them in front of the application's other windows. (An application's users can override this behavior by setting preferences in the operating system.)
Use a modal dialog box only if a user might put the application in an
inconsistent state that the user cannot easily remedy. (A user might put the
application in an inconsistent state by making changes in other windows while
the dialog box is open.)
Use a modal alert box only to alert users of a condition that requires user
input before the application can proceed. For example, create a modal alert box
to verify that a user wants to perform an action that will have irreversible
consequences.
Some applications, such as graphics applications, have tool palettes--internal utility windows whose buttons enable users to choose a tool, such as a paint brush, from a set of tools. Typically, each tool corresponds to a particular mode. Clicking a button in a tool palette changes the current mode and, as a result, changes the meaning of mouse operations--for example, causing each mouse click to insert an object instead of selecting one.
In tool palettes, a mode can stay in effect until a user performs the next action or until a user activates a different mode.
If a user chooses a tool from a tool palette, causing a different mode to
take effect, change the pointer's shape to indicate which tool and mode are in
effect. For as long as that tool's mode is in effect, visually emphasize the tool's
button in the palette by displaying it with the pressed appearance. (For
information about command buttons with the pressed, available, or unavailable
appearance, see Chapter 10 in Java Look and Feel Design Guidelines, 2d ed.)
Some applications have application-wide modes, which change the effect of users' actions throughout the application. An example of an application-wide mode is the Edit mode or Run mode of a typical GUI builder. The same mouse actions that modify controls in Edit mode, activate controls in Run mode. For example, clicking a Print button in Edit mode would select that button so that the user could resize or otherwise modify it. Clicking the same Print button in Run mode would issue a command to print a document.
If your application has application-wide modes, provide more than one
way for users to change from one to another. Examples of ways to change
between application-wide modes include menu items, command buttons, and
keyboard shortcuts. By providing more than one way to change between
modes, you make the modes more accessible.
If your application has application-wide modes, provide visible cues so
that users know which mode is in effect. For example, in a GUI-building
application with an Edit mode and a Run mode, you might display a grid
background only in Edit mode so that users could distinguish it from Run
mode.
| Java Look and Feel Design Guidelines: Advanced Topics.
Copyright 2001. Sun Microsystems, Inc. All Rights Reserved. |
|