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.
Re: Teaching a practical business writing class and looking for professional rubrics
Subject:Re: Teaching a practical business writing class and looking for professional rubrics From:Keith Hood <klhra -at- yahoo -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com, Nancy Allison <maker -at- verizon -dot- net> Date:Tue, 18 Aug 2009 07:32:51 -0700 (PDT)
Yes, obviously our output has to please the boss and do what he wants it to do. But on the other hand...
I can't speak for anyone else on the board, but I contend that "creativity" is not a bad thing; at least, not when done right. When I have used that word in previous arguments this board has seen on this point, I meant finding ways to write things, to lay out pages, so that the end result was not full of tedious repetition that annoyed the reader.
One of the most commonly heard complaints about tech docs is, they are hard to read because they are so boring. Many have content that is so repetitive it is mind-numbing. Too many are full of pages that look exactly the same except for the difference of a few words. They keep using the *exact* same phrases over and over until the reader is sick of seeing them. You can actually make documents painful to read with excessive consistency.
It is possible to impart information without having documentation that looks like it was written by a mindless robot. Something which helps break the monotony makes the documents easier on the reader's eyes and patience, and therefore makes them more readable.
And this is NOT personal whim. This is a matter of recognizing a common problem and trying to rework the products so they are still informative but are also less boring. That's not a whim - it's a way of dealing with a well-known usability issue.
Yes, it is possible to overdo efforts to break the reading monotony. It's possible to overdo anything, including adherence to style. Knowing how far to go in either direction is one of the differences between a writer and a good writer. But there is nothing inherently wrong in the idea of trying to make documents less painful to read. It's a relative evil, not an absolute evil.
> From: Nancy Allison <maker -at- verizon -dot- net>
> Subject: Re: Teaching a practical business writing class and looking for professional rubrics
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Date: Tuesday, August 18, 2009, 9:44 AM
> John Rosberg made some good points
> about the fact that a major aspect of our job is to support
> the business goals of the organization that is paying us.
>
> I add that this is why business writing, including
> technical writing, is not an opportunity for the indulgence
> of personal whims, justified as "creativity." The need to
> create usable, professionally accepted documents is the
> reason we consult style guides and standards, and pay
> attention to whatever usability resources we have.
>
> The problem-solving aspects of our work draw on all the
> creativity we possess; there is no need to scatter strange
> fonts and weird indentations all over a page, or put the
> front matter at the back of a book, or do other "innovative"
> things in order to satisfy our personal creative urges.
>
> Yes, I have had this, ahem, discussion (NOT argument! no,
> no!) with several tech writers over the years . . .
>
> --Nancy
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Free Software Documentation Project Web Cast: Covers
> developing Table of
> Contents, Context IDs, and Index, as well as
> Doc-To-Help
> 2009 tips, tricks, and best practices.
>http://www.doctohelp.com/SuperPages/Webcasts/
>
> Help & Manual 5: The complete help authoring tool for
> individual
> authors and teams. Professional power, intuitive interface.
> Write
> once, publish to 8 formats. Multi-user authoring and
> version control! http://www.helpandmanual.com/
>
> ---
> You are currently subscribed to TECHWR-L as klhra -at- yahoo -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit http://lists.techwr-l.com/mailman/options/techwr-l/klhra%40yahoo.com
>
>
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot-
> Visit
>http://www.techwr-l.com/ for more resources and info.
>
> Please move off-topic discussions to the Chat list, at:
>http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat
>
>
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
