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.
We MUST separate them, because often projects depend on our ability to do
so. In our world, "content" is text, graphics, or other material that
directly communicates a concept or fact. "Structure" is the order and
organization of that material. "Layout" is the visual or aural
representation of the content. Simply put, structure is the way the missile
is designed, content is the payload, and layout is the paint job.
When I design a structure, I don't need to know the first word or concept.
The product can be software, a robot, or a procedure. It doesn't matter. The
order of presentation, the organizational pattern, and the hierarchy remain
the same for each type of communication. For example, I may know that I want
three sections, that each section will have a number of chapters (I don't
care how many at this stage) and that each chapter will have specific types
of headings, each containing certain permitted types of information (paras,
tables, graphics, etc.). I make sure that each element is given its own tag
and place in the hierarchy. This planning now permits me to set up and test
mappings, downstream filters, and other attachments. It also permits me to
start training writers in how this document will be produced. At both ends
of the production cycle, I can start buckling together my assembly line. All
without a single word being written. In point of fact, I may not even know
what the product is, although I usually do.
Let's take a simple example. I set up a structure as I've described for a
client's newly-written enterprise software. The software is still under
development and not even ready for me to try it out. But I can still
1)Define a doc structure and create a template and/or DTD; 2)Define a map
between my document tags and the tagging for Webworks Publisher or ForeHelp;
3)Create a sample "dummy" online file for the software developers to test;
4)Use the same sample "dummy" online file to show the client how the links
will work in the real file; 5)Set up and test a "dummy" flow from the creati
on tool, through the various filters, and out to the final destination, be
that HTML on the Web or online help; 6)Create a "dummy" print file and get
the client to sign off on the layout and structure; 7)Get writers up to
speed on using the templates and/or DTDs.
All without one word of real text being applied. All I have to do is pour
the wine drop-by-drop into the bottle I've created. I can now create,
change, shift, and masticate the words and graphics without affecting my
assembly line one bit. I can, if you will, drain out the wine if it's not
correct and just pour in some new. The bottle must remain the same shape to
fit onto the assembly line with all the other project components.
The key to being able to do this is the document specification, which is the
analogue of the engineer's specification for the product. The doc spec
defines what the document is to DO, not how it's to look. Structure flows
from functionality, not from content.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar(TM) System
"Better communication is a service to mankind."
317.562.9298
Check our Web site for the upcoming Clustar class info http://www.simplywritten.com
> 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.
>
