Latest posts by techwriter (see all)
- 15 Questions to Ask After You Finish a Technical Document Project - February 12, 2018
- THY’s Perfect Information Design - February 9, 2018
- Waterfall vs. Agile Models in Technical Documentation - February 7, 2018
© Ugur Akinci
The User Manual Manual : How to Research, Write, Test, Edit & Produce a Software Manual by Michael Bremer (Untechnical Press Books for Writers Series, 1999, 314 pp) is a useful text book to learn not only the techniques of producing a software manual but becoming more aware of the “organizational ecology” of a software company as well.
Bremer does a pretty good job in describing what kind of an experience it is to work for a software company, with its many divisions and departments including development, testing and QA, technical writing, technical support, customer service, etc. He explains the way technical writers should interact with these organizational components and how they can make life easier for themselves. It’s the sort of advice that only a technical communicator who has worked for years for a software company can provide. It’s valuable.
If you are a technical writing planning to work for a software company you’ll find the section on “Software Development Lifecycles” priceless. After giving a brief historic background, Bremer introduces several different life-cycle management models, each accompanied by a great illustration.
One unique feature of this book is the way the author builds up a whole manual for a fictitious “The Personal Newspaper”, starting with the first draft. This mini-manual does not have anything to do with software. So that’s a bit disappointing in a book devoted to software manuals. But nevertheless it’s the sort of comprehensive 35-page mini-document, complete with Heading styles and Appendices, that you can use as a template for your own manual. It’s definitely useful if you don’t know where to start to build your software manual.
Bremer does not stop there. After addressing the issues involved in editing and reviewing a manual, he provides the second draft of the same mini-manual, showing the students how to improve their manuals in successive stages.
One shortcoming of this book is that it’s geared mainly for print production and hard-copy documentation. Even though he briefly discusses “onscreen help,” this is a book that’s especially useful if you’re going to end up printing your manual the old fashioned way. If you’re into online publishing, single sourcing, User Assistance authoring, and other forms of non-print production, you might want to complement this work with other books written specifically for on-line documentation.
A comprehensive work written by an experienced technical writer who developed the documentation of the popular video game SimCity.