Move to HTML help, take II

[Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA>]

Sean Brierley provided more details on his situation:

<<Whichever path I choose, be it WinHelp or HTML help, it
will be the commencement of a process not the continuation
of something tried and true... New products and major
changes to existing products give me quite a large backlog of
projects.>>

That suggests starting with something you know well and
evolving to something new only as required. Until the
backlog clears, staying productive and getting caught up
sound like much more urgent priorities.

<< However, as far as on-line help goes, I am essentially
starting anew. There is no on-going process to interrupt or
change.>>

That's either a frightening situation, or an excellent
opportunity, depending on how you approach these things.
I'd look on this as an opportunity, and take the chance to gain
some control over things. (Or at least the illusion of control!)

<<Thus, are there compelling reasons to start the on-line help
projects as HTML projects or should I continue with
WinHelp. I am very familiar with WinHelp but am not
married to it.>>

Again, unless you're being pushed to HTML help by some
intractable problem with WinHelp, or by strong demands
from your clients, stick with what you know you can do well.
One compromise might be to find out whether your clients
need you to make the move; if they do, then that pretty much
makes the decision for you. If not, stick with what they
already know, and start experimenting with HTMLhelp
outside your regular workload just to get a feel for it and how
it will fit in with your products and process.


--Geoff Hart @8^{)}     Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Patience comes to those who wait."--Anon.


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=