RE: The End Of Technical Writing

Subject: RE: The End Of Technical Writing
From: eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Thu, 28 Oct 2004 09:45:34 -0400

Tony Markos <ajmarkos -at- yahoo -dot- com> wrote on 10/27/2004 07:00:47 PM:
> I'm a passionate data flow diagrammer (a tool
> for rigorous top-down task analysis). All true data
> flow diagrammer's are noted for their fervent approach
> to task analysis.

I agree rigorous documentation of required tasks is of great benefit to
track those that have been documented and those that require
documentation. But how does the diagramming help? I can certainly
understand that it helps visualise the inter-relation between the tasks,
but how complex does the diagram need to be (how much effort must be spent
on the diagram)?

Any references or examples?

I'd also wonder how such an effort is approached. Is it all done before
the actual research and writing, or is it an evolutive process that keeps
up with documentation development (and charts the near future). I'd have
to question the use of resources if it is an exclusive dedicated task
separate from document development and production. How does it tie in with
the completion of the required work?

Diagrams seem to be a side show to me and not a value added product for
either customer or employer. But, maybe it's because of the industry I
work in and the current improvements in process we use. Components and
their relationships are well defined in parts lists, figure trees, parts
maintenance trees, and maintenance allocation charts. Each of these
defines structure and requirements, but they are not exclusively
organisational tools. They form an integral part of the deliverables (IPC
and Maintenance plan). The only loose factors would perhaps be the
Operations Manuals. But, the writers that produce those are usually very
knowledgeable about the roles and functions that required to be addressed.
Also, these manuals are usually single writer efforts and closely linked
to training.

Diagramming for the sake of diagramming would be a complete waste of time
as I don't see any benefits that would outweigh the costs. But, if there
was a way to diagram the existing information to better visualise it, then
perhaps it could be useful. But, we already have a tool that reports
differences between required tasks identified and tasks checked in as

Eric L. Dunn
Senior Technical Writer


ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!

WEBWORKS FINALDRAFT: New! Document review system for Word and FrameMaker
authors. Automatic browser-based drafts with unlimited reviewers. Full
online discussions -- no Web server needed!

You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit for more resources and info.


RE: The End Of Technical Writing: From: Tony Markos

Previous by Author: RE: The End Of Technical Writing
Next by Author: RE: The End Of Technical Writing
Previous by Thread: Re: The End Of Technical Writing
Next by Thread: RE: The End Of Technical Writing

What this post helpful? Share it with friends and colleagues:

Sponsored Ads