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:Re: Structured Writing Question From:doc -at- edwordsmith -dot- com To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Mon, 27 Mar 2006 21:28:12 -0800
On Monday 27 March 2006 08:51, Tony Markos wrote:
>What formal analysis
> techniques to you use to orgainze your documetation's
> outline (or equivalent)?
Reverse speed reading is the only rational approach. It is 50% visualization
(visualize the manual you want to write) and 50% preparation for interviews
(the structure reflects the questions that the manual answers).
Visualizing the manual is the tricky piece. As you know, vision in the mind's
eye is not equal for everyone (i.e., synesthesia). So you might now be
saying that visualizing the finished manual isn't necessary because structure
is about content and not about design.
I would agree in principal, excepting my mental model of the finished manual.
My model is a stack of transparent overlays showing the build-up and
drill-down of information--it is the visual version of the relationships
among my interview questions. IOW, it is structured visually, reflecting the
reasons for the questions I devised.
The visualization makes a handy reference during the manuscript development
process, when I am deciding what views need to be presented as
charts/tables/graphics. I don't need to visualize to know that I am going to
include the traditional visual representation of the system in Overview, a
table of error codes (if appropriate), etc, but I do visualize and detect
topics that feel qualitatively cumbersome to me, and I keep these in mind as
candidates for development and presentation with visial aids.
New unfamiliar subject matter, like if I transferred from Network Development
projects to Software Engineering projects, doesn't defeat my analysis, but
appears as lumps and wrinkles in the overlays. When I report that my progress
on the project is lumpy, you can rest assured that I have the figurative
flopping tuna on deck, and am sooner or later going to chunk it for eventual
consumption by speed readers.
Hope that helps,
Ed Wordsmith Technical Communications
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l