Slashdot Mirror
What Should People Understand About Computers?
counterexample asks: "It seems to me that there aren't very many good books out there that explain to the layman what is really going on with computers. My mother cannot go to the bookstore and pick up a book that will make her understand the strange language that we IT people speak, or why her computer would be susceptible to a virus. So, I intend to write such a book. I have a fair idea of what should be in it (history of the Internet, how computers talk to each other, what a hard drive does, etc.), but I'm interested to see what you all have to say. What do you wish your users knew? What kind of questions are you so sick of answering because you hear them every week? What does the general public think they understand, but really don't?"
All of the above boils down to this:
My parents must read every character on the screen before they can gather a single piece of data from it. They cannot interact with the computer until they have viewed, thought about, squinted at, photographed, printed the photo of, discarded the photo of, composted the photo of, and grown a new tree out of that photo, of every pixel.
Users can't read you the part you need because, with the possible exception of something that is obviously a cheesecake recipe, everything on the screen is nonsense to them. Maybe Cliff could attempt to quantify and describe the filters used by us geeks to read only the important stuff. Extra credit if you can teach them to correctly operate "OK" and "Cancel" buttons in other languages/broken video cards/buggy software (more extra credit if they can do it ambi-interfacedly -- mouse and/or keyboard).
That reminds me: One thing that should definitely be covered is the 3-way "Save file" dialog that comes up when exiting a program/shutting down, and similar dialogs, that offer "Yes", "No", and "Cancel". This confuses the heck out of many users, and it's not reasonable to expect them to figure it out on their own unless they're geeks. They need to know that "Cancel" is a sure-fire way to get nothing done and be back where they started, and that they need to click "No" if they want to continue exiting the program but don't want to save the file. A sidebar should explain that walking away from the dialog will result in the computer waiting forever, and probably an "End task?" dialog will come up too.
Procrastination -- because good things come to those who wait.
It's kind of like taking your car into the shop. A lot of people will be nervous in front of the mechanic and not want to describe what the problem is with the car because they don't know the terminology or where the problem could be. Instead they'll say it sounds like the catalytic converter is overheating the timing belt on the radiator exhaust manifold piston: a bunch of useless information. Nervousness breeds uncertainty breeds impatience breeds hositility, and the same is true with computers.
The problem is often that the person providing support doesn't ask the right questions. Some of the best support I've gotten has been from people that led me to the answers. The questions in your example are perfect: "What does the screen say?" and "What do you mean 'it's blue,' what does it say?" Screens don't say anything, they have things printed on them, and when the user gives you an answer, it doesn't help to ask them a ridiculing question ("what do you mean, 'it's blue?'" (hint: they mean 'it's blue')) and then repeat your original question. It gets you nowhere (as you demonstrated). When it's expected that there's a whole lot of useless information (a hex dump) and a little bit of useful information (IRQ NOT LESS OR EQUAL TO), it's the job of the person providing support to lead the user to the answer. Try the exchange:
You: "The screen should be light blue with a white box for a password below your username. Do you see that?"
Mom: "The screen's dark blue and it has a bunch of white text."
You: "OK, there should be a bunch of random text at the top, with the letters A through F and the numbers 0 through 9. Ignore that part; we're looking for the first line below all the random text that has actual words in it. Read me that line."
Like you said, people aren't dumb and they're naturally inquisitive. Leading them through the troubleshooting steps makes support a lot easier and productive. Most of the problems I see with support analysts is that they don't know how to ask the right questions, not that the user is too dumb to understand. Even the dumbest user can be helped if they're willing and if the support person has the right skills.