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.
I'm in a similar situation -- I'm the only writer for a small
computer engineering firm. Once again, we're producing
a limited run of a new product, to be installed and evaluated
at a number of beta sites. The product is changing daily,
and will continue to do so throughout the beta testing.
It's weird, but I really enjoy working in these kinds of
conditions. I like the challenge of trying to keep up with
everything, and it involves you with the development process
much more so than just being handed a static product to
document.
That said, I don't have any perfect solutions, but here's
what works for us:
- I print and coil bind the beta documentation in-house,
using a Plastikoil binder. Every new installation gets
documentation that's as up-to-date as I've got. And
at least it describes the product as it exists at that
time.
- I place the "publication" date on the copyright page.
- I mark the documentation clearly as "DRAFT" or as
"Preliminary Documentation".
- I keep the Technical Support people supplied with
up-to-date, dated drafts. Then when they're on the phone
with clients, they can find out what version of the
documentation the client has (from the date).
- I try to keep in close touch with Tech Support.
The feedback tells me what parts of the documentation
needs more work.
- When customer sites get upgraded to the final version
of the product, you provide them with the nice, shiny,
final version of the documentation and ask them to
throw the draft documentation away.
This has worked fairly well for us in the past. Our audience
differs from yours --- our "users" tend to be Sys Admin and
Technical Installation people. They'd rather get whatever
documentation is available than no documentation at all.
I'm not sure how this would go over with a less technical
audience. Are they aware that they're getting a software
product that's still changing?
Anyay, good luck with it, and try to have fun.
Penny Staples
pstaples -at- airwire -dot- com
> I am the only technical writer working for a small
> company producing a database which will be used by mostly
> computer illiterate individuals. Our software is changing
> daily. However, I have been asked to provide a "Limited
> Edition" manual which will be printed soon. The manual
> will be outdated almost as soon as it leaves the office.
>
> In the past, this company provided manuals long after
> completing the software; they really want to change
> this by providing a manual with the software. I agree
> with this. I plan on providing an updated version of
> the manual (in help format) regularly as we continue to
> adjust and enhance the software.
>
> Has anyone tried this? What were the results? How did users
> react? Is this likely to discourage further use of the manual?
> Is this just part of developing software (my first run at
> version 1 of a software)?
>
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
