Responsive Enabling
MATLAB's Curve-Fitting Tool | |
What: |
Starting with a UI that's mostly disabled, guide a user through a series of steps by enabling more of the UI as each step is done. |
|
The UI walks the user through a complex task step-by-step, perhaps because he is computer-naive, or because the task is rarely done (as in a Wizard). But you don't want to force the user to go page by page at each step -- you'd like to keep the whole interface on one page. Furthermore, you want to keep the interface stable; you'd rather not dynamically reconfigure the page at each step, as you would with Responsive Disclosure. |
Why: |
Like Responsive Disclosure, this pattern takes advantage of the
malleability of computer displays to guide the user through the
interface interactively. The user thus gets a chance to form a
correct mental model about cause and effect. The UI itself tells
him the possible consequences of some choices: if I turn this
checkbox on, then I have to fill in these four text fields that
just got enabled.
Furthermore, the user can't do things that would get him into trouble, as the UI has "locked out" those actions by disabling them. Unnecessary error messages are thus avoided. |
How: |
In some applications, such as the GUI in the example below, most
actions on the UI start off disabled -- only the actions relevant
to the user's first step are available. As the user makes choices
and performs actions, more disabled items should be enabled and
brought into play. In this respect it's remarkably like
Responsive Disclosure,
since the machine specifies a particular sequence through the
interface.
A similar, less sequence-based technique is much more common in desktop UIs. As the user does things on the interface, certain actions or settings become irrelevant or impossible, and those actions get disabled until the user does whatever is necessary to re-enable them. Overall sequence isn't as important. See the Mac example below. Whenever possible, put the disabled items in close proximity to whatever enables them. That helps users find the magic enabling operation and understand the relationship between it and the disabled items. This pattern's two examples place that button (or checkbox, respectively) at the top and left of the disabled items, which follows the natural top-to-bottom and left-to-right "flow" of the interface. When you design an interface that uses Responsive Enabling or Responsive Disclosure, be sure to disable only things that can't or shouldn't be used. Be wary of overconstraining the user's experience in an attempt to make the interface friendlier or easier to understand. When you decide what to disable, carefully consider each device: is it disabled for a really good reason? Can you offer that functionality all the time? As usual, usability testing gives users a chance to tell you that you've done it wrong. Another usability problem to avoid is what Bruce Tognazzini calls the "Mysteriously Dimmed Menu Items" -- when the design offers no clue as to why a given device is disabled. Again, minimize the set of things that have to be disabled, especially when they're far away from whatever operation turns them on. Also, somewhere on the interface or in its help system, tell the user what causes a feature to be unavailable. Again, this whole problem can be avoided more easily when the disabled controls aren't menus on a menu bar, but instead sit out on the main UI, colocated with whatever switches them on. Spatial proximity is an important clue. |
Examples: |
|
Mac OS X System Preferences This is a typical example of disabling based on a binary choice: should OS X show the date and time on the menu bar, or not? If the user chooses to show it, then she gets a panoply of choices about how it ought to be shown. If not, the choices are irrelevant, so they're disabled. This behavior (plus the indenting of the options under the checkbox) tells the user that these choices affect the date/time display which the checkbox toggled -- and nothing else. |
|