Barker Ch. 1 Summary (Erik Sorenson & Emma Baumann)
This chapter deals with the principles that are applied when a software document is created. It deals with how writers achieve their goals of encouraging users to learn their program and the efficiency with which that program is then used. And on a brighter note, for those of us who are unfamiliar with software documentation, it provides an introduction and many examples.
Barker says that all software documentation should show connections between the new software and how the user will benefit from correct usage of the software in the workplace. He lays out nine steps for production of a successful software manual, which are found on pages 4 – 8. These steps are important to note and become familiar with because they will be a continuing trend throughout the text.
Barker says that all software documentation should show connections between the new software and how the user will benefit from correct usage of the software in the workplace. He lays out nine steps for production of a successful software manual, which are found on pages 4 – 8. These steps are important to note and become familiar with because they will be a continuing trend throughout the text.
Task Orientation is important because, as we mentioned above, it attempts to integrate the software with the user on a professional level, meaning the user and their workplace. Barker contends that it’s not always easy for a user to be truly efficient when using the software manuals because they may inevitably pick the one thing they need to know and dismiss the rest.
Barker goes on to show just how important task orientation is by describing the characteristics of both a default user and a task-oriented user. Basically the default user is the perceived notion that a user just needs to know how the program works in order to apply it at their job. Barker says that earlier manuals were based on this “default user” (who is thought of as simply ‘a person who operates a computer’), which caused many users to often have the following problems: feeling like less job skills are required of them because of the computer’s ability to perform tasks, feeling isolated in their work, feeling overloaded with information, and so on.
Barker then says that designing a document based on what he calls a “task-oriented” user (one whose software use fits with his work environment) would solve these problems by making the program applicable to different workplace tasks. Keeping the task-oriented user in mind while designing software documentation can make the user feel challenged, self-managing, and supplied with information. Instead of developing negative opinions about new software, the task-oriented user will take a positive approach and learn willingly because of the document design. It is important to note the differences between the default approach and the task-oriented approach in order to better understand what challenges may face a software documentation specialist.
Chapter 1 also briefly discusses the three forms of software documentation, and what each one is used for. Tutorials are used to teach users basic actions, procedural documentation is used to guide users through specific tasks, and reference documentation is used to supply information to users about the program. Choosing which form of documentation to create depends both on the user (novice or advanced) and the purpose of the document (to teach, guide, or supply information).
posted by Emma Baumann | 11:57 PM
6 Comments:
I think you two did a great job of capturing the main points of the chapter and presenting it in a very easy-to-understand format. Really good, well-presented synopsis.
As I wrote in my comments on Carl's evaluation of this chapter, I'm not a real fan of this textbook, since I used it Spring semester 2006. It's probably something about the author's writing style that provokes my negative thoughts. What I appreciate about your summary of the chapter is that you waded through the wordiness and found the main points.
How long did it take you two to collaborate on this?
I promise I won't mention my past feelings about this textbook again. Boring.
I think the steps Barker expounds upon on pages 4-8 are important, but I think that a comment he makes further on (page 9) is worth keeping in mind as any documentation is written. The comment states that, according to researcher Barbara Mirel, people use “adaptive computing” to perform tasks. What Mirel means is that “users have to apply software to complex tasks not represented by menu selections.” Put another way, simply writing step-by-step instructions isn’t good enough if the end user can’t apply them to his job. As Erik and Emma point out, you must keep in mind who the end user will be while writing the documentation and note the differences between the “default” and the “task-oriented” approach to writing.
(I think your team did a good job of capturing the essence of this chapter.)
I have to jump on the bandwagon with Larry and Anne. Good summary. Again, like Larry, I agree with your comment about keeping the default and task-oriented users in mind when writing your documents. This was what really stood out to me from the chapter. I’ve seen both of these kinds of users in everyday life, the people who feel defeated by computers and those who seem them as a way of making their jobs a piece of cake. As you two say, it’s important to realize which users we may be dealing with. To ignore one or the other could lead to disaster and our failure as technical communicators. Now, the hard question is how do we cater to both?
I'm in the same boat as Becky. Carl, your terminology and knowledge is far too advanced for me to fully comprehend, so I'll take your word for it.
I also must admit I'm in the same boat as Anne with regards to this textbook. I used it for a previous class, and thought it was much harder to read than it needed to be. But, I'm hoping after a year of further schooling I'll be able to get more out of it this time around.
One thing I want to add to the discussion is this: I wonder if there will be an opposition between this book and our 'Guidelines for Developing Instructions' text. Barker promotes a task-oriented approach, while GDI claims their text will not promote task-analysis.
Obviously, they are not word-for-word the opposite, but it may make for two vastly different viewpoints. I for one would look forward to being given several different ways to look at the same project, so I hope these two books can provide some sort of point-counterpoint relationship.
*note: this post also appears in Haupt's summary of chapter 1. I put it here, too, to make sure my posts appear where they should be.
Great job describing the chapter, keep that up and we won't have to read the book, just your blogs.
Good overview of the chapter. I believe you summed up the importance of what barker is talking about. With Barker 9 steps for a guideline for a successful manual or help system and keeping in mind there being a difference between a default user and a task-oriented user are the key to being successful in document design.
Post a Comment
<< Home