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.
[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
support.]
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
better.
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. ;-)
-Tony
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Read about how Georgia System Operation Corporation improved teamwork, communication, and efficiency using Doc-To-Help | http://bit.ly/1lRPd2l
