Our 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" ....
- 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.
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.
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. (written 2009-01-27)
Associated topics are indexed as below, or enter http://melksh.am/nnnn for individual articlesG310 - Well House Consultants - A better class of course 
C++ Courses - do I get official certification at the end of my Well House course? - (2012-01-20) 
Data that we use during our training courses, and other training resources - (2011-09-04) 
Do university courses teach the right things for life at work later on? - (2011-08-10) 
The importance of feedback - (2011-04-30) 
How will we present courses over the coming years? - (2010-10-17) 
Well House - Mission and Policy summaries - (2010-05-13) 
Why do I teach niche skills rather than mainstream? - (2010-02-13) 
Are we IITT (Institute of IT Training) members? - (2009-05-17) 
Why most training fails ... - (2009-03-30) 
Books and distance learning from Well House Consultants? - (2009-03-15) 
Weekday or Weekend PHP, Python and Perl classes? - (2009-03-10) 
Why Choose Well House Consultants for your course? - (2009-02-20) 
Learning to Program in C - (2008-12-10) 
Seeing how others do it - PHP training - (2008-05-17) 
Making PHP and MySQL training relevant to the course delegates - (2008-03-15) 
New trainee laptop fleet for our Open Source courses - (2007-12-30) 
What makes our courses special? - (2007-12-02) 
Longer hours and better value courses - (2007-01-15) 
In praise of training course delegates. - (2006-05-20) 
PHP - London course, Melksham Course, Evening course - (2006-03-14) 
Short Linux and Perl courses for small groups - (2006-01-27) 
Learning to program in Perl or PHP - (2006-01-26) 
''I don't know'' is sometimes a good answer - (2006-01-09) 
What backup is adequate? - (2006-01-04) 
I have a river to cross - (2005-11-16) 
A year on - should we offer certified PHP courses - (2005-07-28) 
The training team that's looking out for you - (2005-07-07) 
Want to be one better - (2005-06-17) 
Elegant languages - Perl, PHP, Python - (2005-04-26) 
Course sizes - beware of marketing statistics - (2005-02-27) 
YOUR application and YOUR data - (2005-02-22) 
Some unusual features - (2005-02-18) 
Open Source becomes mainstream - (2005-02-14) 
Look after your staff and they'll look after you. AOL. - (2005-02-12)G504 - Well House Consultants - Writing Notes 
Showing what programming errors look like - web site pitfall - (2013-03-06) 
Clear, concise examples - Ruby classes and objects. - (2013-02-17) 
Jargon busting - (2011-01-30) 
Sharing our programs - easy. Sharing our data - harder. - (2010-06-26) 
What is Perl? - (2010-06-15) 
Sample code with errors in it on our web site - (2009-10-29) 
Hello World - a good traditional start to a Java course - (2009-09-22) 
Copy writing - allowing for the cut - (2009-05-21) 
Copyright of Training Notes and Web Site - (2008-12-18) 
Notes from the white board - (2006-12-14) 
Empty seats, Nodding Donkeys and buses - (2006-12-11) 
Writing up new C / C++ notes. - (2006-07-09) 
Theft of training material - (2005-08-09) 
Training course material - why we write our own - (2005-07-30) 
Study room - the Oxford train - (2004-08-10) 
Writing on a Sunday - (2004-08-08) 
Seeing the wood for the trees. - (2004-08-06)
Some other Articles
First ClasswxPython - Introduction and sampleThe Wiltshire PoliceConversion of OSI grid references to Eastings and NorthingsHow long should a training module be?The Royal Mail ReceiptThe Month Ahead - What is happening in MelkshamLaunch of Melksham Food and Drink FestivalContrastVariables and pointers and references - C and C++