Re: On-line help tools for SGI

Subject: Re: On-line help tools for SGI
From: Chet Ensign <Chet_Ensign%LDS -at- NOTES -dot- WORLDCOM -dot- COM>
Date: Wed, 30 Aug 1995 09:41:52 EDT

Monica Stein wrote:
> I need to select an authoring tool to create on-line help and on-line
> documentation for our Unix based (SGI) products. Our printed documentation set
> (approx. 3000 pages) is produced using Frame 4 on the SGI ...

and Sally Derrick replied:
>You might look at Electronic Book Technology's DynaText. I've just
>started looking at it so I can't give a ton of detail. They have a
>variety of tools that create SGML-base electronic docs.
>The various tools create what they call "Dyna-books" from SGML, Frame
>MIF files, RTF, and InterLeaf ASCII (is that different from regular
>ASCII?). They have extensive and FAST search capabilities. You can
>also customize the product to give it your company's look and feel.
>Probably a key point for your situation is that DynaText is the
>on-line tool used by SGI.

Sally is correct; SGI's online doc set is done in DynaText, customized with the
SIT (Software Integrator's Toolkit) to provide a branded interface. DynaText is
also expensive, but as Monica points out, Frameviewer is, too.

One of the other extremely nice features of using DT as your online engine is
that you can use the same source for both the context sensitive help and the
online doc set. DynaText displays electronic documents using 'stylesheets' --
essentially filters into the SGML structure of the document. By using different
stylesheets, you can display a document document different ways.

The way we did this for one of Novell's products was to use an attribute called
"Role" to identify text elements that were part of the help system. When the
user was reading the electronic doc, s/he saw all text displayed. However, when
s/he requested help from within the application, it handed a message off to the
X-Server containing the context-string for the help topic. DynaText was then
called with that context string. It would jump to that portion of the document
and display it through the XHelp stylesheet. Anything in that section that had
ROLE="HELP" would be displayed; the rest would be suppressed. So the user would
see what appeared to be a separate context-sensitive help system, derived from
the same body of information.

A neat wrinkle to this is that you can actually set up the context strings to
be a sort of 'fully-qualified object name' down through the object hierarchy of
the program. So, for example, the program may send the context string
"Edit,Find,CaseSensitive" The script can then be set up to fall back through
the hierarchy in the document itself. So, if the tech writer has not yet
written a help paragraph specifically for the "case sensitive" check box the
program can fall back to "Edit,Find" and display the text written for the Find
dialog box. The reader doesn't immediately get an error message just because no
text has yet been written for exactly that object.

This effectively decouples development of the help system from the software. If
tech doc is chasing the software -- as it so often must do -- you can release
an initial version of the help system with whatever is written at the time of
the software release and then release upgraded versions of the help system over
time as the two come back into sync. It's pretty neat.

You could probably do soem of the this with FrameViewer, but I don't know how.
Also, this stuff is not cheap. But it is powerful!

Best,

/chet

Logical Design Solutions
571 Central Avenue http://www.lds.com
Murray Hill, NJ 07974 censign -at- lds -dot- com [email]
908-771-9221 [Phone] 908-771-0430 [FAX]


Previous by Author: ANN: All day SGML seminar in New York City
Next by Author: Re: On-line help applications
Previous by Thread: Re: On-line help tools for SGI
Next by Thread: Re: On-line help tools for SGI


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


Sponsored Ads