Print design has the physical constraint of the canvas. The format is fixed. The situation is different on the web. We can’t know in advance exactly how someone will view our sites. We don’t have a fixed canvas. We need to create websites with the ability to adapt and respond.
Designing for the web means being open to the flexible nature of the web. We need to develop flexibly so our sites work well and look good across a range of devices and device characteristics. These are the ideas behind responsive design.
How To Build A Responsive site
Believe it or not we’ve already covered all the technical details for building responsive sites over the last few weeks. In order to create a responsive site we need to use:
- Flexible grids — which are based on relative measurements, ideally elastic sites that are relative to something internal to the design. We want to be developing from the inside out. Content out, not canvas in.
- Flexible images — that can adapt to our adapting layout. We want to create images that can resize as the layout resizes while still looking good.
- Media queries — to serve different presentation (and possibly different content) to different device, OS, browser, screen width, etc
The last few weeks we’ve gone over the details of each of the above and I’ll refer you back to those posts for the details. Even better would be to take a look at the work of Ethan Marcotte.
Ethan is the person responsible for responsive web design and my posts, including this one have relied heavily on his work and writing.
- Responsive Web Design
- Example Site for Responsive Design
- Fluid Grids
- Fluid Images
- A Book Apart, Responsive Web Design
I can’t recommend the links above enough, particularly the last link, Ethan’s new book on responsive web design. Seriously it’s $9 for a digital copy. If you want to learn responsive design spend the $9 and read the book.
With the technical details covered elsewhere I want to spend the rest of this post with some thoughts about responsive design including some ideas for developing a responsive workflow.
Thoughts About Responsive Design
I’m only beginning my exploration of responsive design. I can’t offer advice based on experience at the moment so I’ve been leaning on the advice of others, mostly Ethan. I would however like to share some thoughts as one beginning the exploration.
A couple of months ago when I began talking about different css layouts. I had listed some pros and cons of responsive layouts and later added:
However in the end it’s browser and object detection. If history is a teacher developers will push toward standards over detection and device makers will become more consistent in how they render websites.
At the time I was a little too focused on the media query part (perhaps I was just reaching for cons to balance the pros in that post). I’d like to amend my previous thoughts.
The problem in the past with browser detection was how complicated it was and that it didn’t always work. Media queries don’t have those same issues.
I wasn’t entirely sold on responsive design then. I am now. I can now clearly see it as the way forward.
The Way Forward
Mark Boulton recently posted that responsive design is s shift in how people design websites.
He suggested that designers are still working out the details and eventually something else will come along leading to another shift, but this is the current path forward.
I completely agree. This is where web design is currently heading and if you ignore responsive design you stand a good chance of being left behind and designing sites that look out of date.
Is One HTML Document Enough?
In his book Ethan mentions that responsive design is serving one html document to countless browsers and devices to ensure the design is as portable as possible.
He also points out that not everyone agrees with this approach and their arguments mainly come down to 2 things.
- A device implies a context as different devices have different capabilities
- Visitor priorities and goals differ in different contexts
Because of the above some think serving different html documents to different devices is the better approach.
Both points above are important considerations, but they rest on assumptions that may or may not be true. Research suggests the most common use of mobile devices occurs in the home. The context probably isn’t as different as some might assume.
Viewing on a tablet likely doesn’t lead to significantly different goals and priorities than viewing in a browser, especially while leaning back on the couch. The context is probably more dependent on where a person is physically than the device used.
For some sites it will make sense to have a dedicated mobile version. For most it probably isn’t worth the extra effort and cost. Personally I think some of these changes in priority and context can be accounted for through responsive design.
I’m sure something will come along later that will be better, but I’m also sure this is the right path to walk right now. The technical details with improve and designers will find better ways to work with those details.
What might be even more important where responsive design is concerned is the thought process and workflow it inspires.
Developing a Responsive Workflow
In his book Ethan walks through what he considers a good responsive workflow and mentions the following.
- Identify breakpoints — Which devices are you designing for and what resolutions do they have?
- Prototyping — Design changes for device and resolution will be harder to show with comped images so move things to the browser sooner. Create a prototype and then refine it in the browser.
- Mobile first — Decide what’s most important for your audience and serve only what’s needed to the least capable devices instead of hiding things for that device.
- Progressive enhancement — – Scale your design up from the minimum instead of scaling it down from the maximum. Load content and code intelligently for each device and device characteristic
Identifying Breaking Points
Last week when discussing media queries I closed with a question about the breaking points in our designs. Where should we set those breaking points and how many should we set.
I don’t think there’s a single answer to either question. It will come down to the specifics of your design, audience, etc. However we can look at the sizes of the common devices people use to consider good values for our breakpoints.
- 320 px— smart phones in portrait mode
- 480 px — smart phones in landscape mode
- 600 px — smaller tablets like the Kindle (600 x 800) or Nook (600 x 1024)
- 768 px — tablet in portrait
- 1024 px — tablet in landscape and netbooks
- 1200 px — low end for widescreen displays
- 1600 px — widescreen displays
You wouldn’t set different media queries and css for each of the above, but you’d probably choose from the values above to set your own points of change.
Again how many and which you use really comes down to the specifics of your project and design.
In recent years there’s been input from the design and development community in regards to our general workflow for building sites. A big part of the workflow has usually been designing comps with pixel perfection in Photoshop, Fireworks, or similar. Many have begun to rethink that approach.
Remember we don’t have the constraint of the format to guide us. Tools used to design for the web need to be more flexible than their equivalents for print. You can’t see how a design responds in a single Photoshop comp.
Better is to take things to the browser sooner. Create a working prototype so you and clients can see how the design responds and keep iterating and refining.
That doesn’t mean we should ignore Photoshop or wireframing or anything else where we work solely in pixels. Instead it’s about moving to the browser as soon as possible.
The idea behind mobile first deserve its own post so understand what I’m saying here barely scratches the surface. The mobile first ideas come from Luke Wroblewski and below are two of his posts on the subject.
Above is a one of Luke’s presentations on mobile first. I’ve also included the PDF that goes with the presentation in the links below.
We’re trained to think browser on computer first and then remove or hide things for different devices. This is really the opposite approach we should take. We should start where things need to be more minimal.
Mobile first forces us to think about what absolutely needs to be included in a design and to serve them to the least capable devices. We should be scaling things up instead of reducing them down.
A natural next step from mobile first is progressive enhancement. Start with the minimum and build from there.
As part of this Ethan suggests our media queries should take on a slightly different form than how we’ve talked about them until now.
/* default styles */
@media screen and (min-width: 320px)
/* small screen */
@media screen and (min-width: 600px)
/* desktop */
@media screen and (min-width: 1024px)
/* wide screen */
@media screen and (min-width: 1200px)
Notice the change from max-width to min-width. Here we’re sending the least width the most necessary styles and from there building up as more can be included for wider screens.
We can also serve smaller devices smaller images and replace those images with larger versions as screen size increases. We might even choose to only add some content for wider screens and more capable devices.
Again much of this will come down to the specifics of your site and audience.
This overall approach is probably somewhat different than what most of you are used to. I know much of it is different for me. However it makes a lot of sense to approach web design this way and I’ve been slowly changing my own workflow.
Responsive design is something I think we all need to pay attention to. Mark Boulton is right. This is not a trend. It’s a shift in web design thinking.
Responsive design takes a number of best practices like elastic layouts and progressive enhancement and combines them into a new way to think about and build websites.
Once again the basics of responsive design come down to:
- flexible layouts
- flexible images
- media queries
None of the above is difficult. The hardest part will likely be changing your workflow and developing a responsive mindset.
I’m still learning to make these changes myself and I’m sure over time I’ll have more to say about everything we’ve been talking about these last few weeks.
Out of curiosity how many of you are currently building responsive sites or are looking to develop them? What have you found are their pros and cons? What have you found to be the easier and more difficult aspects of responsive design?
Download a free sample from my book, Design Fundamentals.