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.
Subject:Re: advice on writing tutorials From:"Yancey, Lonnye M" <lmyancey -at- INGR -dot- COM> Date:Thu, 5 Aug 1999 12:55:59 -0500
Hi, Jessica.
In the tutorials I've written, I've generally tried to teach users to
perform certain tasks, and then build on that knowledge when the same
procedure comes up again. This really helps to keep procedures fairly
short, especially if the same group of steps is required several times in a
lesson or group of lessons.
For example, if step 2 (or steps 2 - 4 or whatever) already describes
grouping objects and grouping objects is required again in step 10, for step
10, I would say, "Group the objects. For more information on grouping
objects, see step 2 (or steps 2 - 4) of this lesson." In the first sentence
of step 10, I'd be specific about exactly which objects the user should be
grouping.
I think (or at least I hope) this provides enough information for the user
to understand the step while avoiding a lot of redundancy.
Hope this helps,
Lonnye : )
> -----Original Message-----
> From: Jessica N. Lange [SMTP:jlange -at- OEE -dot- COM]
> Sent: Thursday, August 05, 1999 12:06 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: advice on writing tutorials
>
> Current project: Reference manual.
> The product has several modules, some fairly complex
> for the user's ability. While they'll get human-being training
> onsite (& phone support), not every task will be covered
> in depth during training.
>
> So, I'm going to include tutorials on a few of the more
> obscure modules (ones I expect the trainer will gloss over
> as something the user will never do. Never say never!)
>
> Since I've never before written a tutorial, I'm
> asking for any advice or tips anyone who has written
> tutorials might care to share.
>
> BTW---Output: _Paper_ only
>
> An example of what I'm puzzling over is how much detail
> I need to repeat. If in step 4, I detail all sub-steps, then if
> step 5 starts out in a similar manner as step 4, can I
> "short-cut" what I say? To explain further, in step 5 could
> I say "Group the objects" if in step 4 explains how to do
> that? To me it seems logical to do this, but it sure isn't
> consistent!
>
> If it helps, the tutorial is similar to showing how to create,
> in MS Access, a form or report. Lots of steps, each one pretty
> easy.
>
> As always, thanks for any advice, tips, or comments!
> Jessica
>
> ---------------------------------------------------
> Jessica N. Lange mailto:jlange -at- oee -dot- com
> Technical Communicator, Ohio Electronic Engravers, Inc.
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000=
> =
>
>