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.
Subject:Re: HTML Help and stability From:Tim Altom <taltom -at- SIMPLYWRITTEN -dot- COM> Date:Wed, 4 Nov 1998 09:14:06 -0500
>This may be really obvious, but it occurred to me that one major
>impediment to a stable HTMLHelp standard (similar to the relative
>stability of WinHelp) is the litigation currently underway in
>Washington, DC. If the Justice Department rules that the IE browser
>cannot be an integral part of the operating system, MS's HTMLHelp
>standard becomes totally non-standard and funky.
It's a sign of our times that we as professionals have to watch an antitrust
case so closely, so that we can advise our bosses and clients. You're
right...I have to consider the case when I talk to clients who have products
that will reach maturity in the next couple of years. It'll definitely
affect our help file planning if IE isn't going to be an integral part of
the next generation of Windows. It's yet another reason to think seriously
about sticking with WinHelp.
>So I don't have any insight on what to do, and remained a bit stymied as
>I try to decide how we're going to develop a new help system -- WinHelp?
>WebHelp? Probably both.
You do, however, hit here upon one of the few compelling arguments in favor
of an HTML help system: web portability. If a client is intent on using both
online and Web help, I wouldn't develop both WinHelp and HTML help
simultaneously unless he had a lot of time and money. I'd advise HTML help,
then work with him to make sure that the IE dll is definitely loaded along
with the rest of his software. The end user, even if a diehard Netscape fan,
would never even know that we'd actually loaded part of IE on his system.
In the future, I'd even look seriously at using a markup document in XML
instead of HTML, once the browser/dll can handle it. With XML, I can give
the user categories of search, rather than having to anticipate all the
search words for him, or making him do a full-text search.
Adobe Certified Expert, Acrobat
Simply Written, Inc.
The FrameMaker support people
Creators of the Clustar Method for task-based documentation