January + February 2008
system should not be more complex than your present needs,
and by allowing the system to
increase its power incrementally,
the dream of providing products
that are truly simple initially can
be achieved, without their being
made to merely look simple, and
without impairing their flexibility,” he wrote.
My father also discussed
the conflict between seamless
user tasks and divided applications: “Instead of a computer’s
software being viewed as an
operating system and a set of
applications, then, the humane
interface views the software
as a set of commands.” That is,
functionality should be learned
on an as-needed basis, and be
available anywhere in the system,
regardless of the dividing lines
between the individual applications. Applications interfere with
the idea of as-needed functionality. The learning curve for each
application can be overcome with
use, but if we need to use any
additional piece of functionality
not provided in our main application, we must learn an entire
other application that provides it.
This makes a simple task such as
editing a document with pictures
unnecessarily difficult.
I’ve tried to follow through on
these ideas in my own work and
to design an interface system
that works beyond the boundaries of an individual application.
The challenge is that the current
software economy is tied to the
concept of applications. Disparate
applications aren’t going to disappear. Providing services, however, allows us to granulate that
software economy. If you don’t
need all of the functionality of
Photoshop, you can just buy the
photo-editing features you need
as a service. Instead of arguing
for the abolition of applications,
we can champion services with a
universal way of accessing them.
That way, we can snap our fingers
and have the functionality we
need, regardless of the application we happen to be using. This
shift also reframes the interface
challenge, which then becomes
this: If all functionality is available to us anywhere, at any time,
how do we tell the computer
which particular piece of functionality we want?
We’re going to need a universal
way to access those thousands of
possible services we might want
to perform on our selected data—
from calculating the sum of the
values, to performing a Google
search on the text, to changing
the size at which it is displayed.
Current paradigms for accessing
this functionality don’t scale to
how we really work—i.e., across
applications, not within them.
Imagine grafting together the
endless menus for PowerPoint,
Mathematica, Firefox, and
Photoshop. Certainly, there would
be some overlap, but the result
would still be a Medusa’s head of
seething submenus. It would be
laborious to find anything in such
a monstrosity, and inefficient
to manually select a menu even
if we knew where to find it. We
headed toward graphical menus
initially because they made all
options visible, by allowing recognition of an option instead of
forcing the recollection of an
option. Jef Raskin and the rest of
the Macintosh team found that
menus worked well. In hindsight,
they worked well because of
the limited number of available
options.
With increasing scale, the
menu metaphor falls short.
While the recognition solution
can work in a single application
with a restricted set of options, it
fails when we look at real tasks
that cross application boundaries. For example, the argument
that menus provide visibility and
findability breaks down when
applied at a large scale because
they become slow to learn and
use. Similarly, keyboard shortcuts—patches meant to increase
the speed of menus—also do not
scale. The keyboard features a
finite number of keys and even
fewer mnemonic matchings of
keys to functionality.
Icons fare worse than menus
and keyboard shortcuts. The
abstract concepts inherent to
detailed functionality are difficult
to represent visually. Microsoft
Word attempts to use icons to
represent some of the basic functionality of text processing, but
this method doesn’t work out
well. Can you figure out what
each of these icons does?
Even if you can recognize a few
of the examples, your recognition
is learned. Those icons, no matter
how self-evident Microsoft would
like them to be, require language
(in the form of tooltips) to actually explain what they do. If
simple text-formatting operations
fail so greatly, how can icons be
designed to express the full range
of functionality that services
provide? And how would we page
through that giant lexicon of
icons to quickly to find the one
we’re looking for?
The “window, icon, menu,
pointing-device” or WIMP paradigm, has its limits, and these
limits are now growing clearer as
the complexity of modern computing unfolds.
The Linguistic Command