RE: [wwp-users] Re: SUMMARY: How (un)popular is JavaHelp?

["David Knopf" <david -at- knopf -dot- com>]

John Wilcox recently posted a summary of comments about JavaHelp that he
received in response to an inquiry he posted to several mailing lists. I
realize that none of these comments were John's and do not mean to put him
on the spot. However, there are an awful lot of inaccuracies in the comments
offered about JavaHelp, and as someone who knows the JavaHelp technology
pretty well, I would like to set the record straight.

My specific comments are interspersed below.

David Knopf (mailto:david -at- knopf -dot- com)
Knopf Online (http://www.knopf.com)
Tel: 415.550.8367

RoboHELP MVP & Certified RoboHELP Instructor
WebWorks Publisher Certified Trainer
Co-moderator, HATT & wwp-users




| -----Original Message-----
| From: John Wilcox [mailto:jwilcox -at- tcsi -dot- com]
| Sent: Wednesday, February 07, 2001 12:05 PM
| To: Framers List; STC Lone Writer SIG; WWPusers List
| Subject: [wwp-users] Re: SUMMARY: How (un)popular is JavaHelp?
|
|
| Someone asked:
|
| > Would it be possible to post some of the comments you received?
|
| OK, here are the relevant excerpts:

| ============================
| I've developed JavaHelp but at this point there are too many
| issues to release
| it to our users.  We're sticking to HTML Help until we can
| provide external web
| links (and until I can figure out how to get CSSs to actually work).

Current releases of JavaHelp support both external Web links and CSS. Some
external Web pages may not display well if they have been optimized for IE
or Netscape instead of following the relevant standards, but the
functionality exists and is supported.


| ===========================
| I was on course this past October and the instructor said that
| Sun had pulled
| development for JavaHelp but hadn't announced it. It looks like

This instructor was seriously misinformed. Sun did not "pull" development of
JavaHelp. In fact, the JavaHelp team has expanded in recent months to make
it possible to devote more resources to developing JavaHelp 2.0, which has
been publicly announced and is scheduled to ship in October 2001. I am a
member of Sun's JavaHelp 2.0 Working Group, which means I am participating
directly in the design and specification process. I can assure you that
development is very much alive.


| ===========================
| At my last company (Spring of 2000) I would have used it even
| though it was not
| quite ready for prime time. I guess it still isn't ready based on
| all the mail I
| get from the JAVAHELP list server.

The volume of messages on the JavaHelp-Interest list reflects the growing
size of the JavaHelp developer community. I don't think it reflects the
degree to which JavaHelp is or is not "ready for prime time."


| ===========================
| I used JavaHelp when my company was producing a Java application. Once we
| switched to an applet, it didn't make much sense to continue using
| it, and I changed to straight HTML.

|
| I didn't have any big problems with it. It wasn't pretty, but it
| had all the
| *functionality* that I needed, which is what I considered to be
| important, and
| it was supported by the HATs.

I agree that JavaHelp has all the functionality required for most Help
systems.


| One thing that was frustrating was
| the lack of
| 3rd-party books.

AFAIK, there's only one book on JavaHelp. It's by Kevin Lewis and is
published by O'Reilly. The JavaHelp documentation from Sun is pretty
comprehensive, though.


| But, the HAT did its magic even though I didn't
| necessarily
| understand what was going on.
|
| I think one of the reasons it's not too widely used is that it's
| relatively new.
| It's easier for people to stick with something they know, like
| WinHelp, unless
| they're forced to change because of technical requirements. Also,
| it is klunky.
| I think it's pretty natural that you won't ever see it at the
| same popularity as
| Java itself.


I'm not so sure about that. JavaHelp 2.0 will be a big leap forward.


| ==========================
| I used JavaHelp for a big Java-based network management program
| within the last
| year or so. I consider it very bad in many ways. Slow, clunky,
| ridiculous. One
| example is the index feature, which doesn't even do a simple thing like
| alphabetize entries. And if you had an index in several helpsets
| and merged
| them, it just threw the indexes in any old order. Great feature.

We could argue about this feature, but it is exactly what HTML Help does, so
JavaHelp is not alone here. The idea is to allow authors to order index
entries as appropriate. Admittedly, that's alphabetical for most indexes.
Authoring tools will do the sorting for you.


| JavaHelp is an API, not a product.

Not true. JavaHelp is a product. An API is part of the JavaHelp product.


| The system people are calling
| JavaHelp is
| Sun's "reference inmplementation."

Not true. The JavaHelp product includes reference implementations of various
components. That hardly means that JavaHelp is not a product.


| Fair enough. I suppose the
| idea is to leave
| developers free to develop great new help features or something,
| but I don't see
| any around.

Actually, I've worked with quite a few JavaHelp developers who have extended
the basic functionality by creating their own viewers, their own look and
feel, and their own lightweight components. It is by no means necessary to
do this, but it's certainly nice that JavaHelp's clean API makes this so
easy to do.


| ===========================
| Yup, I've been using JavaHelp for close to a year now. I think
| i's quirky and a
| bit rough around the edges, yet I've grown fond of it...or
| perhaps fond of the
| challenge of making it work. The application I support is Java;
| thus, the choice
| to use JavaHelp. If nothing else, I don't have to worry about my
| Help browser
| matching the application..since the Java code takes care of that for me.

Exactly.


| I use FrameMaker and WebWorks Publisher as my development tools,
| which seem to
| work well.

Yes, this is a winning combination.


| =============================
| I am currently writing online documentation for a Java-based
| application, and
| the original plan was to produce the doc in Javahelp format via
| RoboHTML. If the
| app is Java-based, why not the doc, right?
|
| We abandoned Javahelp a couple of months into the project in
| favour of WebHelp
| (uncompiled HTML with a Java applet). The reasons:
|
| * We could not get help pages to print reliably.

Printing was a problem in JavaHelp 1.0. It's much improved in 1.1.1.


| * A flaky interface (hyperlinks that sometimes worked and
| sometimes didn't,
| pages that either failed to open or opened twice, etc., etc.)

These issues probably have more to do with your authoring tool than with
JavaHelp. Most of the HATs I've seen don't do a great job of producing HTML
and CSS that work well in JavaHelp. If the code is correct, hyperlinks will
*always* work. "Pages that opened twice" sounds like a bug I'm familiar with
in JDK 1.2.2. The bug was resolved in JDK 1.3.


| * Javahelp was far too slow to execute.

Performance is a continuing issue with JavaHelp systems. However, the
problem is not with JavaHelp itself but rather with the underlying JDK (now
called the Java 2 SDK). I'm told that JDK 1.3.1 will bring substantial
performance improvements to JavaHelp even before JavaHelp 2.0 is released.


| My personal opinion is that the whole Javahelp development
| project is operated
| on a shoestring, and that those responsible have basically given
| up on producing
| a competitive product.

This is not true. I know the people involved, and I admire the level of
commitment they have to the JavaHelp technology.


| ========================
| A friend and I ran a JavaHelp 1 seminar [about a year and a half
| ago in a major
| software-development metropolis].  Since then, I've had exactly
| one inquiry and
| not a single project.  There is a market for it, as there is for
| Mac-based help,
| but it's very small and self-contained and you have to go looking for it.

There have more than 60,000 downloads of JavaHelp in the last year. My
company develops Help systems and single source processes, and we get a lot
of inquiries about JavaHelp and have a lot of customers who are using it.


| ===============================
| We use FM5.5 + WWP to create our java help. I'm just getting my
| first pdf / jh
| project to 1st draft. I've been single sourcing from RH / HDK for
| many years
| now, and find the fm / wwp pretty straightforward.
| ....
| JH has that 'I'm newborn please don't expect me to juggle yet'
| feel to it. Not
| perfect by any means, but perhaps not nearly as nasty as early MS
| HTML Help -
| that [irritated me] bigtime.
| JH may not be feature rich - but three good paragraphs of useful
| content in the
| user's face at the right time is more than 80% of what you need,
| and that's
| easily do-able. Bells and whistles can wait - it's the potential of true
| cross-platform ability that matters as much to us.

Exactly. Content is central. Bells and whistles are far less important.


| ===============================
| I am producing JavaHelp and I am frustrated by it. First time
| around I used
| ForeHelp to create the help topics, but now I am trying to get
| the FrameMaker to
| WWP setup working. I feel less in control now than when I used
| ForeHelp, but
| perhaps that's I'm finding WWP pretty difficult to get to grips
| with.

Actually, you have far better control with WWP than with FH or any other
authoring tool. But, as you correctly point out, when you're new to WWP,
figuring how to wield that control can be quite a challenge. I've buitl
quite a few JH systems with WWP, though, and it works very well.


| All in all, I'd much prefer to be back with good old-fashioned
| WinHelp! But we
| are a Java development group and at present JavaHelp is our only option.

Exactly. If you are working on a 100% pure Java application, you cannot use
WinHelp or HTML Help or WebHelp or InterHelp.


| ==============================
| I use JavaHelp and find some things wrong with it; specifically,
| formatting
| difficulties and inability to provide mid-topic jumps.

There is no problem providing mid-topic jumps. JavaHelp has supported that
since 1.0.


| ========================
| I'm using JavaHelp 1.1 with RoboHelp HTML 2000. I like JavaHelp,
| hate RoboHelp.
| Their TrueCode editor is terrible and just gets in the way. Apart from
| HelpBreeze, I've not seen any other tools that can do it. Its a shame the
| browser's support for CSS is so bad. My developers like it, but
| my boss doesn't
| and we're looking at moving to WebHelp for the next release.
| There seems to be a
| real lack of resources regarding JavaHelp.

Most authoring tools refuse to leave your HTML alone. That is probably the
source of your frustration with RoboHelp 2000. JavaHelp's CSS support is
actually pretty good, but the viewer is finicky about correct syntax. IE
will often display things correctly even when the .css file is riddled with
errors; the JH viewer is less forgiving in this respect. CSS support comes
from the JDK, however, not from JavaHelp itself. There will be improvements
in CSS support in future releases of the JDK.


| =========================
| I personally avoid JavaHelp for two primary reasons:
|
| 1) it's still technically in Beta

This is simply not true. JavaHelp is not in Beta, technically or otherwise.
The JavaHelp software has been a released Sun product for almost 2 years.


| 2) it requires the JRE if not Help for a Java application

Well, yes, but then again JavaHelp is designed to enable online Help for
Java applications. Anyone using a Java application will have the JRE, so
this is really a non-issue. I guess if you wanted to create online Help for
a Visual Basic application, JavaHelp would be a poor choice, but that's not
what it's designed for.


| I personally think JavaHelp was a great idea when it was first
| announced in the
| mid-1990's. But, IMHO, Sun made a big booboo by letting it sit
| for so long. Now
| there are many other comparable formats which don't require the
| installation of
| an 18MB runtime engine.

The JRE is 5MB not 18MB. The JRE is installed on any system that is running
a Java application. No additional download or installation is required.

David Knopf (mailto:david -at- knopf -dot- com)
Knopf Online (http://www.knopf.com)
Tel: 415.550.8367

RoboHELP MVP & Certified RoboHELP Instructor
WebWorks Publisher Certified Trainer
Co-moderator, HATT & wwp-users




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-Based Help with Macromedia Dreamweaver 4 ($100 STC Discount)
**WEST COAST LOCATIONS** San Jose (Mar 1-2), San Francisco (Apr 16-17)
http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.

Sponsored by ForeFront, Inc., maker of ForeHelp Help authoring tools
for print, WinHelp, HTML Help, JavaHelp, and cross-platform InterHelp
See www.forehelp.com for more information and free evaluation downloads

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.