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.
Been there, done that, found it was a supremely boring waste of my time and
talent. I have a whole portfolio of stuff done for the DOD, and I never need
it anymore. I can write to MilSpecs if necessary, and wrote everything you
talked about. I am so happy I don't have to do it anymore--it's content and
process for its own sake, and like the government, never accomplishes
anything useful.
My not so humble opinion
Connie
-----Original Message-----
From: Dan Emory [mailto:danemory -at- primenet -dot- com]
Sent: Monday, June 12, 2000 5:00 PM
To: TECHWR-L
Subject: RE: Structure vs. Substance?
At 04:32 PM 6/12/00 -0400, Giordano, Connie wrote:
>We must be defining "content" differently, because I can't see doing
>structure without content--you just can't do an outline on nothing and you
>can't develop a structure for nothing.
>
>I have to have some idea of what the content is going to be before I can do
>any kind of structure. Whether it's an outline for an essay or a complete
>set of DTDs, if you don't know what's in it, by at least simple definition,
>you won't have a clue about how or why to structure it a certain way. What
>does the product do, why does it do it, and why should anyone care? If you
>have the answer to that, you have the start of content. If you don't have
>an answer, you will have no clue as to whether your structure has
successful
>communicated the content.
>
>I guess we'll have to agree to disagree-I just can't separate content and
>structure so completely as you can.
==================================================
Then apparently you've never written a manual to a generic government
or in-house document specification that typically defines the organization
(i.e., structure), the kind of content to be included in each structural
component,
and sometimes even the level of detail of the required content.
Typically, separate specifications are written for each document type,
and all documents prepared in accordance with a particular
document type specification are quite similar, at least at the
highest levels of structure. There are obvious advantages
to this approach: Regardless of how many different companies
produce manuals for a large, complex system, users know, at least in a
general way, where they can find various types of information
(e.g., troubleshooting, preventive maintenance, installation
instructions, operator instructions, etc.) in the manual for
each component of the system.
====================
| Nullius in Verba |
====================
Dan Emory, Dan Emory & Associates
