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
expressive interfaces can command
combinations of actions not anticipated by the designer of the
program, but which nevertheless give the user useful and consistent
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.
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.
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
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.