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.
----- Original Message -----
From: "Ellen Vanrenen" <ellen -dot- vanrenen -at- clear-technology -dot- com>
>>>
[...] I am floundering in trying to define policies and procedures docs. I
was told a task differs from a procedure. Does anyone know in what way(s) it
does? I have looked into it and cannot find a difference. [...]
<<<
"You're going to find that many of the truths we cling to depend greatly on
our own point of view." - Obi Wan Kenobi ("Return of the Jedi")
It's a common choice to make in tech writing, and it depends on who will use
your document and what their aim will be. As I see it*, a "task" is your
defined goal or the object of your endeavours. A "procedure" is a
step-by-step view of how you will get from point A to point B.
Task-based documents generally follow an assessment of what specific jobs a
user will want to use the product for and describe how to do each job. These
documents are organised by the task - that is, by the desired final outcome.
Procedure-based documents generally describe the functionality of the
product and may not take into account the needs of a user. These documents
are often organised in a manner that parallels the organisation of the
product itself.
To my mind, task-based documentation is better for the user, but it may not
always be possible for a tech writer to write it, for example, if it is a
new product for which there is no developed user base, or if the only
feedback for documentation comes from the product's developers**.
/ Mark Moloney
* A classic disclaimer.
** I always try to involve sales / pre-sales engineering in documentation
review - however indirect it may be, it's as close to customers as I can
get.
A landmark hotel, one of America's most beautiful cities, and
three and a half days of immersion in the state of the art:
IPCC 01, Oct. 24-27 in Santa Fe. http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
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.
