Insights into responsive design and development
- Jun 15th, 2013
- 1 Comment
Responsive is a major buzzword in the industry at the moment, with everyone saying that responsive design is the best way forward for websites, and even Google recommending it for SEO purposes. But I want to look at what building responsively actually means for developers, and how it has changed over time, to where it might go in the future.
The first responsive website that I ever built was a hideous collection of restrictive media queries, that only considered iPhone and iPad (it was probably more suited to the term adaptive rather than responsive). I shudder to think about it now, but that’s partly because the range of devices has exploded over the last few years, responsive really must be a one size fits all.
The first website I built at Yoyo was a responsive site for a company called cloudIQ, a tech company that build apps for businesses to manage their marketing. Almost by accident, we found a great way of managing the workflow. I worked with our creative director Jan to completely develop the site one page at a time, and finished each one before moving on. This approach meant:
This project taught me huge amounts about responsive design, but also got me thinking about the workflow. This is a tricky balancing act, as responsive design means there are far more considerations than with fixed width sites. For example, which devices should I use for testing? What screen sizes should I use in my media queries? These are questions that I’ve often asked myself whilst working on projects. The answers lie within two things, content and audience. What content am I trying to relay and what audience is it aimed at. Working this out first will improve your workflow because you’ll know how your content needs to behave.
Recently we’ve been busy rebuilding our company website for Yoyo Design, which will be going live soon. We have used this site for a number of different experiments with our workflow, in an effort to try and decipher which works best for us as an agency. A fellow developer and I have been working jointly on the project, enabling us to discuss ideas and work out the best way forward.
The first thing to do was to decide whether to go down the responsive or adaptive route. We built a prototype for each and then compared them on a variety of different devices, eventually settling for the responsive route. This was because responsive worked best for the content and layout that we had designed, and secondly for longevity. New devices and screen sizes are being introduced all the time, and as an agency we want to give our clients something that will work well across the widest cross section of devices possible.
A set of media queries were decided on at this point in the project, but interestingly the set I ended up with were very different. Once the content had been added it became apparent that it wasn’t always displaying perfectly on each device, landscape and portrait. More media queries were added to try and improve the appearance and usability of the site on each device we tested. These extra media queries greatly improved the site overall.
Images were a particular complexity in the Yoyo website because we have a variety of different image sizes and types throughout the site. I started experimenting with retina images and how we could test the browser, device and internet connection of the user’s device to decide which images to serve up. Looking at this demo: certainly made me decide that it is worthwhile to use retina. Another image issue that arose during the project was that some of the images were poking out of the grid on the designs, it worked well and improved the overall design of the pages. The simple solution would have been to move them back inside the grid, however, we didn’t want to compromise on the design, so we decide to proceed with a grid inside a grid. This allowed us greater flexibility and improved the overall look and feel of the site.
Working with a CMS (Content Management System) as well as a responsive site needs more consideration – we need to know what content will need to be editable. Images that are editable, for example, will need to appear in the foreground, as images set with the background property in CSS won’t be accessible to the CMS. It is also important to consider that with CMS driven sites the content will be ever changing, therefore it is important to test different content scenarios on different devices, to ensure your layout doesn’t break when media items or longer/shorter sections of text are added.
Those are just a few of the things I have learned as a graduate building my first responsive websites.
A few other tips that I have started to work by are:
I have found that when unsure it is best to do some research and build a demo first before spending hours trying to incorporate things into a project, just to have to strip it out again. If in doubt, test, test and test again!