![[LWN Logo]](/images/lwn.banner.gif)
Here's something I just found on Linux Weekly News. I think it's very
good advice for all of us who are advocating Linux in schools (or
anywhere else, for that matter).
>
> Date: Mon, 8 Nov 1999 21:34:48 -0800 (PST)
> From: Phil Agre <pagre@alpha.oac.ucla.edu>
> To: "Red Rock Eater News Service" <rre@lists.gseis.ucla.edu>
> Subject: [RRE]How to help someone use a computer
>
> How to help someone use a computer.
>
> Phil Agre
> http://dlis.gseis.ucla.edu/pagre/
>
> Please forward this article to everyone who can use it.
>
> 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. This is natural.
>
> * 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. Try to 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.
>
> * Explain your thinking. Don't make it mysterious. If something
> is true, show them how they can see it's true. When you don't
> know, say "I don't know". When you're guessing, say "let's try
> ... because ...". Resist the temptation to appear all-knowing.
> Help them learn to think like you.
>
> * 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. If you need to show off, show off your ability
> to criticize the bad interface. 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.
>
> * Formulate a take-home lesson.
>
> * Take a long-term view. Who do users in this community get help
> from? If you focus on building that person's skills, the skills
> will diffuse outward to everyone else.
>
> * 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 at <http://dlis.gseis.ucla.edu/people/pagre/tno.html>;,
> copyright 1996 by Phil Agre. You can forward it to anyone for
> any noncommercial purpose. For more copyright information, please
> see <http://dlis.gseis.ucla.edu/people/pagre/copyright.html>;.)
http://lwn.net/1999/1111/a/agre.html
--
Doug Loss The difference between the right word and
Data Network Coordinator the almost right word is the difference
Bloomsburg University between lightning and a lightning bug.
dloss@bloomu.edu Mark Twain
Title: a/agre
Date: Mon, 8 Nov 1999 21:34:48 -0800 (PST)
From: Phil Agre <pagre@alpha.oac.ucla.edu>
To: "Red Rock Eater News Service" <rre@lists.gseis.ucla.edu>
Subject: [RRE]How to help someone use a computer
How to help someone use a computer.
Phil Agre
http://dlis.gseis.ucla.edu/pagre/
Please forward this article to everyone who can use it.
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. This is natural.
* 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. Try to 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.
* Explain your thinking. Don't make it mysterious. If something
is true, show them how they can see it's true. When you don't
know, say "I don't know". When you're guessing, say "let's try
... because ...". Resist the temptation to appear all-knowing.
Help them learn to think like you.
* 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. If you need to show off, show off your ability
to criticize the bad interface. 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.
* Formulate a take-home lesson.
* Take a long-term view. Who do users in this community get help
from? If you focus on building that person's skills, the skills
will diffuse outward to everyone else.
* 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 at <http://dlis.gseis.ucla.edu/people/pagre/tno.html>;,
copyright 1996 by Phil Agre. You can forward it to anyone for
any noncommercial purpose. For more copyright information, please
see <http://dlis.gseis.ucla.edu/people/pagre/copyright.html>;.)