30 Jul Responsive design isn’t right for your publication
Responsive design often comes up in my discussions with other publishers. By enabling one website design to perform on screens of multiple sizes, it holds a lot of attraction for publishers.
With responsively designed sites, publishers can code one website which works on iPhones, iPads and desktops and their Android flavours. When there’s big wide screens, the site fills up much of this space with multiple columns.
When viewed on a mobile device, the site ‘responds’ and contracts to adjust to the smaller viewing area. (Actually, the design process should really start-off on a mobile device and then ‘respond’ up for large screen – but that’s another blog post.)
So within the code of the page, various CSS rules adjust the page and its assets, moving elements about and hiding sections depending on the screen size of the requesting browser. The CSS does a lot of heavy lifting to make sure the page renders appropriately for the given screen.
It immediately appeals, doesn’t it?
But I don’t believe responsive design is the right way to go for publishers. In fact, I’ll be firmer: if you’re an online publisher, then you should not use responsive design.
Providing a great experience to people using small devices (e.g. smartphones) is critically important as more and more content is consumed this way. Over half the audience on our sports site, The Roar, is now from mobile.
But as a publisher, the trick isn’t in simply repurposing your content for viewing on a smaller device. You must be thinking of providing different content.
On The Roar, we elevate stories and data that people on mobile phones want.
So our live blogs don’t show the preview text, for instance, which is less likely to be read when out and about. Instead we lift to the top of the site scores and live information. We don’t show the Twitter stream and other elements.
It’s quite a different experience from our desktop view, but it’s appropriate for the handset.
In short, we treat the mobile site as a different property. Which is what it is.
Responsive design doesn’t let you do this. Yes, the page will look different depending on your device, but it’s still the same content.
Second, what works on a desktop (big CSS, many JS files, lots of images, various ad formats) does not work on a mobile device.
With mobile devices, the goal is tailored content for the handset, serious speed, and also acknowledging the different needs for this user type. Ideally with an msite, you want a single CSS and JS file each. If you were ninja, you’d do away with a CSS file altogether, instead using inline styles and asynchronous JS which loads the below the fold content after the initial page render…now I’d love to have a crack at coding that sort of site!
On our msites, we don’t load many of the external libraries or features that we do on our desktop. There’s a small cost in functionality (though in my years of publishing I’ve yet to find a ‘feature’ which has significantly improved our page impressions per session – Outbrain being perhaps the only exception). But the benefit is speed for the end user. And if you get this right, you’ll see rivers of audiences flowing to your mobile offering.
So our msites are stripped right back for speed and they’re tailored for the handset. You simply can’t do this on a responsively designed site.
Third, as a publisher the key thing to get right is advertising placement. This is your inventory. I’ve seen responsive sites which lose certain ad units as they compress. What would happen if supermarkets lost shelves depending on the size of the person. It’s crazy.
Mobile advertising is also very different to desktop; you often want different ad tags and servers. Again, not easily done in responsive design.
I’m sure there are some design and development geniuses out there who can counter each of the points above with crafty CSS and JS code. So the final point is the key one: responsive design increases development and testing costs and adds risk to the business.
With our sites, we build and test a desktop version, and we build and test a mobile version.
On the mobile version, it’s actually a separate theme which inherits the desktop view unless we’ve coded a specific mobile template. So we can iteratively build out our mobile presence, putting resources only to the pages or functionality that are being used on the mobile handset.
This approach means our templates are super simple to code and test. We can easily bring in new developers as needed as the code is simple. The two sites are also decoupled; it’s easy for us to change a mobile page without re-testing the desktop version (and vice-versa).
Dedicated sites mean a simple build for mobile; it’s very easy to get right and has low risk for the business.
The is not the case with responsive.
While you don’t need to code separate sites, you have coupled two products. In IT, a golden premise is loose-coupling and now as a publisher you’ll suffer the pain that goes with breaking this rule! CSS rules can be highly complex, the testing is significant and ongoing, and developers who can elegantly maintain such complexity are rare.
Instead of buying a car and a bike, you’ve built a hybrid which purports to serve both needs but in doing so has many other costs.
The best proof of this is to look at a few responsive sites on your phone. Try going to the Newcastle Herald or even Wired’s new site. At best, it’s a painfully slow experience, at worse it’s a dog’s breakfast.
Don’t get me wrong, there are many instances where you should use a responsive design.
This corporate site, for example, is responsive. If I were a restaurant, I’d want to use responsive. It makes sense for these sites to do it this way, especially when there are so many good, cheap themes that already work responsively out of the box.
But it’s not the right approach for a publisher running a business from their content and audience.
So in summary, our focus is on great msites, which are simple to code, fast to use, low-risk, and tailored to the needs of someone with a small screen.