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?"
Might wanna check out How Computers Work before getting too far into writing the new book. I've used it several times to explain concepts to new computer users.
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.
Chapter 4: Understanding the file system.
d er\filename.ext. (Maybe explain file extensions, the ability of Windows to hide the file extension from the user, and why they might want to disable that feature and look at those extensions themselves before double-clicking a file).
A "file" is data or a document of some sort. It may be letter, a photo, a song, a video, a shopping list, a piece of a program, a piece of the operating system, a piece of adware, an insurance form, a contract, or whatever. A "folder" is a container that can contain many files, can contain folders, and can be found in a folder.
A file has a "location" in the file system. When you save it, if you know it's location, you have lots of power. For example, if you save a file in Microsoft Word, and want to start using Open Office, you simply need to know the location of the file. If you download your music in iTunes, and want to listen to it in MusicMatch Jukebox, you must merely know it's location. If you don't know the location of your file, your geek won't be able to find it either, so don't bother him until you know.
You describe the location of a file by listing the folder where the file can be found, the folder in which that folder can be found, ad nauseum, with the "backslash" character ("\") in between, and the drive letter followed by a colon before, so a location looks like d:\outerfolder\middlefolder\middlefolder\innerfol
You have my permission to use any or all of that, verbatim or modified, and take credit for it as your own.
My mother cannot grasp the concept of folders. She puts every document relating to one theme in a single file; she prints out whatever pages of that file matter for a single document. It's a terrible system.
No non-geek understands file locations. Even semi-geeks may only partially understand; I can think of two or three people who know where their MS Word files are, but don't even understand that eMule or iTunes keeps their music in files located in the filesystem.
On a separate topic, maybe the concept of email delivery would be useful (user clicks "send", his computer attempts to deliver mail to server [post office analogy]; then server attempts to deliver to destination server [post office analogy again]; then receiving user MUST connect to server [post office analogy again] to retrieve their mail). Oh, and the difference between a web address and an email address (the "@" signifies a person's name "at" a place, while a web address is just a place).
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.