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.
Re: About mil/heavy industries documentation standards (long)
Subject:Re: About mil/heavy industries documentation standards (long) From:k k <turnleftatnowhere -at- yahoo -dot- com> To:TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 12 Feb 2004 09:01:24 -0800 (PST)
>
> When a large organisation (like AECMA, ATA, or any
> other
> civilian/military organisation or body) sets out to
> create a
> specification for the creation, maintenance and
> production of technical
> documentation, why is such an infinitely small
> amount of effort put on
> the part of the spec that defines how technical
> documentation complying
> to this spec should look like when formatted as
> page-oriented output? I
> know - page-oriented output may not have been
> AECMA's first intention
> with the spec (rather IETP &c), but that is the way
> that many industries
> use the spec anyway.
>
Because they don't care what it looks like?
In a way, it is sensible. It's quicker and easier to
turn out a finished document if you work only on
finishing the content, and not on both finishing the
content and polishing the appearance. When I do a user
manual I'd probably save a couple of man-days if I
didn't have to care where the page breaks are. And it
is most important that the information be complete and
accurate. Polished page layouts and formatting may
make things easier to read to some extent, but when it
comes to finding information in a document a good TOC
and index are even more important.
When was work on creating that spec begun, what kind
of systems were they using, and who did it? I've seen
a lot of specs and other documents used in
government-related work that are the way they are
because of the ages involved. It's possible the first
draft of that spec was begun on a 486 with a CGI
monitor. And remember that the review/approval process
for government-related work can take unGodly long. I
would not be surprised to find that the process of
drafting that spec was started by people whose
familiarity with using computers to create documents
is mainly text file editing using vi or emacs. Maybe
the spec writers really did think in typewriter terms.
(Last year I heard constant complaints like yours from
a friend working in a company that does business with
a state government. He had to deliver his content for
review to the state liason people. They insisted it be
delivered as simple text in hard copy - very close to
what you can do with a typewriter - because the state
people were all old bureaucrats who barely knew what a
computer is, much less how to use Word's change
tracking feature.)
I'll bet some of the work done under that spec will be
done on VMX terminals or similar systems. There are
plenty of places where "legacy" systems are still
used. There's absolutely no point in even thinking
about a spec that includes rules about MS Word-style
headings when the only way you can view the documents
is in glowing green block text.
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html