How to Create a Responsive, Retina-ready Website

My team and I at Dallas Theological Seminary just finished putting together a new site that has both a responsive layout and Retina graphics, and I thought it would be worth documenting the decisions we made along the way and some of the tools we used.
We are a pretty small team (we hired the awesome Chris Merritt to do the design and our 1.5 person team [including the awesome Michael Jordan] at DTS did the coding) and had a very tight window (2.5 months) and fairly large site (700+ pages and 2000+ videos and blog posts), so that led us to make some strategic decisions (i.e. compromises) to get it done.

Responsive Layout Plan

In the past we had a separate mobile site (mobile.dts.edu) and I wanted to move to a single site with a responsive layout. We surveyed a lot of responsive sites and found quite a few approaches and ways we could go with it.

Some Great Options

Some have several very different layouts for each of the following: (1) desktop, (2) portrait tablet, and (3) mobile phones. A good example of this is www.BarackObama.com which rearranges its content for each size. Obama’s site is an amazing achievement, but from my perspective there are two main issues. First, it requires an incredible amount of work and time which we didn’t. Second, I personally find that some sites are so different in each layout that its hard to remember or guess where anything will be. For example, in Obama’s case, the big three buttons under the header such as “Get the Facts” are missing in the tablet layout and the “Donate” button gets moved to a more prominent spot.

Other sites use a fluid grid to handle both desktop and tablet and then when the screen is small enough (like a phone), the layout collapses. A good example of this is www.marshill.com. I like this simpler and more straightforward approach, but a fluid grid layout wouldn’t really fit with what we wanted to do design wise on many of our subpages.

Our Modified Approach

About 5% of our users are on tablets and 5% on mobile phones, and it seems that tablet users seem pretty adept at pinching and zooming. This lead us to a pretty simple approach: (1) a desktop/tablet site, (2) a mobile phone site where our grid collapses (see above).
While changing responsive layouts for mobile devices gets a lot of attention, we also wanted to take into account different desktop sizes. This lead us to create a kind of “bleed” that allows the site to look good on older 1024×768 monitors, traditional 1440×900 laptops, and much larger screens. For our  90% desktop users, we now have a site that is “responsive” to their screen sizes without actually modifying the structural layout and placement of content.

Retina (pixel-density: 2.0) Graphics

Right now there are only three main devices that have “Retina” graphics (iPhone4+, MacBook Retina, and iPad 3), but I’m betting that the clones will be arriving very soon and over the life of this site Retina graphics will become an important distinctive, so I wanted to plan ahead to make things look good now and in the future.

Logos and arrows as SVG

Anywhere we have a graphic that’s not a picture (logo, arrow, symbol, etc.) I used SVG (with a fallback PNG). If you go to our site, you’ll see SVGs in our logo, the search icon, and even the social media icons in the footer (roll over the Apple logo for a fun surprise). On a normal computer, the SVG and PNG don’t really look much different, but the difference on an iPhone or MacBook Retina is quite noticeable.

To create the SVGs, I’ve been using Fireworks and Illustrator together. Illustrator can natively work with SVGs, but I couldn’t find a good way to work in pixels to produce the fallback PNGs I wanted for IE8. Fireworks is much better in my opinion for this kind of thing, but it doesn’t have native SVG support (seriously, Adobe?). Here’s the workflow I came up with:

1. Use Fireworks to create an icon and save as a Fireworks PNG which retains all vector data (myicon.fw.png). Note: Sometimes I made simple vectors like arrows myself, but I also used some EPS and AI files or the SVGs on www.thenounproject.com and elsewhere. The trick is that you have to open many of these in Illustrator, select the vectors you want, then copy them into Fireworks. Yuck, but it works.
2. Save a flattened PNG for older browsers that don’t support SVG (myicon.png). Make sure you keep this separate from the original Fireworks file (myicon.fw.png) so you can work with the vector data later.
3. Fireworks can’t natively save in SVG, so I used this amazing “Export SVG” script which does everything you need to create (myicon.svg). So far, I haven’t run into any problems with my images.
4. I used the SVG/PNG combo as background images and relied on a class on the <html> tag to tell me which one I needed. I initially was going to use SVG detection in Moderizr, but I went ahead with the HTML5 Boilerplate’s approach of using IE’s conditional comments since I didn’t want to wait until JavaScript fired and possibly download twice. So I ended up with CSS like this:

/* SVG for modern browsers */
.logo {
   background-image:url('myicon.svg');
}
/* applied with IE conditional tags */
.lt-ie9 .logo {
   background-image:url('myicon.png');
}

Pictures with HTML5-ish Markup and JavaScript

The W3C hasn’t quite come to a consensus on a new <picture> element and how the <source> elements should work, so right now you have to roll your own or choose a library. Here was my criteria: (1) Support everyone with a client side approach (no server-side logic), (2) Don’t force Retina users to download images twice (like Apple.com does!), (3) Distinguish between Retina devices with large screens (MacBooks and iPad 3) from those with small screens (iPhones 4).
I decided to go with PictureFill.js by Scott Jehl and use the version that employs <div>s with data-* attributes and a <noscript> tag. On the the backend I created a simple function (in my case it’s in C#) that renders the markup (like <% WriteDoubleImage(“image.jpg”,”image@2x.jpg”) %>), so that I can switch to something like Wilto’s fork that uses <picture> elements or another tool later on when/if browsers start using it. I’m currently only using it for in-page images (not backgrounds) on some key areas of the site, but I hope to add more soon.

<!-- Scott Jehl's markup -->
<div data-picture data-alt="Alt text">
    <div data-src="image.jpg"></div>
    <div data-src="image@2x.jpg" data-media="(-webkit-min-device-pixel-ratio: 2.0)"></div>
    <noscript><img src="small.jpg" alt="Alt text"></noscript>
</div>

<!-- proposed W3C markup -->
<picture alt="Alt text">
    <source src="image.jpg 1x, image@2x.jpg 2x" />
    <img src="image.jpg" alt="Alt text">
</div>

On our homepage, the video thumbnails have a Retina (double-pixel) image for Retina devices and a normal image for everyone else. But the hero rotator only sends Retina graphics to large displays (iPads 3 and MacBook Retina) and sends normal graphics to non-Retina machines and Retina iPhones. On the desktop the hero graphic is 500px wide (1000px on a Retina desktop), but on mobile it’s only 120px (240px Retina), so the mobile Retina only needs the original 500px image to look good. Here’s one of the video thumbnails:

For the Rotator, we also split the image into a JPG and PNG, so that the PNG is just the little sliver that pops above the rotator into the area above (see the top of Andy Crouch‘s head in the first image of this post). If I had made it one PNG it might be 300KB, but the JPG is only 40KB plus a 10K PNG, so this split approach vastly reduces the filesize. Finally, we made the move to Amazon S3 to better handle all the large Retina files.
Here’s the entire site on a Retina screen (click for 4MB file)

Room for Improvement, Abandoning Media Queries?

There are still some areas of the site we’d like to go back and add double-pixel images or SVG, and there are a few places where the mobile layout could be tightened up a bit. But the biggest consideration I have going forward is possibly abandoning media queries so that phone users can see the desktop site if they want to.
Here’s how responsive CSS works today (using a desktop first approach):

#container {
    width: 1024px;
}
@media only screen and (max-width: 480px) {
    #container {
        width: auto;
    }
}

But if users hit your site with a phone looking for something that they remember seeing when on a desktop, they have no way of making their phone display the desktop version. One way to solve this is to selectively insert different stylesheets like using something like Nathan Smith’s adapt.js. This way you could turn it off and allow a phone to see a desktop site. Alternatively, you could add a CSS class to root <html> that the user could toggle according to preference. The CSS would look like (SASS/LESS would make this much easier)

/* default size */
#container {
    width: 1024px;
}
/* class applied to <html> tag */
.lt-480 #container {
    width: auto;
}

I’m not sure which approach we’ll go with or if we really need to make the change, but for now we have a pretty solid basis to work from as new devices come on the market. The final consideration I’d like to make is using a Facebook/BarackObama.com like side menu for mobile instead of a drop list.
If you have any other tips you’ve learned while creating Retina or Responsive sites, please share them!
And go check out http://www.dts.edu/ !