How long should a training module be?
Archive - Originally posted on "The Horse's Mouth" - 2009-01-27 07:25:07 - Graham EllisOur courses are divided into a series of modules ("chapters"). This allows us to mix and match appropriate material for private courses, to modify public courses over the years as some subjects become more mainstream and others get deprecated into backwaters, and to print out and present specific extra subjects after the normal public course day has finished as necessary. The scheme works very well, ensuring that our delegates cover all the elements of the subject that they need.
I have been asked the question - as a course author - "how long should a module be" ....
Answer - there is no hard and fast answer.
The normal minimum I set for a module is that it should cover a lecture and a worthwhile practical exercise. In fact, that's an ideal size too - very occasionally it could be no more than 15 minutes of presentation, but more typically it will be longer. But, dear course author, beware about going over an hour for a session. No matter how keen they are on the subject, most of your delegate's concentrations will start to lapse somewhere in the 60 to 75 minutes area of presentation in any style, and if they are in the "I am here cos I were sent" brigade (how fortunate that we get few of those!) you'll start having a real issue.
The upper limit for a module is a series of 'a few' lecture / demonstration followed by practical sessions that logically run one after another, are (almost) always all run as a series of successive presentations without a break from the sequence, run on the same day, and have a single logical heading.
Our Linux - an introduction for users module is the longest example we have, and is really a one day course all in a single chapter. Why can it be one?
• It's a neat single description.
• Everyone who learns Linux needs Logging in, navigating, copying, editing, permissions, metacharacters, and using it on the network
Subjects such as Linux Utilities and Shell Programming are separate modules - they are not always needed with the Introduction, they may be presented on different courses for some delegates who already have the experience, and they have their own good, logical headings.
Notes ...
Just because there's a practical and a minimum run time when fully presented for each module doesn't mean that I (as tutor) have to talk at least that long and give a practical every time. There are occasions where some aspects of a subject are less relevant to all the delegates on a course than is the norm, and a quick overview of as little as a minute may be enough. A classic example are the Graphic User Interface modules with Python - TkInter, GTK, Qt or wXPython? Each a logical module, each in a public course note set - but chatting with my delegates I'll more likely than not find that only one or two are relevant each week. But delegates are concerned if you skip a chapter completely without an overview of it - somehow they feel cheated, even if the module wasn't on the public course description.
I personally break the sessions up by switching between projector presentation of material in the notes, drawing diagrams on the board, and writing code examples from scratch. And it's great to involve the delegates by putting data that THEY come up with in those examples. It may be as simple as their names, it may be an object of a type that they can easily relate to ("a golf course" or "a Chinese meal"), or it may be data in a format that they will be having to use. But you really have to know your subject well to avoid getting stuck up on some minor issue that colours the whole session.
Summary ...
Really, modules are an artificial division unit and there is no hard and fast rule for sizing them. A course should average no more that (say) six per day as the subject names provide a roadmap of the points along the course, but in essence the division is logic based not time based.