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.
| Brief Report on the
| JavaHelp Jumpstart Conference
that left me wondering if we went to the same conference!
I left the JavaHelp conference excited about JavaHelp and convinced that it
has an extremely good chance at becoming the preferred solution for
providing online help for Java applications. Notice I am careful not to say
it will become the preferred solution for delivering all forms of online
information systems in all environments. But if your need is to develop
online help for an application written in Java, I don't see a better
solution in the marketplace now or on the horizon.
Yes, there are limitations and weaknesses, and yes the conference presenters
spent a fair amount of time elucidating them. But what point would there be
in going to a technology conference if you couldn't garner this kind of
information? At conferences focused on WinHelp and HTML Help, for example,
substantial amounts of presenter time are usually devoted to describing
limitations (and workarounds) in these technologies.
I agree with Mark that printing -- or rather the lack of printing -- is the
most significant weakness in JavaHelp today, and Sun did say there would not
be a fix for this for some months. With HTML Help, by contrast, I can print
today -- but only if my help system happens to be running on 32-bit Windows.
And btw, printing from any of the other help technologies has always been
less than ideal; if you want to equip the user to produce a good looking and
usable printout of an entire help system, you'll have one heck of a time
accomplishing this using any current online help technology.
Mark is also right that JavaHelp offers fewer bells and whistles than some
of the other technologies. HTML 3.2 only, no JavaScript, no applets, etc. I
am sure some of this will change, but in the meantime it may be a blessing
in disguise. Is there really a software application somewhere for which I
simply could not create effective online help without JavaScript and applet
support? I think not. If you ask me, clarity of content is where it's at,
and HTML 3.2 gives me all the tools I need to create top-notch content.
I disagree with Mark's impression from the HAT vendors. Doc-To-Help has
supported JavaHelp since long before it was released. Forefront is currently
shipping support for JavaHelp, and Blue Sky was enthusiastic about the
JavaHelp support to be offered in the upcoming RoboHELP 2000 release. (Don't
worry, Mark ... I'm *sure* you'll hear from Blue Sky sales real soon!) I
think we can count on the vendors to support this technology as long as the
market continues to be interested in it. Unless JavaHelp flops in the
marketplace, which I think quite unlikely, I think we can look to the
vendors for strong support of the technology.
I think it's important that we look at these technologies in context. If you
look at JavaHelp and ask yourself if it's the ideal solution for every
online information project, you will have to say no. If, however, you look
at it as a solution for providing integrated online help for a software
application written in Java, I think you're likely to conclude it's the best
game in town. (Of course, you'll still have to bear in mind that it's a 1.0
release, with all that that entails.)
