RE: Cross-platform help - WebHelp a good solution?

[Chuck Martin <CMartin -at- serena -dot- com>]

> -----Original Message-----
> From: Lois Patterson [mailto:lois -at- dowco -dot- com]
> Sent: Tuesday, April 11, 2000 10:12 AM
> Subject: Cross-platform help - WebHelp a good solution?
> 
> I am creating online help for a (very) cross-platform 
> application. From what
> I can see, I essentially have two options: JavaHelp and WebHelp.
> 
> I tried JavaHelp and I wasn't pleased with the interface or 
> how clunky and
> slow it was. I created a small sample file, and I found the 
> links were not
> very "clickable," for whatever reason. I often had to try 
> several times.
> 
> WebHelp seems to be fine. The drawback, of course, is that it 
> requires the
> use of a browser.

This "drawback" is true of JavaHelp as well, or any HTML-based Help systems.
JavaHelp uses a browser to display its HTML pages, it just doesn't use IE or
Navigator, but rather HotJava (by default). You can also use a Java-based
browser called ICE for JavaHelp.

> 
> I don't want to use PDF as my online help solution. I've heard that
> Quadralay WebWorks is good, but we aren't using FrameMaker 
> and I don't want
> to purchase another product (currently have RoboHelp).
> Are there any serious drawbacks to WebHelp? Any tips to make the
> implementation go smoothly?

If you're planning to allow users to access this Help system through a
network, the WebHelp files should be tweaked. In the default implementation,
Blue Sky adds about 6KB of JavaScript to each and every file. They claim
they do that because one point version of Navigator (I forget which one)
can't access external, referenced JavaScripts.

However, if a system I was working on, I pulled out nearly all of the
JavaScripting in the files, leaving only the script that detects if a topic
was displayed within the navigation frame or not, and had no problems. If
you're talking about several hundred or a few thousand files, that can add
up to a lot of disk space, or a lot of network traffic, or both.

I tend to be sensitive to such user issues. For example, say there was a
1000-topic HTML-based Help system. Each topic averaged 2KB of textual and
HTML tag information. We're talking about 2MB of disk space (actually, at
least 4MB or real space, because on most systems, the cluster size of the
disk it at least 4KB.) Now add, the 6KB of JavaScript to each and every
file. You've just doubled the hard disk requirements. And that doesn't take
into account the other, WebHelp-specific files: the TOC and index files, the
external JavaScripts (which are there in addition to them being embedded),
and the Java and ActiveX controls.

I also didn't like using the Robo tools for authoring. If you use RoboHELP
classic, you're authoring in Word, and the HTML export leaves tons of
unneeded garbage in your HTML files (which makes file sizes even larger).
RoboHTML doesn't produce nice, clean HTML either.

I'd definitely recommend authoring your HTML in an external tool (my
favorites are Dreamweaver and Homesite), then using RoboHTML to build the
actual Help system. Don't build the system in the same place where your
original source files are located. You might also create your own cascading
style sheet and replace the Robo ones. If you do it right, you can create a
single style sheet that works right in both browsers and not need the
browser-detect JavaScripting.

-- 
Chuck Martin
Sr. Technical Writer, SERENA Software

"People who use business software might despise it, but they are getting
paid to tolerate it....Most people who are paid to use a tool feel
constrained not to complain about that tool, but it doesn't stop them from
feeling frustrated and unhappy about it."
          - "The Inmates are Running the Asylum" 
            Alan Cooper

 


***********************************************************************
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. Any unauthorized review, use, disclosure or distribution 
is prohibited. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original 
message. 
***********************************************************************