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:Trapping your content in HTML From:Bill Burns <BillDB -at- ILE -dot- COM> Date:Thu, 26 Mar 1998 09:26:40 -0700
Okay, I know I might be treading on thin ice here, but I'm gonna do it
anyway.
When I was at Documation 98 two weeks ago, the number one caveat I heard was
"Don't use HTML as a storage format." In other words, if you have
data/content that needs to be reused or simply has to be maintained long
term, you should develop in a tool that allows you to filter to HTML rather
than developing in HTML itself--especially if you have to have multiple
deliverables.
The logic behind this warning, to me, seems very clear, especially since I
work in localization where we leverage content from one project to the next
to reduce costs. It also makes perfect sense if we have to deliver a
hardcopy and then put a copy on the web, or an online document with a
hardcopy for fulfillment. The content we develop is relatively long lived,
so we try to use flexible tools that allow exportation. (Believe me, I'm
looking forward to moving into XML and a structured content management
system.)
HTML is fine if you're creating a document or web site that will always be
in HTML, but trying to reuse content in other applications, especially if
you've used a complex layout, can be hellish. Nonetheless, I see folks going
along with management's or marketing's push to "put the next version of the
manual in HTML" without any consideration for the long term consequences. In
addition, management and marketing often have expectations about print
quality that simply aren't realistic with HTML. They want to start with an
HTML manual (through development), then reformat the document for hardcopy
without increasing schedules or budgets. They think it's a reasonable
request.
SO--my question is this:
How many of you push back when you're asked to develop a manual in HTML
under these circumstances? How many of you explain why these are NOT
reasonable expectations? What tactics do you use to get this point across?
Bill Burns
Senior Technical Writer/Technology Consultant
ILE Communications
billdb -at- ile -dot- com
