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.
