peterr@utcsrgv.UUCP (Peter Rowley) (08/22/83)
There are at least two problems that cog-eng can address, the software crisis
(by designing tools for programmers that allow them to better construct and
understand complicated software) and making computers usable by novices (by
designing systems that lead complete novices to proficiency in simple domains
such as letter writing and home budget keeping).
The two problems are intuitively very different, with experts working in a
rather open-ended domain in the first, and novices-becoming-experts in a
limited domain in the second. But those "novices" are often highly skilled
professionals. And the experts have the same basic genetic structures as
the novices. I think that there are so many questions and assumptions to be
resolved that it is too early to label research as SOLELY "novice" or "expert"
oriented.
However, specific projects WILL deal with either simple domains or complicated
domains such as programming. On the basis of social need, I'd say study of
novices is pretty important to the spread of computers. But providing better
software tools is important for the construction of software, especially
life-critical software (e.g. air traffic control, reactor control). My
impression is that work with novices is far more prevalent, in no small part
due to the fact that novices are far more prevalent than experts. But who's
to say which area is ultimately more important?
peter rowley, University of Toronto Department of C.S., Ontario Canada M5S 1A4
{cornell,watmath,ihnp4,floyd,allegra,ubc-vision,uw-beaver}!utcsrgv!peterr
{cwruecmp,duke,linus,decvax,research}!utzoo!utcsrgv!peterrlaura@utcsstat.UUCP (Laura Creighton) (08/23/83)
There are novices, and then there are casual users. Novices are people who have never learned to use X. Casual users are people who use X this month, and then go away and don't use then for 3 or 4 months, and then go back and use it again -- and so on. I believe that novices have an extremely short lifetime, so designing for them is silly. As soon as they have used whatever for 2 weeks (and in some cases shorter) they may not be expert programmers, but they are not novices any more. Casual users are a different matter altogether. comments? laura creighton utzoo!utcsstat!laura
mark@umcp-cs.UUCP (08/23/83)
I completely agree that we should not be designing for novices.
Novices are very transient. I like the distinction between novice
and casual user. I am not an expert car driver, but I am not
a novice either. Around the turn of the century a car designed
for a novice user would have been one as much like
a horse as possible. It would not have been a very good car,
even for the sunday-only driver.
The solution to novices is education. This does not mean that
studying them and understanding their difficulties is not very very
important. But it is not primarily a system design question, but
a pedagogical educational question.
The expert-at-something casual-user-of-computers is the person
to design for.
--
spoken: mark weiser
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!mark
CSNet: mark@umcp-cs
ARPA: mark.umcp-cs@UDel-Relaybrucec@tekecs.UUCP (Bruce Cohen) (08/26/83)
As a comment to the statement that designing for novices is silly because they don't stay novices, I offer the following observation: If they can't stand the interface they are given, they may not in fact ever become proficient with the system, even assuming they are forced by some consideration to continue to use it. It's really instructive to watch some people fumbling with the automatic teller machine, week after week. That's fine for banking (though a damn shame for the people who go through it), but if the equivalent situation existed with the operation of dangerous machinery, I think we'd all have something to fear. Come to think of it, how many people never do learn to drive properly, and endanger everyone on the road when they go out? And the economic and social pressures which make driving essential are well known. What happens when the same kinds of pressures force people to use computers? Bruce Cohen UUCP: ...!teklabs!tekecs!brucec CSNET: tekecs!brucec@tektronix ARPA: tekecs!brucec.tektronix@rand-relay
laura@utcsstat.UUCP (Laura Creighton) (08/28/83)
Perhaps the question of designing for the users reflects a different attitude about learning. I think that a lot of learning is fun. A lot is not. It is incredibly hard work, and akin to going to the dentist. The rewards of (learning Lisp without a manual, going to the dentist...) are, however worth it. Many people want to design for the person who will not learn unless they are being 'spoon fed'. I guess that they have a different attitude towards learning than I do. I do not want to force anyone to learn anything. If they want to learn something, I think that they will be willing to put up with the trouble of learning. I learned about computers with CARDS -- talk about barbaric -- but it was the only thing available at the time. In addition, I do not think that knowledge is a grab-bag of freebies sitting in my office that I am obliged to hand out to every passer-by. If you want to be educated, then you are going to have to work for it. I do not give it away for free. If you can design a system that is both easy to learn, and good for the experts, terrific. if not, I would rather design for the experts. In the short term, the novices will have a tough time, but in the long term (ie for the rest of their lives after they stop being novices) they will have a better tool. I know that this sounds cruel and heartless to the poor people struggling to learn, but then I never subscribed to the "learning is easy" school of education. When the novices finally get there, they may be grateful that we haven't decided that for the rest of their lives they will have to grit their teeth and put up with a "designed-for-novices" user interface out of consideration for the novices. Laura Creighton utzoo!utcsstat!laura
sch@linus.UUCP (Stephen C. Hemminger) (08/29/83)
I think Laura hit the crux of the problem...
For most computer system developers, they want to learn about new
systems. They are eager learners. This applies equally well to many
novice users of computers as well.
The problem comes when people are forced to learn a new system.
When a boss tells his secratary she has to learn a new system, the
system (no matter how user friendly) is at an extreme disadvantage.
As an engineer, I really can not see a perfect solution to the
problem. You can't make the customer change his ways, and you can't
make a system that the user can learn under duress.
--
Stephen Hemminger, Mitre Corp. Bedford MA
{allegra,genrad,ihnp4, utzoo}!linus!sch (UUCP)
linus!sch@mitre-bedford (ARPA)mason@utcsrgv.UUCP (Dave Mason) (09/02/83)
Note that experts can also be novices:
I currently use Unix,VMS,RSTS/E,UCSD P-System,VM/CMS and maybe CP/M or
AppleDOS in a typical week. There is no way I can remember how to use
the command syntax on all of these (perfectly), and I prefer systems that
prompt me on how to do something (when asked for), or give me help when I
forget how to do something with this O/S's arcane syntax (or with the
editor's arcane syntax). Because of this my casual use favourites in
order are VMS,UCSD,VM/CMS,Unix. (Go ahead with the flames..but let me
continue first.) VMS & VM/CMS have good, consistent help facilities in both
the command interpreter and the editor, but I don't 3270's. UCSD gives a 1 line
prompts all the time, so it's easy. Unix man facility is OK, but you have
to read the whole thing or know what you're looking for, and there does not
appear to be help from within the editor (which is where I think it is most
important). I like the UNIX process model better than VMS, but for casual use
DCL beats csh. (Please if you haven't used both save us both time..if you have
..flame away.)
One other thing I like in Unix and VMS is the ability to define aliases
(better done in csh than DCL).
-- Gandalf's flunky Hobbit -- Dave Mason, U. Toronto CSRG,
{cornell,watmath,ihnp4,floyd,allegra,utzoo,uw-beaver}!utcsrgv!mason
or {decvax,linus,lsuc,research}!utzoo!utcsrgv!mason (UUCP)