Summary of Webhelp vs. HTML Help (long)

Subject: Summary of Webhelp vs. HTML Help (long)
From: "MacLemale, Laura A. (LNG-MBC)" <Laura -dot- A -dot- MacLemale -at- bender -dot- com>
To: "'TECHWR-L'" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Thu, 16 Mar 2000 10:46:05 -0500


Thanks to all of you who responded to my recent questions about Webhelp and
HTML help. I've put together an informal summary of my findings, but please
feel free to make comments or add to it. There are some other list serv
members who are in the process of evaluating online help formats, so I'm
sure that we all welcome your further suggestions.

Special thanks to William Swallow, Betty Fleming, and Jo Byrd who answered
some of my questions directly.

We are currently evaluating Homesite and Forehelp, and we are leaning toward
HTML help due to some internal considerations.

This list never fails to impress me!


Laura MacLemale

__Help Considerations__

Time - deadlines demand best use of resources and tools
Resources - in-house or out-sourced?
Tools - cross-functionality for sharing and converting files (especially if
End User Systems - will we need to work with programmers to provide some
type of IE installation (i.e., so that users will be able to view frames or
properly formatted CSS in their browsers)?
Experimentation - need to experiment with existing help files created with
various tools on various browsers for a better idea.

__Help Systems__


Compatability: Uncompiled help file that can run on a variety of browsers
and on a variety of platforms.
Runs on any platform including Windows, UNIX, Linux, Sun Solaris, and
Requires IE 3.02, 4.x and Netscape 3.04, 4.03 and later (opens directly in
browser window).
Can be installed locally on a user's machine with the application
Posted on a server and retrieved via Internet or intranet.
Creates individual HTML files for each topic.
Strengths: Time and costs. WebHelp can be quickly and easily edited and
Good for cross-platform help needs and good for delivering your help via a
Limitations: Known problems in several versions of Netscape with frames,
Javascripts, and style sheets.
No auto-synch topic to TOC, no "Favorites" tab; no "Glossary" tab; can't
size the navigation panel; no alpha headings in the index; questionable
browse sequences.
The "WHStart.htm" file will appear at the mercy of the browser capabilities;
in NN some formatting may be lost.

_HTML Help_

Compatibility: Compiled help file.
Requires 32-bit Windows.
Requires latest IE, which can be bundled with program. (Application opens in
a separate browser window whether NN or IE is default browser.)
One writer suggested that this is not good help format for help that will
run off the web and not off the local PC.
Strengths: Good user interface and functionality; takes full advantage of
"bells and whistles" such as Javascript, DHTML, and CSS, etc.
Time and costs - we already own the tool and have created HTML help in-house
Limitations: Not good for help that runs off a server-the compiled help
file downloads from the server to the user's machine, which can slow things
down considerably.

__Third-party tools__

_RoboHelp Office_

Used to create standard Winhelp, WebHelp, and HTML Help.
Uses Word to create RTF help documents.
Creates index and TOC (although you have to tweak it).
Creates search functionality.
Time element - will be brief as contractors and in-house tech writers have
used it before.
(May need to upgrade to Robo 2000)


Used to create standard Winhelp, cross-platform help and HTML help.
Costs - we would need to purchase product (approx. $600).
Time element - expect a shorter learning curve for experienced RoboHelp
user/help author.

__HTML Editors__


Strictly an HTML editor (non-graphical HTML editor, not a help authoring
Gives more layout control to someone who moderately knows HTML coding.
Creates no index or TOC-these must be created manually by the help author
(although we may be able to copy and modify the existing in-house index
Preserves code integrity.
Integrate existing code into our help files for a consistent look and feel.
Supports latest web technologies, such as JavaScript, CSS, DHTML, etc.
Need to build search functionality.
Need to create sub-topic links on a topic-by-topic basis.
How are popup codes and Javascript handled?
Time element - may encounter a fair learning curve if not a WYSIWYG
environment (i.e., time to build code, index, browse sequences, search
function, etc.). Also, time will need to be added to adequately test the
help file.

_Word to HTML_

This is probably a last resort, since we already own RoboHelp, the tool most
closely associated with Word docs when creating help systems.
Might be useful only if we don't use a third-party tool and need to share
files with an outside source.
Time element - moderate; code would definitely require tweaking.


Free text editor with no WYSIWYG environment.
For experienced HTML coders only who can enter straight code.
Time element - moderate for experienced coder; higher for less experienced

_HTML Indexer_

May be useful if we go with an HTML editor and need to build an index.
Time element - may be considerable learning curve.

Laura A. MacLemale
Technical Communications Coordinator
Matthew Bender, part of LEXIS Publishing
1275 Broadway
Albany, NY 12204
Phone (518) 487-3465
Fax (518) 487-3681
Laura -dot- A -dot- MacLemale -at- bender -dot- com

Previous by Author: RE: Documentation for Beta Users
Next by Author: RE: Old thread, hopefully new spin on "allow" v. "enable."
Previous by Thread: Re: MS Word Master Document to PDF
Next by Thread: Plagiarism vs Fixed Botches

What this post helpful? Share it with friends and colleagues:

Sponsored Ads

Sponsored Ads