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.
Robin,
In an ideal world, I'd agree with you. However, based on my own experiences
teaching and learning software, I'd say this often just doesn't work. For
example, I worked at a national software training company for some time.
Their training manuals used the kind of real-world, task-oriented approach
you mention. The problem was that the writers had no way of knowing just how
someone was going to use the software. The examples always seemed to apply
to one or two people in the class and no one else. It's a tough, tough thing
to imagine what extreme uses someone might have for a product like MS Word.
On the other hand, I try to use a version of that approach where I currently
work. I document an accounting package specialized for the construction
industry, and use section headings like "Adjusting an Invoice," "Calculating
Deductions," etc. I also have a "task list" just after the TOC that walks
users through a typical job. It has topics like "When you get the bid...",
"When you perform work on the job...", etc.
Dannette Thompson
Technical Writer
Foundation Software, Inc.
The #1 Accounting Software for Labor-Intensive Contractors
The opinions expressed in this message do not necessarily reflect the
opinions or policies of my employer or coworkers.
-----Original Message-----
From: R. Johnson [mailto:rjayz -at- yahoo -dot- com]
Sent: Tuesday, July 17, 2001 4:00 PM
To: TECHWR-L
Subject: Documents I'd like to see...
I'd like to see more documentation that illustrates
potential real-world solutions based on the functionality
of particular software applications. For example, I'd be
interested in seeing how others have used mail merge in
ways other than creating form letters; or how to create a
knowledge base that enables you to maintain, update or
generate an entire policy and procedures manual at the
click of a button; or how (and why) to create an animated
movie using layers in PhotoShop; or creating CBTs in Power
Point.
Why is there such a dearth of "solution" based
documentation? Everything seems to be "process-oriented"
rather than "results-oriented." Reference manuals and user
guides are fine, but sometimes I'd like to see an example
of the functionality in actual use, rather than
"Select-File-Click-OK." Am I alone in this or do others
feel this way too?
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
TECH*COMM 2001 Conference, July 15-18 in Washington, DC
The Help Technology Conference, August 21-24 in Boston, MA
Details and online registration at http://www.SolutionsEvents.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.
