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.
Subject:RE: Which came first: the manual or the help? From:"Beth Kane" <BethKane -at- TCISolutions -dot- com> To:<TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM> Date:Wed, 15 Sep 1999 14:28:53 -0700
I have tried it both ways. At first I was determined that the book should be
written first. But I was later surprised to find that it was much easier if
I wrote the help first. This is because help is so modular. Writing the help
first is very much like single-sourcing, because you end up with lots of
concise pieces that can easily be brought together in various ways, with
some tweaking.
It also turned out better if we wrote the help first because, as soon as the
product was pretty much/kind of working ("feature complete"), it went off to
beta testers -- and the company wanted context-sensitive help in place for
beta, a long time before a book would have to go to press. So our process
evolved such that context-sensitive help was the top priority. Next, we'd
write the task-oriented, how-to topics -- VERY easy to do, when you already
have context-sensitive topics to work with. Then heavy indexing. Then the
overviews. Next we'd start bringing all of this into a manual. A book takes
longer to write because of the necessarily structured flow, the maintenance
of continuity.
This worked great for our company, which had frequent new products and short
deadlines. Yours may be different. (We did some planning too, but didn't
have a lot of time for it.)
We also found, beta after beta with different products, that beta testers
are the kind of people who like to poke around in an interface -- not thumb
through a paper book. If we had the context-sensitive help in there right
off the bat, they would find it, read it, and not call for support so much
(saving us time/money). In earlier days, when we would give them a draft of
the book first, we found they didn't read it. We figured this out from their
answers to the periodic beta surveys (which they were required to answer in
order to get the product free at the end of beta). Any survey questions
about the book were virtually ignored. Questions about help received some
response.
Note: This post is written in past tense because I no longer work for that
co. I don't yet know the processes at my new job, but I do know we're
looking into WWP for single-sourcing.