Responsive Summit

Last Thursday, I popped over to London and met with a small group of folks to chat about the various tools, techniques, problems, and solutions surrounding the subject of responsive web design; a day we semi-jokingly referred to as ‘Responsive Summit’. As soon as we announced it, the hashtag exploded with all sorts of idiotic snark, but I’ll get to that later. For now, I want to discuss the day itself and some of its outcomes.

Firstly, I should talk about its inception. The previous week, Chris Armstrong and I had a Skype chat to discuss our own approaches to responsive web design. It was a productive talk and afterwards I tweeted that I had ‘just had a very cool chat with @armstrong, trying to work out the ideal responsive web design workflow. Good times.’ Our mutual friend Josh Brewer — over in England on Twitter-related business — replied: ‘We should chat. Been having similar conversations of late.’ Then Alex Morris made the suggestion of a get-together: ‘A big group powwow would be so helpful for all of us.’ The rest, as they say, is history, and — thanks to the efforts of Martin Beeby at Microsoft and a bunch of people on Twitter who expressed interest in participating in such a discussion — a week later eighteen of us were sitting around a room at Microsoft HQ in London, with five more joining in via Skype.

I should preface my notes that admitting I only noted down subjects that were of particular interest to me and I thoroughly recommend you read the blog posts written by the other people who were there on the day; there’s a list of them all on Lanyrd.

Please also be aware that none of this is being presented as conclusive. It was never the intention for us to sit down in one day and then come up with a set of rules to dictate to the rest of the world. To think that so many snarky comments assumed we would — or could — even do such a thing is ridiculous. Think of the day’s outcomes as a starting point; an opener to a much larger and much more involved conversation.

Workflow

• Designing (in Photoshop or Fireworks) every possible breakpoint for a website is impossible and a waste of time. We should focus more on designing style guides and thinking of those as systems that would help guide the designer, the developer, and the designer-developer without needing literal depictions of every stage in a design. ‘Keyframes, not wireframes,’ said Cennyd.
• Dan Mall noted that clients bring expectations and responsive design can pose surprises. It’s up to us to set those expectations.
• Mark Boulton suggested that the idea of the designer presenting an idea as some sort of ‘grand reveal’ is damaging — a good client should be happy with the mess we make along the way (because the process is inherently messy) and we should help educate them by explaining our processes before anything starts.

Layout

• I asked if our enthusiasm to move to fluid layouts has actually clouded our judgment to a degree and resulted in layouts breaking when they become too wide? What about optimal measures? What about massive images? I say we shouldn’t be afraid of using max-width where appropriate, although I think I’ll expand on my thoughts for pragmatic web design in another post.
• Mobile-first doesn’t always work. I suggested that it’s not just because of different contexts and different users, but also because of the type of design: if the mobile version only has a couple of changes from the desktop view, it makes sense to design the desktop version first and work back from there, which is exactly what we did with Belong. Again, I’ll probably follow this up with a separate post.
• Not enough is said about the mistakes we make. As an industry, we should not only be proposing conclusions, but also admitting to the scenarios where we’ve had to go back on something that just didn’t work, like Mat Marquis did in his recent article for A List Apart.

Sensors

This is not really related to sensors per se, but came up during that section:

• Using display:none is harmful, because if referring to an image, that image will still be downloaded by the browser. We need a new method to combat this; perhaps something like load:none for when browsers really shouldn’t load content at all.

Images

Responsive images is a big area of interest to me and it’s also the area where I’ve encountered the most problematic parts of the responsive web design equation. You can read about some of that in my last post, ‘Better Background Images for Responsive Web Design’, and I’ll be writing a lot more about it in the near future.

• I suggested that mobile shouldn’t always mean lo-res. Consider the iPhone’s Retina Display: you don’t necessarily want to load lo-res images if the phone has a higher pixel density. (We’re going to see the Retina Display become an even bigger consideration once the iPad 3 comes out and even more so if the rumoured new MacBook Pros support it. Does that mean all of our images on the web are suddenly going to look awful? Perhaps so, although again that’s another post.)
• We spoke a lot about the inline img element, but what about background images, too? Well, they’re actually in a better position: it’s okay to use media queries to selectively load different background images, as the images aren’t loaded until needed. (I must admit that I wasn’t aware of this!)
• Everyone agreed that the proposed picture element felt like the most sensible way forward as a replacement for img, as it follows the same source-selecting patterns as the audio and video elements.
• Scott Jehl has already created a JS-based polyfill for picture. Nice one!
• However, in spite of the unanimous enthusiasm for picture, we wondered if the best possible solution might actually lie with a new file format, rather than as a problem for HTML and CSS? Getting a new format approved and supported might sound like a pipe dream, but consider .WOFF: it happened very quickly because it’s effectively a wrapper around an existing file format. Could that be the answer?
• In terms of what can we do, right now, Josh Emerson’s solution could very well be the best: a lo-res image is loaded by the img element’s src by default, then, if it’s detected that the browser can support a wider image, a hi-res one is loaded in its place using Javscript. The fallback, therefore, is always the smaller file.

When I get a spare moment (ha ha), I’ll be implementing Josh’s method on this site. Jeremy has written about its benefits, too.

A sort of conclusion

As I said at the beginning, there were no hard conclusions to come out of the event, nor were there intended to be. This is the start of something much bigger: a discussion that will, in its next stage, move to more localised ‘summits’ across the globe. The immediate goal for those of us who were there is to respond to all the questions we got on the day via Twitter and blog posts, which Josh has compiled into one Google document. Hopefully that alone should illustrate that our little gathering was for the benefit of the community, not ourselves.

[Photo by Chris Armstrong.]