[clug] Writing Training Materials

Bryan Kilgallin bryan at netspeed.com.au
Sat Mar 25 05:34:44 UTC 2017


Thanks, Paul:

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

I understand that for teaching in a primary school in the ACT, a 
four-year Education degree is required.

> It contributes nothing to the discussion.

I recommend that a person embarking on a training assignment, should 
endeavour to learn something on how to do such a task right!

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

Requirements are important before a computing project. Similarly context 
needs be considered before an adult learning endeavour.

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

Let's start with evaluation. How is the learning experience to be 
evaluated, as to whether it was a flop or a success?

> * Outline what you're teaching at the start of each section, and conclude with
> a summary of what they've learned.

How is learning to be assessed, and when? Reportedly 80% of content is 
forgotten a month after the exam!

> * Involve people often.

How is response to be received? Is there to be a 
computer-aided-instruction form?

> 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.

Where and when is the learner? Is this a stand-alone self-paced learning 
module, such as the user being overseas, in a different time zone from 
the instructor?

> One trick I learned last year is that if someone asks a
> question, see if anyone else in the class can answer them.

No mention had been made as to whether learning would be individual or 
group!

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

Then a sample of learners need to be timed, as to how long they actually 
take to complete the module.

> This often
> takes the form of what people want to achieve, and then how this new thing
> you're teaching them helps with that.

I had been ridiculed for asking what the learners had previously wanted!

> * Avoid correcting people individually if possible.

It seems that self-paced learning has not been considered. Rather is the 
module to be available on the Web?

> 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."

I have taught via computer aided instruction. Wherein the learner 
necessarily received feedback individually!

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

Indeed, how is emotion to be conveyed or invoked? I saw little 
opportunity for that in suggested textual technical literature!

> * 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.

I agree. Since only text seems to have been previously mentioned, then 
how will the other media be done? Nobody else seems to have mentioned 
say a video clip!

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

In computer aided instruction (CAI), that is the only method!

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

This is important in correspondence-teaching. Thus the college at which 
I taught, had a department publishing study-guides!

> * There'll always be people that learn faster than others.

This isn't a problem with self-paced learning!

> 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.

Produce computer-aided instruction content on the Web!

> Try to avoid having them go ahead.

Over-learning is important. Because people forget, revision and 
repetition needs to be done.

> It's not a game to
> see who can get to the end of the training material quickly.

Will the stimuli be available to the learner on-the-job, for reference?

> * Always practice your material.

Rostrum and Toastmasters used to teach public speaking. I completed the 
Rostrum course.

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

Speaking in front of a mirror, or being recorded, is valuable practice.

> * 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.

Content can be posted or e-mailed. The college where I was teaching, 
posted video and audio cassette programmes of my lectures to students in 
Queensland, Papua New Guinea and Indonesia!

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

I discovered a presenter on a computing subject--who was completely 
unprepared for answers from the audience to his questions!

> That's all I can think of right now

As I have tried to explain, there are whole degree courses on how to do 
this right! I therefore recommend that prospective trainers make the 
effort to find out factors that they hadn't previously considered.
-- 
www.netspeed.com.au/bryan/
==========================



More information about the linux mailing list