Business of PDF versus HTML

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
PDFMark.

My major point below wasn't that JavaScript wouldn't work,nor that anything
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.

>> I see that as a drawback, actually. Explorer doesn't read JavaScript, but
>> JScript. But Netscape doesn't honor JScript...Java applets require
>> download...
>
>Actually if if stay away from JavaScript 1.2 then both Netscape and MSIE
>work with JavaScript.
>
>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
>> client.
>>
>
>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?
>
>Scott
>
>
>
>>
>> Tim Altom
>> Vice President, Simply Written, Inc.
>> 317.899.5882 (voice) 317.899.5987 (fax)
>> www.simplywritten.com
>> 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.
>>
>>
>>
>
>
>
>
>
Tim Altom
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
www.simplywritten.com
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.




Previous by Author: Using FrameMaker to Mothball
Next by Author: Re: HTML Programming vs. PDF
Previous by Thread: Using FrameMaker to Mothball
Next by Thread: Training tutorials in the online help


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads