I felt that Chapter 19’s major emphasis was on making sure that when you write a technical description, that you not only make sure that it is relevant to the user but also complete. It was very similar to the first chapters we read that dealt the targeting your audience and understating the context of the document. When writing a technical description the author really stressed planning.
One of the tips was to decide your purpose for writing. They listed a dozen or so different purposes. While I understand that those aren’t the only purposes to writing a technical document or that you might not ever use one of the purposes, some of them seemed…odd. A technical document to characterize? Isn’t that just describing something? A technical document to reveal? Uhhh….? But I’m getting hung up on the semantics.
Another big factor was to be as specific as possible. I did like that the author suggested using your senses. Not only would this help you so that you don’t miss things but I would think that it would also help by targeting different readers learning abilities. Some people learn better by touching things while others learn better by just reading about them.
I also really liked what the author discussed about partitioning the subject. Again not only would this make sure that you were as thorough as possible, but it would also help your reader but dividing your description into smaller, easier to comprehend parts.
Who hasn’t used instructions? Better yet who hasn’t not used directions because they were poorly written? This chapter reiterates the need to plan, consider your audience and the context the document will be used in. It’s almost like these are important or something.
One thing that I think the author could have made a little clearer was when discussing international users and having the document translated. I think that the point should have been made that you should have it translated by a native speaker or someone who is very fluent in both languages. See the ThinkGeek’s blog post on Feb. 18 for an example of what could happen if you don’t have something properly translated. (http://www.thinkgeek.com/blog/2009/02/rejected-product-187.html)
As shown in both chapters as well as in previously read chapters, it is crucial to consider both your audience and context if you want your document to be effective. Not knowing you your target audience is could result in what the Instructor Blog #4 warns against: treating users as "idiots. Also you shouldn’t assume that your reader knows as much as you do. Both of these errors will only serve to alienate or confuse your readers, neither of which is helpful to anyone.
Accounting for all readers
As you covered in this response, utilizing the human senses in your instructions can be advantageous. Whereas the article suggests doing so in order to make the user fully aware of the process at hand, you mention that “it would also help by targeting different readers learning abilities.” This is something important to consider, as it is no secret that users will vary in their learning styles. For instance, some readers will be more visual learners, others more auditory, and others more kinesthetic learners so it is imperative to encompass all, or as many as possible, of the senses to reduce the learning curve for your target audience.
Also, the link you provided to ThinkGeek.com was, beyond comical, a good reference to what happens when instructions are poorly written and / or poorly translated. I personally liked HELONURS’S comments regarding Product #187, “Written in Japanese, translated to Greek, then instructions sent to Swaziland for further translation. Out for some Plutonian verbige, on to Taiwan, then finally some poor fella from Ecuador tried to make the final translation to English...”
As you stated, being specific
As you stated, being specific is extremely important. There really isn’t anything more annoying than a nice looking instruction set with good graphics that is hard to follow due to its lack of specifics. If an instruction set isn’t planned properly and written perfectly, certain specific details can be missed that cause the entire instruction set to become irrelevant to the user. The other really important thing would be to put your instructions through the usability tests. These tests can make sure that your instructions are specific enough and can ensure that there aren’t any areas that really need reworked.
www.JFlitt.com
Specific
I agree being very specific is important. After reading this it reminded be of the instructor’s blog with changing the oil example. Relating for me I have changed oil more time and in more vehicles that I care to mention. I see myself as an experienced individual trying to tell someone how to change their oil is difficult. With some of the instructions I have seen some instructions for changing oil having a diagram with a big arrow pointing to underneath the car and giving a picture of what the plug looks like when it is out not in. This would be unclear not specific enough to a novice and they would have trouble locating a drain plug.
Zebulon Rouse
Characterization and technical documents.
First of all, that rejected product is awesome, it reminds me of Samurai Showdown 5...but this brings up the importance of correct translation. Your comment about getting caught up in semantics was interesting, I read it as almost a play on words. A technical document to characterize could be something that attempts to clarify semantics. For example, a text or journal article on characterizing "Eastern Religions" (I'm taking that course right now-seemed appropriate) What does that even mean-"Eastern Religion"? Alternatively, this could be used as an instruction on a systematic method for characterizing something. For example, in a chemistry or biology lab we are often given unknowns and it is up to us to characterize them to identify them. Typically there are several procedures at one's disposal to accomplish this, procedures that are often quite technical.
I watched your video and I
I watched your video and I can't say I am very surprised. I have encountered many such products which have horrible grammar. Why do companies spend so much money a product and can't even afford to pay some guy $10 / hour to help them fix their instructions? It just doesn't make any sense.
Brilliant Example
Thanks for sharing, Andy!