Difference between process and task-based?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Lisa Wright reports: <<Without knowing too much about the product yet, it
seems as if I need to go a step beyond just task-based writing and
incorporate some serious instructional design... I don't think a simple
procedural approach [will] do it... Is there really a difference between
task-based and process documentation?>>

An ideal documentation set contains both "how do I do X?" information (the
task-based material you refer to) and overview or process information; the
latter tells readers what goals they can accomplish with the product,
explains the overall process required to attain those goals, describes the
tasks required to complete each part of the process (ideally in the most
efficient order, if one exists), and explains how those tasks fit together
or conflict (i.e., identifies interrelationships and dependencies). A good
tutorial accomplishes that role, but many tutorials simply run readers
through all the main tasks in software without ever explaining why the
student is doing those tasks and how the tasks fit together into a larger
whole. The typical example I give of this, for desktop publishing, can be
simplified as follows:

Overview: In this lesson we'll teach you how to design a document. Document
design includes the following aspects, which you'll usually do in the
following order: picking a page size (see module I), deciding where the
white space goes (see module 2), developing paragraph styles that work
within these constraints (see module 3), ....

Module 1: Picking a page size: [description of thought process involved in
choosing appropriate page size, plus a list of tasks required to define the
page size in your software, organized in a typical, efficient order. The
text for each task then describes the goal and outcome of the task, and
either provides the necessary steps or points to the correct pages in the
task-oriented section of the manual.]

Obviously, you'll have to turn this general approach into something more
specific that relates to your product, but the goal is to provide an
overview that tells readers what they'll be doing and why (process
information) and supplement this with the specific task-oriented material
that lets them actually do the work once they know what they should be doing
and why.

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html

Hofstadter's Law--"The time and effort required to complete a project are
always more than you expect, even when you take into account Hofstadter's
Law."

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Collect Royalties, Not Rejection Letters! Tell us your rejection story when you 
submit your manuscript to iUniverse Nov. 6 -Dec. 15 and get five free copies of 
your book. What are you waiting for? http://www.iuniverse.com/media/techwr

Have you looked at the new content on TECHWR-L lately?
See http://www.raycomm.com/techwhirl/ and check it out.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit 
http://www.raycomm.com/techwhirl/ for more resources and info.