- 07 Feb 2012
- 20 Comments
Over the past year or so we’ve been lucky enough to be asked by a number of exciting companies to undertake ‘Responsive’ redesigns.
The ‘Responsive’ approach (as advocated by the wonderful Ethan Marcotte) is one where a single CSS/HTML site adapts to the device on which it is being viewed, as opposed to a collection of separate sites that are designed with particular devices in mind.
The advantage of Responsive sites is that one codebase covers all devices, meaning that changes can be rolled out to an infinite number of devices by amending one set of code, and one set of assets (images, videos etc).
Device-specific sites, however, are often completely separate to their desktop equivalents, which can mean greatly increased ongoing costs to maintain your suite of sites.
Responsive sites run from a single codebase
Here at cx we regularly undertake detailed user testing on all sorts of tablets, smartphones and desktops, which provides us with insights that we can draw upon when making decisions during Responsive projects, however it is still a relatively new approach – one that presents unique challenges along the way.
Testing iPad usage with users
As the approach matures and starts to be recognised as a valid mainstream approach to maximising ROI, we thought we’d share some of our observations from being at the coalface.
Wireframes are no longer enough.
Responsive sites tend to be built around a number of ‘breakpoints’. The sites detect the browser width and deliver the most appropriate layout and content (via media queries – for more info see this article). This commonly results in at least 3 distinct layouts for desktop, tablet and mobile.
Traditional wireframes are very useful for establishing the initial, broad approach, but they fall down when it comes to filling in the gaps between breakpoints.
Developing HTML prototypes from the initial wireframes enables the team to cement their approach to the adapting layouts in the browser. HTML prototypes (with fully functional media queries) enable realtime responsive testing on the devices they are designed for, allowing rapid feedback and iteration based on informed decisions.
The addition of HTML prototypes may be an addition to your usual wireframing process, but they will help your team maximise the value of the wireframing/UX process.
Design your layout according to device type.
Our user testing on a variety of devices uncovered a surprisingly uniform pattern of behaviour. On smartphones, all the users we’ve tested viewed websites in portrait mode (upright). On tablets, however, all automatically held the device in landscape orientation.
This insight can be used to inform the wireframing and prototyping process and ensure that the site’s flow is optimised to the most common use case.
The 960 grid may not be the most efficient any more.
The 960px grid system has been used for years to design websites that work perfectly on fixed size desktop screens.
The Responsive approach, however, is all about designing for a multitude of screen sizes, and uses percentages to determine layout, which can prove to be a rather inefficient process when using a 960px grid (resulting in some crazy numbers).
More appropriate, and potentially much more efficient, are grids that adopt a more rounded, percentage-friendly approach, such Elliot Jay Stocks’ 1000px grid, and the 1140 CSS Grid.
A pragmatic approach to fluid layout.
Pragmatically fluid approaches can minimise development overhead
Fully ‘fluid’ Responsive sites reconfigure their layout and visual hierarchy in realtime as the user resizes their browser window.
Whilst this approach may be seen as technically impressive, it is usually at best an edge-case requirement for users, who are more likely to find unnecessary rejigging of content a confusing distraction.
That is not to say fluidity is completely inappropriate – indeed when designing the breakpoints for tablets and mobile devices it is a good idea to allow for a certain level of flexibility in layout to accommodate for the many differing screen sizes.
Retaining the use of Photoshop maximises the efficiency of the visual design workflow.
There have been a number of calls from members of the design community for designers to start working exclusively in the browser, designing on the fly with CSS/HTML and Javascript.
Whilst this is a nice idea, we have found that from a practical level it is much more efficient to begin the visual design process in Photoshop (and/or Illustrator), and move in-browser once a visual direction has been determined and the more intricate assets created.
In most cases we’ve found working in the browser from the outset to be considerably more time-consuming, and more restrictive, than working with Adobe’s suite of tools.
Thomson Sport - designing look & feel in Photoshop maximised efficiency
Time to get agile.
The Responsive approach to designing for multiple devices demands a certain level of experimentation, of trying out concepts in realtime, of iterating regularly – more so than the traditional fixed-width development process.
This iterative approach naturally lends itself more easily to an Agile process than a Waterfall one, which means some changes in the project management process are often necessary to allow for more collaborative ‘sprints’.
The need for buy-in.
“Embracing the Responsive design approach is like shifting from tables to CSS.”
— JAMES DRINKWATER, TUI
Media queries, the building blocks of Responsive design, demand a complete rethink of how CSS/HTML is put together, therefore a complete change of approach is needed.
If your development team is going to become a lean Responsive team, they will need to be completely sold on the benefits of it, which may mean an evangelical approach from the project leaders – providing insights where needed, encouraging ongoing experimentation and ensuring everybody is fully versed on the reasons why you are adopting the approach.
A new approach, with fresh challenges..
Whilst we have worked on a number of successful Responsive design projects now, we are aware that it is not appropriate for every situation. There are instances where dedicated mobile-specific sites or apps are the right option, especially where device functionality (cameras etc) are utilised, or where large amounts of content need to be navigated on the go (e.g. Twitter, Flickr etc).
And of course, whilst it is no doubt a cheaper alternative to a device-specific approach, the changes to your UX and development process do need to be factored in.
However our pragmatic approach to Responsive design has excited us about the possibilities of multi-device design, and we’ve a number of sites in development at the moment that we can’t wait to launch upon our clients’ customers.
It would be great to hear of your experiences, so please share in the comments section below.
Great article – it will be interesting to see the speed of uptake within the industry.
Great read, thought provoking.
My experiments with RWD at the moment are for an artist’s gallery – from hi res images which look good on the expansive screen real estate of a big Mac monitor, down to the humble(?) iPhone. The issue I’m hitting is adaptive images – this is not a simple problem to fix and has *lots* of ifs & buts!
May we live in interesting times ;)
Joel_Hughes
This is cool. I just wrapped on my responsive version of my portfolio site yesterday. Used foundation.zurb.com. Let me know what you think. http://blakecrosley.com
Cheers!
Most impressive! Well put and on the right track for sure.
Great stuff! I’ve shared them to my followers as well since it was quite enjoyable.
Really useful and great to have some experiences to back up the hypothetical discussions and eyecandy that have dominated discussions to date on RWD.
Just to say on the matter of grid frameworks it is worth noting that 960.gs does offer the ability to custom build your own fluid layouts as well as fixed layouts – see http://grids.heroku.com/
I’m a bit confused about what you mean by ‘pragmatically fluid’. Do you mean that individual elements have a fixed width (e.g. a sidebar) but that this sidebar itself drops down below the main content if the browser window gets narrower than a certain width? I always thought that was called ‘adaptive design’ and to be properly ‘responsive’ a site needed to be fully fluid, have flexible images, etc. I guess maybe the terminology is pretty blurred right now.
With regard to ‘fully fluid’ (RWD) approach, I agree that most users don’t resize their browser window while they’re using a site. But I think the main advantage of being fully fluid is that we don’t need to try and guess the common screen sizes of popular devices. For example, next year the most popular device might be a mini tablet with a width of 500 pixels, which might be somewhere between the ‘phone’ and ‘tablet’ classes of device you mention above.
On the other hand, I guess an adaptive (or ‘pragmatically fluid’) layout does get you a lot of the benefits with less headaches along the way. Just don’t let Jeremy Keith hear you recommending this ;)
Hi Ben,
By ‘pragmatically fluid’, I’m saying that the site should be fluid between certain points, rather at every single possible variation of browser window size.
Check out the http://www.sony.com/index.php site – you’ll notice that on the desktop view the layout adapts at key breakpoints, but isn’t ‘fluid’ at all until you get down to mobile size – whereby it reflows content to allow in variations of mobile viewports.
So the design allows for every screen size out there, but doesn’t reflow every element of content unless absolutely necessary.
Nice to see a weighed and pragmatic write up, definitely agree with everything covered. We still have a number of problems to solve with this approach (resultant page load for instance), but this will come with maturity.
Really useful read Chris, we passed it round the office to a quiet chorus of accepting “mmmm”s
I think you will find that long-term, the pragmatically fluid approach will be unsustainable (it kind of already is). Even today, there is no such thing as a common screen size (rather 6-10 common sizes…if something with that much variation can be seen as common) and although iPhone use is quite high high our clients regularly see over 300 distinct devices in their analytics reports. Android also enables users to dramatically change their viewport size (regardless of the documented screen size, or default viewport size set by the manufacturer).
While it’s tempting not to design for what’s perceived as in between sizes, a better approach is to pay special attention (and if need be add minor optimisations) for key viewport sizes (derived from market share data and analytics) but let the rest of the layout remain comfortably fluid so that users with (whatever is currently perceived as) unusual devices aren’t left needing to scroll horizontally or pinch/zoom to readjust a layout that doesn’t suit their device.
Thanks for your comments Stephanie,
I think, long-term, you’re right. As the approach matures, and as more Marquee redesigns such as the Boston Globe spread the gospel, there will hopefully be a standardisation of approach, a best-practice emerging that enables us to efficiently design fully fluid sites that we can maintain tight aesthetic control over.
The key challenge for us at the coalface at the moment is to find cost-effective ways of delivering responsive design within ever-tightening budgets and timescales. The pragmatically fluid approach I suggest will deliver a site that is suitable for the device it is viewed upon (always fitting comfortably within the viewport), if not necessarily designed especially for it.
It allows for tight control of graphically-rich UIs (which is a key requirement for many of our clients), which is more difficult (and therefore takes longer to develop) within a fully fluid framework.
Great article Chris
Hi – is anyone serving ads effectively into responsive. We’ve been designing this way for a year for sites not requiring ads, but any ad serving requirements mean we go responsive to tablet and then build specifically for mobile..
Is there a better way?
Totally agree with the whole fully fluid/pragmatically fluid argument. I prefer to go for pragmatically fluid. Coming up with numerous versions of your site just isn’t cost effective. Whereas deciding on a limited number of options, say desktop, tablet, smart-phone I think you’re onto a winner.
Good article.
As an interaction designer and frontend developer I’ve experienced first hand how important it is to have some knowledge about interaction as a developer and some knowledge about developing as a designer. I think this is a key when it comes to creating responsive websites in an agile work environment.
Anyway, great article and the only thing I’m missing is the mention of Adobe Fireworks. That piece of software is a lot better equipped to design for the web than Photoshop or Illustrator.
Also, having graduated on this subject, there’s a lot more to responsive design than meets the eye … Still, I found this article a nice read.
I think it’s a good point that there are still key advantages to keeping Photoshop in the workflow. That sometimes gets lost in the enthusiasm for moving the entire process into the browser.
Btw, my solution to the inadequacy of the 960 grid was to build a set of Photoshop grids for different devices. With these you can kick off the design process at any level (mobile, tablet, desktop) and then handle the other contexts responsively once you get into the browser. Here’s the link for anyone interested:
http://www.ravelrumba.com/blog/photoshop-grid-templates/
Nice article! Responsive design is evolving at a surprisingly fast rate. It kind of makes current websites that don’t have it obsolete.
Another responsive website for anyone interested: http://newevolutiondesigns.com
Great piece, but I think the view of wireframes is informed by those not meeting the demands of the situation. Wireframes should be just as adequate in architecting fluid and responsive designs just as they have for simple device specific sites. Wireframes should be mapping out those breakpoints and the three or more different templates for each screen.
One of the challenges with rwd is to actually pitch it to clients. I totally agree with using an agile aproach for these projects—but it takes some guts and confidence from the client to buy something that are “becoming”. Especially on a large budget. How do you communicate your solution to the clients, are they ok with not knowing exactly how things turns out? Thanks for sharing!
Leave a comment