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.
I'm not sure I understand the terms you're using. I *do* know the difference
between task-based doc and system-based doc.
In task-based doc, you start with a task list of the jobs a user will want
to do, regardless of where he may wander through the software. A task may
start with a particular screen or window, walk through a series of message
boxes, then finish up in another screen or window. This is the Microsoft way
of designing software, so the doc that comes with the software is highly
user-centered.
Much enterprise software, though, is designed to match a task with a screen.
For example, a particular screen may have several fields, but they're all
for recording receipts of cash. So the distinction between "system" and
"task" is blurry, making it tempting to organize the manual by screen or
window, making it a "system" doc. In a system doc, the TOC doesn't use verbs
("Recording cash receipts") but rather lots of nouns (The Cash Receipts
screen). This is, by the way, in contrast to what we generally mean by
"system documentation", which actually just chronicles how the system itself
works under the hood.
A system-based manual often doesn't have anything to dignify the name of
"procedure". What generally happens is that each screen gets one or more
pages, filled with tables listing the various fields. It may have a list of
the fields for each kind of task, but little more.
In my experience, non-expert users (meaning that they're not expert in the
software nor the subject matter) tend to prefer task-based procedures, even
when the software is obviously designed to be a 1:1 match, task to screen.
That tends to change slowly as their expertise increases. It's usually our
argument to the client that screens almost always hold several tasks within
them, so if the manual is system-based, you *still* have to break that
section down by task, so why not start with a task-based doc? And, further,
experts rarely resort to the doc; it tends to be for the beginner, who will
want a task-based listing.
Tim Altom
Simply Written, Inc.
Featuring FrameMaker and the Clustar Method(TM)
"Better communication is a service to mankind."
317.562.9298 http://www.simplywritten.com
> In regards to computer software, what is the difference between
> task-based procedures and system-based procedures?
>
> Also, could you provide an example of each?
>
> We use task-based procedures when documenting our computer software,
> but am struggling to explain the difference between the two.
>
> Thanks!
> Bill Hartzer
> Technical Writer
> CHA Systems, Inc.
> 2711 LBJ Freeway
> Suite 172
> Dallas, TX 75234
> phone: 972-892-7566
> email: bhartzer -at- cha-systems -dot- com
>
