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: winhelp or html help? From:"David Knopf" <david -at- knopf -dot- com> To:"Linda McCulloch-Smith" <LindaM -dot- Smith -at- accumap -dot- com>, "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 15 Jun 2000 09:15:21 -0700
Linda,
| Thanks so much for responding.
You're welcome!
| Around here, two wishy-washy ideas are circulating about going to
| HTML Help.
| First, the TOC is always available in HTML Help.
This, I agree, is a very good thing. However, you do not have to use HTML
Help to accomplish this, You also get a persistent TOC wth WebHelp,
InterHelp, WebWorks Help, and the FramesTOC versions of the HTML output from
WebWorks Publisher. You can get a persistent TOC in WInHelp using eHelp's
WinHelp 2000 format, though this of course requires RoboHELP.
| Second, it's the
| latest in
| online help, and we want to stay on the cutting edge.
Well, it might have been the latest thing in 1998, but I certainly don't
think that's the term for it now! Users, in any case, could not care less if
you are on the cutting edge as long as your Help system is meeting their
needs.
| Not exactly
| compelling
| reasons to leave WinHelp behind. I am very concerned that the users will
| have hassles with the HTML Help viewer because they don't have all the
| components necessary to view the .chm file properly.
Users will have to have IE and the HTML Help components. You can automate
the installation of these components as part of your setup/installation
program, but again I don't see any reason to do that unless HTML Help offers
some functionality critical to your Help system that is not available in
WinHelp. If, for example, you really need to run ActiveX controls or Java
applets within your Help system, well you just can't do that in WinHelp.
| Here's some more info for you: I will be authoring in FrameMaker and
| converting to help using WebWorks Publisher. I have, as yet, no idea how
| easy it is to implement context-sensitivity for HTML Help using Publisher.
| It can be done, but I've just never done it before. I do have experience
| implementing c-sensitivity for WinHelp using Publisher.
CS Help for WInHelp and HTML Help works more or less the same way as far as
WebWorks Publisher is concerned. If you've already got your TopicAlias
markers in your Frame documents, the lion's share of the work is already
done. FYI, the same would be true if you were moving to WebWorks Help
(browser-independent) instead of HTML Help (browser-specific).
| I should also say that the application I am writing about is not
| Web-based.
| So the application will not be residing on a server; it'll be on
| individual
| workstations.
Exactly the environment for which WinHelp and HTML Help were designed. So
back to the original question: what functionality critical to your Help
system will you get with HTML Help that you can't get with WinHelp?
