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.
Just a real quick note, I'm afraid, to summarise what I learnt at a
online documentation conference earlier this week.
Doc-to-Help is good for just that--converting documents for the web.
It's not so good for online help development I believe.
Robo-Help and ForeHelp are supposedly very similar. It depends on the
developer as to which you choose. If your developers like to see code
and tinker around with it, then RoboHelp is better. If your developers
just like to get on with it in a more WYSIWYG environment with no
access to codes, then go for ForeHelp.
These are only the main points that I remember. I'm doing a summary of
the conference now, so if I come across anything else of great
significance that might help you I'll e-mail again later.
- Sonja Draeger
I saw your posting on techwr-l. To respond to your query, I've attached
2 files.
One is a response to a similar query that took place on a local tech
writers list several months ago. Though my overall views regarding
WinHelp have evolved since then, my general satisfaction with the tool
I chose (RoboHELP) hasn't.
The other file is a summary of responses to a similar query that
actually took place on techwr-l, around last November or so. I think
you'll find this helpful.
Essentially, the most important thing in doing WinHelp is knowing what
the end user needs, and how to present it. The tool you use to get
there is secondary, IMO.
At any rate, I'm happy to answer any questions you may have.
- Dave Egyes
Attachment 1:
To: TECHWR-L @ LISTSERV.OKSTATE.EDU cc:
Subject: SUMMARY: Online documentation applications (RoboHelp,
ForeHelp, etc.)
* * * On Nov. 11th, I sent the following message:
The powers that be where I work want more information before they the
leap into placing manuals on-line. I'd be interested to hear
about the experiences of writers who use on-line documentation
applications such as RoboHelp, ForeHelp, and others------except
Adobe Acrobat. I've already researched the use of Adobe Acrobat
in combination with Lotus Notes and had sent a listing of the
responses to this listserv on Oct. 17th.
What is it that you like about RoboHelp, ForeHelp, or other
applications? What do you not like about it? Why did you choose
it? What do you think most tech. writers use? What do you wish you
could have?
* * * Here's a summary of the key points from each respondent:
Common Ground -- This is a Canadian competitor to Acrobat owned by
Hummingbird Communications. The writer said, "Common Ground does
some things better than Acrobat and offers some additional neat
features (like attaching a miniviewer to their 'digital paper'
format output to allow users of a doc to open it without installing
a viewer)." To look at it, go to: http://www.hummingbird.com/
Folio Views -- "Very strong publishing tool" and very good at crossing
various platforms, but expensive.
ForeHelp -- An authoring tool that doesn't use Word ("RoboHelp and
Doc-to-Help are add-ons to Word"). "From viewing the WINHLP-L
list, I see four to five RoboHelp problems and four to five
Doc-to-Help problems everyday...but I see about one ForeHelp
problem a month."
ForeHelp -- One writer has used RoboHelp and ForeHelp, but prefers
ForeHelp. "ForeHelp worked with the graphics files so much easier
and the results were much better."
RoboHelp -- One writer had a bad experience loading it --- it didn't.
When he contacted RoboHelp's tech. support, they weren't able to
resolve the problem.
RoboHelp -- "In looking at RoboHelp, ForeHelp, and Doc-to-Help,
RoboHelp appeared to be the best.
RoboHelp -- Was positive about it. One criticism, "...can't create
frame-based help...all the files are window dependent only." One
big positive mentioned was that, "If you know Microsoft Word well,
RoboHelp is a breeze to use."
RoboHelp -- One writer was very positive about it. "Easy to use
interface...its features are very strong...specifically, it
automates very efficiently the common tasks required to develop and
compile an
RoboHelp -- If you're using an earlier version of Word such as 6.0,
you're relegated to using a more primitive version of RoboHelp.
Corel Ventura, FrameMaker, Word, Doc-to-Help, Word Perfect,
Microsoft Publisher, and Authorware -- For an excellent review of
these applications (pros and cons), contact Martha Lauer at: mailto:Martha -dot- Lauer -at- cexp -dot- com
Online resource. For example, topic creation, K-word (index) listings,
pop-ups, graphic integration, graphic sectoring, custom buttons,
hypertext links, etc. One feature I really like is the standalone
Contents Tab Composer, which provides a well-organized UI for
creating a WinHelp 95 contents box, and lets you easily link each
item with the corresponding topic. I found that after several hours
of tinkering with these main features, I felt very comfortable
using the tool in developing my Help file....and it's the popular
choice."
A big THANK-YOU to all the writers who responded to my questions!
- Jim Bauman
Attachment 2:
Lynne -
I highly recommend RoboHELP. I've been using it for a project I'm
currently developing, and find it relatively easy to use, with a
well organized interface, and powerful features.
You say you want to convert Word docs to Help "without much effort."
This can be done, but the question is how high quality a Help file
you want. As I see it, there are basically 3 approaches to creating
Help:
1. Convert from a Word doc to Help using the conversion feature of
whatever tool you buy. Then call it quits, taking the result of the
conversion as your final product. In my opinion, this would be
appropriate for a project where a minimal quality Help file is
required.
2. Convert from a Word doc to Help using your tool's conversion
feature. Then go ahead and modify the Help file in Word. This
includes changing styles, adding links, editing graphics for Help
(e.g. creating sectors and linking each sector to a relevant topic,
etc.) adding buttons, adding popups, modifying window sizes and
colors, etc. If you have the resources, you can perhaps automate
some of this process by creating and running Word macros.
The advantage here is that you can end up with a high quality Help
file. The disadvantage is that the built in Doc to Help converter
of any tool doesn't have the intelligence to determine what
material in your Word doc is appropriate for the Help file. For
example, there might be content that you deem appropriate for the
printed documentation that you don't want to include online.
Alternatively, you might want to add material to the Help file that
wasn't included in the printed doc.
To get around this problem, after converting, you have to sift
through the resultant Help file, and determine what you want to
keep, discard, or expand upon.
3. Develop the hard copy and online documentation separately. The
advantage here is that you can take advantage of the features
offered by the Help tool of your choice while having full control
over the content of the Help file. The disadvantage is that you
have to maintain two sets of documentation. A possible solution to
this problem, if you have the resources, would be to develop a Word
macro to handle the updating of the Help file after you've edited
the hardcopy documentation.
I'd be very interested to hear what others have to say about this
issue.
- Dave Egyes
