While I was reading through the material for this week, I mostly tried to relate by thinking about how I use instructions and what what I look for.
As the very first phrase from Instructor Blog #4 said, instructions are a lot of times viewed as superfluous. Unless I'm building something, like a Wal-mart book case or a Lego set, I usually only use instructions or owner's manuals to pick out specific pieces of information, as needed. So one thing I look for in a good set of general instructions is a structure that allows me to quickly find the exact information I'm looking for. The video game example is a good one. People just jump on and start playing, and consult the booklet if they have specific problems. That's how I'm mostly likely to approach any owner's manual or set of general instructions.
I was actually a little surprised that none of the readings explicitly talked about a technical guide's searchability. If a manual is pretty long, I appreciate a good index. If it's only a page, it should be scanable - big headings are great. Today I had to teach myself how to use a tool for my job. The instructions were only a page long, but I knew exactly what I needed and I wasn't interested in all the information there. Fortunately, what I was looking for was laid out in bold as one of the major headings on the page, so I skipped right to that and moved on.
That got me thinking a lot about design. One common theme in this course is understanding your readers to point that you can use your presentation to influence them. Design is a big part of that. I took a peek at the instructions in the usability tests, and I instantly realized how much I hate PDFs that are 8.5 by 11 inches. What a horrible shape for computer screen viewing! So why would a set of online instructions be that size? Even though the instructions in question were actually scanned in, that's something I'll remember when I put my instructions together if my reader environment is computer-based.
In a lot of ways, the design portion of the instructions project will be a lot like designing a resume. The end goal is different, but you still have to find ways to motivate your reader to want to look at your document. (Anyone else notice patterns developing?)
Patterns, Design, and Searchability
I think you make excellent points about design and the relationship to resumes, or rather the overall pattern we've seen so far. Audiences are paramount in not just technical writing, but in ANY kind of writing. A great piece of writing for one audience might be the worst writing possible for another audience, even though absolutely nothing may have changed in the document.
You also make an excellent point about searchability. I think the suggestion was implicit in the readings when talking about design, use, etc. but it didn't explicitly discuss it. An excellent index is important, and in my experience, hard to develop. I wish the readings would have addressed it more specifically.
Kristin
Instructor blog #5 is devoted to design
Our next instructor blog deals specifically with design, which is an issue that gets neglected a bit. Design is not a veneer of aesthetics over a functional core; design is how people interact with products (including data-based products, such as documents). People want to say "can't I just put it out there simply and clearly?", but that's the rub. There is no neutral, baseline accessible format. Something that is simple and clear is no less constructed than something rich with decoration. Indeed, making something clear is often a vastly more difficult communicative challenge than making something attractive.
We'll deal with this more specifically next week, but design certainly underpins much of what we do as communicators.
Jump Right In
I think that everyone that buys a video game jumps right in and does not read the pamphlet because usually the pamphlet does not tell you much about the game besides controls. The example of the new tool that you had to use was interesting and correct. Either you needed to get the job done quickly and went to the bold parts, or you can take forever and become a professional with the tool by reading the manual. Usually in industry the job is not to do the best job possible, it is to get it done as quickly as you can. This makes user manuals almost ambiguous.
ASAP
Get it done as quickly as you can.
That's a good point. And I think that could be reflected in our instructions for this project. Conciseness is especially important in this case.
That said, I assure you that I actually did the best job possible once I figured it out, in addition to doing it as quickly as I could!
Searchability
I like your commentary on the searchability of instructional documents. Last summer I was put in charge of managing our companies Nortel phone system. The user manual was 240 pages, and all I needed to do was update a button with a new function. The index of the instruction manual was fantastic, and had headings for basically every individual topic a user could possibly want to address. The function change was really easy because the instructions were clear, and made good use of graphics. However, if I wasn't able to easily locate the page with the instructions, even though they were clear and concise, it would still have taken a vast amount of time to update the button.
My point exactly
A good index becomes more important the longer a set of instructions is, especially with documents like software manuals. Another thing to consider is that a new uer might not know the name of what he or she is looking for. I know this happened to me when I first picked up Dreamweaver. At that point I knew I wanted to add a navigation bar at the top of my website that wouldn't move when you scrolled down. I didn't know it was called a frame, even though it seems obvious to someone who isn't a complete novice. It took me a long time to find what I was looking for, and there was no way I was going to read 300 pages.
Although the need for an index decreases with document size, as I said before, a good, easily-identifiable structure acheives the same thing, for those who are too lazy to read even one full page. And let's face it: Most of us are.
Indexing and Design
Finding the right information in a technical document is key. Often there’s one thing I want to know and I want my answer quick. This is where taking advantage of a table of contents, index, and appendices really can make or break a document. Many times you’ll be dealing with a paper document and have to use a little manual searching. Being able to simply look up a keyword can make the dreaded process a little more pleasing. I also will agree with your comment about design. It never really occurred to me how a documents physical size and layout can really make it a little more pleasing to the eye and ultimately more effective.
Raiders of the Lost Instruction Set
Your response brings back the discussion about users raiding the information for what they need. Your example about how people use video game manuals is great. Imagine how frustrated people would be if they just wanted to find out where a certain menu was and they had to read through the whole manual just to find what they wanted.
Talking about video games brings up an interesting point. In most video games there is a tutorial where they show you pretty much how to do the basic functions and features of the game. However unlike instructions, you can get instant feedback on whether or not you are doing the right thing. If they want you to jump and you punch then a dialog box of some sort usually appears describing the correct button.
Andy
Game Manuals
I agree with you about raiding game manuals. Its so much easier to just flip through and find what you are looking for instead of reading a bunch. I think the writers of game manuals do it right by showing the button layouts so that you can quickly see what buttons do what. This goes back to making use of pictures again and how helpful they can be. I would hate to have to read text about what a button on a controller does.
-Chris