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.
> >
> >Of course, that's the point. EVERY job where the person writes
> >something benefits from clear writing...can you think of any job that
> >benefits from muddy writing (OK, government and legal are excused
> >:-)) we don't have a lock on that skill. I'm trying to figure out
> >what is at OUR core...that points to us.
>
> A quick note, here -- concise and clear are culturally-bound. Not all
> cultures value concise documentation, and concise is not always the
best
> tool in your toolbox. I say this because "technical writing" often
> includes writing non-technical documentation, as well; and actually, I
can
> see user guides benefitting from many examples that an otherwise
concise
> and austere style would leave out.
>
> ~Mike
Just a quibble, and a minor one, but a quibble nonetheless. I would
argue that _User Guides_ (packaged with and accompanying the
product/software/system etc.) are best when concise, clear, and devoid
of excessive examples. When I open a piece of hardware or software I go
straight for the "Quick Install/Setup" guide and dive in head first.
The only time I go to the complete User Manual is when I need to
troubleshoot something, and that's mainly what I want it to tell me.
The type of documentation Mike describes is, IMO, better suited to
after-market supplemental documentation. I'm thinking of titles like
"Adobe <Product Name Here> Classroom in a Book" and the various QUE,
SYBEX, and other titles that are published for users that want to know
how to make a certain piece of hardware or software tap dance and
whistle Dixie backwards while simultaneously working out the orbit of
Neptune to the accuracy of a thousand decimal places.
I agree with Mike that TWs should be the ones to write these exhaustive
documents because many times they are the only ones who will have talked
to enough of the developers working on a project to get an idea of how
many different ways an end user is imagined to poke, prod, test, tweak,
fiddle, hunt, pry, search, use, abuse, misuse, and creatively wrangle
the final product. Even then, I'm sure some end user will bamboozle
everyone by doing something like use MS Project keep a grocery list, for
example.
CONFIDENTIALITY NOTICE: This e-mail may contain information that is privileged, confidential or otherwise protected from disclosure. If you are not the intended recipient of this e-mail, please notify the sender immediately by return e-mail, purge it and do not disseminate or copy it.
Now Shipping -- WebWorks ePublisher Pro for Word! Easily create online
Help. And online anything else. Redesigned interface with a new
project-based workflow. Try it today! http://www.webworks.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit http://www.techwr-l.com/techwhirl/ for more resources and info.
