Opening Hours on the Libraries web site: "Right-sizing" complexity

Last week we rolled out a new set of pages listing the opening hours for the 30-plus library buildings, collections, and other place-based resources that make up the University of Minnesota Libraries. Behind these new pages lies a corresponding new system that relies on Google Calendar for maintaining opening hours information. This system is a considerable improvement over our previous tools for recording and listing opening hours.

The previous system and why we replaced it

When our previous opening hours listing system was built, it was implemented with the goal of using the internal content management tools of our web site's native content management system, Drupal. Drupal provides a means to set up custom types of pages with a variety of data fields of various types (essentially, a content-specific data model and corresponding page authoring template). Additional Drupal components provide means to query, filter, and organize the data stored under these custom content types in flexible ways. So far, so good.

As it turns out, however, opening hours for Library locations and services are…well…complicated. Hours vary over different days of the week and between academic semesters, summer session, and breaks. Throw in the occasional holiday and other special cases, and the interplay of different patterns and exceptions to the patterns becomes quite elaborate——both on the data modelling side (or, “What site maintainers have to enter into the system”) and on the information display side (or, “What visitors see.”) So in the end, the understandable desire to build within our native tool resulted in a system that was more complicated than it needed to be, both for site authors and for site users. See image above: For bonus points, figure out if SMART Learning Commons is open today. Go!

With that in mind, we set out to find a better way.

How the new system works

Turns out that what we might call “the Calendar Problem” has already been solved. Many times. University of Minnesota staff, faculty and students have one such solution ready at hand——Google Calendar——and most are already proficient in its use. Wouldn't it be nice if we could use a familiar tool like Google Calendar to manage opening hours information? That would solve part of our challenge: Providing a (relatively) user-friendly way to manage opening hours data. This would allow us to delegate the maintaining of hours information to those staff who are most familiar with each location without having to get them up to speed on using Drupal along with our elaborate custom hours content model.

Above: The hours for Wilson Library and additional services at Wilson, as seen by the opening hours maintainer in Google Calendar.

That still leaves the other half of the problem: A visitor-friendly way of presenting the opening hours information. As luck would have it, Google Calendar provides an API——Application-Programming Interface, or, more colloquially, a structured and documented way for a computer program to accept requests for its output and send back the results of those requests. With that in mind, we set to work to develop a few tools to provide different types of opening hours data:

• Prominent listings of today's hours for our five main locations on the front page of our web site;
• Prominent listings of today's hours for each library or collection on its own web site (e.g., Special Collections, Rare Books, and Manuscripts);
• A dedicated “hours” page for each library or location listing its own hours for the upcoming week along with the hours of specific resources within that location (e.g. the Special Collections, Rare Books, and Manuscripts hours page); and
• A search tool to allow visitors to find hours for future dates——Much benefit for, say, a researcher from distant lands planning a visit to a special collection (also at link immediately above).

At right: The new web listing of Wilson Library hours, with search option. View the live Wilson Library hours page.

Separation of concerns and positive side-effects

Where the previous system was built entirely within Drupal, this new system was designed with a different set of goals:

• To delegate the work of fetching data from Google Calendar to a separate subsystem optimized for that task and unconcerned with the specific needs of Drupal;
• To provide the basic data in a generic format that could be available to non-Drupal subsystems within our site; and
• To bundle up the presentation and interface elements needed specifically by Drupal into a Drupal module and theme.

The components we developed, then, serve these different goals:

• One script is tasked with nightly queries to Google Calendar to fetch the daily and weekly hours for each location and store content snippets for the front page and collection-specific listings;
• Another script processes the searches that originate from the hours search form, sends them to Google Calendar, and formats the results for display;
• A Drupal module provides blocks (Drupal-specific preformatted units of web content) that can be enabled and placed in the site using Drupal's content management tools; and
• Several tweaks to our Drupal theme allow a more attractive display of the hours content wherever it appears in the site.

One positive side-effect of this new system became evident while working on the project: By using Google Calendar as the source of opening hours information, we now have the option to provide this data as a public data source, or feed, that is already widely supported by virtually all desktop and mobile computers. Thus, regular visitors can subscribe directly to the Google Calendar feeds for their favorite locations in their own calendaring system of choice, rather than than visiting our web site whenever they need to check hours.

A last potential D'oh!

As a worldwide, distributed, collaborative project, Drupal never stands still. Last July, as I was elbows-deep in the code for our new opening hours solution, a blog post entitled Presenting the Opening Hours Module cropped up in my feed reader. Looks good, something we might use. I may follow up on that one of these days.