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.
In the course of his post on "Tired of Giving Free Advice", which I found
quite agreeable, Ed Manley wrote:
<<
"I absolutely have to multitask, have to make the most of every opportunity
to learn something new. I must be able to get to the heart of the issue
rapidly, and reading books is rarely the way to learn quickly. Asking
questions is. Consequently, I am not one bit hesitant to ask the author of
an article for information.
>>
All us writers would do well to remember that "reading books is rarely the
way to learn quickly. Asking questions is ". As I recall, there was research
done to support this contention--interviewing people about their sources of
information--I wish I could remember or reference this research.
Of course, our organizations can't actually talk with everyone who may have
questions, so we still need books. It seems to me, however, that we should
systematically look for ways to make our writing *resemble* or *support* a
question-and-answer approach.
A rigorous task orientation helps, since it allows the reader to search for
the desired information (a form of asking questions) within a set of tasks.
Making writing procedural, as far as possible, helps for the same reason.
Good navigation (headings, running headers and footers) helps to support
readers searches.
A thorough, task-oriented, fully inverted, index is critical; this allows
readers to locate information using keywords of their own choice--another
form of answering a question.
I do not agree with using actual questions (i.e. the FAQ approach) as THE
structure for information (too amorphous and sprawling), but adding a FAQ
section to an already well-structured document can be helpful.
Including any questions that are actually asked of customer-support
personnel is a no-brainer, but I also like to see if such questions indicate
that the document needs to be improved. If a customer question indicates we
have failed to get a high-level concept across, I'll add a conceptual
overview. Often, customer questions indicate difficulty *finding* the
information, in which case I look for gaps and re-examine the document
organization.
Anyone have other thoughts on this?
Chris
_____________________________________
Christopher Knight, Technical Communication Architect http://members.attcanada.ca/~cknight/
E-mail: cknight -at- attcanada -dot- ca
Phone: 604 877 0074
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Now's a great time to buy RoboHelp! You'll get SnagIt screen capture
software and a $200 onsite training voucher FREE when you buy RoboHelp
Office or RoboHelp Enterprise. Hurry, this offer expires February 28, 2002. www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
