Source
Automatically imported from: http://commons.somewhere.com:80/rre/1998/RRE.how.to.help.someone..html
Content
| | | | --- | --- | | Red Rock Eater Digest | Most Recent Article: Mon, 22 Jan 2001 |
[RRE]how to help someone use a computer
``` [I would greatly appreciate if you could forward this article to everyone who needs it. This might include teachers, consultants, customer support people, help desk staffers, system administrators, librarians, trainers, technical writers, and kids who know more about computers than their parents.]
---
This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, see http://dlis.gseis.ucla.edu/people/pagre/rre.html or send a message to requests@lists.gseis.ucla.edu with Subject: info rre
---
How to help someone use a computer.
Phil Agre http://dlis.gseis.ucla.edu/pagre/
Computer people are generally fine human beings, but nonetheless they do a lot of inadvertent harm in the ways they "help" other people with their computer problems. Now that we're trying to get everyone on the net, I thought it might be helpful to write down everything I've been taught about helping people use computers.
First you have to tell yourself some things:
Nobody is born knowing this stuff. You've forgotten what it's like to be a beginner. If it's not obvious to them, it's not obvious. A computer is a means to an end. The person you're helping probably cares mostly about the end. This is reasonable. Their knowledge of the computer is grounded in what they can do and see -- "when I do this, it does that". They need to develop a deeper understanding, of course, but this can only happen slowly, and not through abstract theory but through the real, concrete situations they encounter in their work. By the time they ask you for help, they've probably tried several different things. As a result, their computer might be in a strange state. That's not their fault. The best way to learn is through apprenticeship -- that is, by doing some real task together with someone who has skills that you don't have. Your primary goal is not to solve their problem. Your primary goal is to help them become one notch more capable of solving their problem on their own. So it's okay if they take notes. Most user interfaces are terrible. When people make mistakes it's usually the fault of the interface. You've forgotten how many ways you've learned to adapt to bad interfaces. You've forgotten how many things you once assumed that the interface would be able to do for you. Knowledge lives in communities, not individuals. A computer user who's not part of a community of computer users is going to have a harder time of it than one who is.
Having convinced yourself of these things, you are more likely to follow some important rules:
Don't take the keyboard. Let them do all the typing, even if it's slower that way, and even if you have to point them to each and every key they need to type. That's the only way they're going to learn from the interaction. Find out what they're really trying to do. Is there another way to go about it? Attend to the symbolism of the interaction. Most especially, try not to tower over them. If at all possible, squat down so your eyes are just below the level of theirs. When they're looking at the computer, look at the computer. When they're looking at you, look back at them. If something is true, show them how they can see it's true. Be aware of how abstract your language is. For example, "Get into the editor" is abstract and "press this key" is concrete. Don't say anything unless you intend for them to understand it. Keep adjusting your language downward towards concrete units until they start to get it, then slowly adjust back up towards greater abstraction so long as they're following you. When formulating a take-home lesson ("when it does this and that, you should check such-and-such"), check once again that you're using language of the right degree of abstraction for this user right now. Whenever they start to blame themselves, blame the computer, no matter how many times it takes, in a calm, authoritative tone of voice. When they get nailed by a false assumption about the computer's behavior, tell them their assumption was reasonable. Tell yourself that it was reasonable. It was. Never do something for someone that they are capable of doing for themselves. Don't say "it's in the manual". (You probably knew that.)
(This article is adapted from The Network Observer, which can be found on the Web at http://communication.ucsd.edu/pagre/tno.html, copyright 1996 by Phil Agre. It may be forwarded on the Internet to anyone for any noncommercial purpose. It may also be reprinted in any publication, provided that: (a) I am credited as the author, (b) my copyright is acknowledged, (c) the article is reprinted in its entirety, verbatim, without any additions, deletions, and modifications, and (d) one copy of the publication is sent to me at the address listed on my home page.) ```
| | | --- | | ProcessTree Network TM For-pay Internet distributed processing. | | Advertising helps support hosting Red Rock Eater Digest @ The Commons. Advertisers are not associated with the list owner. If you have any comments about the advertising, please direct them to the Webmaster @ The Commons. |