Summary: Cross-platform Help

["Lois Patterson" <lois -at- dowco -dot- com>]

I sent my initial query in some form or another) to TECHWR-L, TECHCOMM,
WINHELP-L, and JAVAHELP-INTEREST. Here are the responses. My apologies if I
have missed anyone.

Initial query:
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.

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?

Thanks,

Lois Patterson
lois -at- dowco -dot- com


Steve Nash
Ditto with regards to the speed of the links, and a very ameteur looking
interface. I need to provide help for a Java program, 100% cross platform,
and without relying on the clients having a browser. So I think I might be
stuck with JH, unless I can get any other ideas.. Steve

Roger Bell:
I am using it [WebHelp] also. One pitfall is...no glossary tab or window
sizing. Actually, you can do window sizing but with JavaScript. Our
programmers will do that for me. If you are going to support UNIX, make sure
you use the lowercase file name option on compiling and position the
navigation buttons on the left side of the right pane. JavaHelp is the
pits...from a seminar I attended. One thing you will certainly want to do is
test your help file in both IE and Netscape. Both browsers handle coding
differently or not at all.

Rene Stephenson:
I, too, am charged with developing a cross-platform, application help
system. After finding the limitations of JavaHelp far too severe, I also
chose WebHelp. However, I've hit upon a couple of obstacles in using
WebHelp.
This help system is to be context-sensitive. Our application is entirely
Java-based. With JavaHelp, context-sensitivity is a breeze for the
programmers to make happen, primarily because no browser is required to
display JavaHelp. On the contrary, the WebHelp by definition depends upon
having a browser. This presents an issue when dealing with cross-platform
users, because (1) we have no control over the browser(s) they may have
available, (2) each browser requires a different programming call, and (3)
the browser could be installed anywhere.
For the above reasons, WebHelp's reliance on a browser also creates an issue
with obtaining Sun's certification for true platform independence. Since the
program must call a browser, and browsers really depend upon the platform,
the program's platform independence is compromised in the help arena.
Additionally, with WebHelp, for a topic to display with the TOC, etc., I
have to create a new and renamed start file for each topic to which I want
to link directly from the application. This solves one problem and creates
another -- now the destination file for each context-sensitive link has to
be added to the code for the call to the browser for the help program. It's
a bit complicated.
WebHelp does provide more bells and whistles. However, there is a price to
pay for using it: the programmers will spend extra time trying to make it
work and coding for context sensitivity, and you'll have to do some work
arounds to provide them with context-sensitive files.
I have recently learned of the WebHelp3 Information Pack. You can download
it at:
http://robohelpresources.helpcommunity.com/resources/wh3_information_pack.ht
m

At this time I am continuing to develop the help system in RoboHELP 2000,
primarily due to the various types of help it can generate. However, the
Software Manager and I are looking for a better solution than WebHelp. If
JavaHelp were not in its infancy, I'm sure we would use it. I've heard of
Oracle Help for Java, but I don't know anything about it. If any of you
knows about it, please jump into this discussion!

Lois Patterson (jumped into my own topic)
One could create an HTML (or database-driven) web site as Help, and then use
one of the navigational Java applets available from the IMint site at
http://www.imint.com/ .
[Lois' note: As Rene points out, this still requires a browser]


David O'Brien:
You've just outlined the very reasons we chose JavaHelp over options. While
we acknowledged that the bells & whistles weren't there they would probably
come with time, and because our app is almost entirely Java (a couple of C++
plugins) we have only one API to worry about, we know the characteristics of
the display engine, and we don't have to worry about IE vs Netscape vs
whatever, or which version they're using. It also means we don't have to
assume that there is even a browser installed in the first place. I'm sure
as JavaHelp matures and the bugs are ironed out, as other vendors pipe up
with 3rd party products to automate a lot of tasks, etc., it will become a
much more attractive package. btw, I find it curious you can't change the
way you send messages. I use Outlook 98 on NT via a Citrix connection to a
server, so have only limited privileges, but switch between message types
quite regularly (private vs list mail, for example) regards, David


Trevor Woodward:
Have you tried placing the browser in an ActiveX control initiated from your
product, and using the coding for the ActiveX to accommodate all browsers? I
suggested this solution to our software people when I developed the
context-sensitive help for our product using html, and it works great with
the aid of a .dat file that links the product to the browser.
The .dat file is easy to set up, first the identity of the product field is
specified, then the html file/s. The order of the html references determine
the frame they are placed in:
FRM_HRLSTTM index/indx_h.htm#183 text/3468 XXX/3469_XXX_blah blah
blah.htm#IX_131
I don't know *exactly* how the software bods made it work, and I can't
guarantee it'll work for WebHelp, but maybe, just maybe it'll work for your
product.
We are using HTMLHelp, with html pages generated from FrameMaker via .mif
files, for our next product, so I'm reading these mailings with great
interest.

When a security issue was raised, Trevor responded:

The ActiveX we use is just a container for a browser.
We provide System Control And Data Acquisition (SCADA) systems.
We don't use anything that can be a security risk...we can't afford to.

[Lois' note: There was also a brief unresolved discussion of how well such
an ActiveX control will work on Unix or Linux.]

Roger Brinkley:
Well lets see. Speed would depend on which version of the JDK you're
using. JDK1.3 is certianly faster than the others and the presentation
is much better than it's predecessors.

As far as the interface goes are you refering to the API or the GUI. If you
don't like the GUI you can certianly write your own GUI and replace the one
that JavaHelp uses. More importantly, specifically what in the GUI don't you
like?


Michelle Forbes:
In my personal opinion, if you are looking for cross-platform help and can
assume your end users have an internet browser installed, go with eHelp's
(Formerly Blue Sky) WebHelp. Your functionality options are much greater and
many more HTML features are supported.


Bill Sullivan:
I will give it a good C-plus, perhaps a B-minus, although I haven't worked
with the latest version (in RH2000) which they tell me is better. It appears
to be superior to anything else around. Keeping track of a zillion different
HTML files is a whole new ballgame, and so is designing for all the browsers
you think you need to support.

Linda Castellani:
Have you considered ForeHelp? The ForeHelp Premier 2000 package can do
Winhelp, JavaHelp, Windows CE Help, HTML Help, and cross platform help.
Check http://www.ff.com for more info on other help options.

Vicki Whitehome:
I use WebHelp after I have done all the editing I want to do in a compiled
version of the help project. This enables me to use the project management
features available in Robohelp for a compiled help project. I don't have any
real problems.

Kevin:
One of the drawbacks for WebHelp has to do with applets. Some companies
block applets/ActiveX when browsing the internet. For example, I work on
documentation for an internet application and can't use WebHelp for that
reason. The regular WebHelp doesn't work without applets/activeX. They have
a "lite" version, but it isn't as nice. This wouldn't apply, though, if the
help files are resident on the user's machines. They would be able to use
WebHelp with applets in that situation. Judging from your message, it seems
like WebHelp might be okay for you.

Ginger Moskowitz:
I just finished a small webhelp project for a web application; basically the
application is an online form which users log into and then enter search
criteria to query a database. I used webhelp because our customers will be
using netscape and internet explorer.

The biggest problem you will probably run into is browser incompatibility,
but Robohelp's documentation covers that pretty well. I would suggest making
a mini version of your help docs in WebHelp, and seeing how the results look
on different platforms and browsers. Then you can work out any kinks ahead
of time.

Some more notes from me:

Although this is not sufficiently cross-platform for me, I should mention
HyperHelp, which can be used to automatically convert WinHelp to Unix help.
This is available at http://www.bristol.com .

My decision at this point is still to go with WebHelp. I will be tackling
the window sizing issue with JavaScript, and I will let you know what I come
up with.


Thanks all!


Lois Patterson