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:"Ned Bedinger" <doc -at- edwordsmith -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Thu, 28 Oct 2004 19:37:51 -0700
Tony--
Three questions for you to address:
1. Something you said a while back seemed to suggest that the DFD approach
can be risky. What's that about?
2. How do you account for the power of DFDs to capture end-user tasks? My
experience is that many tasks are not related to data flow. Consider a
procedure named "Troubleshooting an unresponsive server." Would you
automatically assume a data view of the diagnostic tasks (checking
configurations, pinging hosts, restarting services) and go from there?
3. You descxribed DFD as a top-diown approach to a system and task
analysis. In what sense is it top-down?
Thanks.
I also diagram (even data flows, if data flow is in scope) to consolidate
what I know about a system. For example, I always try to keep a "state of
my understanding" diagram handy in SME interviews (at all times, really). I
want a SME to validate what I think I know, much of that exchange can be
done quickly, visually with a diagram. IF I am concerned with the flow of
data in a system, then I would of course show the data flow, even in a
separate DFD.
BTW, regarding Task Analysis, I worked in an IT department that had a
program called "Walk a Mile In My Shoes" -- IT people could arrange to
explore their career paths by spending a few hours on the job with other IT
professionals in the company. Some tech writers took this as an opportunity
to spend time with their customers, seeing (often for the first time) who
and what they were the writers for. I'll admit that I have analyzed many
tasks and written many procedures in a complete vacuum, with no real
experience of the user or the real context. I'd go a little further to say
that first hand experience of the user in the work context is a helpful
adjunct in getting task analysis right.
> 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.
>
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.
