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.
To Faith Weber, Geoff Hart, and Sally Weber who asked about ForeHelp and whether
or not HyperHelp is a good candidate for creating UNIX and Windows Help files,
I have the following reply based on my own experience.
I used Windows ForeHelp at my previous employer to create a series of help files
for a rather complicated product. Several of the help files were
rather large. It took a long time to open them and a
long time to execute the first request to the database.
I was using an old version of ForeHelp and it didn't let you break up
a help system into several .RTF files. If it had, I could have made more
efficient use of material that was repeated in each help file. I don't
know if the new version (2.0?) lets you use several .RTF files in one
help system.
In spite of these negatives, I thought it was a great
product and could never have accomplished so large a task within schedule
without it. I also ditto what E Hoornaer said about it.
At my current employer, we investigated how we could create
help for both Windows and UNIX. We first investigated using UNIX ForeHelp as
our authoring tool and compiling the help files for the
different platforms using HyperHelp.
We decided against this because UNIX ForeHelp was a new program and
we could not be sure of its reliability. (We have SGIs and MACs here
so we couldn't use Windows ForeHelp.)
We also considered using FrameMaker as the authoring tool to create
help files with HyperHelp.
This process seemed to be as tedious as the process of building
Help files before there were authoring tools and too prone to
error.
In the end, we decided to use FrameMaker's FrameViewer for our help and not
HyperHelp. It seemed the more open way to go. If we want to go to
SGML in the next few years, we can change to FrameBuilder. If
we want to convert our help and documentation to the Web,
FrameMaker 5.0 has a built-in conversion utility.
In addition, using FrameViewer allows us to create help and documentation
using the same tool. We can put our documentation on line simply
by locking it and building connections to it from our help.
Hope this helps you make your decisions.
Kathy Vincenz
kvinc -at- adams -dot- com
Mechanical Dynamics, Inc.
Ann Arbor, MI
