From the start, we wanted the new site design to be responsive. It was a no-brainer for us as a busy team to want to maintain one site and one set of content and not have a separate mobile site, as we had done previously. It is also a better experience for the user who doesn’t have to choose to go to a separate mobile site (or is compelled to).

We started thinking about responsive well before the front end build. Having an awareness that your expansive ‘desktop’ view is going to be linearised makes you think very carefully about what content goes on each page and its relative priority. This is time consuming but it’s good discipline in getting you into the responsive mindset.

Our approach was to wireframe up a ‘full-width’ view (960px)  and a narrow, linear view of each page template. The transition between these two views would then be fluid, rather than having specific break points dictated by currently popular devices (a hiding to nothing, given the volatility of the mobile market). However, we still wanted the site to look impeccable on currently popular devices, so it was a tough design challenge. These transition states of course couldn’t be wireframed and so the coders worked closely with the designers to ensure that the design remained intact throughout.

Responsive does throw up some interesting challenges though. We didn’t want text to be fluid, or to minimise it as far as possible, as there are clear UX recommendations about optimum text size and column width. Good readability is a major design aim and we don’t want to compromise it.

Fluid images are another interesting area. If we’d had the time, we’d have liked to have built a module for Drupal that allowed you to editorially control the focal point of images, so that as images were rescaled for smaller viewports, the meaning/spirit of the image was preserved. One for the future maybe. For now, the images will just scale in their entirety.

We did toy with the idea of a ‘super wide’ view for certain types of content, such as lengthy reports that need in-page navigation. Responsive is often thought about as scaling down towards small viewports but of course there is no reason why it can’t scale up too, to take advantage of retina displays and large monitors. In the end, we didn’t end up doing this but it’s one to keep in mind for later as I do think there is a use case (and I’d be interested in hearing about others who have done this).

Another thing we considered but didn’t end up doing is giving users the choice of toggling between a responsive and the full ‘desktop’ view. On balance, we didn’t feel it was worth it, as we aren’t hiding any content or functionality as the view narrows and linearises. But we are imposing a view on users nonetheless – and this might not be what they want. Again, grateful for any feedback on this when the site is out in the wild.

Responsive certainly adds length and complexity to the design and build. I’m sure this will change as the approach matures but for now it shouldn’t be underestimated by frazzled project managers with tough deadlines. From the client side, we also found that it increased the length of the testing phase, as we needed to test the site on multiple browsers on multiple devices, in portrait and landscape etc. It was fairly exhausting.

(Big shout out to Stu C, our responsive guru on this build. Think you’ve done a mighty fine job, sir)