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