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.
RE: Using learning theory to build learning documents
Subject:RE: Using learning theory to build learning documents From:stevefjong -at- comcast -dot- net To:<techwr-l -at- lists -dot- techwr-l -dot- com> Date:Wed, 22 Nov 2006 17:47:01 +0000
Rowena, those are very interesting ideas!
Practitioners of Information Mapping or Structured Documentation will recognize the metatags "concept," procedure," "reference," "troubleshooting," and so forth. In theory, you could repackage tagged information into overviews, troubleshooting documents, user's guides, and such.
I agree that information consumers tend to be visually oriented, which is a concept that we writers have trouble grasping. Sometimes even a blindingly simplistic and obvious illustration can be useful to our end users, and we therefore shouldn't hesitate to include them. By combining text and graphics, we support multiple learning styles.
Also, I have seen studies (which I passed along in teaching) that there's a difference between "reading to learn" and "reading to do." The former is typical of students; it is characterized by careful, sequential reading and study to get the information into long-term memory. The latter is typical of adults trying to accomplish a task; it is characterized by quick, focused attention on short and nonsequential passages, trying to complete a procedure, with no attempt to retain anything more than the location of the information.
I think this has implications for our approach to documentation. We have to be mindul that readers won't read from cover to cover or from front to back, and won't take what we write to heart. For the most part, they don't have the time or the inclination. I've advised people against writing headings such as "Learning About The Gimcrack" because readers don't *want* to learn about gimcracks. They just want to use them to finish a task. (How do you use a gimcrack again? I've forgotten...)
A teacher can prepare a lesson plan and decide what to reveal and, more importantly, in what order; students have to go along for the ride. A technical writer can use progressive disclosure in some documents, but for the most part the reader will jump to a spot at random, either in a printed book or, especially, in a help file. (As has been discussed with glossaries, help files arguably don't *have* a beginning.)
-- Steve
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Easily create HTML or Microsoft Word content and convert to any popular Help file format or printed documentation. Learn more at http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
