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[2]: Front Page Fussy From:"Jeanne A. E. DeVoto" <jaed -at- JAEDWORKS -dot- COM> Date:Wed, 13 Jan 1999 19:43:04 -0800
At 1:48 PM -0800 1/13/99, John Gilger wrote:
>I hate to be a curmudgeon here, but....
>
>What is the point about all of this malarkey about Front Page? We all
>use different tools for different tasks. What difference does it make
>which tool we use if we produce a quality product with it. ("Quality"
>means the customer accepts it, in this case.)
Well, I can't agree with your definition of "quality". It is entirely
possible to pull the wool over an ignorant customer's eyes; it's more
difficult to do so with, say, program documentation than with a web page,
but every day sees people (inadvertantly or otherwise) do a song and dance
that makes customers accept a shoddy product that ultimately will not serve
*their* customers well. But there's a more important point lurking here.
What is quality in documentation? Clarity, applicability, completeness,
accuracy are all part of it. In printed documentation, normally our tools
don't matter to the user, because the final product is independent - no
tool is needed to interpret it, so it looks the way it looks regardless of
what it was produced with.
The same cannot be said of web pages. Every web page has to be interpreted
by a web browser, and so the details of the markup do matter, do affect the
reader, whether that reader can see them directly or not.
A manual set completely in Old English type, three words per page, on
glossy fluorescent-orange paper could not be said to be of high quality
regardless of how good the writing was: it's difficult or impossible to
read. In the same way, web pages that are marked up in such a way that
they're slow to download and render, incompatible with a browser the reader
may be using, made to be inaccessible to the blind, or physically hard to
read due to poor choices in overriding the user's font and color choices
cannot be considered good, regardless of the quality of the content. As
writers, we often concern ourselves with content while leaving the quality
of the presentation to specialists. But if we're going to present our
content as well as write it we need to concern ourselves with the quality
of the presentation. And hence (when the tools can profoundly affect
quality of presentation) with the tools we use.
A high-quality web page, to my way of thinking, needs to load and render
snappily, be easy to maintain (into the indefinite future, if the content
is expected to last), present its content in a way that's easy and natural
to navigate through and read, and gracefully cope with whatever browser
situation it's likely to be presented in. These are not subjective
standards, at least in that they don't depend on my personal sense of
aesthetics or taste but on the user's needs.
As far as FrontPage is concerned, I will say that I have yet to see a web
page that is of good quality by my standards. My belief is that the tool
itself is flawed at a basic level - not only in implementation but in
design philosophy. I consider it perfectly reasonable, myself, to point out
the problems to people considering whether to use such a tool; they may not
thank me, but eventually the users who read their work may.
