[clug] Writing Training Materials

Paul Wayper paulway at mabula.net
Fri Mar 24 20:39:52 UTC 2017


On 23/03/17 22:25, Bryan Kilgallin via linux wrote:
> Jeff:
> 
>> Anyone know of any good references on writing training materials?
> 
> I did a graduate diploma in Tertiary Education. That was at Darling Downs
> Institute. Which became the University of Southern Queensland.
> 
>> I (or
>> someone else) might be need to write some in the near future for work
>> and I'm looking for something to give me a way to approach it.
> 
> Take a course such as the above. This isn't trivial!
> 
> Supposed training presentations are often bad, in various ways.
> I've seen:
>     * overcrowded, too-small text that was illegible;
>     * books written in a language other than the reader's;
>     * a topic irrelevant to the audience....   

Bryan, if your only contribution to this conversation is to tell people that
they're doing it wrong, then please don't reply.  It contributes nothing to
the discussion.

We should all aim to give constructive information answering the question.

Re Jeff's original question:

I don't have any good references, sorry :-)  But I do think there are a number
of basic things involved in training people well:

* Outline what you're teaching at the start of each section, and conclude with
a summary of what they've learned.  It's hackneyed but it works.

* Involve people often.  Simple questions like "has anyone here used git?" or
"can someone tell me the differences between TCP and UDP?" are common fare,
but they still work.  One trick I learned last year is that if someone asks a
question, see if anyone else in the class can answer them.

* Aim for blocks of no more than an hour, which is people's usual
concentration span.

* Look for a natural progression or story in what you're teaching.  This often
takes the form of what people want to achieve, and then how this new thing
you're teaching them helps with that.

* Avoid correcting people individually if possible.  Instead, try to
generalise that out - e.g. "OK, I can see a few people are still having
problem creating a merge request, so let's go over those steps again."

* Your only form of humour is lightly self-deprecating.  Never make a joke at
anyone else's expense.

* Use different media.  There are three basic forms of learning - textual
(i.e. reading text), visual (drawing diagrams) and auditory (listening to you
speak).  Most people find one of these three to be easier.  So mix them up to
give everyone the best chance of learning.

* Everyone learns better by doing than by watching or listening.  So aim to
include practice sessions.

* For practice, make sure you have printed material for each person that gives
them the commands or the steps of what they're doing.

* There'll always be people that learn faster than others.  Think of ways you
can engage those people - either get them to help someone else, or get them to
try something more advanced, or have them find something out - or just ask
them to wait quietly.  Try to avoid having them go ahead.  It's not a game to
see who can get to the end of the training material quickly.

* Always practice your material.  Allow at least two run-through sessions
where you talk through the class material and then sit down and do your
practice work.

* In your practice, look for friction points - places where everyone's waiting
for something.  For example, it takes time to hand out sheets of instructions,
so consider how often you have to do that and try to minimise the amount of time.

* Ask for questions regularly, especially before you've given the summary.

That's all I can think of right now :-)

Hope this helps,

Paul



More information about the linux mailing list