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: Help with Help From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Tue, 2 Feb 1999 13:03:21 -0600
It's a rare day when I agree with Mr. Altom ;^)], but I concur that if you
are learning to work with WinHelp, don't rely on a HAT. True, the HAT may
bring quicker results; however, you will know no more about constructing,
customizing, or troubleshooting help than you did on the day you installed
the HAT software.
My advice is to start with a practice help file with about 5 topics. I
would first learn the mechanics for creating topics, an index, and a TOC. I
would then proceed to jumps, ALinks, and multiple windows. Then I would
become familiar with context-sensitivity. Eventually, I would learn macros
and multiple help file configurations.
When I felt that I was proficient with constructing and correcting help
files by hand, I would utilize the HAT. Especially if there is a tome of
documents to convert to help.
Personally after using RoboHelp and Doc-to-Help, I go HAT-less. I prefer to
use templates and home-made macros to automate the construction of my help
(yes, I realize that many HATs are macros. But the difference is in the
control of what actions are being performed and granularity. Not to mention
the level of understanding gained by writing the macros).
I'm not against using a HAT. I'm against using it instead of learning the
intricacies of help. To me, the HAT removes you another level from the
subject matter and adds another level of troubleshooting. That is, at the
core there is the subject matter, then there is the medium (WinHelp) and
it's compiler followed by the source files. Now add to that, the HAT. As a
help project develops, focus is lost from the subject matter while design
aspects are worked out in the project file. Then there is format/compiling
configuration and troubleshooting through the compiler and source files.
Often, the content is compromised to get the compiler to work or to make up
for time. By adding a HAT, you now have the, "How do I get the HAT to do
what I want?" matters to deal with.
Many will argue that the HAT removes the intermediate steps (source file and
project configuration) and thus is more efficient. Theoretically, this is
correct. However, not every project is the same flavor as created by the
HAT or configurable through the HAT. Often there are problems that must be
solved at the source (and not through the HAT). Try doing something
innovative, and you most likely have to do it by hand-coding. If a HAT
truly did all that it should, we would not have so many. "I can't get
RoboHelp to do this" or "Doc-to-Help keeps breaking on that" messages to
this forum. Often, these problems could be solved by the user going
directly to the HPJ and RTF files rather than trying to find a magic wand in
> Hi All,
> Where do I begin? Literally where do I begin? I'm writing my first Help
> project and I'm overwhelmed. My HAT has been ordered and I will receive
> it next
> week sometime. I've begun my writing in Word so I can get started before
> my HAT
> arrives. So far I've written a "How do I?" list, a Glossary of Terms
> definitions and a few help topics. I have plenty to write but I need to
> like I have some kind of a plan. How do you plan a Help Project. What
> steps do
> you take before you begin writing?
> I'm feeling grossly disorganized and without direction (two feeling that
> me up a wall). Can anyone suggest a site or some reading that might help?
> advice would be appreciated.