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: The End Of Technical Writing From:Tony Markos <ajmarkos -at- yahoo -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 28 Oct 2004 09:20:28 -0700 (PDT)
Eric Dunn asks:
But how does the diagramming help?
Tony Markos responds:
For Discovery of Tasks:
Data flow diagrams add rigor to task analysis by
making logical "holes" in ones analysis glaringly
evident. When we have tasks on the diagram with
outputs, but no inputs, or vice-versa, or when data
flows show as going nowhere, they stick out like a
sore thumb! They actually prod one through the
analysis (i.e., discovery) phase.
For Verification of Procedure With End-User:
DFDs are great communications tools for verifying
procedure. You bust them down to right-size peices
(one never should approach a user with a big diagram)
and then sit down with the user and walkthrough them.
Often, during walkthroughs, users take the diagram and
draw in the necessary corrections. This is so much
more effective than, lets say, trying to have users
verify text.
Eric Dunn asks:
...how complex does the diagram need to be (how much
effort must be spent on the diagram)?
Tony Markos responds:
Not nearly as complex as many think. The key to
reducing effort is to understand the principles and
then become very street wise:
* The text books are too complex - only use what
you need to. You want to caputure the essential
inputs, tasks, and outputs - here you want rigor. But
you can do without things like a data dictionary and
specific file identification. I have always found
that a medium-cut rigor data flow diagram is all it
takes to be ahead of the pack - including, believe it
or not, ahead of the chief architect(s) of the system.
* Forget Visio and the like! Talk about an
initiative killer! Often rapid iterations are
necessary. Always have a good supply of sharp #2
pencils with good erasers to rapidly hand draw
diagrams. Use Visio only at the very end if you want
something pretty.
* Don't be afraid to be messy! Your first cut at
your higher-level diagram is going to look like heck.
A couple of months ago, when a fellow TW saw a
first-cut diagram of mine, she let out a scream
because she thought it was so messy. So what, it only
took a couple of hours to redraw it (with pencil of
course).
Eric Dunn asks:
Any references or examples?
Tony Markos responds:
I think Ive got a couple of my samples for my
portfolio, but nothing to put on the net. The
overwhelming majority of hiring managers don't have a
clue as to the power of data flow diagrams - or are
fearful of them. Therefore, I don't use them for a
self-marketing tool.
Eric Dunn asks:
> 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).
Tony Markos responds:
As we are talking about task discovery, much is done
up front. But thereafter, you have an excellent
baseline document for capturing changes.
Eric Dunn asks:
> How does it tie in with
> the completion of the required work?
Tony Markos responds:
After diagram iterations for task discovery, I then go
through an iteration or two of redrawing so that the
interface complexity between tasks is minimized.
Bang! - now I have the system both properly scoped out
and chunked into right size peices - Great for
planning the outline of your docs!
Eric Dunn states:
> Diagrams seem to be a side show to me and not a
> value added product for
> either customer or employer....
Tony Markos responds:
The goal is come up with a rigorous, comprehensive
understanding of the essential end-user tasks and how
all these tasks interrelate. All efficient and
effective written documentation is based upon this
understanding.
When I went through a Yourdon data flow diagramming
class, the instructor told us that obtaining such an
understanding is ninty-eight percent (98%) of the
required work in any systems tech comm project.
Ninty-eight percent of anything is alot! And nothing
comes close to DFDs in providing this understanding.
ROBOHELP X5: Featuring Word 2003 support, Content Management, Multi-Author
support, PDF and XML support and much more!
TRY IT TODAY at http://www.macromedia.com/go/techwrl
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! http://www.webworks.com/techwr-l
---
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 http://www.techwr-l.com/techwhirl/ for more resources and info.
