Hmmm

Steve steve at advocate.net
Mon May 17 01:26:13 PDT 1999


x-no-archive: yes

=========================

Book Review -

The Inmates Are Running the Asylum: Why High Tech Products Drive
Us Crazy and How To Restore The Sanity, by Alan Cooper

Elias Crim
IntellectualCapital.com


Anyone who has ever had the impulse to smash an annoying piece of
electronic equipment will be happy to learn that the "inmates"
referred to in the title of Alan Cooper's new book are actually
software programmers. And they are in control, lamentably, of one of
the most important business functions in the world economy, namely
the design and production of software. So argues Cooper, and
persuasively at that.

Given that almost every tool we put our hands to these days has a
chip somewhere in it, Cooper believes this fact of user- hostility is
hugely unproductive and even on occasion fatal. Cooper, who is known
in the industry as the father of Visual Basic, argues that there is a
reason for all the pain, literal and figurative, that software causes
us. And that is in the nature of the software creation process
itself.

Software design must be distinguished from programming, just as
architecture is different from construction engineering. The design
process is aimed at reaching a particular goal, whereas programming
is about implementing the design. A house constructed without an
architectural plan might be cheap to build but it might also be
difficult to live in.

The problems with letting programmers take over significant design
responsibilities, argues Cooper, are numerous. First, programmers are
typically people absorbed in the engineering process and want it (not
the user's experience of the software) to be easy. Asking them to add
intelligent interface design as a last stage of the process both
lengthens the development process (against enormous pressures in the
other direction) and proposes a key step too late in the process for
it to be implemented. 

Second, most software involves a high degree of "cognitive friction,"
a term coined by Cooper. That is, our experiences using most software
make us either an apologist (boasting about how difficult a program
was to learn) or a survivor. Cooper calls this survivor mentality the
Stockholm syndrome: we hostages tend to fall in love with our captors
(the programmers). The result, as Cooper entertainingly describes, is
"weird, sullen software" produced by (typically) weird, sullen
people. 

In truth, software programs are as malleable as human speech: they
can be rude or friendly. There is no reason why we cannot make our
programs more like us, rather than asking us to imitate our machines.

Programmers do not really mean any ill: they are simply engineers who
often answer the request for more user-friendliness in the way Bill
Gates supposedly once did: By offering, in effect, to stamp the
phrase "user-friendly" on the outside of the box.

This closed mentality is due to the all-encompassing demands of the
programming task itself. All his or her attention is focused on the
nature and needs of the computer, rather than the nature and needs of
the user. The programmer consciously designs the code inside the
program (what the program does), all the while almost unconsciously
designing the program's interaction with the users (how the program
behaves).

When programmers think about us at all, we software users are
typically viewed as at one of two extremes, Cooper claims. We are
either complete novices (as the product marketers quickly assume) or
else we are "power users" (as the programmers prefer to see us). The
term Cooper suggests as closest to reality would call us "perpetual
intermediates."

The high-tech industries are in denial of a simple fact: our
technology tools are too hard to use. The engineers who make these
tools see their power and their rich combination of functions and
features. They do not see how difficult to use most of these tools
are nor do they see that they are violating the #1 goal of most
computers users, as Cooper puts it -- not to feel stupid.

We get that feeling because many software tools are built with the
ejection-seat lever mixed in with the everyday functions. As a
result, a single errant keystroke can have an impact out of all
proportion to reality. That is because we rarely design programs with
common sense -- i.e. ones that are designed to know when we are
asking for an unusual or outlandish result with potentially
significant consequences.

How did we get here? The main reason is that, despite appearances,
business executives are not really in charge of the software
development process: the engineers run the asylum. And with software,
typically nothing is visible until it is done, meaning that any
second-guessing by non-programmers is too late to be effective.

So what's the alternative? Cooper offers a design-directed
methodology that claims to produce "polite" software. This slightly
comic term turns out to mean something important, however. Polite
software does not forget things (such as what you were doing with it
on the last occasion you used it), nor does it blame the user
(forcing you to start over a sequential process because of one
misstep). In other words, the emphasis is on how the software behaves
toward, communicates with, and informs the user, not just on what the
software does for the user. 





* * * * * * * * * * * * * *  From the Listowner  * * * * * * * * * * * *
.	To unsubscribe from this list, send a message to:
majordomo at scn.org		In the body of the message, type:
unsubscribe scn
==== Messages posted on this list are also available on the web at: ====
* * * * * * *     http://www.scn.org/volunteers/scn-l/     * * * * * * *



More information about the scn mailing list