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:Re: Visual metaphors (#479678) From:wburns -at- MICRON -dot- COM Date:Thu, 7 Mar 1996 15:24:45 -0700
7-MAR-1996 14:26:12.06
>On Thu, 7 Mar 1996, Richard Mateosian wrote:
>> >I'm arguing against *global* metaphors. No software 'desktop' that I've
>> >seen looks anything like the top of my desk. Computer calendars, clocks
>> >and files would be much better at their jobs if they weren't pretending
>> >to be the real thing.
>>
>> The issue isn't whether the software desktop looks or acts like a desktop.
>> The issue is consistency and predictability. Once users grasp the "physics"
>> of your user interface, they can figure out a lot for themselves.
Stuart Selber adds to the discussion:
>It's also more than that.
<snip>
>But the
>metaphor works because it relies on cultural narratives, the stories we
>tell ourselves about the way things are, and not because the comparison
>between the two domains holds up in any substantial way.
<snip>
And I pitch my $0.02 into the kitty and add:
Perhaps introducing the term "global" is causing the confusion here. Is this
issue really more about simple metaphors compared to extended metaphors or about
the level or abstraction in a visual metaphor? When we talk about a computer
desktop, we're building a system of associations. (A desk often has a clock on
it, a place to store files, assorted utilities stashed here and there.) To
expect the metaphor to go deeper than that is really to expect a parallel
correspondence between the metaphor and that which is represented, at which
point many metaphors have to get very subtle.
This discussion reminds me of the painting (Dali, I think) of a pipe with the
caption "Ceci n'est pas une pipe." (Correct me if the I've got the caption
wrong, s'il vous plait.) A metaphor is not what it represents, any more than
words are not what they represent. We can avoid using any metaphors for fear
that we will exclude some members of the audience. We can also dive headlong
into the sea of extended metaphorical associations and drown in the interplay of
signifieds and signifiers (as if we weren't already swimming in them). Instead
of holding to one extreme or the other, we could, as Stuart mentioned, put some
effort into usability testing and determine the thresholds for metaphoricity in
technical documentation and GUI design. I think the latter is our
responsibility.
Anyone raise?
Bill Burns
Assembly Training and Documentation Supervisor
wburns -at- micron -dot- com
