Visual metaphors

[Stuart Burnfield <slb -at- FS -dot- COM -dot- AU>]

In "Re: Trends for Technical Communicators?", Sue Gallagher said:

> ...Coupled with this is an increase in the importance of visual
> literacy. A technical writer must be able to contribute to/
> enhance the visual metaphore of the product...

Hasn't this business of user interface metaphors been overworked?
Metaphors may help beginners, but software users are only beginners
briefly. If they don't give up quickly, they go on to become what Alan
Cooper (About Face) calls 'perpetual intermediates'. PIs get good at
remembering the features they use often, and good at tracking down the
ones they only use occasionally. They would rather learn the software
than the metaphor.

If you 'bend the interface to fit the metaphor' (Cooper again) it's a
less effective interface than if you had designed it properly from the
start. The parts that neatly fit the metaphor probably would have been
the easiest to use anyway. The parts that would have been hard to use
anyway are now excruciating, because they've had to be warped further
to fit an inappropriate metaphor. And our job as documentor is harder,
because we have to explain things in a way that makes sense in terms
of both the task AND the dud metaphor.

Some specialised metaphors are great. In Word's Page Layout view, your
document is laid out on a metaphorical sheet of paper, In Normal view,
which is used for the bulk text entry work, there is no sheet of paper,
just a blank white background. This works very well. When you're
entering and formatting text, you don't care about paper. When you're
laying out the document, Page Layout view gives you a simple, subtle
and very effective cue that your document is nearly ready to print.

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.

I think tech writers should be contributing to designing a good
interface. If instead we spend our time helping the developers make a
sow's ear into a silk purse, we end up with something that is neither
a good ear nor a good purse.

> the code developer is now more likely concerned with the back-end --
> making the product function -- and the information developer is
> concerned with the front-end -- the user interface -- making the
> product communicate with the user.

I agree with this completely.

Rant, rave, dribble.
---
Stuart Burnfield (slb -at- fs -dot- com -dot- au)        Voice: +61 9 328 8288
Functional Software                     Fax:   +61 9 328 8616
PO Box 192
Leederville, Western Australia, 6903