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.
By your definition of "task based" I take it that any documentation that helps the user do his or her tasks is "in" and anything else is "out."
The problem with that definition is that it assumes that the task set of a user is, in fact, knowable. Secondly, it assumes that the writer is in a position to understand the user's situation and needs precisely.
I submit that this is not something that can be more than approximated in either case. What tasks a user wants or needs to do today may have little relation in any specialized sense to what he or she may be doing tomorrow. Thus, to a significant degree, as-yet-undefined tasks are not able to be known.
Further, some tools lend themselves to purposes far beyond their original intent. Consider a modern spreadsheet, with hundreds of functions built in. Many of those functions are used in ways the tech writer does not know and does not expect to know. At some point, the doc set must be tailored to a concept of the universe of potential users. Since such a universe in the case of an Excel or a Calc is so very broad, I would suggest that your view of "task" orientation would soon break down if you pretended to be even nearly comprehensive.
Failing the ability to determine what these tasks are with any real precision, then, creating any sort of pure task-based understanding that even pretends to be all-inclusive is bound to fail.
On the other hand, if you have a product with a clearly defined capability set, it could be easy to understand what sorts of tasks may be included in a user set. However, the "great unwashed" community of users reminds me of the story about the gorilla who was the object of a psychology experiment. It seems the behaviorists placed him in a cage in which there were eight possible ways to escape. The gorilla, not being privy to the list, found an eleventh. In fact, he had discovered a "task" which the designers of the experiment did not foresee.
Given your definition of the terms involved, therefore, I think the honest approach is to admit up front that it is a very inexact goal. The most we can do, in many cases, is come "somewhat close" to the ideal of a purely task-based documentation set. However, to me the utility of the concept lies in the stress on the function the tool is to serve within the user's environment. To borrow the popular cliche, I would suggest that "task based documentation" has value in the "journey, not the destination."
However, to me this is simply a semantic distinction. My approach, driven by years of *marcom* work, is to carefully target the user and, therefore, what the user seeks to accomplish with the product. The better the marketer understands the user, the more facile is the response to the user's needs. On the other hand, although tech doc teaching for years has said we must focus on the audience, too often this sort of thing is so often used as to become a cliche. By "repackaging" the approach and finding another way to describe it, we interest the practitioner of the information in approaching the subject with renewed enthusiasm.
Which is the essence of *marcom* practiced well. Your act of discovery of the tasks of your user base is the essence of a marketing function; realizing the need for it is the result of increasingly sophisticated understandings of good marketing practices--and the extent to which they have permeated other parts of business.
To come full circle--with a sentence fragment: Including tech writing.
David
-----Original Message from Mark Baker listsub -at- analecta -dot- com-----
However writing about the task does not mean writing procedures. Procedures
are just one type of information. Writing about the task is about the entire
orientation of the piece. In fact, it is when you are writing reference
material that it is most important to keep in mind that your document is
about the task and not the product. That is what makes you ask if the
reference information you are creating is relevant to the user's task and if
the organization of the information best supports the performance of the
task.
ROBOHELP X5 - ALL NEW VERSION. Now with Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!
Now is the best time to buy - special end of month promos, including:
$100 mail-in rebate; Free online orientation on content management
functionality; Huge savings on support and future product releases;
PLUS Great discounts on RoboHelp training. OFFER EXPIRES April 30th!
Call 1-800-358-9370 or visit: http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.
