Writing tutorials

["Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA>]

Misti Tucker asked for advice on writing tutorials. I can't speak as
a trained instructional designer, but I can provide some feedback
based on nearly 20 years of tutoring. Here's my experience:

First and foremost, start with a list of objectives that students
must be able to accomplish, not a list of topics. In short, don't
design each module based on something like "an overview of printing";
instead, start from the premise that users must learn how to (i)
print the entire document, (ii) print only a single page of the
document, and (iii) print on different printers on the network. Then
structure the flow of the support material for these objectives
logically. In my example, the tutorial might run from how to select a
printer or ensure that the correct printer is already selected, to
conjuring up the print dialog box, to toggling between printing
everything and printing a page range. If possible, provide some means
of testing whether the student actually learned what was taught. A
quiz is simplest, but a "watch, then do, then get feedback on what
you did" type of wizard or macro is probably most effective.

Second, provide a quick entry into the material for those who already
have some expertise, but options for more detailed instruction for
those who are rank beginners. There's nothing as annoying as trying
to learn something and either being deluged with material you
already know, or being unable to find information you don't know.
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca

Hart's corollary to Murphy's law: "Occasionally, things really do work right."