Goodbye to RTFM
I worked as a technical writer for 4 years before I heard (or at least recognized) someone use the initialism RTFM. I don't know how that happened. People I work with don't know how that happened. It just did.
If you don't know - and from what I hear, it is not possible to not know - RTFM stands for Read The ... um ... Funny Manual.
RTFM is used in and around software companies in response (both spoken and unspoken) to both internal (spoken) and external (unspoken) people who ask questions or seek guidance for something that is covered in the documentation. RTFM's cousin is the less alphabetical "It's in there somewhere." I call that check mark documentation - "I wrote something about the new drivers on pg. 56, check."
I'd like to think that my lack of familiarity with this term has something to do with my approach to documentation. That approach being that is my job to make it easy, attractive, and fulfilling for people to RTFM. The fact that people are turned off by the idea of reading the manual is something that drives my thoughts on the subject of documentation. The fact that people are often unable to find what they are looking for when they do read the manual is a challenge I try to address daily.
Why do we need to tell people to read the manual? They know it's there. Why do we have README files? Does this imply that the other doc files should not be read? Maybe this is why people don't read the manuals. Doesn't popular psychology tell us that people might respond better if we named the file DONTREADME?
People don't have to be told to do things that make their lives easier. We don't have an acronym for telling people to use the software. When they learn that the software can help them accomplish something, they use it. People don't have to be told to turn on the heat in their homes. They do it because it makes their lives more comfortable. That is what documentation should strive to do. Until documentaion consistently delivers what people want, people won't use it.
And, it's not enough that the information the user is looking for is in the manual. The job of a technical communicator does not end when all the words about a particular product are assembled into a PDF file. The presentation of information must lead the users to the information they want - even bring it to them. Just saying "It's in there" is not enough. Why didn't the user find it? Why wasn't it obvious that this was the information they were looking for? These questions can't always be answered (users do make mistakes), but striving toward answering them and minimizing opportunities for mistakes is where there is value.
An additional challenge comes when trying to address the needs of both beginners and experts. One article about RTFM states it this way:
"When evaluating whether it is acceptable to express sentiments like RTFM, one must consider the trade-off between maintaining the usability of an Internet forum for its existing users, and making a forum welcoming to newcomers."
Rather than a trade-off between one or the other, I put the onus on the technical writer to accommodate both types of users through some speical organization or innovation in documentation. Those are the kinds of innovations that can make our jobs more valuable and exciting, and can push documentation over the edge.
RTFM may have come to popular use in the hacker community, where people are willing participants in a quest to learn all they can and implement that knowledge in novel ways. Perhaps, in that setting, RTFM is the right sentiment when someone asks a question that is documented somewhere. But, when documenting a product that is indirectly important to the people using it (i.e. it helps them get something else done), RTFM is always the wrong response.
The information that comes with a product, and the task of processing that information, is part of the experience of using the product. That experience should be a positive one. Not one that we should curse at people to take part in. Ultimately, it is our problem.
If you don't know - and from what I hear, it is not possible to not know - RTFM stands for Read The ... um ... Funny Manual.
RTFM is used in and around software companies in response (both spoken and unspoken) to both internal (spoken) and external (unspoken) people who ask questions or seek guidance for something that is covered in the documentation. RTFM's cousin is the less alphabetical "It's in there somewhere." I call that check mark documentation - "I wrote something about the new drivers on pg. 56, check."
I'd like to think that my lack of familiarity with this term has something to do with my approach to documentation. That approach being that is my job to make it easy, attractive, and fulfilling for people to RTFM. The fact that people are turned off by the idea of reading the manual is something that drives my thoughts on the subject of documentation. The fact that people are often unable to find what they are looking for when they do read the manual is a challenge I try to address daily.
Why do we need to tell people to read the manual? They know it's there. Why do we have README files? Does this imply that the other doc files should not be read? Maybe this is why people don't read the manuals. Doesn't popular psychology tell us that people might respond better if we named the file DONTREADME?
People don't have to be told to do things that make their lives easier. We don't have an acronym for telling people to use the software. When they learn that the software can help them accomplish something, they use it. People don't have to be told to turn on the heat in their homes. They do it because it makes their lives more comfortable. That is what documentation should strive to do. Until documentaion consistently delivers what people want, people won't use it.
And, it's not enough that the information the user is looking for is in the manual. The job of a technical communicator does not end when all the words about a particular product are assembled into a PDF file. The presentation of information must lead the users to the information they want - even bring it to them. Just saying "It's in there" is not enough. Why didn't the user find it? Why wasn't it obvious that this was the information they were looking for? These questions can't always be answered (users do make mistakes), but striving toward answering them and minimizing opportunities for mistakes is where there is value.
An additional challenge comes when trying to address the needs of both beginners and experts. One article about RTFM states it this way:
"When evaluating whether it is acceptable to express sentiments like RTFM, one must consider the trade-off between maintaining the usability of an Internet forum for its existing users, and making a forum welcoming to newcomers."
Rather than a trade-off between one or the other, I put the onus on the technical writer to accommodate both types of users through some speical organization or innovation in documentation. Those are the kinds of innovations that can make our jobs more valuable and exciting, and can push documentation over the edge.
RTFM may have come to popular use in the hacker community, where people are willing participants in a quest to learn all they can and implement that knowledge in novel ways. Perhaps, in that setting, RTFM is the right sentiment when someone asks a question that is documented somewhere. But, when documenting a product that is indirectly important to the people using it (i.e. it helps them get something else done), RTFM is always the wrong response.
The information that comes with a product, and the task of processing that information, is part of the experience of using the product. That experience should be a positive one. Not one that we should curse at people to take part in. Ultimately, it is our problem.
posted by Pete at 7:13 PM
0 Comments:
Post a Comment
<< Home