Working with the Technical Writer

Once the ball is rolling, working with the technical writer generally requires keeping the technical writer informed of significant changes to the program and reviewing intermediate results.

I have to admit that I find reviewing documentation one of the most tedious tasks. It's no fun, and it seems to take forever. Is there an alternative? Unfortunately no—you have to suffer through it. Although you might be able to have QA testers do some of the reviewing, it's ultimately up to you to make sure that the documentation is accurate and complete.

I find it most convenient to use the change-tracking feature in Microsoft Word. You can set up Word to use revision bars and highlight changes to clearly indicate what changes have been made. The comment feature is also very helpful, since you can embed any comments you have within the document itself. The comment feature is especially helpful in a group project in that it lets you see the comments made by all the other team members.

If for any reason I can't track changes using Word, the next best alternative is to mark up hard copy. When I am done reviewing the documentation, I go over it with the technical writer and keep a duplicate of the marked hard copy for my records. That way, when I get the next release I don't have to start completely over. Rather, I can focus on the areas that I found needed work. The last thing I want to do is completely read every draft.

Unless the user interface is stable, I recommend against making screen shots until the end of the process. Constantly updating screen shots is a fair amount of work with little benefit. After all, the people reviewing the Help at this point already know what the program looks like.



Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net