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.
>> "Does anyone know of any metrics out there for planning a
>> Windows Online Help system?"
>>
>> Probably, what should be taken into consideration is how the
>> Windows software is developed? Should the Windows Help schedule
>> merely follow the software development cycle? Does it depend if
>> they are using a structured programming (C) approach or an
>> iterative object-oriented approach (C++), etc.?
>>
>Our experience over multiple projects involving both docs and Help systems is
>that the single bottleneck you're most likely to fight about with developers
>is when the screens freeze. You can't really do the Help tags until you know
>what the windows will look like. And while you can write around the screens,
>you can't really do your screen shots for the docs until the screens freeze.
>We have found it efficient to plan to do the tagging as soon after the screens
>are dependable as possible, but to hold off linking the text until you're
>reasonably sure that the manual's descriptions of them is accurate. That way
>you can do *some* cutting and pasting from the manual, and edit/rewrite as
>appropriate for the other tags.
>It doesn't really matter, in our experience whether they're using the C or
>C++ approach - you can't do Help until you know what the user will be seeing.
>Elna Tymes
>Los Trancos Systems
I highly recommend the book "Developing Online Help for Windows," which proposes
a very workable development process that
recognizes the problems of working with software under development.
You can order it by called 206.285.2830
As Elna says, it all depends on the stability of what you are working with. Do
you have a good, frozen spec? Do you have
a previous version to work with? Do you have a milestone development process
that says certain features are done at each
milestone so you can write about them? All of these things mean you can do
writing with a reasonable certainty that there
will not be much rework. But you can spend time profitably planning your help
and constructing prototypes and the shell
of the system long before you have text to insert.
The book I mention suggests waiting until the print piece is in editing and the
software is in bete, especially if you
are planning to leverage the print work. It is highly ineffective to have two
sets of writers writing about the same
things. You might also consider using a tool like Doc-To-Help that lets you
write once and then "compile" both your book
and your help from the same source file. It allows you to designate things as
manual only and help only so that you do
not just produce completely redundant pieces of information.
