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: Readability...some more observations From:Michael Lewis <lewism -at- BRANDLE -dot- COM -dot- AU> Date:Sun, 5 Apr 1998 20:11:30 +1000
The problem Mary reports here is widespread. Mary attributes it to "not
being an editor"; I usually attribute it to "not being a linguist". In
fact, it's just a matter of people knowing that something's wrong but
not having the analytical tools to understand what the problem is, and
not having the concepts or vocabulary to clearly express their view.
Exactly the same thing happens when academics mark term papers etc:
unless they are working in a language- or communication-related field,
they give feedback that rarely helps the student understand exactly what
they are doing wrong or how to get it right in future.
So, yes: we do have to look behind the description of the problem, and
ask what the real problem is.
> Here are some of the other criteria I consider:
> (1) Need to know.
> If people really need to know certain information, you can
> do (or not do) things. I'm not advocating poor
> writing; but in a world where "good enough" is sometimes the best you can
> do, this is one criteria to consider. OTOH, if I want my reader to use
> a document to get info that s/he may not consider valuable, the metaphor I
> think of is seduction...using every trick I can think of to get the reader
> to decide to read the info!
> (2) Translate readers' comments. I listen for phrases like "too
> long," "too wordy," "too boring." IME, people use these phrases because
> they aren't editors and they don't have a way to say "you're using passive
> voice too much here." But almost anytime I hear these comments, I find
> no-no's in
> the text: sentences are too long; text could be bullets; list structure
> isn't parallel; information is hard to find (lack of visual cues, lack of
> index or TOC, lack of page numbers,lack of heading levels); task and
> knowledge info is
> mixed together like meat and potatoes in a stew.
> I think it's important to figure out what these comments really
> mean. I'm currently working on a project where the client says they want
> "no more
> than 10 or 12 pages." I suspect what they really want is a way to find the
> *single* page that has the info they need at a given time. However,
> they're responding to an existing manual some 200 pages in length that is
> not organized (no page numbers!!)...hence the request for brevity.
> My mission (having chosen to accept it!), is to figure out what
> they really want from what they're asking for.
> Mary Durlak Erie Documentation Inc.
> East Aurora, New York (near Buffalo)
> durl -at- buffnet -dot- net
Brandle Pty Limited, Sydney, Australia
PO Box 1249, Strawberry Hills, NSW 2012
Suite 8, The Watertower, 1 Marian St, Redfern 2016 http://www.brandle.com.au/~lewism
Tel +61-2-9310-2224 ... Fax +61-2-9310-5056