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.
I worked with FH/HH a lot this past fall and liked it.
It's easy to use, does more for you than RoboHelp,
and of course is the only WinHelp-like solution for
UNIX (maybe not for long...).
But it's not perfect, of course:
* you have to use a separate viewer to view the
help on Windows (as opposed to the executable .hlp
file running native). But you knew this. I wish
they'd produce a cross-compiler instead of stick
us with a viewer.
* SHED graphics didn't work for us. Period. Bristol
acknowledged this and said it would get fixed, but
did not give us a release date. As of December, when
I left the client, this was still true. There was
a workaround that Bristol suggested: after creating
the project, move it to Windows and open it using
Windows ForeHelp (which is made by ForeFront of CO,
not Bristol). Somehow the SHED problem magically
goes away. The client didn't have the Windows
version by the time I left.
* Importing .RTF files was not implemented, nor was
the concept of using multiple .RTFs in the same
help project.
* I found it amusing that FH would not work with
Sun raster-format graphics (had to convert
our screendumps to BMPs--using xv was the easiest answer).
As I recall, we were using FH 1.0. I don't recall the
version of HyperHelp--5 something?
Suggestion: cobble together a prototype help project that
uses all of the technology you expect to use
(SHED graphics, secondary windows, any funny
macro calls you know you'll need). Rig your
app to make those all-important context-sensitive
help calls. You can use dummy content.
Prototyping can expose
some gotchas earlier in the game, and give you
and Bristol more runway to work around any
you find.
Good luck,
John
--
John Gough gough -at- austin -dot- asc -dot- slb -dot- com
Technical Consultant johngough -at- aol -dot- com
Schlumberger -- Austin Product Center C1.147 -- (512) 331-3656
