Re: RTFM? Really?

Subject: Re: RTFM? Really?
From: Tony Chung <tonyc -at- tonychung -dot- ca>
To: TECHWR-L <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Fri, 26 Sep 2014 10:03:10 -0700

[Kyle Simmons wrote comments about:
1) Implied lack of respect for our users by the acronym "RTFM"
2) Why write manuals at all?
3) Why not alternate formats like video?]

[Peter HIrons responded:
What is wrong with being advised to Read The Fine Manual ?]

[Gene Kim-Eng wrote a non-writer's big-picture perspective of the
real-world problem that businesses need to produce products at a
competitive cost, but can't always provide the same level of technical

I've always thought that RTFM meant "Read the Forgotten Manual" (grin) but
Kyle does make a point that developers and writers who chastise their users
for NOT doing something is an attitude in need of adjustment. If users
complain about support but don't read how the products are supposed to be
used, then there are problems with the documentation or even the product.
In the Apple age, more complexity is masked behind relative ease, which
influences the design of future products.

Customers want out of the box functionality, with some power-user
customization. You can no longer send a help file and tell users to "build
as instructed". Case in point: The success of WordPress over Drupal. Sure,
Drupal is a scalable framework that allows you to build high-performance
applications. But WordPress' one-click install ends with "Were you
expecting this to be more difficult?"

The WOTD is turnkey. Smart companies are providing standalone solutions
that demonstrate their product's features immediately. And the
documentation enhances what the user can already figure out for themselves.

About video: I prefer not to watch a video presentation without a
transcript. I like the systems like TED that provide real-time transcripts.
Scrub to a video event, the transcript highlights. Click a highlight, the
video scrubs. Pure genius.

Sadly, I have subscribed to a number of online video courses that are rich
in content but difficult to follow, for that very reason. I expect our
users probably feel the same way.

About "why write manuals"? Often marketing or product development dictates:
"Once this product gets released, the following documentation suite always
follows." I'm a firm believer in just in time/point of need
documentationâgive the user what they need in the moment. Either
context-sensitive help, built-in IDE instructions, single page job aids,
whatever the user needs to get working with the product more quickly, the

Users don't have a lot of time. When I have a need I could explore several
comparative systems in a single week. If I can't figure something out
quickly, I won't explore much further than the initial startup guides
before turfing that product and moving on to the next one.

Well, back to my lurking place. ;-)


Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -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 for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @

RTFM? Really?: From: Karl Norman
Re: RTFM? Really?: From: Peter Hirons

Previous by Author: Re: P&P suggestions
Next by Author: RE: Questions about the work day for the Whirlers
Previous by Thread: Re: RTFM? Really?
Next by Thread: Re: RTFM? Really?

What this post helpful? Share it with friends and colleagues:

Sponsored Ads