New story pages for MPRNews.org

mprnews_story2For the past several months, a team of us in St. Paul have been hard at work crafting a new and more modern reading and listening experience for the MPR News website. The story pages that we’re unveiling today are the next step in our process to modernize our site to keep it up to date with our audiences media consumption habits. These new story pages will work on all devices, load faster, be easier to read, and present our journalism better.

Right now, we’re only making our story pages available. Our existing homepage and ancillary pages will retain their same look and feel for now. To get to a new story page, visit an old story page and follow the link to the beta version on the right. These new pages will live alongside our existing pages for the next few weeks (in Beta!) as we continue to fix bugs and listen to the feedback from our audiences. You can help us by sharing your gripes, likes and ideas in our feedback forum.

Here are a few stories in the new design:

Since this is a developer blog, I shall now delve into the details of what we’re doing.

New domain

Just like we moved The Current from minnesota.publicradio.org to thecurrent.org, so too are we moving MPR News to mprnews.org as a canonical domain name instead of just an alias. One reason is that we want the URL to match our brand. Moving to a separate domain also allows us to have more sophisticated URL routing and CDN settings that are harder to manage when shared on the same domain as other sites.

Responsive design + mobile first

Like many sites, including our own Marketplace, The Current, and MPR News Blogs, our pages are going responsive. They’ll work on all your devices (or at least devices made within the last decade). For The Current and the MPR News blogs, we had two breakpoints because we used Foundation. We found that at smaller sizes of our desktop/large breakpoint that pages felt cramped. For our new story pages, we have three major breakpoints: Small/phone (0-540px), Medium (541px-748px), and Large (749px+).

Our CSS has been structured with Mobile First in mind. Mobile browsers only have to deal with the simplest and smallest parts of the CSS, while tablets (medium) and desktop (large) have more rules to parse, but in theory have more CPU horsepower to work with.

We support IE8, but IE8 does not read media queries. There are several ways to work around this. We use LESS, so we can do some pre-processing on our CSS and generate a IE8 compatibility stylesheet. IE8 stops parsing as soon as it sees a media query, so if we were to load our CSS without doing anything, IE8 would render a mobile page. This isn’t terrible, but could be better. Instead, we generate a ie8_compat.css file for IE8 that has our medium, large, and other rules, all without media queries. IE8 only loads this, and it makes IE8 render the desktop site. Here’s a sample gist of how we’ve structured the base.less file.

Performance + pjax

Part of being a good responsive site is that performance, how long a page takes to load up, needs to get better, not worse. Going between pages needs to be faster, not slower. Many re-designed responsive sites actually perform worse than their desktop only counterparts. We’re attempting to avoid this pitfall with laser-like focus. We’re doing a lot of the standard things like reducing http requests, using icon fonts, setting long expires, etc, but we’re going the extra step with two other techniques.

pjax Pjax is short for push-state asynchronous javascript and xml.  To put it more succinctly, when someone clicks a link, we only reload parts of the page that need to change, but not the whole page. The main benefit is that don’t have to download assets or repaint the entire screen. Using pjax, pages really snap into view almost immediately, rather than having a couple second delay. Pjax, unlike ajax or other techniques, means that the URL changes as the portion of the page change.

A nice non-performance benefit of pjax is that our new audio player can stay persistent and playing in the same window, even as a visitor navigates to other pages or stories.

We’ve tried to minimize the amount of javascript on our pages, because in a responsive world doing fancy things with javascript gets complicated to mange. Javascript is also not free: it incurs loading, parsing and execution time that is particularly pronounced on slower mobile devices. One technique to mitigate the performance issues is to only load up the bits of script you need to use right before you need to use it. We’re using require.js for this. Here’s an example on our site: Many of our stories have audio and an audio player, but most people read the story and don’t listen to the audio. We don’t want to load the audio player scripts up for everyone. We only want to load them up, on demand, for people that request audio playback. Require.js helps us do that. Require also integrates nicely with our build system, grunt, to generate tidy and linted code. It’s swell.

Responsive Images

There is no official, ratified specification for responsive images. This makes it really hard to do well. On our blogs, we used a <picture> polyfill, and it works fairly well. However, it depends on javascript to actually run, and a not insignificant amount of javascript at that. For our new story pages, we’re testing a technique some have dubbed clowncar. It takes the ability to have media queries in SVG images and combines it with raster images. For IE8 and older android users, there is a fallback of a standard <img> tag hidden with conditional comments.

We have a a few issues with aspect ratios not scaling properly, but overall we find it to work well. To our knowledge, this technique hasn’t been used in a larger website yet, so we have some hesitation in being the guinea pig, but think the benefits are useful.

Your feedback and our next steps

We have a list of 58 issues open in our internal bug tracker, most of which are things we plan on fixing before these new pages replace our existing story layout. We want you to help us identify things that we may have overlooked, and help us prioritize what we should add or change. We will be pushing new releases to the beta site over the next few weeks, and going live in mid-November.

Comments are closed.