Aucbvax.2447
fa.works
utzoo!decvax!ucbvax!works
Sun Jul 26 21:50:03 1981
mundane systems
>From JWALKER@BBNA Sun Jul 26 21:46:04 1981
I have to voice my strong support of Joe in his message against
"mundane" systems. The original message advocating mundane
systems used an analogy of a car -- you choose a boring automatic
because you don't care what wonderful things you might be able to
do with a standard transmission. Let's point out a few things
that make this analogy somewhat less applicable to the current
case (system/software design).
Notice that with the kind of technology people are accustomed to,
once you choose one (automatic), you can't have the other
(standard). (This can lead people into defending their choices
with more reasons than they originally had for making the choice.
Some psychologists talk about related phenomena under "cognitive
dissonance".) With the kind of technology we use, you can either
follow the same design philosophy -- make things in a limited
number of flavors and make people choose -- or you can design to
support redesign by the purchaser. Surely with the flexibility
of computers behind us, we can do at least as well as the kludge
in the car that chooses 4, 6, or 8 cylinders depending on load,
mileage goals, or whatever.
People don't like the illusion of choice nearly as much as they
like having the choice. The reason that so far we don't find
ordinary people looking for software modifications is that they
don't expect to be able to have them. (The old technology of
course has molded people's expectations about the new one.)
While I am on the car analogy... I hear a lot about providing
systems for people who want to be able to use a computer without
any training or practice. How many people do you know who wanted
to just jump in and drive a car without any training or practice?
(Not many!) Why do you suppose that difference exists? Consider
that a car has one primary purpose -- transportation. They all
have standard components and operating procedures. Even people
who have never driven know a lot about cars, for example, that
they have a little slot where you put a key and turn it in order
to start the engine. The point is that cars are simpler in
purpose and operation than computers, yet people don't expect to
just hop in and drive away until they know from cars. Maybe the
real lessons in this analogy come from considering training,
learning, and transfer issues.
The ideal way to provide software is to offer something that a
new user who knows about the application of the software (for
example, editing, drawing) can start using it with the help of a
good summary and maybe 15 minutes of explanation. The next
hurdle to pass is in discovering that things can in fact be
changed. A well-designed and documented program helps you make
this discovery and then provides good support tools to help you
find out what it is possible to change and how best to do it.
Jan
(JWalker@BBNA)
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
of
http://communication.ucsd.edu/A-News/
This Usenet Oldnews Archive
article may be copied and distributed freely, provided:
1. There is no money collected for the text(s) of the articles.
2. The following notice remains appended to each copy:
The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996
Bruce Jones, Henry Spencer, David Wiseman.
