Evaluating Interface Designs
All these interface styles survive because they are adapted for
different jobs. When making design decisions about a project, it's
important to know how to pick a style (or combine styles) that will be
appropriate to your application and your user population.
We will use five basic metrics to categorize interface
styles: concision,
expressiveness, ease,
transparency
, and
scriptability. We've already used some of
these terms earlier in this book in ways that were preparation for
defining them here. They are comparatives, not absolutes; they have
to be evaluated with respect to a particular problem domain and with
some knowledge of the users' skill base. Nevertheless, they will help
organize our thinking in useful ways.
A program interface is ‘concise’ when the length and
complexity of actions required to do a transaction with it has a low
upper bound (the measurement might be in keystrokes, gestures, or
seconds of attention required). Concise interfaces pack a lot of
leverage into a relatively few bits or state changes.
Interfaces are ‘expressive’ when they can readily be
used to command a wide variety of actions. The
most
expressive interfaces can command
combinations of actions not anticipated by the designer of the
program, but which nevertheless give the user useful and consistent
results.
The difference between concision and expressiveness is an
important one. Consider two different ways of entering text: from a
keyboard, or by picking characters from a screen display with mouse
clicks. These have equal expressiveness, but the keyboard is more
concise (as we can easily verify by comparing average text-entry
speeds). On the other hand, consider two dialects of the same
programming language, one with a complex-number type and one not.
Within the problem domain they have in common, their concision will
be identical; but for a mathematician or electrical engineer, the
dialect with complex numbers will be much more expressive.
The ‘ease’ of an interface is inversely proportional
to the mnemonic load it puts on the user — how many things
(commands, gestures, primitive concepts) the user has to remember
specifically to support using that interface. Programming languages
have a high mnemonic load and low ease; menus and well-labeled
on-screen buttons are simpler.
Recall that we devoted an entire earlier chapter to
‘transparency’. In that chapter we touched on the idea of
interface transparency, and gave the
audacity audio
editor
as one superb example of it. But we were
then much more interested in transparency of a different kind, one
that relates to the structure of code rather than of user interfaces.
We therefore described UI transparency in terms of its effect (nothing
obtrudes between the user and the problem domain) rather than the
specific features of design that produce it. Now it's time to zero in
on these.
The ‘transparency’ of an interface is how few things
the user has to remember about the state of his problem, his data, or
his program while
using
the interface. An interface has high
transparency when it naturally presents intermediate results, useful
feedback, and error notifications on the effects of a user's
actions. So-called WYSIWYG (What You See Is What You Get) interfaces
are intended to maximize transparency, but sometimes backfire —
especially by presenting an over-simplified view of the
domain.
The related concept of discoverability applies to interface
design, as well. A discoverable interface provides the user with
assistance in learning it, such as a greeting message pointing to
context-sensitive help, or explanatory balloon popups. Though
discoverability has to be implemented in rather different ways
for each of the interface styles we shall consider, the degree to
which it is achievable is largely independent of interface style.
Thus, we shall not use it as a metric in this discussion.
Note that transparency of code and design does not automatically imply
transparency of interface, or vice versa! It is all too easy to point
to code that has one but not the other.
The ‘scriptability’ of an interface is the ease with
which it can be manipulated by other programs (e.g., through the IPC
mechanisms discussed in Chapter7). Scriptable programs are readily
usable as components by other programs, reducing the need for costly
custom coding and making it relatively easy to automate repetitive
tasks.
That last point — automating repetitive tasks —
deserves more attention than it usually gets. Unix programmers,
administrators, and users develop a habit of thinking through the
routine procedures they use, then packaging them so they no longer
have to manually execute or even think about them any more. This
habit depends on scriptable interfaces. It is a quiet but tremendous
productivity booster not available in most other software
environments.
It will be useful to bear in mind that humans and computer
programs have very different cost functions with respect to these
metrics. So do novice and expert human users in a particular problem
domain. We'll explore how the tradeoffs between them change for
different user populations.
