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: Task-based vs. System-Based Procedures From:"Susan W. Gallagher" <susan-gallagher -at- vertel -dot- com> To:techwr-l -at- lists -dot- raycomm -dot- com Date:Fri, 07 Jan 2000 14:17:56 -0800
>In general, what we commonly refer to as task-based procedures
>assume the user's perspective while system-based procedures
>assume the developers' or software interface perspective.
>Tony Markatos responded:
>This is a very common misconception...
> Such confuses systems design with bad systems design.
>...good systems analysis/design, the developer's
>perspective is EXACTLY the same as the end-user's perspective. In the
>ideal, one software module (and it's associated procedures) accomplishes one
>end-user task. This is THE major principle upon which formal systems
>analysis/design techniques - such as Structured Systems Analysis and Design
>- are based upon.
>Technical Writers like to be thought of in terms of best practices; so do
Structured systems analysis and design documents are the cave
paintings of the software industry. Today we perform object-
oriented analysis and design. And, as Yvonne DeGraw pointed out:
>In object-oriented design, user tasks
>definitely *do not* correspond one-to-one with object classes.
That said, despite the underlying design of the software, there are
task-based software interfaces and function-based software interfaces.
Neither can be classified as good or bad, only as appropriate to the
Of the many different accounting packages available to small businesses,
some are task-based interfaces, offering menu selections like "pay my
bills" and others are function based, offering menu selections like
"cash dispersments journal". This doesn't make one package better than
the other, both will keep your books. The task-based interface can be
used more easily by someone who has no domain knowledge in accounting;
but if you've had a basic accounting class, you'll probably be just as
comfortable and maybe a little more productive using the function-
Hybrid interfaces exist. MS Word, for example, began life in the DOS
days and so has its roots in function-based interface design. By that
I mean that Replace and Save and Format are functions, not tasks. A
task is "write a letter". Now, OOA&D has enabled the programmers to
extend the function-based interface by adding task-based wizards to
the program. The novice user can, indeed, select the task "create
a letter" and be guided through the process. A well-designed wizard
will even shield the user from ever needing to learn about the miriad
functions that need to be performed to accomplish the task. But this
task-based interface is not appropriate for all audiences. I'd venture
a guess that none of the readers of this list would use the letter-
writer wizard. It's a boon to the novice or occasional user but
totally inappropriate for the expert.
That said, despite the design of the interface, documentation can
be based upon funtions or tasks. Neither approach is inherently
bad or good; but one or the other will be more appropriate for the
target audience. In _very_ general and _very_ broad terms, one
would consider task-based documentation to be more beneficial to
the novice or occasional user and function-based documentation
(or, reference material???) to be of more use to the expert user.
Perhaps, Tony, when you find a misconception that is so common as
to be held by everyone but you, it's time to re-evaluate your