peterr@utcsrgv.UUCP (Peter Rowley) (08/21/83)
Some comments on the topics of the last little while:
Human factors engineers study novices, not experts:
This is true as experts are often too busy to be studied, but studies of
experts HAVE been done, in a number of areas. In fact, there have even
been studies of novices becoming experts (on relatively simple tasks); see
below. If anyone knows of studies of expert programmers doing non-programming
problem-solving tasks (especially logical deductions), I'd very much appreciate
hearing about it.
Ed:
I looked through the reference for specific problems with ed, with no luck.
I expect the memory load referred to, however, is simply knowing where one is
in the text file, and the surrounding text, especially important if one is
writing English prose. This is a problem with all line-oriented editors.
Norman has a paper in the Proceedings of the "Human Factors in Computer
Systems" conference, (Mar. 15-17, 1982, sponsored by Nat'l Bureau of Stds,
Washington DC ACM chapter, in cooperation with Office of Naval Research,
Software Psych. Society, Human Factors Society, and IFIP WG6.3) which
explains some of the problems with "vi", in particular the tendency for
a user trained to end a session with ":wq" to type that sequence even if
ONLY wanting to write the file out and the use of the equivalent ":zz"
to solve the problem by greater differentiation of the two operations.
By the way, this proceedings contains many interesting papers, though
I'm afraid I don't know how to order it-- one of the sponsoring societies
should know. (If anyone knows how to get them, pls mail me and I'll post
it). Even better, the second such conference is being held early this
December in Boston (12th-15th to be precise), sponsored by ACM SIGCHI and
the Human Factors Society.
Teaching Novices about Computers:
A useful paper on this is "The Psychology of How Novices Learn Computer
Programming", by Richard Mayer, ACM Computing Surveys, March 1981. The
issue is a special one, devoted to the psychology of human-computer
interaction. The Mayer paper is reprinted in the IEEE Computer Society's
Tutorial on Human Factors in Software Development. It's impossible to
summarize the paper in 25 words or less, but it strongly supports the use
of concrete models as teaching aids. Interestingly, it found that such
models interfered with rote learning (e.g. of prog. lang. syntax) but
greatly improved "transfer performance"-- performance on a task for which
they were not specifically trained. Another technique found useful was to
have the students rephrase technical material in their own words, causing
them to integrate it better into their past knowledge.
As this is a Comp. Surveys paper, it is better written than most, and
has a good bibliography.
On the other hand, a paper by Halasz and Moran in the above-mentioned
conference proceedings, warns against the use of analogy, saying that
undesired parts of the object being compared to the computer system are
likely to be incorporated into the student's model. The authors suggest
alternatives that I can't do justice to in a few sentences.
If anyone's had good success with specific concrete models, let's
hear about them-- people teaching first year CS need all the help they
can get. Also, any particular dangers of using specific models would
be helpful. I used the railroad shunting yard model to explain infix-
to-postfix conversion once and ran into trouble because the diagram
I used forced me to write the infix expression in reverse, and I didn't
make this clear enough... leading to postfix expressions equivalent to
the REVERSE of the infix; insidiously, this is right as long as one
sticks to plus and times but is dead wrong when non-commutative operators
are used.
Menus:
This message is getting rather long, so I'll just say that there are
papers on this topic in the conference proceedings, including one from
authors at IBM describing an interface that allows both menu and command-
driven input and a study done at Exxon Office Systems showing that, if
it's easy to do so, novices migrate from menus to commands. With respect
to Unix, there's an interface called "Cousin" developed at CMU that
will prompt for arguments if they're left out, will provide "help"
information, and do other friendly things like spelling correction, but
I'm afraid I can't remember a reference. Has anyone used this?
peter rowley, U. Toronto CSRG
{cornell,watmath,ihnp4,floyd,allegra,ubc-vision,uw-beaver}!utcsrgv!peterr
or {cwruecmp,duke,linus,decvax,research}!utzoo!utcsrgv!peterrmikezi@shark.UUCP (Mike Ziuchkovski) (08/22/83)
An assumption has been made that the majority of computer users are programmers. I think this assumption is wrong. Most of the users are not programmers. Are we trying to show people how to program (take our jobs away) or are we trying to make computers more friendly to the user and I emphisize "FRIENDLY". Try taking J. Q. P. off the street and sit them down to a computer runing un*x. See how long it takes them to do anything. Give them a task like writting a letter on their experiance with the computer. If J. Q. P. can do the assignment with what they can find out from the computer, is this a start to general use of computers for the public? The question I am realy asking is "Are we designing for the users or are we designing for ourselves (a small user population)?" What about it cog-eng's? mike ziuchkovski