Although the differences between responsive and adaptive design are nuanced for the non-developer, the distinctions are increasingly important as publishers see more and more traffic come from mobile devices.
There are two similar buzzwords flying around the digital media space right now, and to the uninitiated, responsive and adaptive design might seem like interchangeable labels for the same tech. They are both, after all, methods to optimize web content for mobile consumption -- a challenge that publishers must face if they are to adapt to today's news consumption trends.
A recent Pew Research study shows that mobile users are not just skimming headlines as once assumed, but "many also are reading longer news stories -- 73% of adults who consume news on their tablet read in-depth articles at least sometimes, including 19% who do so daily. Fully 61% of smartphone news consumers at least sometimes read longer stories, 11% regularly." So, having established the importance of offering a site well-adapted for mobile use, the question is: What's the best way to go about getting there for publishers, adaptive or responsive design?
In an attempt to fully understand what distinguishes the two methods, I've been asking experts in media, mobile development and PR from three countries to describe the methods for me in layman's terms. Perhaps unsurprisingly, each had a slightly different explanation, and it turns out that what's best for publishers depends on what they're trying to achieve with mobile.
There are a few ways of comparing the two methods:
The Client-Server Distinction, Simplified
One of the easiest ways to understand how responsive and adaptive design differ is to consider it in terms of how the website is delivered to a device.
Responsive design is client-side, meaning the whole page is delivered to the device browser (the client), and the browser then changes how the page appears in relation to the dimensions of the browser window.
Adaptive design is server-side, meaning before the page is even delivered, the server (where the site is hosted) detects the attributes of the device, and loads a version of the site that is optimized for its dimensions and native features.
As you might guess, a major difference here is in where the work is being done. With responsive, the device itself does the work with media queries to display the re-sized images and optimized layout, whereas with adaptive, the server does the work and delivers the page already optimized.
This is how the distinction was described to me by Ilicco Elia (@ilicco), who is the former head of mobile for Reuters and currently heads up mobile at Digital Agency LBi in London, and his colleague Lorenzo Wood (@lorenzowood), CTO at LBi. If you hadn't heard of LBi, they recently worked on the Sony Mobile rebranding and delivered a fully responsive brand homepage at sonymobile.com.
After a recent conference in Paris, I got the chance to pose the same questions to Julia Beizer (@juliabeizer), head of mobile at Washington Post. Beizer's team has been working on some responsive web design (or RWD) projects, and just recently launched this participatory site for Obama's 2013 Inauguration event. During our chat in Paris, she broke down the differences in terms of breakpoints.
The simplified explanation is that breakpoints are used to specify when a site layout will change when the browser window reaches certain dimensions.
Looking at a site that uses responsive design, as you drag the corner of your browser window to resize it, you will see the site shrink until it reaches a breakpoint, and then the layout of the site will reload differently to better suit that smaller screen size and new browser dimensions. Give it a try with Bostonglobe.com, can you spot how many breakpoints there are?
With adaptive design, the layout for a specific device type will be loaded right off the bat, so there's less of the fluid transitioning between breakpoints, as the right version should already be displayed for whatever device you're accessing the site from. You can test it by going to CNET UK from a few different devices if you have them handy.
Generally, publishers will design different layouts for their site for a minimum of three types of devices (mobile, tablet and desktop). However, as I mentioned above, the team behind the Boston Globe responsive website defined 6 breakpoints that correspond to "smart phones, dumb phones, tablets, laptops, PCs, etc".
Four versions of Boston Globe's responsive design site. Credit: mediaqueri.es
Ethan Marcotte (@beep), who first coined the term "responsive design" in a 2010 article on A List Apart, and also worked on the Boston Globe responsive site, describes changes in layouts according to breakpoints:
In short, we're moving from a three-column layout to a two-column layout when the viewport's width falls below 400px, making the images more prominent... Now our images are working beautifully at both ends of the resolution spectrum, optimizing their layout to changes in window widths and device resolution alike.
The Right Solution for Your Mobile Strategy
Like all tech decisions facing publishers, the solution to the responsive vs. adaptive dilemma depends largely on the strategy, and the decision should be made with the publisher's specific outcomes in mind. The CTO of dotMobi, Ronan Cremin (@xbs), did a nice job of categorizing the two types of outcomes publishers are often seeking with their mobile web strategies:
- trying to make an existing website work passably well on mobile devices or,
- building a mobile experience from the ground up.
For the first lot, Cremin suggests responsive design, and for those looking to harness the extra capabilities mobile devices offer (geolocation, touch gestures, compass, accelerometer, etc) to build a mobile-first experience, he suggests adaptive design.
In my conversation with Elia at LBi, he highlighted that responsive is not always the answer for publishers. He suggested that the best solution can be a combination of both methods:
Detect the device, "adapt" the page on the server and send down the smallest amount of code you can get away with, while allowing the page/code to "respond" to the small variations in devices -- i.e., do both!
Baptiste Benezet (@Ba_B), CEO at French mobile development firm Applidium, had another word of advice about the responsive vs. adaptive question. After a panel discussion where major French media houses discussed the future of mobile news, Benezet told me that before even getting into the "front end" design challenge, "publishers need to sort out their 'back end' content management systems, and moreover their API, to give them a standard way to work with their content." Only with a strong CMS and API can publishers actually arrange their content into multiple layouts for optimal consumption across a range of devices.
The Bottom Line
If a publisher chooses to use responsive design, they should have a strategy of designing for mobile constraints, ie. not assuming a site will by default be accessed from a desktop computer, and progressively enhance up to the optimal experience. As Elia suggests, "load small/mobile images first then replace with larger images designed for broadband/desktop experience." It's like coding for the lowest common denominator: a small screen and a slow internet connection.
If a publisher chooses adaptive design, it can allow them to go further with optimizing the mobile and tablet experience by taking advantage of the extra features these devices have to offer like accessing location and using touch gestures. Plus, serving the best version of a site to a user can cut down on loading times, further improving their experience. That would explain why, of the Alexa top 100 global sites, 82 percent use some form of server-side device detection to serve content on their main website entry point.
As Beizer put it in an email:
The larger point here is that, sure, there are technical differences between adaptive design, adaptive layout and responsive design. For publishers, the technical differences aren't really the point. The goal is ensuring content is optimized for our audiences no matter what device they're on. And that's why we're so excited about the possibilities with these approaches.
The definitions and distinctions I've provided above are meant to give you a basic understanding, they are by no means comprehensive, as this stuff gets much more complicated. If you'd like to dive deeper into the realm of responsive design, adaptive design, progressive enhancement, resolution independence and the like, here is some suggested reading: