Registrar time-range preferences rather than hard rules

There was a time, almost a decade ago, when our primary goal was to simply make a computed schedule. No sheen. No shine. Just a schedule. In the many days, weeks, months and years that have passed, we have reached an enviable point where we are no longer just trying to MAKE schedules, but now we get to focus on making BETTER schedules. To do this, we occasionally step back and study our work looking for opportunities to improve our processes. We have recently put our hooks into something that once again seems obvious enough now, but when you start at the very, very beginning, when things like footnotes or custom durations were for-sure luxury accouterments, you can understand why. This latest extension is adding a new layer to our Preference Collection Engine that we predict is going to be responsible for substantial gains in our school's end schedules.

Before introducing this latest feature, allow me to better describe the current preferencing landscape. Let me start with the Registrar Override as it is the least complicated entry point. All that happens through a Registrar Override is an admin would say I need this class scheduled on these precise days at this exact time, say Mon/Wed at 5 pm. That's what goes in and unless you have administratively double-booked a Professor, Room, or Section at that same time, that is what will come out on the other side.

The second preference option, used with your full-time faculty, is a little more involved. This begins with an email sent to all professors slated to teach, requesting their day and time preferences (it may be worth noting this polling-process takes less than five minutes of an admin's time). The email each professor receives will welcome them to the new teaching year and show them the classes they are scheduled to teach. Below each class will be a link. Those links will lead to a smart and handsome webpage (that may have been designed by me!!!) that will ask them to indicate when they would like to teach each of their classes.

For each class, they will need to provide three unique options. For each option, they will be asked to provide two things: the day(s) of the week they would like to teach, and then the time of the day they would like to teach. For the day selection, only viable options are presented. This means if it is a one-credit course, it will not offer them three-day options. Further, the school will define which days are presented. For instance, some schools only allow traditional day options, like Mon/Wed, Tue/Thu, while others will allow every possible combination, like Mon/Tue, Mon/Wed, Mon/Thu and so on. For the time option they will not select a specific start time but instead, indicate a time-range. Their options get bucketed into blocks that look something like:

  • Early-Morning
  • Mid-Morning
  • Late-Morning
  • Early-Afternoon
  • Mid-Afternoon
  • Late-Afternoon

Each block will note a set of possible start times (which are defined by each institution). The short story is, selecting a block selects a small group of start times, usually between two and four options, and not a specific time of day (e.g., 9:30 a.m.).

The professor will provide feedback for both of those options (day and time) for all three of their preference slots (1st, 2nd, and 3rd). To answer the most-asked questions—yes, they must provide an answer to all three, and yes, each option must be unique. If a professor is teaching multiple classes in a term, we even compare the selections across their courses and make them provide unique options globally (or else they would be competing with themselves for a time window). So a typical request might look like:

  • 1st preference: Mon/Wed, Mid-Morning
  • 2nd Preference: Tue/Thu, Mid-Morning
  • 3rd Preference: Mon/Wed, Late-Morning

So that is a fuller description of what the Faculty Polling Engine has looked like for a good while and how it works.

Now to the update. When it comes to making an optimized schedule the more variability we can send into the brain, the better the end schedule. The more hard restrictions we send in, the weaker the end schedule because we didn't give the algorithm enough space to flex its computing muscles and maneuver, or put differently, we placed too many cinder blocks on the playing field for it to make proper use of the full terrain. When we started studying this part of our system, we noted the extreme natures of these two preference mechanisms. One is wonderfully flexible and the other wholly rigid. It occurred to us that if we could create a hybrid option that could be used when there was a little but not a lot of flexibility, that might produce better scores on the schedules we were creating. To this end, we divined a new sort of preference. We call it a Registrar Time-Range preference.

This new preference blends the traditional 1st, 2nd, 3rd faculty options with the traditional Registrar hand-set preference. Going forward, when our admins travel into the course properties screen, where they used to have a single way to manipulate a course's placement, they will now see two options. Of course, they can continue to hand-set a course as they always have because that need is certainly not going away. But now they have an additional time option to choose from. In this newly added region, instead of having to assign an EXACT day-time combo (e.g., Mon/Wed @ 5:00 p.m.), they can direct the class to a particular part of the week and/or day using the same Day and Time selectors offered to the faculty (e.g., Mon/Wed - Late Afternoon). And instead of having to provide three unique options, like the faculty, they will choose just one. The net and meaningful result of this seemingly minor tweak is for every class you can convert from a hand-set time to a time-range option; you will create bonus space for the algorithm to work which should, in turn, do nothing but good things for your end solutions.

We're confident that turning more of these decisions over to the brain is going to improve the overall schedules for all of our schools because as all schedule-makers know, whether you're using the ofCourse platform or still doing manual builds, the fewer restrictions you can place on the endeavor the better your odds are of fielding a schedule that meets the needs AND pleases the people, well, the lion-share of the people at least. And, here at ofCourse, our immense hope for all of us schedule-makers is that our NEXT schedule is always better than our LAST schedule.

As always, see you on the scheduling pitch.

Troy

Troy Dearmitt

Troy is the CTO & Co-founder at ofCourse.

Subscribe to the blog for
university schedule makers