The Responsive Process

Warning: file_get_contents(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/ on line 11

Warning: file_get_contents( failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known in /var/www/ on line 11

I was fortunate enough to be at the Responsive Summit last week. Unfortunately many of those who weren’t there responded to this very negatively on Twitter and described the event as elitist. Suffice it to say, I understand where you are coming from, but it just wouldn’t have been possible to have everyone around one table. I think Josh Brewer did an excellent job channeling the questions that were asked from the wider community and submitted on the responsive summit website.

So what knowledge did I gain from this day? We discussed every detail of what it means to create a responsive website. We even discussed future tools for designing websites which respond to their context and new file formats for images which could responsively enhance themselves. I’m really excited about the future of the web, but how can we improve our work using only the tools available today?

A Responsive Workflow

Within a minute of the topic of workflow being brought up, Cennydd put it to rest with a single word; Agile.

He’s right you know. The best way to create a responsive website is to have responsive teams. The more that everyone within the team knows about the product and the more they know about each other, the greater the outcome.

I think theres a basic assumption that development follows from design. A designer produces a mockup of the entire site in Fireworks and hands it over to the developer, who codes it up and turns it into a website. This process is not ideal for a static website which isn’t responsive. With responsive websites and dynamic content it just falls apart. Design and development must feed into one another and be given equal importance.

One of the things I love about working at Clearleft, is the integration of design and front end development. Physically, we sit close to each other, often side by side. At several points in the day I’ll go and chat with those I’m working with to discuss various details of the project. Where possible, all people who will be working on a project will be involved from the start. In future I will propose that we get into code on day one. I want to create rough and ready prototypes of the design even whilst it is still evolving. So that we can get an idea of how the site will respond and alter the designs to optimise the experience.

One question raised was at which point should the client be involved in the responsive process, and how do you explain to them that their site won’t always look the same?

If clients only see flat images of their website, there is a danger that they are surprised by the outcome when seen in a browser. In addition to showing clients flattened images, the client should be immersed in the process.

I like the idea of asking the client to sort the content on a page into a hierarchy list, with those items which are most important appearing at the top of the list. It’s a simple task, one which any client could easily perform. This hierarchy list can become the DOM and in turn can inform the design. Knowing which items should have more presence will be hugely important on smaller screens where a certain degree of linearisation is bound to occur. On larger screens, important items could appear at the top center, with less important items floated either side. This simple start point may just take all the pain away from reflowing content as a site responds to available space.

Often, clients find it hard to grasp the concept of responsive design, indeed it makes my brain hurt some days. Instead of trying to explain the concept of responsive design, it may be more important to talk about sustainable design. Cennydd made the point that sustainability is something that most businesses already concern themselves with. A website which responds to context is far more sustainable than one which offers a non-optimal experience on the majority of devices and where the design only considers desktops and laptops.

How Should We Respond?

Its been assumed that when creating a responsive website, designing for the mobile first is the best solution. Generally I agree with this principal, and when I’ve adopted it in the past it’s resulted in great products. But I’m worried about the impact that this strategy is having. Responsive websites have a tendency to be optimised for certain devices, and leave others feeling like an afterthought. This is the difficulty with responsive design - creating a single site that sings for all people and for all contexts. It’s inevitable that one device is going to get preferential treatment, but by adopting an iterative design process which gives equal consideration to multiple different devices and contexts we can improve the outcome.

So where do we start if not mobile first? I think we should start with concept first, and then transform that loose concept into a design targeting different devices in any order that feels right for the given project. Keep your concept simple, and always keep different contexts in mind when turning concept into design. In the end, your site has to be optimised for certain people trying to achieve certain tasks in certain contexts. Go with the most likely scenario and iterate from there, removing all the sharp edges in your design.

What Should We Respond To?

Most of the time, media queries are used to adjust the layout of a site at different widths. With sites that scroll vertically its clear to see why this is important. I’d say that responding to width is the baseline for responsive design. But what else should we respond to?

In many cases its desirable to respond to height as well as width. You may want a more compact header for screens with very little height in order to reveal more content.

In general we assume that small screen devices have touch screens and so ensure touch areas are large enough to be targeted. This is a bad assumption to make, but without a media query for touch, is an assumption that we have to make. Perhaps using javascript we could improve our initial assumption and override the media query if necessary.

We discussed many other sensors that we could respond to such as connection speed, ambient light, ambient noise and speed of movement. In some very niche situations these may be desirable, but I’m worried that by making assumptions we could do more damage than good. If we are going to respond to a plethora of environmental factors, we should be very aware of the assumptions we are making.

Responsive Images

One of the sticking points of responsive web design has been loading the correct image for a screen size. One solution prevents images from downloading until the screen size has been detected using javascript. Unfortunately this solution can be unreliable and is difficult to set up. I’ve been using a technique where a small image is always downloaded. If needed, a large image is downloaded in the background, and replaces the small image only once it’s fully downloaded. This results in a faster perceived page load speed, but a slower actual speed. I’m happy with this solution as I care more about perceived speed than actual speed.

I’ve called this technique Responsive Enhance. You can see a demo of this technique and try it out for yourself on GitHub.

Vector images automatically lend themselves to responsive design, as they are resolution independent. Paul Lloyd is using SVG icons throughout his site,, which looks great when you zoom in on an iOS device. There are some issues relating to browser support of SVG files, but it’s definitely something to keep an eye on for the future.

I had a crazy idea for a future image format that progressively enhances the size of an image as it downloads. So the first part of the file download would result in a very small image, but as the file continues downloading, its dimensions would increase. Browsers could continuing downloading the image until the dimensions of the image file match the dimensions of the image in context. Using HTTP 1.1, the browser could continue downloading the image from part way through if the browser dimensions were to change and a higher resolution version of the image was required. This solution may be a little far fetched, but I think this would solve the problem of responsive images once and for all.

Update: Jason Grigsby informs me that a JPEG 2000 format image has been designed to do just this, but support for this format is still poor. Apparently Internet Explorer 10 will have support for the format, so let’s see what the future holds.

Is Responsive Design Always Appropriate?

I see responsive design as raising the bar for website design. A poorly made responsive website can offer a worse experience than one that doesn’t respond to context at all, but that’s not a reason for giving up. We should strive to optimise the experience for everyone, in every context.

For some web products, a version of the site specifically developed for the mobile may be desirable. Whether a web app or a native app, I believe this mobile version of the site should be an addition to the responsive version, not an alternative to the desktop version. Unless your mobile app does everything your website does, people are going to visit your desktop site on their mobiles. If it isn’t responsive, that experience is going to be sub-optimal.

Lanyrd is one example of this approach. Lanyrd offers a responsive site for all users, and a mobile version for use on the go.

The Responsive Summit

I had a brilliant time at the Responsive Summit. Instead of working on these difficult problems in isolation we had the opportunity to discuss our different approaches and discover solutions that others had learnt the hard way.

I didn’t get a chance to note everything we discussed in this post but I look forward to reading what other people took home from that meet up. I’ve heard mumblings of further responsive summits, and I welcome those, and other summits, which aim to further our knowledge and understanding of the web at large.

Notice: Array to string conversion in /var/www/ on line 22

Fatal error: Uncaught Error: Function name must be a string in /var/www/ Stack trace: #0 /var/www/ tags(Object(page)) #1 /var/www/ require('/var/www/joshem...') #2 /var/www/ tpl::loadFile('/var/www/joshem...', Array, true) #3 /var/www/ tpl::load('post', Array, true) #4 /var/www/ site->load() #5 /var/www/ require_once('/var/www/joshem...') #6 {main} thrown in /var/www/ on line 22