Insights into responsive design and development

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:

• We could fine tune the design and the UX for each element of the site before our focus moved on to the next section.
• We could create the perfect menu, footer, contact form and of course the all-important call to actions, without our minds and ideas being clouded by the site as a whole.
• The client could review each page individually to ensure they were happy with it.
• Any changes to the overall design and build would be made to every page automatically as this happened at the beginning of the project rather than throughout.
• It also meant that the client was constantly involved with the whole process, and able to feedback to us throughout.

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.

I also used this project to experiment with responsive video for the first time. Video is a notoriously tricky thing to get right when building responsive sites and through doing research and experimentation a solution was developed for a homepage video carousel and also videos that will appear in blog posts. We used FitVids JQuery plugin to create the perfect fluid width video embeds throughout the site, and our JavaScript wizard will be creating a carousel of responsive videos.

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:

1. Don’t use responsive on every element of content just for the sake of it. For example if you have a 50 x 50 pixel image, there’s no need to shrink it down on smaller devices if it will fit perfectly anyway. Be driven by the content.
2. Experiment with different layouts on different devices to create the best overall result for each device. With mobile, there’s a temptation to always lay things one on top of the other, which in many of cases works great, but don’t be afraid to try something different.
3. Make landscape different to portrait. This rule stands for any device. There’s no point in users being able to turn the device around if it’s always the same. Consider how the content is best displayed on each and every screen.
4. Test on a variety of devices, and by variety I don’t mean an iPhone and a Samsung Galaxy S4. Consider older smartphones and consider different markets. Many developing countries primarily use mobile to access the Internet, if your site doesn’t work on an older/less powerful phone popular in these parts of the world you could be missing a massive market.
5. Consider page speed and weight. No one is going to thank you if they get a huge bill from their mobile carrier after visiting your site.
6. Don’t get stuck on a set of media queries and use the same ones on every website you build. Create a standard set, and then add any further ones you need as the website progresses.

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!