Small Screens Come First: Build for 320 And Up

Small Screens Come First with 320 And Up

If you’ve yet to learn how to work with CSS3 media queries, I hope it’s near the top of your to-do list, because 2011 is definitely the year of the mobile device. Whether you need to build a separate mobile site, or plan to make one size fit all, you’ll still need to be up to date with responsive web design techniques.

One common issue developers face with the media queries approach is that you often have to do a lot of work to keep small-screen browsers happy; you’ll find yourself resizing big images, switching scripts around, maybe even hiding big chunks of content. While this technique gets the job done, it means that small-screen browsers may be loading up huge bits of content that they’ll never need to show. For slow, expensive mobile connections, that means paying for additional packets that I’d personally prefer to avoid.

Louis: … And I guess one of the biggest challenges with Responsive Web Design is dealing with that bandwidth challenge, right, if I need to serve an image that will look good at 1024 or 1280 and it also needs to look good at 320, the approach so far in most responsive cases has been to use a really large image and scale it in CSS, but that does pose a problem for bandwidth. And then the other issue that comes up is some of the superfluous content, so you’ve talked a little bit about lazy loading as a solution to that. So I wanted to hear what your opinions are on where we’re going with respect to these sorts of technical challenges and dealing with bandwidth issues.

Jeremy: When it comes to serving up different size media, like images, I think as with this idea when it came to layouts instead of scaling down a desktop-centric layout to flow into a mobile site, what if we flip it on its head and start with the narrow version and then scale it up to desktop. I think that’s probably a good approach to take with media as well; instead of thinking about the large image as the default, and (asking) how do we scale it down for smaller screen sizes, to flip that on its head and think about the smaller image as the default, and then how do we provide a larger image for the devices that have larger screens — laptops, desktops and so on.

I mean, partly that’s because the smaller screen device is going to include a whole bunch of phones that are not all that capable. We’ve got some great mobile browsers out there now, Mobile Safari and so on, but there’s also a lot of mobile phones that have kind of crappier browsers. So the safe default is to think about the lower bandwidth, think about the smaller images, think about the linearized design, and then to apply larger images, more content, multi-column layouts for the more capable browsers that are likely to be on a desktop or laptop computer.

Or, as Luke Wroblewski put it back in 2009: design for mobile first. Your base design is a plain, simple, bells-and-whistles-free experience that even the dumbest phone and the smallest screen can use. For more modern phones and tablets with support for media queries, we can lay on more styles and create new layouts to suit their dimensions, or make use of cooler CSS effects. Finally, for desktop browsers, create layouts and use assets that make the most of all that screen real estate. Of course, some desktop browsers just have to be different; for those browsers, we can use polyfills to include that support, or find other workarounds — or maybe just leave them to use the simplest design, if you’re feeling uncharitable! It’s so head-smackingly simple that you wonder why we haven’t all just done this from the outset.

Before you leap for your text editor, though, consider picking up Andy Clarke’s new 320 and up template. Using the excellent HTML 5 Boilerplate project as a base, he’s added a bagful of polyfills, helpers and bug workarounds, such as Selectivizr to add CSS3 selectors, Respond.js for media query support in Internet Explorers 6 through 8. The stylesheets come already prepared for five different device widths — small screen, 480px, 768px, 992px, and 1382px — plus one more for the iPhone 4 and latest iPod Touch’s Retina display. You can choose between separate stylesheets for each design variation, or a single stylesheet that contains it all.

What’s left for you to do? Of course, there’s more to responsive design than just squashing or growing your logo. Some interfaces might need you to show or hide some content at certain sizes, while others might contain entire features that are only intended for some sizes. Menus for phones may need to look and feel quite a lot different to one intended for a desktop computer, especially considering that more of us are using a fingertip to navigate. (Yes, there are still non-touch smartphones.) You might need to do some more work around context aware image sizing You may need to consider whether certain information on your website should be emphasised for mobile users. Whatever your needs, though, you should find that the 320 and Up templates are a solid, tried and tested starting point for when it’s time to build your next responsive layout project.

Raena Jackson Armitage is an Australian web developer with a background in content management, public speaking, and training. When she is not thinking about the Web, she loves knitting, gaming, all-day breakfasts, and cycling.

David Hyland

With regard to resizing images for smaller screens this is an excellent resource:http://tinysrc.net/

johans

I enjoyed the podcast and specifically the comment that you cannot make assumptions about mobile users – a common approach used to justify a stripped-down mobile site with features targeting users who are on the go. A mobile device does not mean the user is out and about.

320 and up is nice. However it does not solve problems with loading content images (backgrounds can be dealt with using media queries).

I think the easiest solution for content images is to use viewport size detection and javascript to load the appropriate images – for example upload a set of optimally sized images for each screen size and change the path dynamically. Alternatively process images on the fly serverside.

Another option is using service like tinySrc (sencha): http://tinysrc.net/ but
not convinced that is a long-term/scalable option.

How are others handling content optimization/loading of content images?

johans

The context aware approach from Filament Group is interesting but does place additional requirement to modify the .htaccess file for Apache (and of course to use Apache).

I like their use of the HTML custom data- attribute to reference the large/source image.

Wondering how their approach of inserting BASE and using url rewrite is any better that simply using smallest image (or placeholder) by default and modify image path based on detecting screen size.

I’m think this would work on all browsers.

Scott Jehl

johans: Scott from Filament here. The responsive images approach uses the base tag to prevent the first image request from going out. Trying to replace the src with JavaScript will happen too late – after the img element is in the DOM and the request has left. So, the technique is meant to satisfy two critical requirements: the page is served with a mobile-optimized “real” content image, and on large screens, it’s swapped for a larger size without requesting the smaller one. If you visit the github repo, I’ve got some different variations outlined as well, and a branch that uses cookies for the redirect (same-domain limitations apply of course). Ideally, if you’re able, I’d recommend not using the data- attribute at all and redirecting “responsive” images directly to a larger image through a predictable naming convention (ie image.r.jpg and image.large.jpg).
-Scott

powerpotatoe

I like your concept of starting small and then moving to big. As I was reading the article I was asking myself, “Why do we default to large designs? Why is this always our starting point?”

Obviously, some designs require alot of screen real estate. But I wonder if most designers use the whole screen because that’s the way it has always been done. Moreover, there seems to be an inherent desire or compulsion to use the entire screen. I remember art teachers encouraging me to use the entire canvas. Why?

Again, project requirements should help determine the design layout. But maybe designers should first think of less and then move to more as needed. I know that when I sit down to design I usually want to fill the entire desktop size screen even when the content does not require it (which leaves me filling the space with alot of fluff and distracting elements). I assume that users will freak out if the page does not fill the whole screen. But if I learn to design well with less, maybe my visitors will appreciate the site more. And maybe this will prove to be a great exercise in learning how to design well with more.

Michael Slater

I think part of the problem is trying to make one HTML page do the job of delivering both desktop and mobile sites. While I understand the advantages of this approach and agree that it fits in some situations, in many cases I think you’re better off building two sets of HTML, one for mobile and one for desktop. This is both cleaner and encourages you to rethink things from the mobile perspective, and change anything you want.

With a CMS that enables automatic switching to a mobile set of pages if accessed by a mobile device, this approach works very smoothly. And if the pages are generated from content in a database, you can pick and choose from the same content for the desktop and mobile versions.