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:Designing by outline From:"Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA> Date:Sat, 13 Feb 1999 04:55:31 -0700
Damien Braniff noted that <<I often do a rough outline of a manual
etc before starting. This isn't a detailed plan but is often a first
shot at putting my ideas down on paper... There will be many changes
from the initial scribbled outline to what could be described as firm
manual plan! ... I don't see this as a hard and fast approach - more
organic really, that grows into the project.>>
I hate to say "me too", but... me too. <g> I usually spend a fair bit
of time contemplating a product until I have a reasonably good
wholistic view of what it is and what it does. With that schema in
hand, I put together a good first draft of an outline, and dive into
the product to begin documenting it. It rarely takes long before I
realize that my wholistic view needs considerable refinement, and as
the refinement proceeds, the outline gradually conforms to my new
understanding. It's kind of like watching a Polaroid instant-picture
developing: everything starts out fuzzy, but pretty much close to the
final product, and as you watch, the picture becomes progressively
better defined. My fiction writing is much the same, only more so.
One of the more intriguing things I find is that some topics set much
later in the original outline, which originally seemed to demand
their own sections, often end up merged with the current topics I'm
writing simply because the reader needs the explanation _now_, not
several chapters later. The end result is that the manual tends to be
much shorter than it would otherwise be, and the concepts are much
more tightly integrated with the tasks they explain.
Oddly enough, there's a branch of computing called "genetic
algorithms" that follows a conceptually similar approach: the
programmers come up with a bunch of good approximations of what they
want to accomplish, then "virtually" engage in Darwinian natural
selection to create "mutations" in the algorithms and see which ones
are most efficient and survive best. Over a series of "generations",
the best algorithms gradually emerge from the soup. Science
(programming) imitates art (writing)!
--Geoff Hart @8^{)} Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
