Opera’s Bruce Lawson talks to Scott Jehl of The Filament Group about developing the highly-regarded and responsive website for The Boston Globe
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?
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.
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.