RE: HTML v .hlp

["Glenn Maxey" <glenn -dot- maxey -at- voyanttech -dot- com>]

Warning, the following contains rants about Microsoft. No criticism or
offense was intended for either of the two earlier posters.

> -----Original Message-----
> From:	Brierley, Sean

> > -----Original Message-----
> > From:	Paul Hanson [SMTP:PHanson -at- Quintrex -dot- com]
> >
> > A technical support person wrote
> > to me today and stated that "the reason that HTML Help seems to get more
> > attention is because the vast majority of our users have told us that
that is the
> > direction they are moving, either to chm or Webhelp."

> Well, Microsoft about 4 years ago announced they were putting
> WinHelp (HLP) into maintenance mode and were supporting HTML-based help
> (which turned out to be CHMs).

I'm sorry, Sean, but your choice of language made me gag on my lunch, what
with "Microsoft" appearing in the same sentence with "maintenance mode" as
it relates to WinHelp.

<Rant>If this is the case -- which I don't contest --, then "maintenance
mode" means "don't do a damn thing" in the Microsoft dictionary. In some
cases such as legacy problems in Word going back to Winword2, it is hard to
distinguish between "maintenance mode" and an "active release mode." They
still haven't done a damn thing. [The reliability of section breaks comes to
mind; Style implementation; master document feature, although it doesn't go
back quite as far as Winword2.]

All Microsoft really accomplished with that HLP/HTML announcement was to
scare the technical writing community into putting various projects on hold
with the misguided belief that something better was right on our doorstep.

Well it wasn't. And it still isn't as is evident by any attempt no matter
how small to work with [Microsoft] HTML Help.

They've been promising us [Microsoft] HTML Help for 5 years and they still
haven't delivered. It still doesn't do what Winhelp does unless you can
program in their proprietary programming languages, like ActiveX or
JavaScript (yet another bone of contention). It is slower than WinHelp. If
you aren't using a help authoring tool, you can forget about simple things
like browse sequences, indices that are automatically alphabetized, even
effective document management, etc.

Let's also not forget that the source HTML files produce different results
when used standalone or compiled into a CHM file with the HTML Help
compiler. ("<A href=bogus.pdf>link</A>" can be a pretty handy reference on a
webpage or standalone HTML system. Compiling that HTML file into a CHM file,
though, nets you a huge CHM file with the PDF file embedded in the middle of
it.)

<\Rant>

> Uncompiled HTML-based help and Java-based help
> solutions can work via any browser on Macs and Unix, as well as Windows.

> HTML-based help is the way to go because it is the future and MS has
> announced the end of WinHelp development. HTML-based help is the way to go
> because it is potentially and really cross platform. HTML-based
> help is the way to go because HTML is a lot easier to fuss with than
RTF...
> even if the resulting help system has different strengths and weaknesses
than
> WinHelp.

Absolutely no argument there. The only thing I point out is your careful
usage of language: "HTML-based help."

<Rant>We're forced into being careful with our word choice, because
Microsoft has polluted the name space by saying "HTML Help" is their (weakly
supported) product, a very poor choice; WinHTML would have been infinitely
better at avoiding confusion.

To the uninitiated, "HTML Help" logically could have had the meaning "a help
system based on HTML" and would have been applicable to any
browser-independent and platform-independent online help system. But,
NOOOooooooo. That wasn't good enough for Microsoft, and neither were
standards for HTML and Java.<\rant>

> On the MS operating systems, CHMs are the way to go because MS has
publicly
> supported development in this arena for years and has stated HLP will go
> away. CHM is the way to go because it can be delivered as one
> file, like HLP which exists as two files (HLP and CNT).

The only caveat to this sound advice would be: if you have legacy WinHelp
(RTF/HLP), you will not always be able to cost-justify coverting it to HTML
Help. Because conversion isn't without error and Microsoft doesn't even do
it, Microsoft is going to end up shipping the "maintenance mode" WinHelp
executable for a lot longer than they will publicly admit. And when they
stop, they'll be forced into giving you permission to ship it with your
product. So don't worry.

On the day HTML Help is a fast and as reliable as WinHelp and is
out-of-the-box as function-rich as WinHelp, that'll be the day to completely
embrace this "new" technology.

> Also, with support for ActiveX, and
> other web technologies, such as Java Applets, JavaScript, etc., you can
> customize the help quite a bit.

<Rant>... Only if you are a programmer or a very technical technical writer
while at the same time having lots of time to tweak things. Worse, if you
tweak your HTML source documents with lots of bells-and-whistles (or even
some very necessary functionality) using these wizbang technologies, don't
expect your HTML source documents to be useful or functional to any browser
application except HTML Help (a subset of Microsoft Internet
Explorer).<\rant>

> It's not that HLP doesn't work. It is that HLP has gone as far as
> it will go ... for better or worse. Sure, there's things you'll prefer in
HLP over
> CHM, but suck it up. Change the way you develop. Move on . . ..

There is no denying that HLP has gone "about" as far as it will go. However,
certain very helpful RoboHelp DLL's clearly illustrate that it can be pushed
to go even a little bit farther. I wouldn't be completely advocating sucking
up to CHM.

You need to take into consideration the expected life of your product and
what your customers are using.

I just completed a year working for an Austrian company. One of the carrots
dangled in front of me when I hired on was the prospect of taking them into
the realm of CHM. If we ignore all of the structural and language problems
that they had in their HLP system which needed to be addressed first, I
still couldn't cost-justify making the conversion to HTML. I could justify
using the RoboHelp DLL to give them the "HTML-Help-like" tri-pane
navigation. But I could not justify wasting time converting to HTML Help
just to have it be slower WITH NO NEW CONTENT. Conversion gave no additional
benefit to the customer, and in fact, would have made it worse.

Keep an eye on HTML Help. When it really does do out-of-the-box (or
upon-download) all that they claimed it would do (preferably without a HAT);
when it supports XML (without tweaking); when it no longer "improves" upon
the standards and no longer makes your source incompatible; when they really
do improve it and make it fast; THEN it's time to get on their CHuMmy
bandwagon.


Glenn Maxey
Voyant Technologies, Inc.
Tel. +1 303.223.5164
Fax. +1 303.223.5275
glenn -dot- maxey -at- voyanttech -dot- com


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY.
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by DigiPub Solutions Corp, producers of PDF 2001 
Conference East, June 4-5, Baltimore/Washington D.C. area.
http://www.pdfconference.com or toll-free 877/278-2131. 

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.