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:RoboHelp Review From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Sat, 13 Jan 1996 21:00:00 EST
>>A pod of programmers is convinced that RoboHelp is the solution for our
>>WinHelp authoring needs.
>>Anyone out there using it currently? If so, could you please give me a quick
>>overview on how it works and whether there are any alternatives?
>Jeez, I'm tired of hearing that "this tool over here" or "that there tool"
>will make all of our WinHelp woes vanish! It won't. No tool will.
>Many writers think of Windows help authoring tools the same way they view
>DTP packages...different file conventions, different capabilities, and so
>on. Nada. Nay, nay. Nope. Not. Every help tool produces EXACTLY the same
>result, bar none. (This is, of course, ignoring the occasional DLL that's
>supplied with an authoring tool. Such DLLs aren't, IMO, worth the high price
>of the tool.)
>I've used Wysi-Help, RoboHelp, Doc-to-Help, Help Writer's Assitant, and
>others. All of them do precisely, exactly and totally the same thing.
>WinHelp files are the same whether produced in these things or in Word for
>Windows, which is what RoboHelp is REALLY doing. I just learned how to do it
>That's the key to all WinHelp work...you have to know what's going on, and
>how to use it to best advantage. That means learning the codes, the
>processes, and how to manipulate the compiler. It means learning the
>capabilities of WinHelp, not Robo-Thiso or Thato help tool. That's the
>approach we take in our classes: teaching WinHelp and help file creation,
>not a tool. We use and support ForeHelp, but that's more a result of
>happenstance than a massive commitment to the product. ANY tool will produce
>great help files in the hands of a skilled, trained and experienced writer.
>I've used Word for Windows extensively for help file creation. Conversely,
>any tool with produce dreck in the hands of a neophyte.
>In short, please tell your programmer friends that you need a tool that
>suits your own workstyle, because all tools are functionally identical,
>despite the hype around Robo-Help. Personally, I'd prefer a standalone tool
>like ForeHelp over RoboHelp or Doc-to-Help, just because I may need to edit
>some of the RTF myself later, and I can't do that as effectively while
>plowing through the thousands of K of bookmarks and field codes that tools
>running on Word have to insert into the RTF. The compiler ignores that
>chaff, but I have to pick my way through it in the editor.
>I'd suggest that you get Doc-to-Help's decompiler, find a help file you
>really admire, and decompile the thing. See how the author did it. Learn how
>that's done, then pick a tool on the basis of how you prefer to work. Ignore
>hype. Don't focus on the tool. Focus on what you want the help file to do,
>then pick a tool for your own cubicle. Jim Mischel's book is excellent for
>background, and you can find comparison articles in back issues of several
>Windows and PC magazines. You might also pick up a book or two on hypertext
>development. And be sure to learn proper techniques for preplanning the
>hypertext project. As you may have noted, this ain't like putting together
>brochures. It's a different paradigm and thought process.
>Feel free to email me directly if you need to, and best of luck.