TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Two weeks ago, I posted a request for information on how other tech writers handle frequent software releases. I received some great responses and a number of requests to summarize to the list.
Many writers expressed some frustration with their companies' current methods of documenting software releases. (One writer's proposed solution was to give dissatisfied customers the home numbers of the employees in marketing who decided to add features at the last minute. <g>)
Most respondents used release notes (sometimes printed) in combination with updated helps and updated online versions of the printed docs. The helps and online docs are often available from the company's web or ftp site. In most cases, the online docs are updated versions of printed manuals the users already have. (In one case, most of the documentation is distributed only online. The manuals that are printed tend to cover areas that don't change often, such as installation.)
Writers tended to agree that major releases justify reprinting the entire book, but there didn't seem to be any consensus on what determined if a release was major.
I heard from several writers who print their manuals in 8.5 by 11 inch, 3-ring binder format. I envy them, because they are able to send change pages. Their users can easily see what has changed in the release, and then incorporate those changes neatly into their existing manuals. (Some emphasized the importance of change bars.)
Several people suggested shortening our print cycles. The reason it takes a month to print our manuals is because we use OTA binding and there is apparently only one company in the state (Utah) who does it. Our users don't like regular perfect binding. They like wire-o, but that takes as long as OTA (and I don't like not being able to see which book is which on the shelf).
Thanks to all who responded. This list is a great place to vent while getting some ideas on how to prevent the problem in the future. (BTW, our programmers don't like the release schedule any more than we do in documentation. In fact, during the time the initial manuals were at press, they used the documentation as a reason not to implement new features. Somehow, the marketing people still won. It's that old argument: "If we add this feature, we'll make a ton of money. If we don't, the product isn't worth anything.")
Melinda Carr (melindac -at- capsoft -dot- com)
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
