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:Business of PDF versus HTML From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Wed, 11 Mar 1998 08:06:00 -0500
I have the feeling that this discussion has ambled away from PDF versus
HTML and into another subject: the business imperatives of documentation.
In his message quoted below, Scott seems rather exasperated with me for
holding that efficiency and risk reduction are more desirable than user
pleasures. Not so. But they ARE more important for my clients.
We're a contract house here, and that means we're conscious at all times of
the business needs of our clients, which are sometimes in conflict with
their documentation needs. We're also conscious of OUR needs, which simply
stated are dollars and cents. We thrive only on our ability to do jobs
faster and more efficiently than our competitors. And despite Scott's
desires, or mine, or anyone else's, there is a direct positive correlation
between glitz and cost. Writing scripts costs money. Not being able to
automatically update a help file from a print file costs money. And at some
point the client has to pay that tab. Few around here seem willing to foot
a bigger bill for what they perceive as a marginal increase in usability.
Scott may be right that HTML is inherently a better and more usable medium.
I'd dispute that in most cases, but he's welcome to his opinion. But it is
a fact that creating all those pages and graphics, keeping track of them,
moving them, updating them, creating graphics for them, costs more than it
does to whip out a PDF from FrameMaker, complete with links courtesy of
else in particular wouldn't, but that it couldn't be shown to work
reliably, every time. Businesses don't like supplying things that may or
may not work (unless the company is Microsoft, I suppose). But around here
our clients aren't happy with an online system that depends so much on the
customer's caprice, knowledge, and preparation. Businesses like to reduce
variables, not introduce more of them. More than once I've found a client
who relaxes when told just how ubiquitous and reliable WinHelp is. HTML
can't make that claim, nor probably will it ever be able to.
Having run this business for a while, it's easy for my partner and me to
understand the business imperatives of our clients. Sometimes a ten percent
increase in possible usability isn't going to provide enough ROI for a
fifty percent increase in cost or complexity.
>> JScript. But Netscape doesn't honor JScript...Java applets require
>too many options, too many opportunities for the unknown to
>> intrude. It's fine if it's a website that you're experimenting with, but
>> users on real systems have jobs to do and don't appreciate having files
>> that don't read or perform properly. At least PDF is fairly bullet-proof,
>> and WinHelp is just about invulnerable. Flexibility often brings risk with
>> it. I'm never comfortable with risk when I deliver something for the
>> client's customer base, something that can reflect well or badly on my
>Oh yes, Im sure they would they would rather go about reading page
>after page of written documentation rather than having a dredfully
>rich and interactive lesson where they actually LEARN something.
>> Further, creating system support HTML with lots of scripts and applets
>> isn't my idea of efficient production, especially if you're creating both
>> print and online. Too much skill needed and too much testing required to
>> get it all right. It takes time, and most clients aren't in the mood to
>> write bigger checks at the back end of big, expensive projects.
>We all know that efficiency of production is much more important than
>the users efficency in understanding and learning don't we?
>> Tim Altom
>> Vice President, Simply Written, Inc.
>> 317.899.5882 (voice) 317.899.5987 (fax)
>> Creators of the Clustar Method (TM)
>> An out-of-the-box methodology for fast task-based documentation
>> that's easy to port to paper, WinHelp, Acrobat, SGML, and other media.
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
Creators of the Clustar Method (TM)
An out-of-the-box methodology for fast task-based documentation
that's easy to port to paper, WinHelp, Acrobat, SGML, and other media.