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[4]: Should we skip HTML? From:"Walker, Arlen P" <Arlen -dot- P -dot- Walker -at- JCI -dot- COM> Date:Tue, 10 Mar 1998 14:31:24 -0600
I guess that I must be using HTML differently than most.
Most? Perhaps. Many? Yes. And you're able to do that because you've drawn a
tight circle around your audience. Follow:
ability to interact with the reader that drives my choice.
I am using HTML because my product (an automation programmer's guide
to our application) is as much an application itself as it is a
document.
I am making liberal use of dynamic HTML features
I am also automating the product through the document (by using
VBScript).
I need the scripting to do "Show Me(s)" for the code.
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.
It would be inappropriate for you to try to do your application in PDF, I
think, but to extrapolate from that to it being inappropriate for everyone
is a long, and shaky, step.
You've provided a very good example of why the audience should define the
toolset.
If, however, the document is more than just something to be read,
HTML wins hands down.
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.
As a piece of generic advice, I'd avoid testing for browser version. The
rate new versions come out and the changes that are made makes that a high-
maintenance item. Try instead to write a piece of code to use as a
"function detective," which will tell you if the particular function you're
after is supported by the browser. Then a new browser version is less
likely to break your code.
Have fun,
Arlen
Chief Managing Director In Charge, Department of Redundancy Department
DNRC 224
Arlen -dot- P -dot- Walker -at- JCI -dot- Com
----------------------------------------------
In God we trust; all others must provide data.
----------------------------------------------
Opinions expressed are mine and mine alone.
If JCI had an opinion on this, they'd hire someone else to deliver it.