Comments on Engl476576: Case/Pass Barker ch 10 Barker discuss...

I've always created the table of contents dead las...

2007-05-04T17:51:53.909-07:00

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.

Everyone’s comments bring up good points with docu...

2007-05-02T21:11:31.011-07:00

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.

Most of the time I do most any project, I make a g...

2007-04-19T14:28:54.597-07:00

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.

I think the author nails it on this chapter in man...

2007-04-14T19:34:27.966-07:00

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.

This chapter reinforces just how much document des...

2007-04-10T23:19:58.426-07:00

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 have to admit that along with Carl I don’t neces...

2007-04-01T20:46:28.834-07:00

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.

I think the more a person writes documentation, th...

2007-04-01T16:16:56.211-07:00

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 think the more we read in this class, in any tex...

2007-04-01T13:41:40.168-07:00

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.

When I first examine a documentation project I can...

2007-04-01T02:16:01.791-07:00

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.