Inaba, Parsons & Smillie, Chapter 2 Summary - (Haupt)
This is an excellent introduction to procedure writing. For my own definition I've always thought of a procedure as a set of steps that a person performs to achieve a specified outcome. I consider a "process" to be a set of related procedures. Inaba, Parsons & Smillie offer us a similar definition - "procedures as instructions that lead the user step by step through a number of tasks until the work is completed".
I agree with the principles of procedure writing taught by Inaba, Parsons & Smillie but I feel they do not delve deeply enough into the analysis of information types. If any of you ever have the opportunity, take a class from Information Mapping, Inc. (www.infomap.com) called "Developing Policies, Procedures, and Documentation". The theory behind Information Mapping is that all information can be categorized into six different Information Types. One of these types is an action type called a "Procedure." Once an author identifies that he is dealing with a Procedure, he can utilize various Information Mapping techniques to write the procedure. The most common technique is a Step-Action table. In other words, you create a table with all the steps numbered. Then in each row you enter the specific action a user takes for that step. I can't teach the entire method here as that would violate Information Mapping's copyright - but I highly recommend the user of Information Mapping in real-world projects. The Information Mapping methodology can be used within Microsoft Word as a plugin called Formatting Solutions. A second plugin, called Content Mapper, allows technical writers to use the Information Mapping methodology in a structured documentation environment, i.e., an XML data repository.
Inaba, Parsons & Smillie wrote this as a very short chapter - but they made a number of good points in these few pages: 1) Procedures contain steps and step represent user actions, 2) be aware of the need of "packaging" information into large organizational units such as chapters, 3) be aware of the perils of cross-referencing, 4) multiple models require multiple sets of procedures, 5) integrate text with graphics, 6) plan the project prior to writing the documentation, and 7) be flexible - requirements vary.
I agree with the principles of procedure writing taught by Inaba, Parsons & Smillie but I feel they do not delve deeply enough into the analysis of information types. If any of you ever have the opportunity, take a class from Information Mapping, Inc. (www.infomap.com) called "Developing Policies, Procedures, and Documentation". The theory behind Information Mapping is that all information can be categorized into six different Information Types. One of these types is an action type called a "Procedure." Once an author identifies that he is dealing with a Procedure, he can utilize various Information Mapping techniques to write the procedure. The most common technique is a Step-Action table. In other words, you create a table with all the steps numbered. Then in each row you enter the specific action a user takes for that step. I can't teach the entire method here as that would violate Information Mapping's copyright - but I highly recommend the user of Information Mapping in real-world projects. The Information Mapping methodology can be used within Microsoft Word as a plugin called Formatting Solutions. A second plugin, called Content Mapper, allows technical writers to use the Information Mapping methodology in a structured documentation environment, i.e., an XML data repository.
Inaba, Parsons & Smillie wrote this as a very short chapter - but they made a number of good points in these few pages: 1) Procedures contain steps and step represent user actions, 2) be aware of the need of "packaging" information into large organizational units such as chapters, 3) be aware of the perils of cross-referencing, 4) multiple models require multiple sets of procedures, 5) integrate text with graphics, 6) plan the project prior to writing the documentation, and 7) be flexible - requirements vary.
posted by Carl Haupt | 7:13 AM
5 Comments:
Again, I think it's important to listen to what you use in the real world for technical writing. However, I think that this chapter strips down a somewhat complicated process and shows us how to come up with an end result without getting to complicated or technical. I like the fact that this chapter addresses us as if we are all inexperienced writers and if we follow their steps and layout procedures we too can come up with a desired end result by breaking down a much larger process in to several smaller ones.
I like the idea that a process is a series of related procedures--it's kind of intuitive, really.
I think the authors' use of a pyramid to descibe the relationship between tasks, steps and actions is good. It shows that tasks are the smallest unit of the procedure, then steps to perform the task grow in complexity, and finally, the actions needed to perorm the steps are the most complex.
A comment about tables-most "procedures" as we know them are typically written just as a two-column table would be written. The numbered steps are in the first column and the actual actions are placed in the second column.
I appreciated all of the definitions included in this chapter that described steps, tasks, and so on. I've never really thought about instructions as separate elements like that, but this text really made it clear.
The sentence that really stood out to me was in the Role of Memory section, where it says "Using information helps to embed the information in memory." I find this true in learning any kind of procedure. I am especially dealing with this idea in a graphic design class where the professor lectures for a long time showing different tools and tasks without letting the students try them out for ourselves. It's frustrating because by the time I get to try a procedure, I have already forgotten the steps to take to fulfill it.
I am growing to like this book. It's very concise and well thought out.
I don't really think this chapter was trying to turn us away from cross-referencing, but simply trying to warn us to not overuse it (speaking of cross-referencing, couldn't you conider cross-referencing to be method of content management, since you are preventing sections from being needlessly repeated?). Keep it simple, ergonomical, and logical.
The pyramid diagram confused me for a moment, until I processed the rest of the chapter. As I understand it, tasks, steps, and actions are all hierarchically related. The task is the general process to be completed, the step(s) are the broken-down sections of a task, and the action(s) are the broken-down sections of a step.
This chapter helped me to think of instructions as more of seperate, connected elements making a whole rather then individual steps that lead to a goal.
It helped me to see instructions as more of a whole rather then step by step.
Post a Comment
<< Home