Metaphor abuse

[geoff-h -at- MTL -dot- FERIC -dot- CA]

 John Cornellier wondered whether <<metaphors flatten the
 learning curve but introduce long-term redundancy &
 inefficiency>>.

 I've indeed read that this is the case, but can't recollect
 where... it was a reputable source, probably William
 Horton? A metaphor works perfectly well as an introduction
 to a concept, and makes a complex, foreign, or intimidating
 concept easier to handle; in the long term, and sometimes
 far sooner, the metaphor breaks down because it's only
 similar to (not identical to) the reality, and users
 eventually reach a point where the metaphor no longer
 matches reality.

 The issue of efficiency isn't truly related to your
 original point, because not all metaphors are visual... so
 the Macintosh "select an object and then say what you want
 to do with it" metaphor is very different from the DOS
 "choose what you want to do, then say what you want to do
 it unto" metaphor, even if you had a visual version of DOS
 or a text-based version of the Mac. The true efficiency
 depends on the user and the task; I find keyboard commands
 far more efficient while working with text, but a mouse
 more efficient for file manipulation (with single files,
 leastways) and page layout. YMMV.

 <<Or is it a pygmies on the shoulder of giants thing: we
 can only learn relative to what we already know?>>

 It's not accurate to say that we can't learn something
 unless its in comparison to what we already know, otherwise
 babies would never learn to speak or understand English.
 It's more a case that most of us learn more effectively
 when we can fit new knowledge into a framework of existing
 knowledge. Think of science, for example. It's a very few
 geniuses who are able to contemplate something wholly new
 and relate it to what's already known.

 <<Anyone out there had any practical experience with naming
 new features, specifically with user reaction to new
 concepts vs. "piggybacking" user abilities by using
 metaphor & recycling old design?>>

 Very little direct experience, though the software I'm
 currently documenting uses an elegant flowchart metaphor
 that very nicely simulates the thought process that its
 users follow. So the metaphor is well-received by users,
 and well liked... despite numerous other metaphorical
 horrors in the interface. (Next time around, I'm hoping to
 have a say in the interface design; this time, I'm just
 doing the docs and pointing out problems.)

 The crucial thing with a metaphor is to figure out where it
 breaks down, and make sure that you stop well short of that
 point in your use of the metaphor; if users will naturally
 try to go beyond that point, you need to emphasize that
 they shouldn't do so. If the metaphor is actively
 dangerous, then you need to rethink it. (Ex.: The original
 Mac trash can icon was really a paper shredder, not a
 physical repository... files in the trash would eventually
 get overwritten when the system needed the space. When this
 caused enough problems for users, they eventually turned it
 into a separate directory that actually preserved files
 until you threw them out... a much more robust metaphor.)

 --Geoff Hart     @8^{)}     geoff-h -at- mtl -dot- feric -dot- ca
 Disclaimer: Speaking for myself, not FERIC.

 TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot-  Send commands
   to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
  Search the archives at http://www.documentation.com/  or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html