From cincy!duke!decvax!utzoo!datamat!rumor Sat Aug  1 23:37:27 PDT 1981
The Truth about UNIX: fa.unix-wizards





                   The truth about Unix:
                The user interface is horrid

                      Donald A. Norman
                  Department of Psychology
                            and
                Program in Cognitive Science
          Center for Human Information Processing
            University of California, San Diego
                 La Jolla, California 92093
                 (to appear in Datamation)

     Unix is a highly touted operating system.  Developed at
the  Bell  Telephone Laboratories and distributed by Western
Electric, it has  become  a  standard  operating  system  in
Universities,  and  it promises to become a standard for the
large micro- mini- systems for  home,  small  business,  and
educational setting.  But for all its virtues as a system --
and it is indeed an elegant system -- Unix is a disaster for
the casual user.  It fails both on the scientific principles
of human engineering and even in just plain   common  sense.
The motto of the designers of Unix towards the user seems to
be "let the user beware."

     If Unix is really to become a general system,  then  it
has got to be fixed.  I urge correction to make the elegance
of the system design be reflected  as  friendliness  towards
the user, especially the casual user.  I have learned to get
along with the vagaries  of  its  user  interface,  but  our
secretarial staff persists only because we insist.  And even
I, a heavy user of computer systems for 20  years  have  had
difficulties:  copying  the old file over the new, transfer-
ring a file into itself  until  the  system  collapsed,  and
removing  all  the  files from a directory simply because an
extra space was typed in the argument string.  In this arti-
cle  I  review  both the faults of Unix and also some of the
principles  of  Cognitive  Engineering  that  could  improve
things,  not just for Unix, but for computer systems in gen-
eral.  But first, the conclusion;  Unix fails several simple
tests.

     Consistency: The command names, language, functions and
          syntax are inconsistent.

     Functionality: The command names, formats,  and  syntax
          seem to have no relationship to their functions.

     Friendliness: Unix is a recluse, hidden from the  user,
          silent  in  operation.   "No news is good news" is
          its motto, but as a result, the  user  can't  tell
          what  state  the system is in, and essentially, is
          completely out of touch with things.

     Cognitive Engineering:  The system does not  understand


                       August 2, 1981






                           - 2 -


          about  normal  folks,  the everyday users of Unix.
          Cognitive capabilities are strained  beyond  their
          limits,  the  lack  of  mnemonic structures places
          large loads of memory, and the lack of interaction
          puts  a strain on one's ability to retain mentally
          exactly what state the system is in at any moment.
          (Get  distracted  at  the  wrong time and you lose
          your place -- and maybe your file.)

What is good about Unix?   The system design, the generality
of  programs,  the  file  structure,  the job structure, the
powerful operating system command  language  (the  "shell").
To  bad  the concern for system design was not matched by an
equal concern for the human interface.



     One of the first things you learn  when  you  start  to
decipher  Unix  is  how  to list the contents of a file onto
your terminal.  Now this sounds straightforward enough,  but
in  Unix even this simple operation has its drawbacks.  Sup-
pose I have a file called "testfile".  I want to see what is
inside  of  it.   How would you design a system to do it?  I
would have written a program that listed the  contents  onto
the  terminal,  perhaps  stopping  every 24 lines if you had
signified that you were on a display terminal with only a 24
line  display.   To  the  designers of Unix, however, such a
solution lacks elegance.  Unix has  no  basic  listing  com-
mand,  but  instead you must use a program meant to do some-
thing else.

     In Unix, if you wanted to list the contents of  a  file
called "HappyDays", you would use the command named "cat":
                       cat HappyDays
Why cat? Why not?  After all, said Humpty Dumpty  to  Alice,
who  is to be the boss, words or us?  "Cat", short for "con-
catenate" as in, take file1 and concatenate  it  with  file2
(yielding  one  file,  with the first part file1, the second
file2) and put the result on the "standard output" (which is
usually the terminal):
                         cat file1 file2
Obvious right?  And if you have only one file, why cat  will
put  it  on  the standard output -- the terminal -- and that
accomplishes the goal (except for those  of  us  with  video
terminals  who  watch  helplessly as the text goes streaming
off the display).

     The Unix designers are rather  fond  of  the  principle
that  special purpose functions can be avoided by clever use
of a small set of system primitives.   Their  philosophy  is
essentially,  don't  make  a special function when the side-
effects of other functions will do what you want.  But there
are several reasons why this philosophy is bad;



                       August 2, 1981






                           - 3 -


     1. A  psychological  principle  is  that  names  should
          reflect  function, else the names for the function
          will be difficult to recall;

     2. Side-effects can be used for virtue,  but  they  can
          also  have  unwarranted  effects.  Thus, if cat is
          used unwisely, it will destroy files (more on this
          in a moment).

     3. Special functions can do nice things for users, such
          as  stop  at  the  end  of screens, or put on page
          headings,  or  transform  non-printing  characters
          into  printing  ones, or get rid of underlines for
          terminals that can't do that.

Cat, of course, won't stop at terminal or  page  boundaries,
because  if it did that, why that would disrupt the concate-
nation feature.  But still, isn't it elegant to use cat  for
listing?   Who  needs  a  print or a list command.  You mean
"cat" isn't how you would abbreviate  concatenate?  gee,  it
seems so obvious to us.  Just like
   function             Unix command name
c compiler                      cc
change working directory        chdir  (cd in Berkeley Unix)
change password                 passwd
concatenate                     cat
copy                            cp
date                            date
echo                            echo
editor                          ed
link                            ln
move                            mv
remove                          rm
search file for pattern         grep

Notice the lack of consistency in forming the  command  name
from  the  function.   Some  names  are formed  by using the
first two consonants of the function name, unless it is  the
editor  which  is  abbreviated "ed" and concatenate which is
"cat" or "date" or "echo" which are not abbreviated at  all.
Note  how  useful those 2 letter abbreviations are.  See how
much time and effort is saved typing only 2 letters  instead
of  --  heaven  forbid  --  4  letters.  So what is a little
inconsistency among friends, especially when  you  can  save
almost 400 milliseconds per command.

     Similar statements apply  to  the  names  of  the  file
directories.  Unix is a file oriented system, with hierarch-
ical directory structures, so the directory names  are  very
important.   Thus,  this  paper  is  being written on a file
named      "unix"      and       whose       "path"       is
/csl/norman/papers/CogEngineering/unix.  The name of the top
directory is "/", and csl, norman, papers, and  CogEngineer-
ing  are  the  names  of  directories  hierarchically placed


                       August 2, 1981






                           - 4 -


beneath "/".  Note that the symbol "/" has two meanings: the
name  of  the  top  level  directory  and  the  symbol  that
separates levels of the directories.  This is very difficult
to justify to new users.  And those names: the directory for
"users" and "mount" are called, of course, "usr" and  "mnt."
And  there  are  "bin," "lib," and "tmp." (What mere mortals
might call binary, library, and temp).   Unix loves abbrevi-
ations,  even  when the original name is already very short.
To write "user" as "usr" or "temp" as "tmp" saves an  entire
letter:  a  letter  a day must keep the service person away.
But Unix is inconsistent;  it doesn't abbreviate  everything
as   2  or  3  letter commands.  It keeps "grep" at its full
four letters, when it could have been abbreviated as "gr" or
"gp".  (What  does  grep mean, you may ask.  "Global REgular
expression, Print" --  at  least  that's  the  best  we  can
invent,  the  manual  doesn't  even  try  to  say.  The name
wouldn't matter if grep were something obscure, hardly  ever
used, but in fact it is one of the more powerful, frequently
used string processing commands.  But that takes me from  my
topic.)


     Do I dare tell you about "dsw"?  This also turns out to
be  an important routine.  Suppose you accidentally create a
file whose name has  a non-printing character  in  it.   How
can you remove it?  The command that lists the files on your
directory won't show non-printing characters.   And  if  the
character  is  a space (or worse, a "*"), "rm"  (the program
that removes files) won't accept it.   "dsw"  was  evidently
written  by someone at Bell Labs who felt frustrated by this
problem and hacked up a quick solution.  Dsw  goes  to  each
file  in  your  directory  and asks you to respond  "yes" or
"no," whether to delete the file  or keep it (or  is  it  to
keep it or delete it -- which action does "yes" mean?).  How
do you remember dsw?  What on earth does the name stand for?
The  Unix people won't tell; the manual smiles its wry smile
of the professional programmer and says "The name dsw  is  a
carryover  from the ancient past. Its etymology is amusing."
(The implication, I guess, is that true professionals  never
need  to  use such a program, but they are allowing it to be
released for us  novices  out  in  the  real  world.)  Which
__________________________
Verification of my charges comes from  the  experiences
of  the  many users of Unix, and from the modifications
that other people have been forced to make to the  sys-
tem.   Thus, the system of Unix I now use is called The
Fourth Berkeley Edition for  the  Vax,  distributed  by
Joy,  Babaoglu, Fabry, and Sklower at the University of
California, Berkeley (henceforth, Berkeley Unix).  They
provide   a  listing  program  that  provides  all  the
features I claim a user would want (except  a  sensible
name  -- but Berkeley Unix even makes it easy to change
system names to anything you prefer).



                       August 2, 1981






                           - 5 -


operation takes place if you say  "yes":  why  the  file  is
deleted  of course.  So if you go through your files and see
important-file, you nod to yourself and say, yes,  I  better
keep that one, type in yes, and destroy it forever. Does dsw
warn you? Of course not.  Does dsw even document itself when
it starts, to remind you which way is which?  Of course not.
That would be talkative, and true Unix programmers are never
talkative.   (Berkeley  Unix, has finally killed dsw, saying
"This little known,  but  indispensible  facility  has  been
taken  over...".   That  is a fitting commentary on standard
Unix: a system that allows an "indispensible facility" to be
"little known.")


     The symbol "*" means "glob" (a typical Unix name:   the
name  tells  you  just what action it does, right?).  Let me
illustrate with our friend, "cat." Suppose  I  want  to  put
together   a  set of files named paper.1 paper.2 paper.3 and
paper.4 into one file.  I can do this with cat:
     cat paper.1 paper.2 paper.3 paper.4 > newfilename
Unix provides "glob" to make  the  job  even  easier.   Glob
means  to  expand the filename by examining all files in the
directory to find all that fit. Thus, I can redo my  command
as
                  cat paper* > newfilename
where paper* expands to {paper.1 paper.2  paper.3  paper.4}.
This  is  one  of  the  typical virtues of Unix; there are a
number of  quite  helpful  functions.   But  suppose  I  had
decided  to name this new file "paper.all".  After all, this
is a pretty logical name, I am combining the separate  indi-
vidual files into a new one that contains "all" the previous
ones.
                   cat paper* > paper.all
Disaster.  I will probably blow  up  the  system.   In  this
case,  paper*  expands  to  paper.1  paper.2 paper.3 paper.4
paper.all, and so I am filling up a file from itself:
 cat paper.1 paper.2 paper.3 paper.4 paper.all > paper.all
Eventually the file will burst.   Does  nice  friendly  Unix
check against this, or at least give a warning?  Oh no, that
would be against the policy of  Unix.   The  manual  doesn't
bother warning against this either, although it does warn of
another, related infelicity: "Beware of 'cat a b  >  a'  and
'cat  b a > a', which destroy the input files before reading
them."  Nice of them to tell us.


     The command to remove all files  that  start  with  the
word "paper"
                         rm paper*
becomes a disaster if a space gets inserted by accident:
                         rm paper *
for now the file "paper" is removed, as well as  every  file
in  the  entire directory (the power of glob).  Why is there
not a check against such things?  I finally had to alter  my


                       August 2, 1981






                           - 6 -


version of rm so that when I said to remove files, they were
actually only moved to a special directory  named  "deleted"
and  they  didn't  actually  get deleted until I logged off.
This gave me lots of time for second thoughts and for catch-
ing  errors.  This also illustrates the power of Unix:  what
other operating system would make it so easy for someone  to
completely  change  the  operation  of  a system command for
their own personal satisfaction?  This also illustrates  the
evils  of Unix: what other operating system would make it so
necessary to do so?  (This is no longer necessary  now  that
we use Berkeley Unix -- more on this in a moment.)


     The standard text editor is called Ed.  What a  problem
that  turned  out  to  be.   It was so lovely that I spent a
whole year using it as an experimental vehicle  to  see  how
people dealt with such awful things.  Ed's major property is
his shyness; he doesn't like to talk.  You invoke Ed by say-
ing,  reasonably  enough,   "ed".  The result is silence: no
response, no prompt, no message, just silence.   Novice  are
never sure what that silence means.  What did they do wrong,
they wonder.  Why doesn't Ed say "thank you, here I am"  (or
at least produce a prompt character)?  No, not Unix with the
philosophy that silence is golden.   No response means  that
everything  is  ok.   If  something  had gone wrong, then it
would have told you (unless the system died, of course,  but
that couldn't happen could it?).

     Then there is the famous append  mode  error.   To  add
text  into  the buffer, you have to enter "append mode."  To
do this, one simply types "a",  followed  by   RETURN.   Now
everything  that  is  typed  on  the  terminal goes into the
buffer.  (Ed, true to form, does not inform you that  it  is
now  in  append mode: when you type "a" followed by "RETURN"
the result is silence, no  message,  no  comment,  nothing.)
When  you are finished adding text, you are supposed to type
a line that "contains only a . on it."  This gets you out of
append  mode.   Want  to  bet  on how many extra periods got
inserted into text files,  or how many commands got inserted
into texts, because the users thought that they were in com-
mand mode and forgot they had not left append mode?  Does Ed
tell you when you have left append mode?  Hah.  This problem
is so obvious that even the designers  knew  about  it,  but
their  reaction  was  to  laugh:  "hah-hah, see Joe cry.  He
just made the append mode error  again."   In  the  tutorial
introduction  to  Ed, written at Bell Labs, the authors joke
about it. Even experienced programmers get screwed this way,
they  say, hah hah, isn't that funny.  Well, it may be funny
to the experienced programmer, but it is devastating to  the
beginning secretary or research assistant or student  who is
trying to use friendly Unix as a word processor,  or  as  an
experimental tool, or just to learn about computers.  Anyone
can use Unix says the programmer, all you need is a sense of
humor.


                       August 2, 1981






                           - 7 -


     How good is your sense of humor?  Suppose you have been
working  on a file for an hour and then decide to quit work,
exiting Ed  by saying "q".  The problem  is  that  Ed  would
promptly quit.  Woof, there went your last hour's work. Gone
forever.  Why, if you would have wanted to save it you would
have  said  so,  right?   Thank goodness for all those other
people across the country who immediately rewrote  the  text
editor  so  that us normal people (who make errors) had some
other choices besides Ed, editors  that  told  you  politely
when  they were working, that would tell you if they were in
append or command mode,  and  that  wouldn't  let  you  quit
without  saving  your file unless you were first warned, and
then only if you said you really meant it.


     I could go on.  As I wrote this paper I sent out a mes-
sage on our networked message system and asked my colleagues
to tell me of  their  favorite  peeves.   I  got  a  lot  of
responses,  but  there  is  no  need to go into detail about
them; they all have much the same flavor about them,  mostly
commenting  about  lack  of  consistency,  about the lack of
interactive feedback.  Thus, there is no standardization  of
means  to  exit  programs  (and  because the "shell" is just
another program as far as th system is concerned, it is very
easy to log yourself off the system by accident).  There are
very useful pattern matching features (such as the "glob"  *
function),  but the shell and the different programs use the
symbols in inconsistent ways.  The Unix  copy  command  (cp)
and the related C programming language "stringcopy" (strcpy)
have reversed order of arguments, and  Unix  move  (mv)  and
copy (cp) operations will destroy existing files without any
warning.  Many programs take special  "argument  flags"  but
the  manner of specifying the flags is inconsistent, varying
from program to program.  As I said, I could go on.


     The good news is that we don't use  standard  Unix:  we
use  Berkeley  Unix.   History lists, aliases, a much richer
and more intelligent set of  system  programs,  including  a
list  program,  an  intelligent screen editor, a intelligent
set of routines for interacting with terminals according  to
their  capabilities,  and  a  job control that allows one to
stop jobs right in the middle, startup new ones, move things
from  background  to  foreground  (and  vice versa), examine
files, and then resume jobs.  And the shell has been  ampli-
fied  to  be  a more powerful programming language, complete
with file handling capabilities, if--then--else  statements,
while,  case,  and  all the other goodies of structured pro-
gramming  (see the accompanying box on Unix).

     Aliases are worthy of special comment.  Aliases let the
user  tailor the system to their own needs, naming things in
ways they themselves can remember: self-generated names  are
indeed easier to remember than arbitrary names given to you.


                       August 2, 1981






                           - 8 -


And aliases allow abbreviations that are meaningful  to  the
individual,  without burdening everyone else with your clev-
erness or difficulties.

     To work on this  paper,  I  need  only  type  the  word
"unix,"  for  I  have  set up an alias called "unix" that is
defined to be equal to the correct command to change  direc-
tories,  combined with a call to the editor (called "vi" for
"visual" on this system) on the file:
alias unix "chdir /csl/norman/papers/CogEngineering; vi unix"
These Berkeley Unix features have proven  to  be  indispens-
able:  the  people in my laboratory would probably refuse to
go back to standard Unix.

     The bad news is that Berkeley Unix  is  jury-rigged  on
top  of regular Unix, so it can only patch up the faults: it
can't remedy them.  Grep is not only still grep,  but  there
is  an  egrep  and  an  fgrep.  But worse, the generators of
Berkeley Unix have their problems: if Bell Labs  people  are
smug  and  lean,  Berkeley  people  are cute and overweight.
Programs are wordy. Special features  proliferate.   Aliases
--   the  system  for  setting  them  up  is not easy to for
beginners (who may be the people who need them  most).   You
have  to  set  them  up  in a file called .cshrc, a name not
chosen to inspire confidence!  The "period" in the  filename
means that it is invisible -- the normal method of directory
listing programs won't show it.  The directory listing  pro-
gram, ls, comes with 19 possible argument flags, that can be
used singly or in combinations.  The number of special files
that  must be set up to use all the facilities is horrendus,
and they get more complex with each new release from  Berke-
ley.   It  is vey difficult on new users.  The program names
are cute  rather  than  systematic.   Cuteness  is  probably
better  than the lack of meaning of standard Unix, but there
are be limits.  The listing program is called "more" (as in,
"give  me  more"),  the program that tells you who is on the
system is called "finger", and a keyword help file  --  most
helpful by the way -- is called "apropos."  Apropos! who can
remember that?  Especially when you need it most. I  had  to
make  up  an alias called "help" which calls all of the help
commands Berkeley provides, but  whose  names  I  can  never
remember (apropos, whatis, whereis, which).




__________________________
The system is now so wordy and  so  large  that  it  no
longer  fits  on  the  smaller machines: our laboratory
machine, a DEC 11/45, cannot hold the latest release of
Berkeley  Unix  (even  with a full complement of memory
and a reasonable amount of disc).  I write  this  paper
on a Vax.



                       August 2, 1981






                           - 9 -


     One reader of a draft of this paper -- a  systems  pro-
grammer   --   complained  bitterly:  "Such  whining,  hand-
wringing, and general bitchiness will cause most  people  to
dismiss  it as over-emotional nonsense. ...  The Unix system
was originally designed by systems programmers for their own
use and with no intention for others using it. Other hackers
liked it so much that eventually a lot of them started using
it.  Word  spread about this wonderful system, etc, the rest
you probably know. I think  that  Ken  Thompson  and  Dennis
Ritchie  could  easily shrug their shoulders and say 'But we
never intended it for other than our personal use.'"

     All the other users of Unix who  have  read  drafts  of
this paper agreed with me.  Indeed, their major reaction was
to forward examples of problems  that  I  had  not  covered.
This  complaint was unique.  I do sympathize with the spirit
of the complaint.  He is correct, but  ...    The  "but"  is
that  the  system  is  nationally  distributed, under strict
licensing agreements, with a very high charge  to  industry,
and  nominal  charges  to  educational  institutes.  Western
Electric doesn't mind getting a profit, but  they  have  not
attempted  to  worry  about the product.  If Unix were still
what it started to be, a simple experiment on  the  develop-
ment  of operating systems, then the complaints I list could
be made in a more friendly, constructive manner.   But  Unix
is  more  than  that.   It  is  taken as the very model of a
proper operating system.  And that is  exactly  what  it  is
not.

     In the development of the system aspects of  Unix,  the
designers  have  done  a  magnificent  job.   They have been
creative, and systematic.  A common theme runs  through  the
development  of  programs, and by means of their file struc-
ture, the development of "pipes" and "redirection"  of  both
input  and  output,  plus the power of the iterative "shell"
system-level commands, one can combine system level programs
into  self-tailored systems of remarkable power with remark-
able ease.

     In the development of the  user  interface  aspects  of
Unix, the designers have been failures.  They have been dif-
ficult and derisive.  A common theme runs through  the  com-
mands: don't be nice to the casual user --  write the system
for the dedicated expert.  The system is a recluse.  It uses
weird  names,  and it won't speak to you, not even if spoken
to.  For system programmers, Unix is a delight.  It is  well
structured,  with  a consistent, powerful philosophy of con-
trol and structure.  My complaint is simple:   why  was  not
the  same  effort  put  into  the design at the level of the
user?  The answer to my complaint is  a  bit  more  complex.
There  really  are no well known principles of design at the
level of the user interface.  So, to remedy the harm that  I
may  have  caused by my heavy-handed sarcasm, let me attempt
to provide some positive suggestions based upon the research


                       August 2, 1981






                           - 10 -


that  has  been done by me and by others into the principles
of the human information processing system.


     Cognitive Engineering is a new discipline, so new  that
it  doesn't  exist:   but it ought to.  Quite a bit is known
about the human information processing system,  enough  that
we  can specify some basic principles for designers.  People
are complex entities and can adapt to almost anything.    As
a  result,  designers  are often sloppy, for they can design
for themselves without realizing the difficulties that  will
be faced by other users.  Moreover, there are different lev-
els of users:  people with a large amount  of  knowledge  of
the  device  they  are about to use are quite different from
those who lack a basic understanding.  Experts are different
than novices.  And the expert who is normally skilled at the
use of some systems but who has not used it for awhile is at
a peculiar level of knowledge, neither novice nor expert.

     The three most important concepts for system design are
these:

     1.  Be consistent.  A  fundamental  set  of  principles
          ought  to  be  evolved  and  followed consistently
          throughout all phases of the design.

     2.  Provide the user with  an  explicit  model.   Users
          develop  mental  models  of the devices with which
          they interact.  If you do not  provide  them  with
          one, they will make one up themselves, and the one
          they make up is apt to be wrong.  Do not count  on
          the  user fully understanding the mechanics of the
          device.  Secretaries  and  scientists  alike  will
          share  a  lack  of knowledge of a computer system.
          The users are not apt to understand the difference
          between  the buffer, the working memory, the work-
          ing files, and the permanent files of a text  edi-
          tor.   They are apt to believe that once they have
          typed something into the system, it is permanently
          in  their  files.   They  are  apt  to expect more
          intelligence from the  system  than  the  designer
          knows  is  there.   And  they are apt to read into
          comments (or the lack of comments) more  than  you
          have  intended.   Feedback  is  of critical impor-
          tance, both in helping to establish the  appropri-
          ate  mental model and in letting the user keep its
          current state in synchrony with the actual system.

     3.  Provide mnemonic aids.  Human memory is  a  fragile
          thing.   Actually,  for  most  purposes it is con-
          venient to think of human memory as consisting  of
          two  parts:   a  short-term memory and a long-term
          memory (modern cognitive psychology is  developing
          more  sophisticated  notions than this simple two-


                       August 2, 1981






                           - 11 -


          stage one, but this is still  a  valid  approxima-
          tion).   Short-term  memory  is,  as the name sug-
          gests, limited in duration  and  quantity:   about
          five  to  seven  items is the limit.  Thus, do not
          expect a user to remember the contents of  a  mes-
          sage  for  much  longer  than it is visible on the
          terminal.  Long-term  memory  is  robust,  but  it
          faces  two difficulties:  getting stuff in so that
          it is properly organized and getting stuff out, so
          that  it  can  be  found when needed.  Learning is
          difficult, unless there is a good  structure,  and
          it is visible to the learner.  The system designer
          must provide sensible assistance to  the  user  so
          that  the  material  can be structured.  There are
          lots of sensible memory aids that can be provided,
          but  the  most  powerful  and  sensible  of all is
          understanding.  Make a system so that  it  can  be
          understood and the memory follows with ease.  Make
          the command names ones  that  can  be  understood,
          where  the  names follow from the function that is
          desired.  If abbreviations must be used,  adopt  a
          consistent policy of forming the abbreviations. Do
          not deviate from the policy, even when it  appears
          that  it  would be easier for a particular command
          to deviate:  inconsistency is an  evil.   Remember
          the  major  problem  of  any large-scale memory is
          finding the information that is  sought,  even  if
          the  information  is there someplace.  We retrieve
          things from  memory  by  starting  off  with  some
          description  of  the information we seek, use that
          description to enter their  memory  system  in  an
          attempt  to match against the desired information.
          If the designer uses cute names  and  non-standard
          abbreviations,  our  ability  to  generate a valid
          description is impaired.  As a result, the  person
          who  is  not  expert and current in the use of the
          system is apt to flounder.



     There are many ways of formatting information on termi-
nals  to  provide  useful  memory and syntax aids for users.
With today's modern terminals, it is possible to use  menus,
multiple  screens  and  windows, highlighted areas, and with
full duplex systems,  automatic  or  semi-automatic  command
completion  systems.   The  principles for these systems are
under active study by a  number  of  groups,  but  none  are
directly  relevant to my critique of the UNIX operating sys-
tem.  UNIX is designed specifically so that it can  be  used
with a wide variety of terminals, including hard copy termi-
nals.

     The problem with Unix is more fundamental.   Unix  does
not provide the user with a systematic set of principles; it


                       August 2, 1981






                           - 12 -


does not provide a simple, consistent mental model  for  the
user, consistent not only in the shell but in the major sys-
tem programs and languages; it does  not  provide  the  user
with simple memory aids that can be used to learn the system
structure and then, when  one is not completely  current  in
the  use  of  a  particular  command,  still  to  be able to
retrieve (or better, derive)  what  is  needed.   There  are
essentially  no  user help files, despite the claim that all
the documentation is on-line via the command named man  (for
manual, of course).  But "man" requires you to know the name
of the command you want information about,  although  it  is
the name that is probably just the information you are seek-
ing.

     System designers take note.  Design the system for  the
person, not for the computer, not even for yourself.  People
are  also  information  processing  systems,  with   varying
degrees   of   knowledge,  varying  degrees  of  experience.
Remember, people's short-term memories are limited in  size,
and they learn and retrieve things best when there is a con-
sistent reason for the name, the function, and  the  syntax.
Friendly systems treat users as intelligent adults who, like
normal adults, are forgetful, distracted, thinking of  other
things,  and  not  quite as knowledgeable about the world as
they themselves would like  to  be.   Treat  the  user  with
intelligence.   There  is  no need to talk down to the user,
nor to explain everything.  But give the  user  a  share  in
understanding by presenting a consistent view of the system.


























__________________________








Message-ID: <anews.Aucbvax.2534>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!mark
X-Path: utzoo!decvax!ucbvax!mark
From: ucbvax!mark
Date: Wed Aug  5 08:47:18 1981
Subject: The truth about Unix

I read your Unix flame with interest, but you seem to be
ill informed about lots of things.  Obviously you are comparing
V6 Unix with 3BSD, but you claim to be comparing "Unix" with
"Berkeley Unix".  You credit Berkeley with things that are
part of V7 (getting rid of dsw, adding egrep and fgrep).
I might compare your note with a message saying "don't go
out and buy a 1975 VW Rabbit - those are crummy cars because
the 1979 Rabbit is better".  (No, I'm not complaining about
the recent Rabbit note, this just happened to be a handy example).
You also claim that "Berkeley Unix is too big to fit ... on an 11/45".
Hogwash!  3BSD is a Vax distribution - it has a C compiler that
generates Vax object code, a kernel that knows the Vax memory management
and I/O conventions, and some other VAX specific things.  So are 4BSD
and 4.1BSD, which superceded 3BSD the same way V7 has superceeded V6.
We have lots of PDP-11's here at Berkeley, including 70's, a 45, and
several 40's.  Most of them run some version of Berkeley Unix.
Bigness is not important - we run vi 3.6 on a 40 in the virus lab.
Of course, it is a different system than the one on the vax.
"Berkeley Unix" is about as specific as "Chevrolet".

You also have to bear in mind that the various flavors of Unix have
evolved from one system years ago in Bell Labs.  In upgrading from
version x to version x+1, issues of upward compatibility have to
be taken into account.  If you changed /usr to /user, not only would
you infuriate most of the users "What a pointless change!  Now I
have to retype half my commands!" but you would break a large number
of programs that look for such places as /usr/spool/mail, /usr/dict/words,
and so on.  Things that are not obviously wrong and horrible tend
to get left alone.  (There are, unfortunately, exceptions.  index
and rindex are called strchr and strrchr in some versions of Unix.)

From cincy!duke!decvax!utzoo!henry Sun Aug  9 23:43:32 1981
datamat!rumor       : net.general,NET.general
There is no such system as "datamat" connected to us, nor is there
any person named "rumor" locally.  Any communication purporting to
be from such a person at such an address is either garbled or
fraudulent.  Will somebody PLEASE tell me why we are suddenly getting
tons of mail addressed to "...!utzoo!datamat!rumor", apparently related
to an unfriendly evaluation of Unix that I have never heard of and
that most certainly did not come from here?

From uucp Mon Aug 10 22:18:44 1981 remote from pur-ee
Aucbvax.2598
fa.unix-wizards
pur-ee!cincy!duke!decvax!ucbvax!unix-wizards
Mon Aug 10 12:23:20 1981
EUNUCH for large machines
>From csvax.mark@Berkeley Mon Aug 10 12:15:19 1981
Care to back up your flame about big machines with some reasons?
It does run on a Vax, Univac 1100, Amdahl, 370, and 3B.

Bell invests lots of effort into Unix - about as much as the rest
of the world.  But their version doesn't get released.

	Mark

Message-ID: <anews.Aucbvax.2643>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!unix-wizards
X-Path: utzoo!decvax!ucbvax!unix-wizards
From: ucbvax!unix-wizards
Date: Wed Aug 12 00:12:07 1981
Subject: Yet more truth about Unix.....

>From greg@NPRDC Wed Aug 12 00:08:58 1981
I almost hesitate to mention this, but Donald A. Norman, the author of
"The Truth About Unix", gets mail as "Norman at NPRDC".  (NPRDC is
notorious enough; a little more won't hurt, right?)  You could send him
copies of your flames to see if he might respond.  It could be a very
interesting discussion.....
----

Message-ID: <anews.Aucbvax.2660>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!unix-wizards
X-Path: utzoo!decvax!ucbvax!unix-wizards
From: ucbvax!unix-wizards
Date: Wed Aug 12 11:44:04 1981
Subject: Misunderstanding about Unix.....

>From Nowicki@PARC-MAXC Wed Aug 12 11:35:03 1981
I would like to make a few comments on Donald Norman paper on "The Truth
About Unix".  The arguments for Consistency, Simple Models, and Mnemonic
Aids should all be Motherhood, even though many system designers continue to
ignore them. (If you want consistent abbreviations you can use RSX-11M for a
while where all commands are three letters; then you'll appreciate Unix.)

The major mistake that is made, however, is failing to consider the possible
multiple levels of abstraction.  For example, the title says "The user interface is
horrid", but in reality every level of abstraction has a "user interface," namely
its interface to the next higher level.  The motto of the Unix was not "let the
user beware," but rather, "make the primitives simple but powerful, so as much
as possible can be done at higher levels".  With his arguments, you could say
that all man-computer communication is doomed to failure because it uses only
ones and zeros, which are not very mnemonic.  The real problem is that an
appropriate level for a systems programmer is not appropriate for casual end
users.  This conclusion is hinted at near the end of the paper, but it means that
the paper should not be a criticism of Unix itself, but rather a criticism of how
people use Unix. 

The point that someone reading only the first few paragraphs of the paper can
miss is that the primitives in Unix CAN be either easily replaced or encapsulated,
while almost no other systems provide this capability.  As an example, two
Stanford students have implemented a TOPS-20 style command interpreter for
Unix.  It has arbitrary  abbreviations, <escape> command completion, the
question-mark help facility, and a delete-undelete-expunge facility.  Version
numbers for backup files are implemented with a simple suffix to the file name.

The real shame is that the Unix users themselves are forced to make the system
as distributed from Western more humane, and thus every wheel gets reinvented
many times.  Luckily groups like Berkeley and Usenix are trying to help this
situation, but as indicated progress is very slow.

	-- Bill

Message-ID: <anews.Aucbvax.2671>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!unix-wizards
X-Path: utzoo!decvax!ucbvax!unix-wizards
From: ucbvax!unix-wizards
Date: Thu Aug 13 10:01:32 1981
Subject: Reply to 'The Truth about UNIX'

>From clyde@UTEXAS-11 Thu Aug 13 09:53:17 1981

	While the gentelman has some cogent points, I also believe he
has permanent brain damage . He is obviously used to DEC systems which
like to hold lusers hands lest they damage themselves, and I had great
difficulty reading completly through his treatise (diatribe?) because
of his own inconsistancies and notions.

	Oh well, not everyone can be enthusiatic (though I noticed he
wrote his document on a UNIX system, using NROFF -- I wonder how
he managed to hold his nose with one hand and type with the other) .
-------

From uucp Fri Aug 14 09:31:36 1981 remote from pur-ee
Aharpo.407
net.general
pur-ee!cincy!duke!mhtsa!harpo!jerry
Wed Aug 12 10:42:36 1981
forgery

I suppose Steve should know better than I do, but why couldn't 
a forger just uux (or execute directly)  rnews on a machine
with the input indicating the item came from datamat!rumor. 
In fact couldn't you drop it in almost anywhere in the net?  
Potentially the later can be detected because you will end up with 
peculiar headers (e.g. the item
appears to have passed through a machine twice.)  A little
more cleverness, and a better understanding of netnews might
circumvent even that problem, and in any event the only thing
you could learn would be the machine rnews was executed on. 

From uucp Fri Aug 14 11:37:48 1981 remote from pur-ee
Aduke.943
net.general
pur-ee!cincy!duke!swd
Thu Aug 13 09:23:28 1981
more rumor rumors
Some random thoughts on the datamat!rumor article.

1) it did not enter the net at utzoo by having someone
   there run rnews to submit it.  If they had, utzoo
   would have seen the article.  If it entered at decvax,
   it would not have been sent to utzoo -- the anti loop
   code in news will not send an article to any system
   on the return path.  Since the article did show up at
   decvax, it entered the net there.

2) what probably happened is that someone on the west coast
   (Note the PDT in the date line) created the article
   and ran  uux - decvax!rnews <fake article.

3) there is no way to prevent this (short of an elaborate
   public key encryption scheme).

From uucp Fri Aug 14 11:39:22 1981 remote from pur-ee
Aucbvax.2619
fa.unix-wizards
pur-ee!cincy!duke!decvax!ucbvax!unix-wizards
Tue Aug 11 09:14:54 1981
unix on large machines
>From BH@SU-AI Tue Aug 11 09:06:37 1981
Since KLH doesn't seem to have answered the request for details on
why UNIX isn't perfect for big machines, let me try:

1.  The file system is flaky.  UCB is working on some aspects of
this problem but not all.  They seem to be fixing the problems in
which a disk block is added to one list BEFORE it's removed from
another, which is how the file system is compromised by a system
crash.  But they aren't changing the fact that overwriting a file
(a creat with an existing name) deletes the old file right away
rather than on a successful close, nor are they adding an exclusive
access discipline to the kernel.  (About once a month or so my
/etc/passwd disappears when several people try to change their
passwords or create new accounts at once, despite supposedly
foolproof lock-file code in the user programs.)

2.  Debugging facilities leave a lot to be desired.  You can't
type instuctions in to adb, so it's hard to patch code.  The
symbol table doesn't know about things like fields in a struct,
so symbolic debugging only partly exists.  You can't use adb
standalone to poke at a crashed system.

3.  Many smaller, easily-fixed things show that UNIX was designed
with a small machine in mind.  One example: the result of compiling
"foo.c" should be called "foo", not "a.out".  Clearly they designed
the naming convention for a machine without much disk space, in which
it was antisocial to have executable files for more than one program
at a time!

4.  There are terminals in the world other than the model 37 TTY.
The UCB termcap package makes it possible for there to be a few
huge, hairy user programs which support displays.  But there needs
to be kernel support (or the equivalent in shell support, with
all other user level tty interaction funneled through the shell,
which would be awkward) for things like automatically dividing the
display screen into pieces for different processes.  The user must
be able to type escape sequences of some sort to control which piece
hse's typing into right now.  It should be possible to write a
TRIVIAL user program which can still fit into this display
discipline, e.g., it shoul be able to type a control-L and have that
mean "clear my piece of the screen".

5.  Some things aren't written as efficiently as they might be.

There's more, but this will do to begin the discussion.  Mind you,
I think UNIX is wonderful in many ways.  Pipes are great, filters
are great, process trees are great, etc.  Many of the flaws in UNIX
could be fixed in a more or less compatible way.  (Not the one about
deleting the old file too soon, though.)  (By the way, yes I know
you can program around it.  The difference between an okay system and
a great system is that you don't have to program around the great
system, you can program THROUGH it!)  It's not that the future
large-computer standard operating system should look nothing like
UNIX, it's that the standard large-computer UNIX needs some redesign
before it gets ossified as a standard.

From uucp Fri Aug 14 11:40:30 1981 remote from pur-ee
Aucbvax.2628
fa.unix-wizards
pur-ee!cincy!duke!decvax!ucbvax!unix-wizards
Tue Aug 11 11:41:44 1981
Flaming Psychologists
>From mo@LBL-UNIX Tue Aug 11 11:23:32 1981
Well, you see what kind of stuff gets into DATAMATION.
I don't understand these things: many of the criticisms
are right, but the facts are categorically wrong!  Unix
could benefit from some "normalizaion" (the Software Tools
benefitted greatly from having been written all at once, not
over the years), but the claim that Unix does not present
a simple set of principles is the most incomprehensible
statement he could have made!  That is ALL Unix does,
and that is precisely why he doesn't like it!  If he hates
it so much, why doesn't he go get an account on a TOPS-10 system
or since he is at UCSD, a UCSD PASCAL machine?
	Well, enough of that.  I yield the floor to Lauren.
	-Mike

From uucp Fri Aug 14 11:55:22 1981 remote from pur-ee
Aihuxl.103
fa.unix-wizards
pur-ee!cincy!duke!decvax!ucbvax!ihnss!ihuxl!jej
Thu Aug 13 20:19:50 1981
Forced Interaction, and YAUF (Yet Another Unix Flame)
Subject: program interface to mail-like commands, Unix documentation

I've run into a problem of how to automate commands that, to quote
Ritchie, "force interaction on the user whether it is wanted or not:"
the primordial example is mail.

It is not clear how one could write a program that would issue the
correct commands to mail to do a particular filtering, such as "save
all mail from John Doe, and delete the rest after printing it offline."
mail expects standard input to direct it, based on what it itself has
output.

Any notions of a technique for writing such programs?

----------------------------------------

The item about the Unix user interface was very good--one item
that the author left out, though, was Unix documentation.

Most notorious, I think, are the multitude of manual pages which
say about the error messages that they are "self-explanatory."
I believe that this must mean that the author intends them to be
meaningful to himself.

Examples:

1. run-time error messages from C programs--these are QUITE machine
	dependent; rather embarassingly so for an OS based on C as
	Unix is, one would think.
2. C compiler error messages, which describe every syntax error as
	"syntax error," which may be enough for Dennis Ritchie, but
	not for mere mortals. Another worthless error message is
	that which describes the error in terms of compiler internals.
	What does that have to do with the constructs the user knows?

Also quite helpful are the error codes one gets from make(1), such as
"Error code 100".

Manual pages are frequently vague and casual: I recall the times when
I had to try VERY hard to persuade someone that egrep(1) should treat
'$' as just another character when it is not at the end of a regular
expression, and in another case, that ed(1) permitted nested escaped
parentheses in regular expressions. Formal specifications of options
and accepted commands may not be useful to some readers, but they cer-
tainly are more useful to those who CAN understand them than vague
English prose.

"Casualness" at times degenerates into flippancy or display of the
author's self-estimated cleverness: e.g.

	"This brash one-liner intends to build a new library from
	existing .o files." (This sentence, with absolutely NO other
	explanation, accompanies an example of lorder(1).)

or

	"This is an area where experience and informed courage
	count for much."

What good do these do to the reader who is trying to figure out
what on EARTH a command does?

Options on commands, in a sense documentation, don't have much chance
to indicate their meaning, since they're typically restricted to one
letter. (Some day I intend to write a phony command page containing

	SYNOPSIS
		cmd -[abcdefghijklmnopqrstuvwxyz] name ...

	OPTIONS
		-a	Use the 'a' option.
etc.)

				James Jones (ihuxl!jej)

From uucp Fri Aug 14 11:56:36 1981 remote from pur-ee
Autzoo.885
net.general,NET.general,fa.unix-wizards
pur-ee!cincy!duke!decvax!utzoo!henry
Thu Aug 13 00:56:51 1981
datamat!rumor
I've now seen a copy of the infamous utzoo!datamat!rumor article
that has caused all the fuss (I thank decvax!jm for mailing it to
me).  It most definitely DID NOT originate at or pass through
decvax!utzoo, the University of Toronto Zoology department.  The
"PDT" in its postmark strongly suggests a west-coast origin, as
does the author's affiliation, and a friend of mine who gets various
things from the Arpanet community says he has seen "utzoo" on the
cc-list of a document that may even be the same article (we haven't
yet had a chance to compare notes).  THIS IS NOT US.  We may have
a first here:  the first real live authentic name conflict on Usenet.
[Why me, Lord?]  Would anyone knowing the possible identity of the
other "utzoo" please pass this information on to me?  My friend's
comments suggest it may be in the Stanford area, the origin of
the article itself suggests the San Diego area.

					Henry Spencer
					decvax!utzoo!henry
					(416)978-2006 (for now)
					(416)978-6060 (shortly)

From uucp Fri Aug 14 11:59:42 1981 remote from pur-ee
Aharpo.423
fa.unix-wizards
pur-ee!cincy!duke!decvax!ucbvax!mhtsa!harpo!ber
Thu Aug 13 23:31:58 1981
YAUF
Gee whiz.  Bitch bitch bitch.  There is better documentation than
manual pages provided with your unix system.  The manual page
is a brief description of a command, routine or concept.  It's a starting
point, and frequently enough.  If you want to know more, look at the source.

I think the page for lorder is terrific.  I never use lorder for anything
other than ordering libraries, and to have an example right there is great.

All this crap about UNIX being unfriendly and UNIX lacking documentation
and so on is just that.  UNIX is an operating system.  It's clean, concise,
and clear (at least traditionally).  The beauty of the environment that
generally surrounds a unix is that it is easilly growable by the people
that use it.  If some turkey writes a poor manual page, then unix is blamed.
Look at all the crap you have to deal with at IH because they won't permit
a public directory for NON-STANDARD this and that.  Well I guess they want
to make sure nobody polutes their system.  That stinks.  But that's the only
way your going to censor it.  At least you can point your finger directly
at the computer center staff.

If you don't like a command or documentation your free to avoid it.
Or better yet, improve it!  Unix provides an excellent program development
environment.  If you can't figure out what a syntax error is, ask someone.
You'll find dozens of experts in every hallway.  Why?  Because it's relatively
easy to comprehend.

Please don't start restricting creativity with naming standards and style
standards and how many lines are permitted in a subroutine ...
That's almost tolerable for a project, but unix isn't a number 7 electronic
sump pump.  Just because management feels that 'C' and UNIX are the do-all
to end-all doesn't make it so.  And the attempts to fit that misconception
are ruining a perfectly good environment.

Why don't you send your comments to the MINI-SYSTEM newsletter in the
form of a modification request?  I'ld like to see an OFFICIAL response.

(deep breath)

Now I feel better.   Let's face it, unix is not geared to the naive user.
So what?  It's great for the knowledgable user.  Why bring the level
of excellence down to least common denominator?  For a profit!  Yeh well
that's another story.  But let's try to raise the level of the users.

Message-ID: <anews.Aucbvax.2783>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!unix-wizards
X-Path: utzoo!decvax!ucbvax!unix-wizards
From: ucbvax!unix-wizards
Date: Fri Aug 21 21:54:17 1981
Subject:   [Stephen Wolff:  The Truth about UNIX]

>From mike@bmd70 Fri Aug 21 21:39:51 1981

----- Forwarded message # 1:

Date:      20 Aug 81 22:53:18-EDT (Thu)
From:      Stephen Wolff <steve@bmd70>
To:        bruce at Bmd70, howard at Bmd70, mike at Bmd70
Subject:   The Truth about UNIX

At a "retirement community" not too long ago, I saw tacked to the door
of one the apartments a neatly lettered sign that read:
		"Old age is not for sissies"

Neither is UNIX.
						-steve

----- End of forwarded messages

Message-ID: <anews.Aihuxl.104>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!mhtsa!ihnss!ihuxl!jej
X-Path: utzoo!decvax!ucbvax!mhtsa!ihnss!ihuxl!jej
From: ihuxl!jej
Date: Sat Aug 22 12:40:23 1981
Subject: Hacker Conceit and Unix

Subject: Fallacious Argument Forms

Concerning the following message:

	Date:      20 Aug 81 22:53:18-EDT (Thu)
	From:      Stephen Wolff <steve@bmd70>
	To:        bruce at Bmd70, howard at Bmd70, mike at Bmd70
	Subject:   The Truth about UNIX
	
	At a "retirement community" not too long ago, I saw tacked to the door
	of one the apartments a neatly lettered sign that read:
			"Old age is not for sissies"
	
	Neither is UNIX.
							-steve

This is totally irrelevant to the criticisms of the Unix user interface
in the datamat!rumor file. Putdowns of those who find the Unix (user interface
inclusive or documentation) cryptic and confusing, while perhaps satisfying
to the source, do not answer anything. I assume that the author of this
message has never inadvertantly destroyed a file system and has always been
able to figure out how to make Unix do what he wants.

The implication of this message, as well as a response I got to complaints
about lax, vague, and flippant documentation of programs that come with Unix,
is that Unix is REALLY for the "true hackers", and anyone else, such as those
who think that one should be able to use a program without reading the source
code, or who think that programs released to the outside world should consider
human factors of someone other than their author, may use Unix by their conde-
scension. If that is the prevalent attitude, then Unix will come to a
well-deserved oblivion at the hands of an operating system which will pay
attention to documentation and human factors while keeping those features
of Unix which make it useful to homo faber (which is distinct from homo
C-programmaticus (apologies to speakers of Latin), one should keep in mind).

				James Jones (ihuxl!jej)

Message-ID: <anews.Apurdue.124>
Newsgroups: net.general
Path: utzoo!decvax!pur-ee!purdue!mab
X-Path: utzoo!decvax!pur-ee!purdue!mab
From: purdue!mab
Date: Tue Sep  1 11:56:17 1981
Subject: The Truth About UNIX -- not a flame


Does anybody know if and/or when Dr. Norman's "The Truth About UNIX" was
published? Has Datamation printed it yet?

                                                Matt

Message-ID: <anews.Aucbvax.5282>
Newsgroups: fa.unix-wizards
Path: utzoo!decvax!ucbvax!unix-wizards
X-Path: utzoo!decvax!ucbvax!unix-wizards
From: ucbvax!unix-wizards
Date: Sun Nov 22 10:40:37 1981
Subject: Important article about UNIX

>From gwyn@UTEXAS-11 Sun Nov 22 10:37:40 1981
The November 1981 Datamation has an article starting on page 139
entitled "The Trouble With UNIX" by Donald A. Norman.  It is very
critical of the UNIX user interface.  There is a rebuttal by Mike Lesk.
This article is likely to reach a wide audience of DP professionals,
so Unix Wizards should know what it says.  Some of the criticisms
resemble topics under discussion in this mailing list, and others
offer food for thought ...
-------

Message-ID: <anews.Aucbonyx.228>
Newsgroups: net.news,net.unix-wizar
Path: utzoo!decvax!ucbvax!ARPAVAX:Onyx:jmrubin
X-Path: utzoo!decvax!ucbvax!ARPAVAX:Onyx:jmrubin
From: Onyx:jmrubin
Date: Mon Jan 18 16:10:29 1982
Subject: Norman article

	In the current Datamation, Donald Norman has a short article
"The Trouble with Networks".  Those who have read this stuff for a while
will remember that a draft of Norman's article, "The Trouble With Unix",
appeared on the network around August or September, with a non-existent
return address.  According to Norman, he left his draft in an open file
and asked for comments.  He didn't know it had been submitted to the netnews
until people told him about it. (He still doesn't know who did it and disguised
their address.)  ("The Trouble With Unix" appeared in November Datamation.)

						Joel Rubin