Lowest Common Denominator/Reading to Learn

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.

Any ideas?

--George Hayhoe (george -at- ghayhoe -dot- com)

George Hayhoe Associates
Voice: +1 (803) 642-2156
Fax: +1 (803) 642-9325
http://www.ghayhoe.com

Winner
APEX '98 Award for Publication Excellence

Best of Show Winner
Carolina Foothills/South Carolina STC Chapters
1997-98 Technical Publications Competition

From ??? -at- ??? Sun Jan 00 00:00:00 0000=




Previous by Author: Best Examples
Next by Author: Re: Teaching without seeming to teach!
Previous by Thread: Re: Documentation White Papers
Next by Thread: Re: Lowest Common Denominator/Reading to Learn


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


Sponsored Ads