Scott Jehl on the responsive Boston Globe site

Opera’s Bruce Lawson talks to Scott Jehl of The Filament Group about developing the highly-regarded and responsive website for The Boston Globe

Shares

This article originally appeared in the November issue (221) of .net magazine - the world's best-selling mag for web designers and developers.

Bruce Lawson: Who worked on this with you?SJ: Filament Group, Ethan Marcotte, Upstatement, Mat Marquis and Miranda Mulligan, digital design director at The Boston Globe, comprised the main ‘design-velopment’ team. Meanwhile the Globe’s in-house team was incredibly proficient at translating our frontend code into the fully-functional site that it is today.

BL: Ethan Marcotte is the poster child for responsive web design; how much of an influence did he have in the process? SJ: Much of the development process was driven by Ethan’s thinking with regards to designing ‘responsively’. In order to employ that thinking on a large scale site, we had to extend the original techniques that largely applied to layout to other areas like behaviour, markup enhancements, conditional asset loading and performance.

BL: What were the initial technical challenges? SJ: Mainly, we wanted the page to perform well on underpowered devices, which meant figuring out a way to load assets efficiently and responsively so that we would not add significant overhead where it wasn’t properly supported or needed. Every critical feature of the site was designed to work independent of JavaScript, but enhanced with richer JavaScript-driven interactions in capable browsers. We focused on delivering the least amount of JavaScript upfront that we’d need to perform important polyfills, detect features, and conditionally load more JavaScript depending on environmental conditions.

BL: Why did you choose to useHTML5? SJ: We used HTML5 for a number of reasons. Mostly, it’s future-friendly and offered features that were useful in our feature set. For example, we made wide use of data- attributes for configuring behavioural options or associating content enhancements. We also appreciated the ability to use newer semantic elements in place of div/p/ span where they made sense.

BL: How did you make the site degrade gracefully on older browsers? SJ: In order to make the responsive layouts work in browsers lacking media query support, such as IE6-IE8, we needed a fast CSS3 Media Query polyfill. We found that existing solutions were too heavy and didn’t translate the layouts quickly enough, so we needed to write our own. The result of that is the Respond.js polyfill, which is open sourced on Github.

BL: What was your approach to images? SJ: We wanted to serve mobile-friendly images up front, to be responsible with bandwidth on slower connections, but we needed to serve much larger images on devices with bigger screens. We devised an approach called Responsive Images, which allowed us to detect the screen size, and on large screens, swap the mobile-sized image for a larger one without loading both.

Another challenge was advertising, as many third-party ad services are not built with fluid layouts in mind, and their embedding mechanisms and number of requests they make can be quite costly from a performance perspective. In the end, we devised some patterns for loading the ads dynamically so that they would not block the content from loading immediately. I think third- party services will need to be rethought to adapt to the future of how websites will be made.

BL: And what about old IE/no-JavaScript browsers such as Opera Mini? SJ: We spent a great deal of time making sure the site was functional and enjoyable to use without JavaScript, as the mobile web makes that issue all- the-more relevant again.

Internet Explorer browsers needed to be polyfilled for media query support. Other than that, we had the occasional Internet Explorer-specific CSS workarounds, but nothing too much.

I find Opera Mini tends to be pretty easy to support if you build with progressive enhancement: it’s a great browser with lots of performance optimisations included, and of course it’s incredibly popular so supporting it is a no-brainer.

The baseline browser we were regularly testing was BlackBerry 4.6, which receives a basic, JavaScript-free experience like most other non- media-query-supporting browsers. Somebody sent us a screenshot of the Globe site running on a Newton recently!