Clover Park Technical College

August 12, 2014

The main website for Clover Park Technical College, one of Washington's public schools. Check out the site for yourself

Layer 1

Story Time

For my day job, I work as the webmaster for Clover Park Technical College in Washington. Yes, “webmaster” is typically used to describe shady web developers from 2004. In this case, though, webmaster means I’m responsible for all of the college’s stuff on the web, i.e., their website and blog and whatnot.

When I first started at the college in January 2013, their website was, in my opinion, a mess. I want to be fair and evenhanded here and not besmirch the previous web regime, so here are some facts about that version of the website:

I bring all of this up not to cut down people I don’t know, but as a case study: what do you when your (large) website is a total mess, and you need it to not be a total mess, but you don’t have a budget beyond one person’s staff time? 

I can’t give you a definite answer, but I can tell you how I did it.

Phase 1: Emergency Measures

Doing a full website redevelopment for a medium-size college takes time; you need at least four months, I’d say, and that’s if you’re hauling and taking shortcuts. But we needed to stop the bleeding much more quickly than that, so I tackled the low-hanging fruit right away: I fixed the broken links and 404 errors, ditched the backgrounds, added a flyout menu instead of making people go to landing pages for each item, and generally simplified things and gave them at least a little bit of design effort.

Was the site beautiful? No, not really. But it was much more effective than it used to be (page load times plummeted; people began finding what they were looking for much faster). And it had only taken a month or two to get it live, since I was only really making CSS and HTML changes (and getting them reviewed and approved and whatnot).

Phase 2: Making Something We Could Build On

Once the bleeding was stanched, I had the time to address some of the larger issues and do a full redevelopment, of sorts. Here were the most pressing issues:

Content Management System

The site at that time was built with Expression Engine. I’m not sure that it’s Expression Engine’s fault, but the back end was a mess. Doing something as simple as making clean URLs was a giant hassle. There was no WYSIWYG; just an HTML editor that wouldn’t let you indent code. Editing templates was backwards and not intuitive. Long story short: whether or not we used Expression Engine, we needed to rebuild the back end of the site.

I know that people get OPINIONATED about content management systems, and I’d like to add another opinion to the mix: if you don’t have much money for a CMS, you should use Drupal or WordPress. They are both free, and they both have amazing community support. That is, whatever problem you’re facing, someone else has probably already faced, and they’ve probably blogged about it or at least answered a forum post. This sort of support is a) free and b) helps you actually learn what’s going on with your site, rather than just paying someone to fix it for you.

I chose Drupal for this site. I’m not going to get into the technical pros and cons of Drupal vs. WordPress. That’s been covered extensively in the front-end world. Both are great; I could’ve used either.

But here’s the thing about CMSs: you have to sell your choice to Management, and Management is consistently terrified about it. How are we going to run our website? What about support? How do we make new templates? And, strangely, Management is particularly terrified of WordPress and Drupal because they’re free. If you’re not involved in an open-source community, the idea of trusting the most public face of your organization to something you downloaded off the internet for free seems absolutely terrifying. It feels safer to just spend a bunch of money on something, anything.

In my case, I probably could’ve fought to use whatever I wanted. But between the two, WordPress has more of a reputation as a blogging software, and Drupal is known more as an enterprise-level solution. I could’ve made a solid case about how, yes, those statements are true for WP and Drupal out of the box, but with either one you’re going to use enough plugins and do enough modifications that their out-of-the-box state won’t really matter. But really, either would’ve worked, and Drupal’s offered the right solution for us at either turn.


I once worked on a medium-size website where we spent months deciding on our main navigation categories. Cards were sorted. Surveys were done. Diagrams were drawn. In the end, we just did the same categories that everyone else in that industry did, and it worked fine.

So for this one, my supervisor and I just looked at hundreds of college websites, and lo and behold, pretty much all of them used more or less the same four categories: About, Academics, Admissions, Campus Life. So that’s what we did.

I know, I know, I know: someone out there has probably done usability testing and studies and has discerned that these categories are All Wrong and that using these categories is a Disservice to Your Users and Having Dropdown Navigation at All Is So 2013. But this is a one-man-shop funded by student tuition and taxpayer dollars, and so doing the fast, effective thing was the right thing.

Were these categories perfect? Nope. But they were way better, and I’ve been able to tell from our analytics what areas have cause users trouble and have adjusted accordingly.

The other organization thing we did is that we flattened the site out. That is, we got rid of most of the landing pages. The guiding theory here was we should only use landing pages when there are a bunch of things that are clearly grouped together. So we wouldn’t make a landing page called “Resources,” because no one would know exactly what would be there. But we do have a landing page called “Financial Aid” that links to the many Financial Aid pages, because that makes sense to people.

Front-End Design

For this phase of the website, I was going for a design that would make people say: well, it’s not totally terrible, and I can use it. Truly great graphic design takes time and attention to detail, and at the time we just wanted to replace the old monstrosity as quickly as possible. And to do that, we started with Bootstrap.

Bootstrap is great if you, like me, needed to do quick mockups and you like to do your mockups in code. Let’s say we have four different page layouts for the site, and I needed to present several options for each page. And, furthermore, this isn’t 2007, and I needed to also have mockups of what it would look like on a phone or tablet or funny-shaped laptop. So we’re looking at a few dozen mockups there. Bootstrap makes it relatively fast to do all of those; doing them in code in Bootstrap is faster than doing them in Photoshop, and then, once a design is approved, you already have code to start with.

But obviously I didn’t leave everything all Bootstrappy. In fact, by the time I was done customizing everything, we pretty much were only using Bootstrap’s grid system and a few of their javascript plugins. But it gave us a good starting point for a responsive, not-terrible design.

In total it took about four months from when I started working on the new version of the site until it launched. I didn’t spend all my time on it — I have other duties around here, and I had to maintain the existing site — so I was pleased with how quickly we were able to replace the old site. And even though this was a less-than-perfect site, it got us (relatively) incredible results: visits to our target pages went up more than 150%. Load times were cut in half. Mobile usage went way up; our audience had mobile devices but apparently our old site was so bad that they didn’t even bother visiting it on their phones. There was great rejoicing, but we weren’t done yet.

Phase 3: Making an Actual Really Good Site

One of the benefits of rehabilitating our site in phases like this was that we didn’t have to waste time solving problems that weren’t really problems. Here’s what I mean: the problems with the version of the site I inherited were so obvious that I really didn’t need to use analytics or data to know what needed fixing. The site was too slow. It wasn’t organized. It didn’t work on small screens. It really just needed a common-sense design based on web-design fundamentals. And that’s what we did for Phase 2. Once we had that in place, we could use our analytics and whatnot to see what problems we had that were specific to our site.

So I pretty much just let the site collect data for six months or so, only fixing obvious bugs while I worked on other projects. Here’s what our data showed:

Basically, all of this came down to rethinking our front-end design, which is immensely easier than rebuilding a whole site from scratch. To do this part, I looped in our super-talented print graphic designer. He came up with some homepage concepts that included a new header and footer, and I put them into code and added some ideas.

Implementing this part was way easier than launching a whole new site; we were just implementing a new Drupal theme, which is no problem at all.

In total, it took roughly 18 months from the initial “we need to fix this” to having a site that we love and that accomplishes what we need it to accomplish. And because we did this in steps, we got way better results (and data) during those 18 months than we would’ve if we’d just undertaken a complete redesign from the start.

The Technology I Used, If You’re Interested in that Sort of Thing


Combined with SASS and LiveReload, Grunt saved me hundreds of hours on this project. I probably spent a total of three hours installing, configuring, and troubleshooting Grunt, and it probably saved me 100 hours — I didn’t have to worry about anything except the actual code and design, and Grunt took care of all the compiling and compressing and (probably most importantly) putting all of the files in the right place.


I couldn’t have kept this project remotely organized without partials, variables, and mixins. SASS makes it so easy to keep things consistent throughout the site, and then to change them without drama. I use a lot of math in my SASS — any number that’s based on any other number is obtained through math. That way if you change one number by a pixel or a fraction of an em, everything recalculates nicely and you don’t have to hunt down any problems. Huge time saver.

I used Compass on this project as well, but Compass isn’t getting its own heading because I’m not sure I should’ve used Compass. On other projects I’ve been using Autoprefixer without Compass, and I sort of like it better. On the other hand, having all the Compass tools at hand — advanced math and link-color mixins and etcetera — is quite convenient.


I use Modernizr for progressive enhancement in a few spots where I wanted to use SVGs or flexbox for something fancy-ish. We have to support back to IE7, so I don’t get too crazy with CSS and javascript to begin with, but it’s nice to be able to reach for Modernizr when you need it.


SVGs look better and are smaller and are better for users, but the real reason I like SVGs is that they’re convenient for me: they mean I only have to deal with one image file. I don’t need multiple sizes, I don’t need sprites with different colors. It’s great. I love SVGs. I particularly like SVG icons, because if they don’t show up, it’s no big deal — they’re a nice but not critical touch.