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.
I divide the world into "give it to me" and "I can figure it out" people. The latter generally passed mathematics courses with relative ease. What's more, they learned how to think and reason.
John Allred
> On Sep 26, 2014, at 1:17 PM, <Brian -dot- Henderson -at- mitchell1 -dot- com> wrote:
>
> I too will admit that I'm not a manual-reader.
>
> I have been long-trained to assume that a (consumer product) manual will likely be:
> 1. Poorly written.
> 2. Frustrating.
> 3. Confusing.
> 4. Will cause my blood pressure to rise to dangerous levels.
> My general attitude is that I'll look at the instructions if I run into trouble.
>
> And, I will rarely call Product Support because I also assume a high likelihood they too will not be helpful.
> (especially if the documentation is really bad)
> So there's that bright spot for companies worried about phone support costs.
>
> I have come to the conclusion that the root of the problem is the inability of designers and writers to approach their products from an "ignorant" perspective; to be able to see things from the point-of-view of someone who has no idea how the product is assembled and/or operates. It's not that I believe the responsible parties don't try - it's that they are truly unable to "forget" what they know about the subject. So much of what seems "obvious" to producers is anything-but to most everyone else. And even though writers can be just as guilty of this, I consider them to be only point in the process where the trait has a possibility of being offset. Writers are often a member of the "great unwashed" and are seeing a product for the first time when they're asked to document it. Trying to make sense of something for themselves can be the key to creating instructions that make sense to others.
>
> I'm probably just venting here. I don't actually believe that I'm telling y'all anything you don't already know. I think that (overwhelmingly) the members of this discussion-list are not the sort of writer that has led to my low opinion of so much what passes for "instruction".
>
> And don't even get me started on products designed completely inside a computer, and sent straight to production without prototyping. Some of the worst products I've run across have clearly gone to market that way.
>
> Brian H.
>
> -----Original Message----- From: Karl Norman
>
> I've noticed that when members of this listserv start talking about
> manuals, the level of strong language rises significantly (e.g. rtFm!).
> This seems odd to me because I don't want to read a manual either. I learn
> better through human contact. I understand that it costs a lot when a user
> makes a support call. But, good grief, I bought a thing from you; the least
> you could do is help me use it. And if your response at my most vulnerable
> hour is "rtfm," or even "I'll help you for a price," then you've just lost
> my loyalty as a customer. I have no respect for a company that only gets
> out of bed for POS.
>
> My thought is, if your users don't read your manuals, then why do you keep
> writing manuals? Has anyone been with a company that stopped writing
> manuals altogether? What about using more video tutorials? Or even setting
> your users to work for you by helping each other through forums? I'd really
> like to hear from both sides: the writers who insist on manuals (why?) and
> the writers who have sought out alternatives (why?).
>
> --
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as john2 -at- allrednet -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and info.
>
> Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
