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: Robohelp vs. Doc-to-Help From:Lorraine Kiewiet <lorraine -at- EZ-DATA -dot- COM> Date:Mon, 2 Mar 1998 13:53:44 -0700
I learned online Help on RoboHELP 3.0 in 1994. It was a snap to learn and
easy to make prototype systems (since my organization didn't know exactly
what they wanted.)
I moved to a different company in 1995, and they had already decided on
Doc-To-Help (v1.6). I felt as though I was learning to build Help
"backwards." This is because of Doc-To-Help's focus on the manual. For
example, when you select text to make a jump, you don't see the actual
Topic Title (context string) to which you are jumping, but rather a
bookmark that D2H uses to find that topic in a document that is part of the
project. You cannot do a lot of "clever" things with Help macros and test
them out quickly because you always have to go through the "make into Help"
process. Also, connecting Help to the program depends on "context or Topic
IDs" in your "map files." Doc-To-Help can change these without telling
you, so I had to keep track of all of my numbers all of the time and check
for "surprise" renumberings when I made Help. The 2.0 version resolved this
problem, but I had a lot of legacy data to maintain.
We stayed with Doc-To-Help through version 2.0. With a beefier machine and
the new release, it wasn't quite so laborious to make a prototype, but the
"backwards" feeling was still there.
We converted to RoboHELP in 1997 and my capacity to test and prototype are
now back to normal. When we need a *quick and dirty* (emphasis equally on
quick and dirty) manual, we use RoboHELP's 'make documentation' feature.
But I guarantee you FrameMaker users that you won't be as satisfied with
any MS-Word 'book' as you were with a FrameMaker book!
Our company made a conscious decision not to publish an expensive manual
that would immediately go out-of-date and to rely exclusively on the Help
system. I was the "lone writer" from 1995-1997, so I needed the 'fastest'
tool possible. If you have a big, well-organized department, you might not
need the on-the-fly benefits that RoboHELP gives you. We now are two
writers, but we are creating and maintaining 16 help systems that appear on
~70,000 desktops, so we need the tool that emphasizes Help first, manual
Manager, Technical Documentation
E-Z Data, Inc.
918 East Green Street
Pasadena, CA 91106
Voice: (626) 585-3505 ext. 6206
Fax: (626) 585-3550
One thing that can be said of the period is that most writers don't reach
it soon enough.
++++++++++++++++Opinions are my own and not those of E-Z