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: Re: Should we skip HTML? From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Wed, 11 Mar 1998 09:55:43 -0600
> you do have a very specific use for your documentation. Your product does
> limit the user range, therefore you don't have to care about platform
> independency. You do however enforce quite a lot of resources on your
> users machines.
So, I guess, I can say that calling the PDF format "static and
non-interactive" is kind of a myth. But I do agree with you that it depends
a lot on the circumstances, which format is the most suitable for a certain
All of the above are parameters that define your audience. From
"VBScript," for example, I can see you're defining your audience as Windows
users who are running a recent version of Internet Explorer. Anyone not
running Windows or running Netscape instead of Explorer need not apply.
These definitions, while perhaps fitting for your audience, are not luxuries
shared by all designers.
I don't think so. I do think there are areas of interaction where
each shines. You've shown a good one for HTML. I wonder, though, how many of
your potential customers might resent having to donate the disk space IE4
requires. And how many of them will have their web browsing experience
shaken up because of the changes IE4 makes to their system.
For myself, I'm not comfortable telling customers what browser to
use. I'd rather I cause minimal disruption to their system and work habits.
I combined two sets of comments in this reply. Both seem to make a similar
point. It's also a point with which I agree; that is, that by limiting the
browser functionality, the product 'hems in' the audience. However, this
assumes that all products being documented are low-end, universal-use
programs (such as a word processor or spreadsheet). In these circumstances,
the software is an add-on to the user's collection of programs.
However, I think that I must clarify that the products I document are
high-end technical applications. In most cases, the customer uses a suite
of interrelated software applications as the principal software in a
dedicated machine or system. For example, the computer (or distributed
network, thereof) is a mapping workstation working with a geodetic database,
or an aeronautical information management workstation, and so forth. In
these set-ups, the operating system and support software are configured to
optimize performance of the principal application(s).
In my situation, the user's computer requirements are NT or Windows95 (no
Macs, OS2, etc . . .). We also integrate browser functionality for
user-functions such as using a central symbol library, sharing custom-built
VB commands, and creating technical notes. Therefore, integrating IE4 is
not a burden on the user's system, it is an add-on to the product. Mind
you, these applications are not usually installed on a computer that is
already configured to do other major processing (such as payroll) nor are
they programs that are only run occasionally or added to everyone's system
as another tool. Therefore, in most cases the computer runs the high-end
application most of the time it is in use.
For me, IE4 serves well as both a documentation medium and as an application
construction/demonstration tool. My users are learning how to write their
own commands to add to the product. They study the automation programming
examples in the browser and can exercise them on the product directly from
the browser. They can also reprogram example code through the browser, and
then re-execute. Personally, I have not ignored earlier version or Netscape
(users of them can "apply", Arlen, they just can't participate ;^) ). What
I have done is disable the calls to the scripts if the user insists on using
another browser. They can view all the text and examples, they just can't
interact with them.