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:Hiding what the software does and how? From:Geoff Hart <Geoff-h -at- MTL -dot- FERIC -dot- CA> Date:Mon, 19 Apr 1999 10:32:10 -0400
There's a tricky, fairly subtle aspect to defining what the
software does and how. While it's generally inappropriate to
explain the underlying algorithms and linkages between
modules ("how the software does what it does"), and
generally appropriate to define what the software does, there
are interesting exceptions.
Audience, as always, is crucial. Sometimes users really do
need to understand the algorithm so they can make informed
choices about how to use it, or even whether they should use
it at all. Statistical analysis software is an excellent example,
since it can be crucial to understand whether (say) a test
examines your data for normality (if that's a condition of the
test) before blindly doing the math. If it doesn't, you have to
explain this so statisticians will know to test for normality
themselves; if they don't, the results of the test can be
meaningless or even outright wrong. (As a side note, I've
worked with enough grad students and scientist to have
developed the belief that it's irresponsible to create software
that lets users ignore such safeguards. IMNSHO.)
Explaining things such as linkages can also be vital because it
ties into the "metaphor" for how users interact with the
software and provides a high-level overview for those users.
Without that context, even moderately complex software can
appear overwhelming; with that context, users can more
easily learn how to use the software effectively. For example,
if you're using frame-based page-layout software, it's
important to know that you can't start laying out pages until
you've created effective frames. You could certainly build the
paragraph styles before ever facing the issue of frames, but
you need to know how the two interact so you can make your
own decision which aspect of the design to begin with.
The issue of "what does it do for me?" is certainly important,
but it's only one side of the usability coin: the other, arguably
more important side, is "what _I_ do with it?" These are
respectively reference- and task-based information, and both
are important to different degrees for different types of
audience.