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.
Scott Gray wrote:
>
> I intent for being on this group and several others like it, is that I
> would like to influence you in some small way to open your minds to a new
> way of teaching and learning. With our computers we are no longer
> restricted to just TELLING our users how to do this or that, but we can
> help them to discover for themselves.
...
> If you are thinking of writing INTERACTIVE documentation, make it
> USERactive. Give them an environment to experiment in, to take chances
> in, and most of all to create in.
Scott has been a bit irritating in his methods, but he *does* have a point
-- even if there are faults to find in his implementation. Perhaps if we
discuss the issues separately from discussing Scott...
I created a tutorial for a freeware web authoring tool that encouraged
people to experiment within the authoring environment. I couldn't provide
interactive feedback since the tool didn't support JavaScript or anything
similar. But, the testimonials we got back from users were similar to
Scott's raves. (I won't quote them here. Some are on my web site.)
I think the thing they liked was to be able to *do* rather than *read*, and
that they could *do* in the same environment they would be using and without
switching to a separate help window. They also liked the ability to explore
off the path the tutorial suggested. Some CBT has irritated me by preventing
exploration. Also, it's often the *separate window* (or separate paper book)
that most disrupts the flow of learning.
This brings us to the whole area of embedded help (embedded in the product,
not just the help window). Quicken and TurboTax are often-cited examples.
I've been encouraging those clients who are in the design-phase of their
software to look at doing more of this. Web-based applications are
well-suited to this because some of the necessary "functionality" (tracking
user actions and being able to respond) is already built in.
Yvonne DeGraw, Technical Services o Technical Writing
yvonne -at- silcom -dot- com o Online Help http://www.silcom.com/~yvonne o Web Documentation
Tel: 805/683-5784 o Database Publishing
Santa Barbara STC: http://stc.org/region8/snb
