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.
While it's true that formats can be overridden in either application,
a typical Word doc will find that Word seems to encourage creation of
enormous numbers of "styles" even when that is not intended or even
realized by the users.
Also, it is rare that non-techwriters would even have Frame to mess up.
In my example, the document was perhaps ten years old already, with
fifteen or twenty change releases during its prior life--and, given
the turnover at the company involved, probably with nearly that many
people involved.
Unfortunately, the standards expected of people in docs departments
like that one were very low. In fact, at that time all their
deliverables were .pdf files--with little attention paid to the source
files so long as the output seemed all right to a cursory examination.
In the field, though, customers had fairly substantial frustrations
stemming from the resulting poor documents, while the company was
paying far too much in labor each revision cycle because the docs were
such a mess to make work even in a basic manner.
The product involved was a digital telephone switch. These are not
replaced all that often, but are regularly modified either in software
or hardware to increase their capabilities--hence the long life cycle.
The release changes I was responsible for were fairly small, so for
that release cycle I was the principal author involved. I soon came to
realize that checking through the entire document to be sure it
generated correctly would consume enormous time on my part, while
reformatting the whole thing wasn't really that much more
involved--and would save subsequent writers huge amounts of time when
the doc had to be updated next. As I mentioned, they were on a
six-month update cycle at that time. Since it was Nortel, God knows
what has happened since--although the product was quite popular both
with civilian and military customers. That was considered a "campus
grade" switch--maximum capacity of 30,000 lines---which was used on
miitary bases worldwide, by universities, and by large corporations
(Microsoft had two of them, IIRC).
(There were actually two sets of docs--one for the military market and
one for the civilian one.)
I think a key take-away from this experience was that there is no
substitute for hiring tech writers who are competent, or at least who
take their job seriously enough to want to do it well, with an eye to
"future proofing" the documents for subsequent upgrades as much as
possible.
However, in my view it is unfortunate that Word is chosen by many
firms for documentation just because they buy it for general use. That
does not mean it is the best tool for the job--and because its use is
often so ubiquitous, the law of unintended consequences can mean a
large amount of grief in maintaining documents. Personally, if I were
working again in a Word shop, I would seriously contemplate still
circulating .pdf files for review and comment so I could have some
control over any modifications to the originals.
I did notice Gene's comment about limiting style modifications. Either
that was not a feature of the Word versions I worked with in past
years, or it is a feature I was completely clueless about. Of course,
I have not used Word now in a few years. I grew tired of the gyrations
necessary to get it to work acceptably on complex docs, so when I no
longer was forced to use it I even stopped loading it on my personal
machie--and, now that I am fully in Linux, it is a moot point.
David
> From: "Dan Goldstein" <DGoldstein -at- riverainmedical -dot- com>
> To: <techwr-l -at- lists -dot- techwr-l -dot- com>
> Date: Fri, 26 Mar 2010 09:04:20 -0400
> Subject: RE: Format overrides; was: RE: Top 10 mistakes unstructured FrameMaker Users make
> You were given a large Frame document whose formatting had been messed
> up by the unskilled hands that passed it around. The solution was to
> reduce the whole thing back to plain text, and then reapply styles
> correctly.
>
> How is that different from a Word document whose formatting has been
> messed up by the unskilled hands that pass it around?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use Doc-To-Help's XML-based editor, Microsoft Word, or HTML and
produce desktop, Web, or print deliverables. Just write (or import)
and Doc-To-Help does the rest. Free trial: http://www.doctohelp.com
Explore CAREER options and paths related to Technical Writing,
learn to create SOFTWARE REQUIREMENTS documents, and
get tips on FUNCTIONAL SPECIFICATION best practices. Free at: http://www.ModernAnalyst.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
