Re: Estimating Windows Help

["NIVA Inc." <niva -at- MAGI -dot- COM>]

Leslie McKendry-Smith wrote, in part:

-->What figure do you use to estimate the effort to convert a printed manual to
-->Windows Help.  I'm looking for a figure in hours or minutes per topic?

Hi Leslie:

Your post raises two issues, one philosophical and one quantifiable.  The
philosophical issue concerns how/if a hardcopy manual converts to
on-line format.  From the sounds of your quandry, it may be that the
other quotes referred to by your client are simply to "electrify" the paper
document, not create a true on-line document out of it.  This is a huge
problem in our business, because many people do not realize the basic
difference between paper and on-line documentation, in its construction,
organization, wording, intent, and use.  Your client may need a little
education in this regard, to appreciate the scope of the task.

That being said, I usually approach an on-line help project by considering
that any existing paper-based documentation is there for reference only
(and possibly some use of text, but I assume they have our firm in there
in the first place because the documentation they have isn't suiting their
purposes, so probably isn't written all that well).  So, I look at the application
to determine three things:

1.  How many procedures will the user conduct with the application; that
     is, how many high-level functions (e.g., check inventory, hire a new
     employee, estimate a construction job, etc.).

2.  How many screens does the application have.

3.  How many fields does the application have.

Having learned that, I then run a little formula that says:

<n> overview topics, at 100 words each = <n100> words
<n> procedural topics, at 150 words each = <n150> words
<n> screen topics, at 75 words each = <n75> words
<n> field topics at 40 words each = <n40> words

Then, we have a total number of words to be written.  All that's left is to
figure out how many words it is possible to write, process, format, QA,
etc. in a day. (For a first draft, I use 7 pages [250 words each]/day for
writing, plus various algorithms for WP, DTP, graphics, QA, etc.).  Having
done that, toss on a per diem rate and do the math.

BUT, it is then important to remember that creating on-line help is
NOT simply writing, because you also have to build links, do the
help programming, etc.  Assuming you have a good Windows help
creation tool (we use ForeHelp; like it a lot), the programming is no more
difficult than desktop publishing, so doesn't add a lot of burden to the
process.  Building links and such does take a little time, though, so I
usually add about 10 - 15% at the end of the day, just for good measure.

The key to all of this, I think, is to help your client understand the scope
of the effort, and the quality of the product you intend to deliver to them.
Convince them of the value of the overview/procedure/screen/field
approach (assuming you agree with it yourself), and they will soon see
that the resulting context-sensitive, hierarchical, self-referenceable help
file will be well worth the initial expense.

I hope this is helpful.

John Collins
Group Manager

NIVA Inc.
"Canada's Leading Documentation Firm"
mail -at- niva -dot- com
http://www.niva.com