Re: Task-based documentation-best practice

Subject: Re: Task-based documentation-best practice
From: Chris <cud -at- telecable -dot- es>
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Fri, 01 Mar 2002 09:38:59 +0100

I think the issue of business task vs tool task depends highly on the audience and the product. Some products are quite focused on a work flow, and the procedures follow that flow very neatly - business procedures. Other products are meant to work in a wide variety of work flows, and consequently their "tasks" have as much to do with fitting the product into the specific work flow as they do with achieving a final goal.
Take a word processor - you would be hard pressed to document a word processor along tasks such as writing a memo, writing a letter, writing a report, writing a brief, writing a book, etc. Where you find these types of tasks they're usually all grouped in one section, and are additive - "Before writing a letter, be sure you understand how to write a memo..." But you almost always find other "tasks" which are more tool-based. Making a table, importing a graphic, cross-references, etc.
On the other hand, a database might be more specific - Adding a new customer, shipping an order, getting an inventory report, etc. So the short answer to your question (IMO) is a resounding, "It depends".
The task-based mantra originated in the old days before windows-based U/Is and the like. Modern products actually present a language and a grammar - you have nouns, adjectives, verbs, and sometimes adverbs. Select a thing, apply properties, perform some other action, modify the action. The nouns and verbs certainly mix and match, and often the modifiers as well. One of the more complex languages we all know is the English language. It has task-based user manuals - style manuals and the like, reference manuals - grammar texts, quick references - dictionaries and thesauri. They each serve a purpose, and have evolved into the present form over many years of use. Not forgetting that the complexity of a language has much to do with the way it's documented, I draw inspiration from the English Language documentation set.

--
Chris Despopoulos, maker of CudSpan Freeware...
Plugins to Enhance FrameMaker & FrameMaker+SGML
http://www.telecable.es/personales/cud/
cud -at- telecable -dot- es



^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now's a great time to buy RoboHelp! You'll get SnagIt screen capture
software and a $200 onsite training voucher FREE when you buy RoboHelp
Office or RoboHelp Enterprise. Hurry, this offer expires February 28, 2002. www.ehelp.com/techwr

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



Previous by Author: Stupid TW Tricks (was: Integrating Tech Pubs more closely with Engineering...)
Next by Author: RE: Health Coverage for Contractors
Previous by Thread: RE: Are you a writer
Next by Thread: RE: Task-based documentation-best practice


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

Sponsored Ads


Sponsored Ads