Graphics Reference
In-Depth Information
with a pen and tablet (for which much of the design is optimized), the interface
supports such a wide array of operations relatively smoothly that it's become the
dominant tool in its domain. By contrast, simpler image-editing programs like the
Microsoft Office Picture Manager are easy to learn and use instantly, but this is in
part because they support such a small range of operations. To be clear: A complex
interface may be a necessity for expressive power, but not every complex interface
is a good one. A common evolution pattern is
accretion,
in which new features
are added to a program over time, each one added in the place that seems most
convenient at that moment. The end result is a complex interface in which there's
little logical organization at all, and the resultant program may be difficult to use,
even for experts who use it every day.
These examples, though simple, make it clear that the testing of a user inter-
face may depend on a larger context—not just the interaction process or device,
but the entire user experience, which bundles the GUI together with its interaction
and with the particular software functionality, and perhaps even with the context
of use (shopping mall versus automobile versus office).
Before we leave the topic of complexity versus learnability, there are two more
relevant aspects of GUIs. First, there's a general principle that recognition is faster
than recall: It's easier to recognize a “yield” sign in the United States than to say
whether its triangular shape points up or down, for instance. In the case of GUIs,
this means that using familiar names and icons can help a new user make sense
of a new interface almost instantly. For the same reason, placing menu items in
expected places is generally a good idea. Second, you should, if possible, design
a
gentle slope interface
[HKS
+
97], one in which it's easy to do something right
away, but in which there's a smooth transition from novice to power user. Menus
that display, next to each item, a keystroke that invokes that menu item are an
example. Things like
tool trays,
which are buttons that can either be clicked (to
invoke a standard operation) or be expanded into multiple buttons (to allow selec-
tion of closely related operations), provide easy access to richer functionality. (For
example, a drawing program might have a button that selects line-drawing mode.
When its tool tray is expanded, there might be options to draw solid, dotted, or
dashed lines.) Such gentle slope interfaces provide a pathway between ease of
initial use and ease of expert use.
As with software engineering, there are multiple design approaches that all
share a common trait of needing to be user-centered, that is, to know the client
and the domain. Two dominant ones are (a) a modified waterfall model
1
for soft-
ware engineering, and (b) rapid prototyping, in which the evolving interface is
always functional, but is gradually adapted from minimal function (clicking a but-
ton generates a “button clicked” message) to sophisticated interaction sequences.
Some mixture of both of these processes is typical in the development of new
kinds of interaction.
Abstraction boundaries can help you develop an interface effectively. These
boundaries are the places where substitutions may make sense, whereas within a
particular layer, there may be dependencies that make substitution less feasible.
For instance, we may have a design in which a mouse is used to point at various
1. In the waterfall model, requirements determine design; the design determines the
implementation. After implementation, the system is verified, and then maintained.
Each step is completed before the next. In the modified waterfall, there is substantial
feedback at all levels.
