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: Is RoboHelp bad for e-commerce? From:"David Knopf" <david -at- knopf -dot- com> To:"Ron Rhodes" <RRhodes -at- fourthchannel -dot- com>, "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 15 Nov 1999 16:27:21 -0800
Ron Rhodes asked:
| My company is an application service provider for companies who
| want to put
| their catalogs on the WWW. And, I am having trouble convincing the
| developers to use RoboHelp or DocToHelp for delivering online-help.
|
| Their arguments actually seem to be pretty valid. Here are just a
| few points
| the developers have made:
|
| 1. RoboHelp and DocToHelp do not use pure HTML (or XML), using WebHelp, to
| compile the project.
I'm not sure what you mean by "pure." Although the HTML that RoboHELP 2000
produces is not compliant with W3C specs, it is parsed correctly by current
browsers. WebHelp is not a compiled format. WebHelp 3 (created with RH 2000)
uses DHTML or a Java applet to provide TOC, index, and FTS capability. Does
"pure" mean HTML only (i.e., no DHTML, no applets, no JavaScript)? That kind
of limitation would make it very difficult to provide some key components of
an online help system, e.g. full-text search. Most good solutions will use,
at least, a little JavaScript.
| 2. The Table of Contents, Index, and Search tabs are served up as
| client-side Java Applets in prior versions of Netscape and IE,
| thus creating
| performance issues.
This is true. WebHelp 3 also relies on the Java applet to provide these
capabilities in *current* Netscape browsers.
| 3. Cross-platform compatibility: Since these two products generate several
| different file types, .htm, .css, .hss, etc, how can we know what will
| happen if we put the end-result help files onto a UNIX box for an outside
| client.
Test it? There's really no getting around this. Even if you use totally
standard HTML (validated against the W3C specs), there are still going to be
variations from one browser/platform combination to the next.
| Right now, my company has me looking for other options to deliver on-line,
| and I am not having a lot of luck.
| Have any of you used RoboHelp or DocToHelp to deliver online help for
| e-commerce companies. If so, how successful were you?
I've been doing work with a number of e-commerce companies over the last
year or so. Believe it or not, they all deliver printed (or PDF'd) manuals
to their customers. And they all use FrameMaker. For online help, we convert
their FrameMaker documents to one of several HTML-based formats using
WebWorks Publisher, but that's another story. I do know of a few e-commerce
companies that have used WebHelp and were reasonably successful.
| And, just out of curiosity, have any of you tried to use the WebHelp
| compiler to link into an XML specific application? And, if so, how did it
| go?
WebHelp is not a compiled format, so there is no WebHelp compiler. A WebHelp
system is just a collection of HTML (and related) files, so linking to it
from an XML-based application is not a problem.
