Figurative language

Subject: Figurative language
From: Ben Kovitz <apteryx -at- CHISP -dot- NET>
Date: Wed, 24 Mar 1999 14:21:47 -0700

Robert Maxey wrote:

>>>>I've searched the archives, but found little on personification.
>Go here:
>The site will explain personification and other figurative language

Er, I just read this page, and it's *awful*. The author just doesn't get
the difference between literal and figurative language. Pointless and
confusing, and not recommended for people who don't already understand the
topic that this page is trying to teach.

While the relevance of this to technical writing is borderline at best, let
me recommend a wonderful book for those who are interested:

Figures of Speech: Sixty Ways to Turn a Phrase
by Arthur Quinn

I do not believe that figurative language has a large role to play in most
technical communication. It's appropriate for inventing new terminology,
sometimes for tutorials, and not much else. Well, it does have a large
role to play in marketing copy, even for technical products. Some of us
occasionally get asked to do that kind of writing, since sometimes we are
the only people in the company who simultaneously understand the product,
the users, and how to put things into words.

However, I believe that getting some experience with figurative writing can
still be useful even for someone doing straight tech writing. The reason
is that it loosens you up. The Quinn book is ostensibly about how to
categorize the various figurative devices. But you don't have to go far
into it to see that he really doesn't care what you call them or even if
you call them anything. What the book really does is open your eyes to the
power and flexibility of language.

It's easy, especially when writing very similar technical documents over a
long time, to fall into a rut. While I strongly oppose creativity in
technical writing for the sake of "being creative" or "expressing your
individuality", it's easy to overlook other forms of expression that would
be much better suited to the audience and the material. Exploration of the
furthest outskirts of language (notice the metaphor?) shows you how much
you can do without losing comprehensibility, and that the duckspeak style
of many technical documents does not aid clarity, but harms it.

Ben Kovitz <apteryx -at- chisp -dot- net>
Author, _Practical Software Requirements: A Manual of Content & Style_

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

Previous by Author: Re: Developer Documentation
Next by Author: Re: Personification of gadgets and thingamabobs
Previous by Thread: gid, fts, ftg, ann, bmk files for windows 95 help
Next by Thread: Re: Figurative language

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

Sponsored Ads