Case/Pass
Barker ch 10
Barker discusses document design and its obstacles in chapter 10. He covers issues such as meeting user needs, how to accommodate specific user groups, as well as the different tools available for writers.
Fist we are given ‘Guidelines for Designing Documentation’
1. Create a table of contents
a. This can help a writer organize their document as well as assist the user in many ways
2. Match the user analysis with information design strategies
a. Design for different groups
b. Design for specific program issues
c. Meet user task needs
d. Meet user information needs
e. Match user computer experience
f. Enhance user’s subject-matter background
g. Leverage the user’s workplace
h. Meet the user’s learning preference
i. Meet the user’s usage pattern
3. Acknowledge production constraints in document design
a. This is where writers evaluate what the want versus what they can do
4. Test and review the design
a. This is best done with a form of usability testing
5. Follow a design process for online help
a. Online help uses topics
· About
· Module
· Action
· Problem
· Question
· Task
· Update
· User Group
The next part of chapter 10 deals with the Design Problem. In short, this is when the writer attempts to accommodate many users with one format. This is especially difficult in print because users’ search abilities are limited. To help remedy this problem the writer must first categorize his users. This can be done in multiple ways; two the book suggests are using computer experience or level of professional use. After the groups have been identified, the writer can then begin to analyze the users’ problem solving methods. Some points to keep in mind when doing so are:
1. No one reads carefully so keeps things short and accessible
2. Most users do not read the entire manual, instead they do specific searches when the run into problems.
3. Users wait until the have failed a task to look for help and are often impatient at this point.
4. Most readers do not bother reading introductions because they feel they are not related to user needs
5. Most users do not read any one section in its entirety; instead, they filter information while scanning.
After looking at the issues writers face when accommodating to their audience, Barker offers us an overview of the tools available to writers as well as a brief summary of how they are best used. Some of the design tools he referred to were
· Navigation
· Cross references
· Running headers and footers
· Layering
· Headings
· Advanced organizers
· Document overview
· Parallel structure
· Cuing
· Bookmarks
· Histories
· Pop-ups
· Links and jumps
Barker ch 10
Barker discusses document design and its obstacles in chapter 10. He covers issues such as meeting user needs, how to accommodate specific user groups, as well as the different tools available for writers.
Fist we are given ‘Guidelines for Designing Documentation’
1. Create a table of contents
a. This can help a writer organize their document as well as assist the user in many ways
2. Match the user analysis with information design strategies
a. Design for different groups
b. Design for specific program issues
c. Meet user task needs
d. Meet user information needs
e. Match user computer experience
f. Enhance user’s subject-matter background
g. Leverage the user’s workplace
h. Meet the user’s learning preference
i. Meet the user’s usage pattern
3. Acknowledge production constraints in document design
a. This is where writers evaluate what the want versus what they can do
4. Test and review the design
a. This is best done with a form of usability testing
5. Follow a design process for online help
a. Online help uses topics
· About
· Module
· Action
· Problem
· Question
· Task
· Update
· User Group
The next part of chapter 10 deals with the Design Problem. In short, this is when the writer attempts to accommodate many users with one format. This is especially difficult in print because users’ search abilities are limited. To help remedy this problem the writer must first categorize his users. This can be done in multiple ways; two the book suggests are using computer experience or level of professional use. After the groups have been identified, the writer can then begin to analyze the users’ problem solving methods. Some points to keep in mind when doing so are:
1. No one reads carefully so keeps things short and accessible
2. Most users do not read the entire manual, instead they do specific searches when the run into problems.
3. Users wait until the have failed a task to look for help and are often impatient at this point.
4. Most readers do not bother reading introductions because they feel they are not related to user needs
5. Most users do not read any one section in its entirety; instead, they filter information while scanning.
After looking at the issues writers face when accommodating to their audience, Barker offers us an overview of the tools available to writers as well as a brief summary of how they are best used. Some of the design tools he referred to were
· Navigation
· Cross references
· Running headers and footers
· Layering
· Headings
· Advanced organizers
· Document overview
· Parallel structure
· Cuing
· Bookmarks
· Histories
· Pop-ups
· Links and jumps
posted by Lindsay | 7:21 PM
9 Comments:
When I first examine a documentation project I can usually envision right way the design (logical structure) I wish to employ.
I don't waste time creating a standalone outline of the document - I use the document itself as the outline. My approach is to complete a document by making multiple passes through the document - performing specific tasks in each pass:
1. I create the logical structure of the document complete with sections, subsections, etc. Once completed I have the actual document - it is just missing the text.
2. I write the text into each appropriate section of the "shell" of the document I created in the previous pass.
3. I format the contents (though much of the formatting is automatically done for me if I am using Information Mapping).
4. I edit the document.
Done. On to the next job.
I think the more we read in this class, in any text, we find it's always very important to identify the audience and their intended usage. I found myself examining my document design when I used RoboHelp to do our help topics. I guess the more familiar I become with RoboHelp the more time and effort I would put in to the document design. Right now, I was just happy to get the thing done but I imagine there are many things that you can do on RoboHelp in order to dress up the overall appearance.
I think the more a person writes documentation, the easier it is to see the big picture and forgo some of the steps Barker talks about. It almost becomes second nature...as it has for Carl. The new tools we're being introduced to in this class seem to lend themselves to a more structured way to write/set up documentation.
I have to admit that along with Carl I don’t necessarily make an outline of the document that I am writing. Usually I will spend some time mapping it out in my head what I want to write down, but the structure doesn’t really start taking effect until I am actually writing the document. For me, the editing process is ongoing, I am editing literally while I am writing the document. It’s a fluid structure, the document can end up taking turns that I didn’t see coming. Of course, I still do an official edit when I’m done writing, but I try to incorporate it into the actual writing.
This chapter reinforces just how much document design revolves around the user. Barker frequently refers to the user analysis, and advises to meet user's need/preference/experience/etc. This is very important in creating documents. I really agreed with Barker's advice to keep things short since users tend to skim through documents. I find myself skimming over instructions and help documents all the time - sometimes I even think to myself how much unnecessary information these types of documents often have.
I think the author nails it on this chapter in many ways. Design considerations are extremely important to assure that the documentation is usable and is used by the intended recipients.
I know that in my own experience I have to agree with Barker on the second portion of the chapter. I know I don't have time to read everything carefully, that I generally search for specific problems, that I wait until I have a need (failed task) to (impatiently) look for help, and that I filter information by reading only what I think I need.
The tools that the author suggests we use are good examples of signposts that will direct the user to whatever information they feel that they need when they need to use it.
Most of the time I do most any project, I make a general outline and then fly by the seat of my pants. That method isn't the greatest but it has been working for me and if it ain't broke, don't fix it.
Everyone’s comments bring up good points with document structure and audience. I also like the lay out in the chapter with the break down of each of the different elements needed for different project as with designing for different groups, design for specific program issues, meeting the user’s task needs, and so on. Knowing that there is a difference and how to respond to each as a separate situation verses a one-size-fits-all approach produces better documents.
I've always created the table of contents dead last; I figured since I wouldn't know the page numbers until I was done, why bother? Organizing the document mentally does make sense though, I'll have to keep that in mind for the future. I also like the point that in print a users search ability is limited, it's annoying to have a printed version of an online help file because you can't access the online version when you need the help, and the organization is virtually non existent.
Post a Comment
<< Home