[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