Re: JavaHelp vs. Interhelp

Subject: Re: JavaHelp vs. Interhelp
From: "Chuck" <writer -at- best -dot- com>
To: techwr-l
Date: Thu, 4 Nov 1999 12:53:40 -0800


Debbie Pesach <debbie_pesach -at- attune-networks -dot- com> wrote in message
news:27427 -at- techwr-l -dot- -dot- -dot-
> This is a question for those of you who are producing online help for
> Java-based applications. Others may delete or proceed at your own risk
> :-).
>
<snip>
> I've decided that I'm going to go over to FrameMaker, and will use
> ForeHelp as my help authoring tool. For those of you who are producing
> online help for Java-based applications, are you writing the help using
> JavaHelp, or are you using HTML-based help instead (I would use
> Interhelp). All my audience will have a Web browser installed (although
> I can't control which browser, so the help must be browser independent).

First of all, I would wonder why FrameMaker? Are you producing print
documents? If not, then why design online information in a tool that's
designed primarily for producing information in a print format?

>
>
> The SME's objection to using HTML-based help is that opening up the help
> file will require opening up another browser window which can be easily
> confused with the application browser window which must not be closed.
> Can anyone provide me with information about this?

That's simply a not-true assertion--depending on the design and
architecture. But I have to ask if what's being designed in as applicaiton
or an applet? Or a browser-based application that uses Java as part of its
functionality?

HTML-based Help (of which JavaHelp and InterHelp are subsets) can be made to
appear in separate browser windows. But you can also design your applicaiton
environment so that the HTML pages are embedded in the applicaiton
environment. For some time now, this has been seen as the superior approach.

If the application is being hosed in a browser window, then a portion of
that browser window can be designed to host HTML-based Help pages. If it's a
true Java application, in a standalone window without a browser, the
interface can still be designed to host the Help without a separate window
appearing. It's more design work, but the result in either case will be a
better user experience.

If the SME is concerned about user confusing an application hosted in a
browser window with Help pages (or anything else, for that matter) in
another browser window, then maybe the applicaiton design needs work so that
confusion will go away (or at elast be minimized).

>
> What are potential pitfalls/concerns that I should take into
> consideration before beginning a JavaHelp project (such as how does the
> application's version of Java affect how/if I prepare JavaHelp)?

I believe the latest version of JavaHelp support Java 1.1 and newer. Check
out the JavaHelp page for actual specs.

It seems that for Java applications, and for others requiring
cross-platform, cross-browser Help systems, a lot of people are authoring
clean HTML in outside HTML editors (such as Dreamweaver or HomeSite), then
importing those pages into the cross-platform Help technologies. I'm doing
that now with Dreamweaver and RoboHTML (which I'm tweaking along the lines
of what was done at the Online Help Journal [www.ohj.com) site).

The Robo tools add lots of "stuff" to HTML files if you author in their
environment. You can get "clean" HTML from ForeFront, but all the
information is stored in their proprietery database (back up often).
JavaHelp doens't provide an authoring environment, so you have to pick a
tool that provides the best HTML.

--
--
Chuck Martin
writer"at"best"dot"com www.writeforyou.com

"[Programmers] cannot successfully be asked to design for
users because...inevitably, they will make judgments based
on the difficult of coding and not on the user's real needs."
- Alan Cooper
"About Face: The Essentials of User Interface Design"

NOTICE TO BULK EMAILERS: Pursuant to US Code,
Title 47, Chapter 5, Subchapter II, 227, any and all
nonsolicited commercial E-mail sent to this address is
subject to a download and archival fee in the amount of $500
US. E-mailing denotes acceptance of these terms.







Previous by Author: Fw: ToolTips and Keyboard Shortcuts
Next by Author: Re: SF, California Wages
Previous by Thread: Re: JavaHelp vs. Interhelp
Next by Thread: PDF and Word Callouts


What this post helpful? Share it with friends and colleagues:


Sponsored Ads