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.
Any sites that I can visit to get an idea how to construct a true
task-oriented manual?
Tony Markatos responds:
I don't know of any web resources. Books? - there are popular books
describing approaches to a task-oriented organization.
However, contextual-inquiry (the basic approach espoused to in the more
popular of these books) is, in the main, a bottom-up approach. These books
may mention creating some (relatively crude) higher-level diagrams, but
contextual-inquiry is still basically bottom-up.
PROBLEM: I have see many contextual-inquiry type task-analysis projects fail
because the analysts got all wrapped-up in the details. There is an old
Business/Systems Analysis saying: [Task] analysis should proceed in as
TOP-DOWN a fashion as possible - else the analysis team will "drown in an
ocean of details." This is especially true for larger-scale systems
(applications) where there is so much more detail.
The reason that I mention all of this is that, while it is a very important
"real-world" issue" (from what I have see, by far, THE major issue), you
will probably not find any mention of such in any review of literature -
on-line or in books. (There is a long history as to why this is so, but
that is another subject.)
My approach to performing a task analysis: I use Data Flow Diagrams to, in
as top-down as fashion as possible, document the essential end-user tasks
and their interrelationships.
I create what I call "medium-level-rigor" Data Flow Diagrams. I do not
create a complete data dictionary. I only rigorously define major data
flows. I have found doing such to be sufficient when the final output is
text (on-line or hard-copy).
I then repartition the Data Flow Diagrams until the interface complexity
(i.e., number of data flows) between the tasks (functions) is minimized. At
this point, I have:
1.) Performed a very rigorous, end-user-focused task analysis.
2.) Very effectively "chunked" the system of tasks into "right-sized"
pieces.
From this point, creating a highly task-oriented organization for the
on-line documentation (or hard copy) is a straight-forward shot. The tasks
from the Data Flow Diagrams become major sections of the documentation.
When I decompose a task into sub-tasks, the sub-tasks become documentation
sub-sections.
Tony Markatos
(tonymar -at- hotmail -dot- com)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
