Schedule Hacking Part One: Building an Audio-Visual Schedule

As a librarian with a website, I don't write about work or libraries very much. I spend a lot more time writing about everything else I do, not because I don't have Big Thoughts on librarianship or because I'm not doing a lot at work, but because most of the time what I do isn't all that interesting.

As a public services librarian in charge of an understaffed, underfunded (aren't they all?) technology department, I spend very little time working on what I would consider "librarian" projects and a lot of time keeping equipment running, training staff, being a manager and generally trying to keep things working.

One of the things I've been working on during final exams is the Audio-Visual Department scheduling system.

When I arrived at St. Thomas three-and-a-half years ago, the scheduling "system" was a disaster. One staff member was in charge of the schedule, which he composed every morning as a Word document, based on little scraps of paper that covered his desk. There was no organization to it whatsoever. He usually would edit the previous week's schedule to add in the content of the scraps of paper. Unfortunately, one-time events from previous weeks were often not removed and so the staff spent a lot of time taking equipment to classes that didn't need it, and also missing classes because the slip of paper was lost. Also, if for some reason that staff member was late or absent, there was no schedule for that day and everyone had to guess what needed to be done.

It was obvious this system needed a complete overhaul. The first thing I did was to take over the scheduling and insist that all requests come through me. The second thing I did was look at different software options for scheduling. Our system is a little weird in that we don't assign staff or equipment to rooms for blocks of time. Actually, we don't assign equipment at all. We have projectors, screens and DVD players in all of our classrooms, but no computers. All but the smallest rooms have a sound system as well. If a professor needs to use a computer, then one is brought to the room and hooked up.

This means that, unlike most schools, someone has to show up to the classroom before every class that is using Powerpoint or some sort of computer presentation. The staff member sets up, leaves, and then comes back at the end to pick up the equipment. This requires a schedule that can be sorted such that setup and pickup times are in order in the same list. The usual block schedule of every piece of software simply doesn't work for what we do. Additionally, the pickups and setups have to be attached to a single event, in case of changes to the request or cancellation. And as an additional wrinkle, the same staff member will not necessarily be handling both the setup and the pickup for a given class or event. Some events straddle shift changes.

Given the unique situation and short amount of time I had to work with (Thanksgiving break to the start of Spring semester the second week of January), I decided I would build an application using Microsoft Access. I had some experience with Access, having used it at my previous job to build an ordering system for professors' desk copies of course textbooks and also a system for keeping track of books bought for students with outside funding (athletic scholarships, military accounts, Higher Education Opportunity Program, etc.).

I had not built a scheduling application before, but I was familiar with the tools in Access and also using it to build a network application. I put a system together and got it mostly functioning by my January deadline. Some of the forms were ugly and a few parts were a little strange to use, but luckily at that time the system only had one user: me. I would receive the emails and phone calls with requests, enter them in the database and then every afternoon before I left, I would print out that night's schedule and the next morning's schedule and leave them in a basket for the staff.

This, of course, also had the problem of no schedule if I wasn't at work, so after a little bit of polishing, I installed the front-end application on the Library director's computer. If I was out, he would print the schedules for the staff. This still had its problems, like if I was out for several days, but it was a vast improvement over the previous arrangement. In the summer, I reviewed the semester's work. I made some adjustments to the printed schedule at the request of the staff. They had found parts of the template hard to read, so I changed some of the font sizes and the way events were grouped. Knowing that eventually I would have other people entering events, I tweaked the forms to make the application easier to use. But the major structure I had assembled was not changed. We would use the system essentially unchanged for the next academic year.