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.
Subject:Lowest Common Denominator/Reading to Learn From:"George F. Hayhoe" <george -at- GHAYHOE -dot- COM> Date:Thu, 17 Sep 1998 09:49:11 -0400
I was really interested in Eric and Deb's story about their
"Dummies" book on database software. I've been thinking for
several years about the problems inherent in documenting
products for which there are no obvious manual equivalents.
Because virtually all users have processed documents,
spreadsheets, and checkbook registers manually, it's
comparatively easy to document a product like WordPerfect,
Excel, or Quicken. At least as far as the basics go,
virtually everyone in the audience is familiar with both the
underlying concepts and the kinds of tasks involved in the
manual processes. They need to know how to perform the
processes electronically with the product you're
documenting.
But when you consider more specialized processes that have
been made available to the mass market through software that
is available in most companies, the difficulty of
documenting becomes significant.
For example, suppose someone has told me I should build a
database to track information for a project, but I have no
idea how to go about the task. I look at the software
installed on my computer or on the company's server, and the
only database application I can find is Access, a very
powerful, very sophisticated product that is also
extraordinarily user-surly.
Or I need to monitor resource allocation on a project, and
the only project management application I can find is
Primavera--again, a very sophisticated product that is
difficult to use (or was, the only time I tried to use it a
number of years ago).
Before 99% of the potential user base can "read to do" in a
user's guide or online help about using either of these
types of products, they need to "read to learn." In other
words, they need conceptual information before they can deal
with the procedural information.
As Deb and Eric say, the problem is that novice users don't
want to be bothered with the underlying concepts--they've
got other work to do. But without those concepts, the
cookbook instructions in software documentation make--at
best--only limited sense.
The big problem, then, is how do we communicate concepts to
people who don't want to be bothered with them so that they
have the knowledge they need to be reasonably competent in
an unfamiliar domain? The big trick is that the
communication has to be painless, quick, and transparent;
otherwise the audience will run.
