Main Page
From Grokdoc
Welcome to GrokDoc. It started as a usability study of GNU/Linux newbies. Our goal was to create a useful manual on basic tasks that new users will find simple and clear and easy to follow, using what we learn from our study. GrokDoc is an offshoot of Groklaw.
However in the interim, most of the usability issues have been resolved. Certainly it would be hard to find anything easier to use than today's GNU/Linux distributions, such as Canonical's Ubuntu and Kubuntu. So Grokdoc morphed. It is now a sandbox for group research projects, as well as a permanent home for certain types of works where a wiki format is more useful than Groklaw's. So here you will find such projects as a history of Microsoft and standards and contacts and issues surrounding MSOOXML, and information on switching to Linux, including an applications crossover chart, where you can find applications that match what you may be used to on another operating system. You can find everything Grocdoc offers on the Table of Contents page.
So what follows, below, is historical now. And what a grand thing it is that it is no longer needed:
____________________
Our idea was this: instead of technically proficient people explaining tasks and functions to newbies, we let newbies show us what is hard for them. Proprietary software companies do such usability studies, and they benefit from the knowledge gained. The Free/Open Source community has all that we need to do the same, using the many eyeballs approach, so to speak. Open source ideals applied to research can be very powerful.
In order to accomplish our goal, we are requesting that you sit down with a friend or family member who has little (or ideally no) prior experience with GNU/Linux and observe them as they try any Linux distribution, watching and noting what they find difficult, so we will know what needs to be explained more clearly.
The research results will be collected here, and we will then write up the manual explaining how to do the basic tasks we have studied. You can also help us write a manual from what we learn. Your friends and relatives who participated in the study can help, too.
If you would like to see an example of a usability report, take a look at this one.
We would like you to give us your research results in the following categories (you'll find detailed instructions below and when you click on any of the links):
If you are ready to begin telling us about your study results, just click on any of the links above and start telling us your experience. If you have any suggestions let us know.
Are you wondering how to start a new page? Feel free to do so any time you don't know where to put something.
Want to send PJ an email? Then just click on the little yellow envelope icon on the left.
Got some great ideas for this page? There is an editable Alternate Main Page which I check regularly for your input. You may prefer it to this page, and that is fine too.
All of us at one time were GNU/Linux newbies. But some of us came from tech backgrounds, which made it not only easier for us but also a lot of fun. But a new group of nontech users are switching, or being switched by their employers and governments, to the Linux operating system. Some of them, maybe a lot of them, will need help to make the transition pleasant and painfree. There are many wonderful newbie documentation projects, including the Linux Documentation Project ( www.tldp.org ) and LinuxQuestions.org, and this isn't an attempt to duplicate their work. You should tell us about good resources. Note that there is a permanent tab above for such resources.
INSTRUCTIONS
GrokDoc proposes that each of us sit down with a friend or relative who is totally new to GNU/Linux, and just let them try to use your distro, any distro you have on hand, including Knoppix and its cousins.
Don't show them anything. Just watch and record. What do they have problems with? How did they try to solve the problem? What happened? Did it fix it? If not, tell them they can find answers on the Internet at such places as LDP or by using Google or by reading the manuals that come with the distro. Don't tell them anything more than that.
Have them try to do a minimum of four things: email, a letter (including printing it), a firewall, and surfing the web. (That includes setting up for email and surfing the web.) Ask them to log out at the end. What do they spontaneously say they like and what do they say upsets them? Is the menu clear? Where do they get lost? Record what you see, not just what they say. If they have a prompt on the screen, and stop for five minutes trying to figure out what it means or how to move past it, note such bumps in the road, even if they eventually solve it.
Watch them try and record the results. If you have a video, and they are willing, record it for your own use so as to analyze carefully what happens. (Don't submit that to GrokDoc, however, without contacting us first.) What works? What doesn't? If they hit an unmovable wall, then step in and help, but don't leap in until they are about to give up, and help them just enough to get them moving forward again. We don't want your mom or best friend to hate Linux, just for a study. But let them really try to solve all problems without input from you until they fail utterly.
If they express an interest in trying other tasks besides these three, let them try, by all means. Maybe, for example, they want to know how to burn a CD. Or they want to know how to set up the PC to interface with their digital camera. Note what you observe is hard for them to do, as well as the things they verbally express are hard. Of course, we need to know exactly what distro you are using, including version, and what hardware. Please also record what level of security your system is set to, if you use a distribution that has such a choice, like Mandrake. It can, as you know, affect what they experience.
If they are willing to try to install a distro, go ahead and let them try. Record what happens. Let them figure out for themselves what they want and don't want, just using the installation built into the distro as if they were alone in the room.
Answers will vary, but that doesn't matter. Standing back and looking at patterns will be the next step. After they have accomplished all the tasks, write down what solved the issues and what didn't and what you think (or they indicated) would have helped. Clear suggestions would be appreciated and very valuable. Would a screenshot have helped? More words in a manual or online resource? Less words? Better organization? Less technical? In other words, evaluate yourself what you think is needed, and please be very specific and as detailed as you can.
We also want input from you on resources that already exist, like LDP. Please list them on the resources page.
Then we will have two versions of GrokDoc, working from the issues that we find crop up the most. The first will be your input, raw and unabridged, which anyone can write to, edit, etc., wiki style. The other will be an official version, incorporating the best ideas and materials, but polished by our tech writers and me, along with others who may wish to help and have those particular skills.
I want screenshots and graphics too, but no pictures of friends and relatives, please. If you see a way to explain a task using graphics and screenshots, by all means be creative and send in your complete solution, with graphics, screenshots, whatever, to the public page. If you wish credit, that's absolutely fine. If you don't, that is fine too. Be aware GrocDoc is under a Creative Commons license and that this is a noncommercial project. Please don't contribute copyrighted material that does not belong to you.
I asked a professional technical writer, to write about what would make this project really useful. Here is his response:
WRITING TECHNICAL DOCUMENTS FOR COMPUTER BEGINNERS
~by Nicolas Richards
The first rule of writing technical documents is to know your audience. This means more than a mental acknowledgement of who you are writing for, and then plowing ahead in your usual style. It means crafting your words to suit your audience, even if your audience thinks in wildly different ways from the way you think. Consider the plight of the help desk. The person manning the phone knows quite a bit about software and hardware, but the person calling in may not. How many times has a problem been reported to a help desk that couldn’t be solved until the person taking the call dialed down the probable causes to a level commensurate with that of the caller. “Is the monitor plugged in? No? Ah, well plug it in now. Is it in? It works now? Wonderful. You’re very welcome.”
This can be the hardest part about writing for the total computer beginner. You and I are light years ahead of them. Think about when you first learned to drive a car. What happened when you had to come to a stop at a stop sign? Didn’t you concentrate, trying to make sure you applied the brake just right so as not to stop short or to overshoot the intersection? Now that you are experienced, however, how do you approach a stop sign today? With one hand on the wheel, looking at your friend in the back seat, twiddling the radio buttons to find a better song, and noticing your hair is messy in the mirror. And what do you know? You come to a stop better than you did when you were first starting out. What changed? You developed muscle memory. Your body can automatically handle the instructions to the foot and to your steering hand while barely taxing the brain. There are so many steps that you used to laboriously take manually to make sure you came to the stop correctly that you now take for granted. Why, you don’t even realize you are taking those steps, they’ve become so automatic.
It’s the same with software. You don’t even think about clicking versus double-clicking, or moving one window in front of the other, or expanding a window, or minimizing it. You just do it while thinking of a hundred other more interesting things. It’s part of your hand’s muscle memory now, not worth thinking about. Guess what? The beginner has still got her tongue sticking out the side of her mouth from concentrating so hard to not make a mistake. You’re sailing into the stop sign, the beginner is running steps through her head.
That’s why it’s so critical to know, and I mean really know, your audience. In our case, our audience is made up primarily of those rank beginners who think the computer is going to blow up if they press a key wrong. All right, maybe not that basic, but for a certainty there will be some of those coming along for the ride too. The “which key is the Any key?” crowd.
This is why Grokdoc is unique and not covered elsewhere. Most Linux documentation, even those aimed at beginners, is written with certain technical assumptions in mind. Assumptions that might work for many users, but it will leave out the total beginners. Microsoft has spent millions of dollars to do usability studies aimed at trying to understand how such beginners react when they sit down at a keyboard. That’s valuable knowledge for there is no other way to really know what is going to happen than to observe it in action.
Have you ever taken part in a usability study? I did once as a beta tester for the original Prodigy online service back when IBM was designing it. I was paid to come in to a local IBM office, sit down at a special computer, and given a set of specific tasks to accomplish that day on Prodigy. Video cameras captured everything I did. If I tabbed to a text box and then realized I missed a step and tabbed back, the camera caught it. If I was asked a question on the screen and it took me a while to figure out what answer I should give, or even how to answer such a question, the camera caught my pause. If I circled back to a screen I had already filled out because I didn’t know where I was going, they caught that too. There was no one next to me telling me what to do. I was on my own with the software and they wanted to see how I would cope.
That is the only way to know if the software is ready for beginner prime time. If the beginner smashes his head against the keyboard in frustration, it’s time for the software designers to get back to work. Remember, the software makes perfect sense to the designer and the programmer, for they know it inside out, and it’s their baby. Even those of us who have not programmed FOSS can still feel that sense of ownership over a set of software we have come to have affection for. I can tell you from experience that it is painful as a programmer to realize the user cannot figure out how to use your software. You get defensive and make excuses, but there are no excuses. Yes, there are dumb users out there, but get used to it. It’s humanity – including the dumb ones. Dumb ones get to use software too, and we need to help them learn.
It is very valuable to have this sort of usability testing done, but it costs money. Lots of money. We don’t have that kind of money, so we have to apply the “many eyes” principle to compensate. With the many volunteers on Grokdoc, we can make up for the lack of financial resources by volunteering our time to help make FOSS better, even for the dumb ones. How do we accomplish this? By replicating the usability testing experience, but by one-on-one encounters.
Take someone who is new to Linux, or even new to computers in general, and explain how they can help this project. Ask them to sit down with you at the computer while you have them try to accomplish a predetermined set of tasks with that software while you watch. Then let them do it. You just watch. Take notes while they try to accomplish each step. See when they make a wrong move – why were they led astray at that moment? What kept them from leaping to the correct step? Is there any way the software could be designed to make the correct step more obvious, or the incorrect step less enticing? If they come to a dead halt, unable to figure out what to do next, make a note of that and why it happened. Ask them questions to see what they think they should do, and why nothing in front of them appears to be the correct step in their minds. Then help them figure out the correct step and stand back again while they continue.
The thing that will tempt you more than anything else at this point is the terrible urge to jump in and tell them, “No, do this instead,” just to ease the excruciation of watching them take forever to come to the right conclusion. Fight that urge! You will think to yourself, “Ugh, it’s just a stop sign! It’s so simple!” Meanwhile they are thinking to themselves, “Oh no, a stop sign! What do I do?” You need to let them struggle with it on their own, for it is in their struggling that you begin to get insights into what could be changed to make them not have to struggle with this step. If you just tell them what to do, you short-circuit the process as surely as if you took the steering wheel out of their hand and stomped on the brake.
As hundreds of volunteers use this method with computer beginners trying various software packages, we can build up a usability library that will prove invaluable in helping to make FOSS appealing and inviting to the average Windows user and the total computer neophyte. You know, that 90% of the market whom we want to try Linux. This will go a long way toward making that dream a reality.
View the editable Alternate Main Page.
