Hiding what the software does and how?

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.


--Geoff Hart @8^{)} Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Patience comes to those who wait."--Anon.


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



Previous by Author: Multitasking or specialisation? Let's do both!
Next by Author: Reorganizing a disordered product?
Previous by Thread: Software : What is it doing and How is it doing it (was RE: The Worst Thing About Contracting)
Next by Thread: FW: Hiding what the software does and how?


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


Sponsored Ads