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: content vs. style From:Jim Purcell <jimpur -at- MICROSOFT -dot- COM> Date:Mon, 3 Mar 1997 11:16:14 -0800
Thom Remington observes:
>A recent post argued that technical content must take
> >style. After all, we're technical writers, not poets. Well.....
> >I agree, but I think that you have to be very careful. Any time that
> >style gets in the way, it becomes a problem. When you have to read a
> >sentence twice (or more!) to understand it, you lose focus. When the
> >style is hard to get through, the reader is likely to start to focus
> on the
> >writing, not on the content.
> <amusing rewrite of proverb deleted>
> Who could argue with this? Not I. Willfully writing opaque prose is,
> as they say, an interesting career move. In the real world, content
> and style are hardly ever in direct opposition. The question for the
> writer is not "Shall I write turgid prose today," but "How well can I
> write in the time I have available."
> Here's an extreme but realistic example. You are assigned to create a
> help file for a couple of hundred new programming interface functions
> by next Friday. (If you document GUIs, substitute an unreasonable
> number of new features here.) You've never seen these functions
> before. You are e-mailed a specification file that, while long on
> content, is short on readability. The prudent writer rejoices that at
> least there is content and goes to work formatting that content as
> pages in a help file. She will then verify the accuracy of everything
> she can check and spot ambiguities where she can. If there is any time
> left at the end (there usually isn't), she will work on improving the
> prose. More likely she will defer the prose cleanup to the next
> product release, hoping that another crisis won't erupt until this
> task is done.
> She takes this approach because she knows that when she has to do
> triage, content comes first. She doesn't like bad writing any more
> than you or I, but when forced to choose she knows what is most
> important to her readers.
> Jim Purcell
> jimpur -at- microsoft -dot- com
> My opinions, not Microsoft's