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.
When I was working for a small software development company last year, we
took a risk and developed an extensive online help system for our networked
email product, and did not develop a similar print copy. In print, we had
information for people upgrading from the earlier version of the product,
and an administrator's manual. We specifically stated that the user manual
The reasoning behind our decision was that the product is used on a
network, and the best way to have the manual reach the end-users is to
network it as well. (And not have the single manual we used to mail with
the product sit in the system administrator's office.)
How well did this work? The initial feedback we received was very
favorable; initial users did not miss the paper copy, and were using the
online help, or no help at all. Unfortunately, I do not know how responses
lasted over the long run, because I left the company soon after this
project was completed.
In answer to question #4, we did the project ourselves. I was the only
technical writer, and I worked closely with the software engineers to
develop the documentation as the product was under development. I learned
about the Winehlp compiler and third-party help tools as I went along. We
found this worked well, but keep in mind that 80% or so of my time was
devoted to this product during final stages (last 3 months) of development.
One advantage to documentating in the development stage is that you end up
reviewing and testing every aspect of the product, and in the process can
provide valuable feedback to the engineers.
I hope this helps.
(original message below)
We are currently in the early stages of planning our online doc
project. We're looking for some feedback from those of you who have
already been through the process.
1. Did you replace your paper doc or continue to provide paper doc
as a supplement to the online system? If you still provide paper doc
to your users, is it a full-blown set or a condensed version?
2. Were your users receptive to the change to online doc?
3. Did you provide the online information as part of the help system,
or did you convert the documentation so that it could be viewed online
(e.g., Adobe Acrobat)? What tool did you use?
4. Did you hire a consultant, or were you brave enough to tackle the
project on your own? If you did the work yourself, how much of a
learning curve did you encounter? Any recommendations on training?