Re-designing and re-building thecurrent.org

tc_redesIn late November of 2012, we launched a beta version of The Current, and this version became the version of thecurrent.org in January of this year. The project actually started in July of 2012, with a brief pause for the November election.  We did a major overhaul of the front-end and a re-organizing of the backend of the site.  Let’s look at a couple of the major components of this redesign.

Responsive layout & visual design

Our primary goal for the project was to create a new site that would work better on phones, tablets, and other devices. We had never done a big responsive project like this in MPR, so it was very much a learning process for us. The frontend developer in me knew that we would save some time and headaches working with a framework, and many of us have experience with Foundation, so that’s what we went with. It might seem odd to choose a css framework before doing visual design, but when doing the design, it helped me think about the various widgets and styles that I could work with. If I could do visual design with those more in mind, it would save time in headache during implementation.

Our general process for doing the design went like this:

  1. Post-it notes on a wall or paper (mobile)
  2. Clickable Keynote slides (mobile)
  3. HTML Wireframes (mobile/desktop)
  4. Photoshop (mobile)
  5. User testing (mobile and desktop)
  6. Photoshop (mobile and desktop)
  7. Implementation

In doing research for the redesign, we figured out early on that the primary reasons people visit thecurrent.org is to look at the playlist and listen to the live stream. Thus, it was obvious those things should be prominent and omni-present. In doing HTML wireframes, we figured out a basic three-column grid structure that facilitated this and the underwriting display ads, and stuck to that grid when doing the visual design. This format omits a traditional nav bar, at least on the desktop. The various sections down the left rail come back as a nav bar on mobile/small screen devices.

For the visual design, we have fairly well-defined brand guidelines, but even the best brand guidelines don’t always translate perfectly onto the web with it’s many quirks. We knew we had to work with the maroon, the logo, and we needed it to have a feel that matched the type of music and personality of The Current. As a concept, the look for the site is based on screen printing test sheet, typically cheap brown paper, with ink (type) that can be semi-transparent. Screen printing and a database-driven website are pretty opposite ends of the spectrum in design, but it gave us a starting place.

User testing & feedback

User testing scenario planning.

We did user testing later in the design process mostly as a sanity check on our choices thus far. We tested in-person with high-fidelity mockups using InVision. Half of our testers saw our site on a desktop, half on a phone, and we gave our testers about 7 different scenarios. During testing sessions, we recorded the tester’s screen and audio, and used Steve Krug’s advice from Rocket Surgery Made Easy verbatim.  The testing showed that users “got” the site on a conceptual level, but there were some minor tweaks and affordances that would help them out, without requiring major design changes.

When we launched the new site, we ran it as a beta site for a month and a half. During the beta period, and for a time afterwards, we used UserVoice to solicit and collect feedback from visitors. This feedback was invaluable, helping us to fix issues with various browsers, clarify pages, and fix errors. Doing the beta period was very important for the development of the site. It let us ‘get something out there’ while still knowing that we had few edges to polish. If we broke the site during the beta, it was not a big deal: beta means less guarantees.

HTML5 audio

HTML5_Badge_512About a year ago, we began rolling out a new web audio player, called APMPlayer (it’s open source!). Prior to this, the web audio players on our site used flash to stream AAC+. AAC+ is very bandwidth and quality friendly, but flash is a major bummer for lots of reasons. We also had a need to display more synchronized display underwriting messages with audio messages, which can happen in APMPlayer. APMPlayer is a jQuery fn and relies on the very awesome SoundManager2 library to handle all the wonderful and numerous quirks of  <audio>.

On all the Minnesota sites (Current, Classical, and News), APMPlayer works in a pop-out window. Pop-out windows have their issues with usability and aren’t used a ton anymore, but we stuck with them for  backwards compatibility and overall development simplicity. I’m skipping over about a year of development time here, suffice to say APMPlayer is a pretty nifty dealio that we’re still rolling out to all our sites.

Bolt-on modern(ish) server-side framework

We also used this redesign to update the way the site was put together on the server. Prior to the redesign, our site was a collection of php files that might include some classes and other things, and then pass data off to smarty 2 tpl file. This was OK when the site was small and simple, but the current had grown substantially, and this meant an unsustainable mess of php and tpl files strewn about the filesystem.  It also meant that a lot of our URLS ended in .php, which always seems inelegant.

We were not undertaking a major re-working of our backend CMS or server-side languages for this, project, but we as developers really wanted some of the conveniences that modern frameworks offer: url routing, caching, MVC, etc. To address this, we chose SLIM Framework as a lightweight layer in the server stack to give us URL routing, template abstraction, and middleware.

slim-in-sublime

SLIM lets you use whatever different template system you want, we chose smarty 3.  Smarty 3 is a lot like smarty 2 (which we run on many other sites), but it’s faster and adds template inheritance. I’ve previously used template inheritance with Django templates; once you use it you never, ever, want to do templates any other way. With a modicum of planning and foresight, you can use it to dramatically reduce the number of templates your site has, and make it much easier to update in the future.

Performance optimizations

Everyone knows that frontend performance makes a huge impact on the user experience and the old site was rather terrible in this regard. We’ve made some major strides towards rectifying that with the new site:

  • CSS, css images, and javascript (except anlaytics) are versioned, compressed, and served with far-future expires
  • CSS sprites are used wherever possible to reduce HTTP requests
  • Expires and cache control headers set up for HTML assets
  • Akamai page cache rules are configured to match specific URL patterns and their various caching needs

Overall, we reduced the number of HTTP requests on The Current homepage from about 120 to about 70 and trimmed the page size by about 400kb. Whereas pages on the old site would sort of rejigger and re-draw as various parts loaded up, the new pages snap into view all at once.

We still have a lot of seperate javascript that runs on the site for ad serving and various analytics packages, but we were able to roll much of that into Google Tag Manager. Not only does this make it easier for us to update in the future, but it means that much of this code runs after DOMReady. It still runs, but the page is theoretically usable before that.

Other nifty things

There are other numerous sections that could be added to this project, but they won’t all fit into this post. Here’s a quick snapshot of what they might be:

  • Better deployments and version control
  • Using the LESS css-compiler
  • Integration with iTunes for album art
  • A server side caching mechanism
  • Migration of the Local Current Blog from Drupal to WordPress
  • Moving from minnesota.publicradio.org to thecurrent.org

Some of these might see a more in-depth post in the future.