Re: Lowest Common Denominator/Reading to Learn

[Tom Herme <hermet -at- DNINEVADA -dot- COM>]

George F. Hayhoe wrote:

> 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.

If I'm understanding George as he intended, I think that an author begins by
addressing those tasks that the user needs/wants  to perform. Thus the source
of motivation for attempting to complete a task is the user him/herself. If I
promise to help the user save time or money in the very near future by a small
investment in learning right now, then I believe I have a chance with that
person.

>
>
> 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.

Right you are, George. However, what motivation does the user have for tackling
some of this software? What perception (call it "hazy notion" if you want) do
they have of how it may assist them in performing a task? Again, I believe,
knowing what those tasks are is half the battle.

>
>
> 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.

Building a database is too formidable of a task. How about if we break it down
into more discrete steps? Can we show them how to perform one step (task) at a
time? Perhaps then the final achievement won't become so daunting.

> 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.

In my current software documentation project I've developed a number of
extended examples, or tutorials. They are designed to help the user learn about
the task by walking through the example, step by step. By the end of the
tutorial, the task example has been successfully completed. I believe that
these tutorials help the user feel he/she can successfully complete a similar
task on his/her own. I'm no psychologist, but  I think many of us understand
the power of the example. If it's close enough to our own experience, then we
can identify with what the example achieves--a task well done.

>
>
> 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.

So then, is this "other work" unrelated to the purpose of the documentation? If
they have better things to do, then we've grossly underestimated our audience.
Or the audience has turned to the documentation in error. I go back to what
I've stated above:  If we're in "sync" with what the user needs/wants to do,
then we have a chance with that person.

>
>
> 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.

Please don't misunderstand me here. I don't mean to oversimply the complexity
of reaching users/readers. It's just that there must be some reason in the
first place that the person turned to my documentation. If I can ask for that
person's short attention span, then I will attempt to teach on paper (on-
line). I also take a very conversational tone with these. Hopefully the reader
will accept me as a peer--and not an expert.

By the way, George, good meat for usability, huh? I'd sure like to have the
chance!

Tom

>
>
> Any ideas?
>
>
>

_________________________________
Tom Herme
Senior Technical Writer
DNI Nevada, Inc.
mailto://hermet -at- dninevada -dot- com

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