Re: Task-based vs. System-Based Procedures

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

I said:
>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
target market.

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-
based interface.

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

-Sue Gallagher
susan-gallagher -at- vertel -dot- com

The _Guide_ is definitive.
Reality is frequently inaccurate. --Douglas Adams

Re: Task-based vs. System-Based Procedures: From: Anthony Markatos

Previous by Author: Re: New Hires
Next by Author: Re: New Hires
Previous by Thread: Re: Task-based vs. System-Based Procedures
Next by Thread: Re: Task-based vs. System-Based Procedures

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

Sponsored Ads