Academic Catalog for Clover Park Technical College

July 27, 2015

A web-based version of the academic catalog for Clover Park Technical College. Check out the site for yourself

Layer 1

What we have here is the web version of Clover Park Technical College’s academic catalog. You might remember the academic catalog from your college days: a bulky book that listed all the degrees, classes, and academic policies for whatever institution you attended.

At Clover Park, we had stopped actually printing a catalog years ago, but we were still producing a 200-page PDF and then posting it on the website. As a web person, this hurt my heart. We were asking users to download a 200-page, 7 megabyte PDF to access essential academic information. It was virtually impossible to use on a phone, and still pretty annoying on a desktop computer.

And, not only that, but producing the catalog was a giant pain. We had dozens of people editing word documents, or PDFs, or InDesign files, sometimes tracking changes, sometimes scribbling notes in the margins. And we had consistency issues: text and data was frequently repeated, but there was no systematic way of ensuring that the data was the same everywhere it was used.

It was high time for us to have a web-based version of the catalog. Here’s how I did it.

The Back End

I used Drupal as our CMS. In general I believe that the CMS isn’t as important as how you use it, but in cases like this, where you’re managing a lot of data and the relationships between that data, Drupal is a much more natural fit than, say, WordPress. Things like Drupal’s Entity Reference and core field options were essential — Drupal is built to establish relationships between content.

That said, this is a heavily customized version of Drupal. Drupal core and modules provided a great starting point, but much of this was so specific to our needs that I had to just code it myself.

A Single Source of Data

As a good computer-science person, I knew that it’s generally best to have a single source for any piece of data. If a class has five credits, that five should be input in a single location, and every page that refers to that class and its credits should refer back to that single source. That’s simple enough to implement, but it completely transformed the catalog: now when we need to change a class title or fix a number, we just do it once, instead of hunting down every instance in the 200-page PDF.

Don’t Repeat Yourself

In the print catalog, there were bits of text that were repeated over and over again — little legal blurbs about degree requirements, mainly. With the web version, we deal with them one of two ways. If it’s boilerplate text that appears on every page of that sort, it’s just included in the PHP template. If it’s a bit of text that’s frequently repeated but not on every page, you can just create it once and assign it to pages as needed. A real headache saver.

Let the Computers Do the Busy Work

One of the problems we had with the old catalog was we didn’t have good ways to check accuracy. For example, on each degree we listed the total number of credits, but to do so we had to add up all the credits by hand. This is obviously something a computer is better suited for. So now total credits are calculated in PHP, and they’re always correct, even if we change the number of credits for a course.

We also had issues where we would list a class under a degree but not actually include the class in the class listings. Checking for this sort of error by hand is hugely time consuming, but now it’s caught automatically — you’re not allowed to add a class to a degree unless the class actually exists in your listing.

The Front End

My goal with the site’s front end was to make it as lean and fast as possible without making it ugly. We just use two small images, our logo and the search icon. No javascript plugins were used — the class description popups were coded in vanilla js just to keep it as lean as possible. CSS was kept simple and weighs in at 9kb.

The site’s font, Futura, accounts for roughly half of the site’s weight. But, in my opinion, this is totally worth it. The homepage is just 250kb, which is extremely light to begin with. And if we’re relying on typography to make the design look nice, we might as well have a nice font. Plus, Futura is our brand font, so there’s really no way around using it.

The Future

I’ve heard that you shouldn’t try to build a complicated system — you should build a simple system and make it more robust over time. That’s what I’m going for here. Right now this is a basic system that meets all our needs, but I suspect that once we start using it we’ll expand it and make it more robust.