Re: Task-based vs. System-Based Procedures

["Susan W. Gallagher" <susan-gallagher -at- vertel -dot- com>]

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 
>analysts/developers.

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
perspective.





-Sue Gallagher               http://pw1.netcom.com/~gscale/susanwg/
susan-gallagher -at- vertel -dot- com   http://www.vertel.com

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