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-Benefit? - Long From:Jason Wynia <jwynia -at- AGRIS -dot- COM> Date:Fri, 6 Nov 1998 15:07:12 -0600
But HTML-based Help deos require some sort of browser component to
disply, even if it is integrated into the software application itself.
So does Winhelp. If it didn't you'd be able to open a 32 bit help file in
Win 3.1. However, because the browser or parts of a browser in question
happen to be another MS product that is distributed seperately right now, it
seems more strange.
So the question arises: whose browser components?
Microsoft is trying to
position its Help development as needing its browser components, which
are part of Internet Explorer. It's clearly a backhanded tactic to
validate the claim that IE is part of the actual operating system.
Business practices aside, they've done that with Winhelp as well, but
because the OS or other MS software has always just come with it and it was
never seperate, we notice more. You didn't see Netscape provide a Winhelp
browser that reads MS Winhelp files. MS was the only place I know of you
could get the Winhelp engine for any platform.
But WinHelp systems can and do run on a Mac, and with assistance, on
Unix boxes. Microsoft originallu developed a cross-platform Help
compiler so authors could write a single WinHelp-style Help system that
would run both on Windows and on Mac. I don't know about the current
version, but previous versions of Mac Office installed a Help engine.
But it still came from MS. The same style is being done now with IE.
While MS is claiming that HTML-Help is cross-platform, it is not browser
independent.
Nor have most of the previous hypertext help systems before. You can't open
a hypercard file with Winhelp.
You can't simply assume that all users will blithely
migrate to Windows (and Win98) boxes.
I never assumed that. However, most people who develop Winhelp now, do so
for the Windows platform exclusively. Therefore, to use Winhelp had already
made an assumption that all users would migrate to at least Win 3.1.
As much of a Windows snob that I am, you can't ignore other platforms for
user assistance. This is
especially true for enterprise development.
I agree. However, right now, I don't see Winhelp as the ideal situation for
those either. I think that HTML based help, or eventually XML based help is
a good idea for those cross-platform/enterprise development environments. I
see HTML Help as the replacement in MS's eyes for winhelp. CHM for HLP.
You don't try to view Winhelp with Netscape, Opera, Arachne etc. and you
need to view a CHM with the HTML Help engine(based on IE 4.0). For HTML
based help systems in a browser for cross platform capabilities, I agree
that HTML Help isn't a good idea.
Once again, not everyone will be Win users. And many users do *not* like
IE and will do all in their power to remove it from their systems, no
matter what.
I understand this. However, current Winhelp systems assume a vast majority
are Win users. Unless the DOJ says they have to completely seperate IE from
Windows, it is going to be integrated far beyond the removal capabilities of
90 percent of the Windows user base. I do *not* like installing animated
font support or HTML export into Word 97, but if I want to be a user of
Word, I don't have much choice. Equally, if I decide to be a user of Win
98, I don't have much choice but to install IE. It doesn't need to be my
default browser for HTM files, but it will be for CHM files.
Personally, I'm waiting for an adequate XML/XSL/DOM solution to come around,
but I think it will still be awhile.