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.
>One perspective that I haven't seen mentioned:
>While a software is being produced, there is limited time to explore
and
>understand how to apply the product to practical situations. There is
>usually only time to understand how the product functionally, which is
why
>so many product manuals are organized by menu items instead of by
tasks.
>After the product ships, there is time to apply the product to
real-life
>tasks and produce documentation that is more task-oriented and
detailed.
>I've purchased stacks of aftermarket books for products I use
regularly,
>such as Microsoft Excel, because eventually there is some particular
thing
>I want to do that is not addressed in the original manual as an
individual
>task, for example, how to write a VBA macro that transfers dates from
>Excel to Microsoft project.
>So, I don't view these books as primarily a way to get documentation
for
>pirated software, although I'm sure they are used for that purpose. I
also
>don't fault the writers of the original product documentation for not
being
>able to become expert in 100% of the product and document every
conceivable
>task before the ship date. This does not, of course, excuse product
>documentation that is just plain poorly done; but I've never been able
to
>learn a complex piece of software thoroughly without third-party
books.
>Glenn Crumpley
I tried to post just that thought when this thread started, but I have
had trouble getting my replies posted. I think I have the bugs out
now.
Yes, I have been in that exact position: The writer of original
manuals, pressed for time, interacting only with product developers, no
contact with users, producing documentation that is more
feature-oriented than task-oriented. Later on, other writers see the
thing in use, study how it is being used, and write books from the user
perspective.
For example, a manual for a word processor might describe how to format
a paragraph, make a hanging indent, and add a bullet, but never connect
all that under a topic of "bulleted lists." Along comes the
third-party writer who notices that people who use word processors
frequently have to piece together these bits of information so he
reorganizes the text and groups all the related information under the
recognizable task of "making bulleted lists."