XAML to the rescue
I’ve been tasked with coming up with the logic for a timetable auto-scheduler to compliment our existing timetable functionality (pdf) offered to our FE and HE customers. This is the big, magic button that will take a whole load of configuration data (i.e. number of modules, number of lessons, durations, week patterns, location, tutor type etc.), whir quietly away to itself for hopefully not too long and produce a lovely, evenly distributed timetable (which could then be used to balance learners using the existing ebs4 Block Matrix functionality).
Not long into the work it soon became apparent that it is actually tricky to know what the process was actually producing when the required output is just an XML file, so I set about adding a noddy WPF front end to try and make sure that it was working as it should.
I’m a big fan of the XAML markup, Data Binding and the power of Converters (all as used in WPF, Silverlight, Windows Phone 7 and Windows 8 Metro Apps) and have very quickly been able to pull together the UI to display all the types of data I’m needing to check to ensure my process is creating the correct output:
Timetable Auto-Scheduler test UI
It’s not going to win any design awards but that’s not the point.
Some quick stats on the progress so far:
- Testing for 10,000 modules.
- Each module has either 4 or 5 lessons.
- Each lesson can have a different week pattern.
- Each lesson can have a different duration.
- 1000 Module Groups.
- Each Module Group has between 2 and 7 modules that need to be able to run without clashes.
- 1000 Linked Lesson Groups.
- Each Linked Lesson Group has between 2 and 5 lessons that must run on the same Period (i.e. merging lessons for joint lectures or dovetailing based on the lesson’s week patterns).
And the time taken for the process:
Timetable Auto-Scheduling process results
Resulting in 2 unresolvable clashing lessons, I’m happy with that. Now time to start dealing with rooms and tutors…