Barker Ch 14

Chapter 14 - Designing Indexes

When I read this chapter I thought of my English 475 Technical Editing class where Dr. Nord told us, "Indexers make a substantial amount of money...probably because no one wants to do that job!" Barker did a good job making the indexing task look less tedious than it actually is, but still showed how detailed the procedure can be.

Barker does mention that indexing can be very redundant work, but he says it's usually we don't realize how important this work truly is. He says that indexing performs a uniqute function by directing users straight to the material in the manual, therefore it is one of the most important functions. It also is the meeting place of multiple users, meaning that all users can find the terms they use and be directed to the information they need.

Campbell Chapter 12

Chapter 12 is about online documentation. It points out that going online with documents will not make them easier for people to understand; it's just an alternate form of delivering your document(s). It lists advantages and disadvantages with going online. Some of the advantages listed are being more efficient than the paper system, delivering the message instantly, less costly to maintain, and save storage space. Some of the disadvantages that are listed are that people who are not comfortable with computers may go back to paper copies, it may require a significant budget, and readability is less than that of a paper document. The chapter also lists some online design considerations.

I think a good example of going online would be the process of registering for classes at MSU. Students used to be able to register on paper or online, but it has changed to online only. Some people might find it much easier, but others who are not familiar with the process may find it problematic.

Barker Chapter 13

This chapter teaches us how to use graphics effectively. If Phillip VanWynGarden would have read this chapter, we wouldn't have had as much work to do on our usability project.

While there was a lot of information covered in this chapter, one of the more important topics covered is under the "Where Is It?" heading on page 408. When I read the section about showing the user where to look to perform tasks, I couldn't help but remember our original Usability document. The large image of the motherboard wasn't clearly labeled, so the user wouldn't know where to look for help. The smaller images weren't clear enough for the user either - I thought they were too upclose for the user to even know where to look.

In the end, I think that we did a great job with our images on the Usability project. I think the image team did a great job of labeling and highlighting the images so the user could understand them.

Barker Chapter 11

Barker chapter 11 is titled "Laying Out Pages and Screens", and covers various design aspects for both print layout and electronic layout.

While this may not be the most abstract chapter thusfar, it is clearly one of the most useful chapters for anyone interested in creating documents--either electronic or print. Some of the important aspects of desktop publishing this chapter covers are creating grids, pagination, margins, styles, and various other topics important to any technical communicator. Basically, everything in this chapter is a review of what gets covered in the Desktop Publishing and Technical Editing classes offered here at MSU.

One interesting part of this chapter is the information on different webpage design structures. The chapter covers a lot of details about creating internet help pages specifically, as long as other various page types.

The chapter ends with some information on creating user-friendly help pages, and is very timely with the robohelp project we're working on now.

Barker Chapter 12

Barker Chapter 12 deals with proper wording and language of software documentation. This includes such practices as creating parallelism (“Opening a file, Closing a file…”), using active voice (“Press ALT + N to open a new window.” not “A new window is opened by pressing ALT + N.”), keeping wording simple, and writing about user actions rather than computer/program functions. Barker goes on to describe several ways to confuse readers such as using too many acronyms, abbreviations, and synonyms; making sentences and paragraphs too long; and either being too formal or (trying to be) too humorous. Even if your documentation is technically accurate, it won’t do users any good if they do not understand the terminology or are turned off by a poorly placed joke when looking for support.

Campbell Chapter 11

In this chapter, Campbell takes a look at revising documents that have already been written. I think she brings out a good point when she says that we need to switch from development to maintenance phase. Keeping documents up to date is a constant battle. As technology, procedures, and the business environment change we need to stay on top of the documentation that supports these efforts. Out of date documentation can cause more problems than they solve.

I like how every sample document in the chapter includes a field for recording the date. I think it makes revising work a little smoother if you can put all your comments and suggestions into a timeline.

Setting dates for revision also seems like a good idea. If you’ve already scheduled the time to perform documentation revision, you won’t be scrambling to squeeze it in to an already crowded schedule when the revision needs to be done. The documentation will probably turn out much better if you have the time to do it right rather than making it a rush job.

Barker Chapter 10

Designing for task orientation
Barkers chapter 10 is all about writing to meet your users specific needs. It starts out by describing different ways to organize your information to meet your users needs, and then moves on to writing to meet the user level of knowlege. Barker talks about how taking advantage of your users skill level in your subject changes how your documentation should be writen. Alot of the concepts covered by Barker I deal with every time I write some documentation I alway state who the audience is and what kinds of prior experience they should have in the Introduction to any documentation I write. For instance if I write some documentation on how to implement a wait screen for any user requested data on a web page, I would state the you should have some idea of what JavaScript is and have a fairly decent understanding of doing your own HTML coding.

Campbell Chapter 10

Chapter 10 is all about implementing changes and doing things differently in a company. Though resistance should be expected, Campbell recommends that you never give up, because no matter where you work you are going to encounter similar problems. She says the way to deal with problems is through early communication with negatity; the sooner it is handled the better chance you have of problem solving. Then, continue education - keep talking to people and get their input. Lastly, give final notice. Sometimes you will just have to agree to disagree with some people and they will have to learn to live with the change.

Barker Chapter 9

This chapter took a look at editing. This chapter reminded me much of an editing class I took a few semesters ago and it was a good review of what I learned in that class. Things like editing plans and different types of editing were all things that the editing class covered, but one thing I liked about this chapter was how it mentioned to keep editing editing. In other words to keep other things out of the editing process that really aren't necessary for editing. Another thing that I really liked about this chapter was the reference to editing for cross culture audiences. That is something that I haven't really been exposed to, but it is a major reality in the world. Something that may be acceptable in our culture may be something that is deemed unsuitable in other cultures. I also found the idea of various languages used for cross culture writing like the Globalized, and localized languages.