Re: Task-oriented manuals

Subject: Re: Task-oriented manuals
From: "Anthony Markatos" <tonymar -at- hotmail -dot- com>
To: TBucheger -at- Winnebago -dot- com, techwr-l -at- lists -dot- raycomm -dot- com
Date: Thu, 20 Jan 2000 09:36:22 PST

Tara Bucheger asks:

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

Previous by Author: Data Flow Diagrams vs Use Cases
Next by Author: Re: Plain English explanation of use cases??
Previous by Thread: RE: Task-oriented manuals
Next by Thread: RE: Task-oriented manuals

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

Sponsored Ads