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: JavaHelp From:Donna Bruce <donna -dot- l -dot- bruce -at- USTRA -dot- MAIL -dot- ABB -dot- COM> Date:Wed, 17 Mar 1999 15:44:36 -0500
Hello "Moore,,
Since we couldn't guarantee that our customer's would have browsers loaded
and we didn't want to make it a requirement (since some companies are
particular about what is loaded on their production machines), I was
limited in the online delivery mechanism.
The java JDK 1.1 (that the developer used to code the GUI) comes with the
Swing set tools one of which is an html text frame. I decided that using
this method for our first release (due 3/30) would make it easier to
upgrade the help when JavaHelp was released. This would make my online
help independent of browsers or applets and it would be fully integrated
into the software.
I wrote html pages for my topics (similar to doing HTML help using
WinHTML) and had the programmer include on the Help menu a listing "Help
for this screen". He also coded a "Contents". The Contents page includes
links to all of the screen-level help and links to short discussion pages.
It was crude (esp. when it was using JDK 1.1 [no bold, no italics, no font,
no font size tags]) but for this initial release I deemed it acceptable.
Now that the developers are using JDK 1.2 (with a Help Viewer text frame)
I'm able to get a bit more elegant since it can parse up to 3.2 html spec.
I asked my programmer about developing an applet to mimic WinHelp's
expanding/contracting book metaphor, but he was reluctant to take the time
to develop this (we are on a very tight delivery schedule) and I don't have
a java programming background. After researching JavaHelp, I decided to
wait to implement this method for our 2nd release.
Donna
(Embedded "Moore, Tracey" <TMoore -at- PARKERVISION -dot- COM>
image moved 03/17/99 01:44 PM
to file:
pic16485.pcx)
Please respond to "Moore, Tracey" <TMoore -at- PARKERVISION -dot- COM>
To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
cc: (bcc: Donna L. Bruce/Raleigh/USTRA/ABB)
Subject: Re: JavaHelp
Security Level:? Internal
I know this has gone round and round the list before. . .sorry.
Our app doesn't run in a browser either, and we use HTMLHelp. HTMLHelp
doesn't require that you have the browser open, it requires that you
have IE 4.0 or higher, or the necessary .ocx components (and others)
installed on your system (along with the help file). You don't have to
ever open the browser to view the help, the help uses the HTMLHelp
engine (whatever it's called) to launch the help. (The problem comes in
when users are accessing the help file from the web using a non-IE
browser, not a problem when accessing the file from their machines.)
In fact, our app is developed in C++. We simply include IE 4.0 in the
installation. There's a place on the Microsoft web site about
distributing IE, and they provide a kit to do it.
There's a great book I just started that I highly recommend regarding
HTMLHelp: Official Microsoft HMTL Help Authoring Kit by Steve Wexler.
As a side: I don't know about JavaHelp, but the upcoming update of
HTMLHelp will allow developers to update the help files on people's
systems, in much the same way as how you update your virus files in
Norton Antivirus or McAfee, except that the update can be invisible to
the user. This allows help authors to update files frequently without
forcing the user to reinstall the help system. The help file goes out to
the web and downloads the changes.