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.
Subject:Re: HTML Help From:Bill Bledsoe <Bill -dot- Bledsoe -at- CMS-STL -dot- COM> Date:Wed, 21 May 1997 12:42:22 -0500
List, Ernie,
More below...
Tamminga, Ernie wrote:
>
> We're in the midst of doing our first major project using HTML-based
> Help.
>
> One clear observation to offer at this point:
> One compelling reason for going to HTML-based Help as opposed to
> "standard" Winhelp is to be able to support remote interaction.
WinHelp add-ons like the inet.dll from BlueSky will do some of this type
of thing... but the interaction is one way (user clicks on link and it
opens browser... passes URL to browser and takes the user there)
But... the die-hard WinHelpers might argue that you could to it all from
traditional WinHelp given the right .dll... but I tend to agree with you
that the interaction is MUCH easier within the HTML-based help relm...
> For example, you really have no choice, if your scenario is this: the
> administrator of your product accesses your administration interface
> via the Web, from a remote workstation. Then your online help pretty > much HAS TO be HTML-based... it can't be resident on the user's PC (a > la standard Winhelp), because your product isn't running on that PC.
Not to pick too much... but in the scenario you've described, the
Administrator's help certainly could be on the Adminstrator's box... the
browser-based application would just have to call WinHelp rather than
another URL.
> What's running on that PC is a browser, which the administrator is
> using to get at your product. In fact, the administrator might access
> you from one PC at one time, and from another PC the next time.
And this is where you'd need the server-based help so that you'd get the
same help every time without having to rely on the "user PC" to have the
updated file, etc. You could certainly have that .hlp file on the
server as well... but again... that's jumping through a lot of hoops
administratively... and I'm admittedly picking a bit... just trying to
play devils advocate I suppose (natural role... sorry for projecting
onto list.)
I neglected to mention one other NetHelp feature that Netscape is
touting to become a W3C standard, and that is the NetHelp URL. This URL
basically would differentiate a call to a HTML Help HTML file from a
call to a "standard HTML" file. Similar to the file:// or ftp://
calls... it would provide an easy way to distinguish what application to
bring up as opposed to a full browser. It also allows applications to
make this call to the browser from within the application, bypassing
more complicated methods such as making an OLE call or calling an API.
cheers,
--
****************************************************
Bill Bledsoe
Senior Technical Writer - CMS
Bill -dot- Bledsoe -at- cms-stl -dot- com or intlidox -at- anet-stl -dot- com
"I'm out on a limb where the fun begins"
Adrian Belew/The Bears
****************************************************
If Bill Said it, Bill said it... Not CMS. Got it?
****************************************************
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html