Room Class Schedule Finder

Two-sentence description

A web application to let room coordinators at the University of Washington view the schedule of events—and therefore also the availability—of any room on campus. It “unlocked” this information, previously available only via a clunky desktop app, by consuming a RESTful web service.

Background

If you’ve got five minutes, the details of the project can be found in an Ignite presentation I gave at the UW’s Web Application Developer’s Group meeting in May, 2010, and subsequently posted to my blog. If you’ve got less than five minutes, you can just burn through the slide images yourself.

CollegeNET makes a room-scheduling software called simply “R25” and the UW uses it to manage rooms throughout its campuses. Unfortunately, the version of the desktop client the UW is forced (due to budgetary constraints) is old, cumbersome, and in most cases overkill for the tasks most campus users need. There’s also a per-license and manpower cost associated with each installation. For these reasons, the Office of the University Registrar wanted a simpler solution: a web application that would present a simplified interface to users to get just the info they needed: what classes and events are in a given room for a given quarter?

Luckily, CollegeNET offered a RESTful web services module for existing R25 customers that the UW Information Technology office (UWIT) installed. Armed with this structured XML room scheduling data and the design goal of a simple-to-use web application, I wrote the Room Class Availability Finder (RCAF). (I know, it’s a terrible acronym.) And reliving my days as a technical writer, I also wrote a page of help for the app—including a screencast!

Skills and technologies

I employed a number of technologies to build the web application. Before I could begin, however, I had to work with my colleagues in UWIT and the resident R25 expert in the office to learn about the data structures. Terms like event, reservation, location, and profile description all have varying meanings and I had to learn and understand them before I could build the site.

  1. Back-end: PHP classes I’d written previously to access the UW’s Student Web Services were my starting point, but I had to re-write them to accommodate the namespaced XML format returned by the R25 web service (the SWS payload was returned in XHTML).
  2. Front-end: Semantic markup was the basis for the tool, but the real magic was in the jQuery code. Leveraging the jQuery javascript framework allowed multiple user inputs (such as room and date choices) and two asynchronous calls to other scripts (one for room details, the other for room availability) all without reloading the page with a standard form submission. Three excellent plug-ins rounded out the web app:
    1. Autocomplete – A dynamically-produced look-ahead menu for room selection.
    2. Week calendar – Not surprisingly, an event display tool showing a week of data at a time. It displays events fed to it in JSON format, which I created using PHP scripts.
    3. TipTip – Custom tooltip display for showing full values for truncated information on the week calendar.

The result of these tools is best shown visually, and since the app itself is available only to specified users, this two-minute screencast should give you a sense of the final product:

[kml_flashembed publishmethod="static" fversion="8.0.0" movie="/wp-content/wp-images/RCSF-video.swf" width="400" height="300" targetclass="flashmovie"]

Get Adobe Flash player

To my viewers on iPads and iPhones: I’m sorry this content is only available in Flash, though I wish I had another, compliant version available.

[/kml_flashembed]

Take aways

The most eye-opening aspect of this project wasn’t technological, though I did teach myself a lot about jQuery, AJAX, and JSON. Rather, it was about personalities. I was excited about the tool I was building and anticipated the excitement and positive reception it would have among its audience. Yet when we first unveiled it to a room full of room coordinators, their reaction was mostly about what else it might do (a slide in my Ignite presentation includes some of the features requested). Happily, I was able to quickly add a few of the requested features and added others to a list of future improvements. But that experience reinforced to me that customers want solutions, not technologies. Did any of them say “hey, it’s cool that you don’t have to click a ‘submit’ button!” or “how did you optimize page loading times by minifying your javascript code?”? No—they wanted it to do the things they needed it to so they can do their jobs better. And that reminder will serve me well.