55 Minutes

Welcome to the 55 Minutes blog.
55 Minutes is a web development consultancy in San Francisco building apps for design-led businesses and startups. On this blog we discuss the technology tools of our trade: Ruby on Rails, Django, Sass, OS X, and more.

Responsive Web Design in Action The Device Scout Website

In which we relay our experiences developing our first real-world website according to the principles of responsive web design.

The first real-world website we built according to the principles of responsive web design (“RWD”) was the marketing website for our new product, Device Scout. In the course of its development, we learned a lot, discovered a bug in iOS 5’s build of MobileSafari, and in general enjoyed ourselves thoroughly. I’d like to share some of the interesting things we learned with you.

Before we begin, it should be noted that I’ve left gaining an understanding of RWD as an exercise to the reader, and that I assume a certain level of familiarity with the basic principles thereof here.

Media query resolutions

Generally speaking, we follow the recommendations of the RWD book when selecting points at which to shift the layout:

During the course of the site’s development, however, we found that the gaps between these resolutions felt very large, and resolutions near the lower end of a given range (e.g. between 480 and 768px) called for different treatment than those near the upper end. Moreover, it made sense for the layout of certain page elements to shift at different resolutions than that of other elements; for example, we shift the layout of the nav bar at 500px, but shift the layout of the feature list on the features page at 600px.

By the time we were done, we ended up with media queries/layout shifts at the following resolutions: 480, 500, 600, 768, 848 and 1024px.

Fluid images

One of the keys to achieving a responsive layout is to use fluid images, where (I’m glossing over the details a bit here) you start with a high-resolution source image and scale it down for smaller resolutions. That way, when you increase the screen-size, we can scale the image up to fit the layout, but it still looks good because we’re still scaling down from the large source image.

Using fluid images is well and good, but that paradigm can cause problems for software marketing sites, on which, by definition, most of the images are screenshots. Software screenshots look best at a 1:1 scale—should arguably only be shown at 1:1 scale—since we’re essentially displaying images of text, and text in a scaled image, to state the obvious, looks really bad.

It was crucial for us to ensure that at some point, therefore, we displayed screenshots of our UI at a 1:1 scale. This was especially troublesome for us, because we needed to use full-screen iPad screenshots, which are rather large. The compromise we reached is that at smaller resolutions, we’d scale the images down to fit the layout and include links to open them at full size in a new window—enabling the user to pan and zoom at will—and past a certain screen size, we would show them at 100% scale. So, at browser window widths of 848px and higher (the width of our screenshot, 768px, plus the page padding), we show the image at full resolution.

The fixed-positioning + JavaScript scrolling bug in MobileSafari

Nowadays it’s not really kosher to just jump directly to an on-page link. No, all the cool kids animate scrolling the page to the desired point instead. This is relatively easy to implement, but we found out the hard way that when you have a fixed-position element on a page that you scroll with JavaScript (as we do at 1024px and wider on the Device Scout site), links in MobileSafari on iOS 5 stop working altogether. (You can see the problem happen yourself if you load this simplified demo in the iOS5 iPad browser or simulator.)

I’ve reported the issue to Apple, who have acknowledged it as a serious bug. Unfortunately, there is no fix as yet, and no viable workaround other than disabling fixed-positioning on iOS devices. If anyone does come up with a good workaround, please do be sure to let us know.

In conclusion

For the most part, implementing RWD recommendations is easy and gives you a lot of bang for your buck. If you’re going to try your hand at a responsive web design, the best advice I could give you is to not be afraid to change or build upon the basic recommendations. Do what feels right for your site.

comments powered by Disqus