Responsive Summit
/65
I was at Responsive Summit yesterday, where we spent the day discussing the experiences we've had and challenges we've faced with responsive web design projects.
We discussed a lot of things during the day and I'm missing out a huge amount in this post. We had differing opinions on things too, these are just my take-away thoughts on some of the things we talked about.
"Responsive design is a fad"
The web has always been fluid by default, text inherently fills the width of the viewport. We added the widths. Now we have a huge range of devices and an even wider set of unknowns that extend further than just the dimensions of a screen. Things aren't magically going to go back to how they were, screens aren't going to be consistent sizes again, internet speeds will continue to vary wildly, as will the way we interact with devices.
It's a big challenge and mindset change, but things move fast, and it's our job to be able to respond to that. Echoing Mark Boulton's thoughts at the end of the day, I guess this does feel a lot like how the Web Standards movement did at the time. It's the disruption the industry needs to do things better.
Changing processes
Responsive design isn't as simple as adding a few media queries to a page. The first topic of the day was workflow and changing skill sets. The way in which we have largely been working for years has been a hack, inherited off print design. The designer opens up Photoshop (the clue for what it was built for is in the name). The first step is to define the width of the canvas. The designer sends the client a static mockup, a painting of how a website will look on a desktop screen. The client signs this off. Design ends and exactly the same mockup is sent to the developer. The developer builds the website exactly as the mockup looks, pixel for pixel. Then the big reveal. Classic waterfall process.
Copying and pasting this process for responsive design projects is like trying to hammer a square peg into a round hole. Now the designer needs to produce mockups at different widths, or the developer has to make lots of design decisions, but in the same budget. How do we present many different designs of the same site to the client, how do we communicate that process effectively, and how do we transition between different roles?
We're trying to control something that's messy.
Broader skillsets
The bleed between designer and developer skill sets and responsibilities needs to be bigger. Hire designers that can code. Hire developers that can design. Maybe even create a separate training budget for your designer that can only be used on development conferences, workshops and books, and vice versa to make sure they maintain T-shaped knowledge, which is useful for communicating ideas in a team.
Adapting roles
When I get sent a mockup to build, I have to fill in the gaps on things that the designer has missed. I don't always see this as a bad thing; designers can't account for every single possible situation, every possible error message, every screen width, nor should they. The design process shouldn't end at client sign off. Therefore, the design deliverables should communicate enough that the developer can make a good judgement. Design deliverables sent to a client often need to communicate different things as those sent to a developer, and that's something that should be considered.
That's what I love about front-end style guides, and being able to work alongside the designer as I'm building. A style guide is the design of a system, whereas mockups on their own only show how certain pages look in certain scenarios. Mockups may be useful for clients, not so much for developers.
Websites are systems rather than pages and as soon as we stop perceiving them as that, the better.
Designing in the browser vs design software
The tools we use aren't important, it's what we can produce with them. Our tools have limitations, but a skilled designer can use any piece software to create deliverables that are appropriate to the medium they're designing for.
Responsive design as an up-sell
There was a split in the room over whether responsive design should be considered an extra service or become part of the process. The first few times you work this way, it does add time to the project, but eventually, it becomes part of the process. I consider it like accessibility, which I don't sell to my clients as an extra, but I'd devote extra time to it if they needed it. I consider it as part of my job, just like testing in different browsers is part of my job. The real debate should be about how far you go to make the site responsive.
I don't know anyone who sells CSS as an up-sell now.
— Dan Mall
How do I sell it to the client?
My approach is to just do it because it's part of my workflow rather than an add-on. I've never been told "I don't want this to work on other devices" and I'd be surprised if I were ever asked that. Where you do have to adjust the budget and mindsets for it, often the client is understanding when you explain that building a site in this way means savings in the long term, and quick entry to new markets as new devices come out.
Responsive design is sustainable design.
Assumptions
It's tempting to make various assumptions when designing a responsive site, but assumptions are dangerous:
"Someone using a mobile device is on a slow connection."
Not necessarily if they're connected to wifi.
"Desktop users are on a fast internet connection."
What about the person using a 3G dongle?
"Mobile devices are small screens."
Have you ever used a tablet to browse the web and been served up a squished mobile version of the website? Or used something like Airplay to switch what's on your tablet to your TV screen?
And maybe in the next few months:
"People on mobiles with slow connections should be served compressed images."
If Apple come out with a retina display iPad, the user's expectation for image quality is going to be different. Don't just think about the devices we have now, think about the devices we will have in the future.
It can feel incredibly daunting. How can we cope with all these unknowns? I think we've got to accept the fact that we will never be able to control every experience exactly as we designed.
The responsive design movement is the catalyst this industry needed to change and improve the way we work. I'm excited about a future of more communication between designers and developers, agile rather than waterfall processes, and designing sustainably rather than for what works now.