All posts tagged ‘responsive design’

File Under: Visual Design, Web Basics

Google Embraces Responsive Design, Recommends You Do the Same

Responsive Book: Google's Chromebook site as seen by a phone (left) and a tablet.

If you’ve been waiting for responsive design to go mainstream, wait no more. While The Boston Globe‘s responsive redesign made a big splash in the developer community, The Globe has nothing on the latest web giant to throw its weight behind responsive design — Google.

That’s right, Google is now suggesting developers use responsive design tools like media queries to handle the variety of screens now accessing the web.

The Google Webmaster blog has posted a new article, Responsive Design – Harnessing the Power of Media Queries, that walks beginners through the basics of creating a responsive website.

It’s not the most thorough tutorial we’ve seen, nor is it the best — Google conflates breakpoints with device width, something we’d recommend against — but nitpicking aside, Google’s official blessing will no doubt help move responsive design to the front burner in many people’s minds.

It’s worth noting that while a tutorial is nice, Google isn’t necessarily making the leap to responsive websites for its own properties. Indeed, sites like Gmail or Reader are excellent arguments for maintaining separate mobile designs. If your “site” is actually a web app as complex as Gmail then we suggest doing what Google does — hiring a fleet of developers to build an maintain separate websites for different size screens.

Chances are, though, that your site isn’t that complex and doesn’t have the developer teams that Google can afford. Even Google uses responsive design when it makes sense. To go along with the new tutorial, Google offers up that the new Chromebook website is responsive, which shows off the company’s responsive design chops.

Responsive Web Design: What Not to Do

Testing a responsive site across devices (using Adobe Shadow). Photo: Adobe.

We’ve covered quite a few ideas on how to build more responsive websites — that is, websites that use flexible layouts, media queries, image scaling and other tricks to make sure that the site looks great and works well on any screen.

Sometimes, though, it’s helpful to see what not to do. Responsive design guru Brad Frost recently outlined five common mistakes responsive developers make over at .Net magazine. Frost covers responsive sins like relying on specific screen sizes to trigger layout changes (it’s far better to create design breakpoints based on a site’s actual design than to just use the screen sizes du jour) and avoiding a one-size-fits all experience.

Of the latter Frost writes:

Mobile is much more than just various small screens…. We shouldn’t sell ourselves short by only creating responsive layouts. For example, we sometimes forget that mobile phones can get user location, initiate phone calls, and much more. Hopefully soon browsers on all these gadgets will have access to even more device APIs, further pushing the boundaries of what’s possible on the web.

We should do all we can to make the entire experience respond to what the device is capable of. Addressing constraints first gives us a solid foundation to stand on, then we can utilize progressive enhancement and feature detection to take the experience to the next level.

The entire post is well worth reading, but we’d like to add a sixth rule to the list: Don’t assume that what you did yesterday will be the best thing to do tomorrow.

That’s not to imply that what you do today won’t work tomorrow, just that chances are there will be an easier way to do it.

Responsive web design is a very new challenge and the best ways of meeting it are still being worked out. That can be a pain, but it also means that some very smart people are solving some very hard problems and you can benefit from their work provided you know about it.

We see new things popping up all the time, whether it’s a new way to handle responsive images or a browser update that adds widespread support for a new CSS feature. We encourage developers to spend some time reading up on the latest tips and tricks before each new project. New responsive tools are being developed and refined so rapidly that the hack you used on your last project might turn into a stable, well-maintained JavaScript library by the time you start building a new responsive site.

File Under: Browsers

Microsoft Urges Developers to Embrace Touch-Friendly Web Design

Windows 8. Photo: Microsoft

Windows 8 is just around the corner and Microsoft wants web developers to get ready for it. We’ve yet to see any tablets running Microsoft’s next-gen Metro interface, but the company is already hard at work telling web developers how to optimize their websites for touchscreens.

The IEBlog recently posted some guidelines for building touch-friendly sites and wants developers to know what makes a successful touchscreen website.

Since Microsoft is late to the touchscreen party there isn’t too much here that savvy developers aren’t already doing for iOS and Android devices. Recommendations include touchscreen basics like using the proper HTML input types such as “tel” or “email” to trigger tailored keyboard layouts, and making sure that touch targets are large and easy to hit. Microsoft also suggests avoiding hover events since touchscreen users never trigger them (unfortunately, content hidden from touchscreens by hover events is still an all too common problem).

If you’re building responsive websites or at least tailoring your designs for touchscreens, most of these suggestions are probably already part of your workflow.

One thing that may be new to some developers is the non-standard -ms-touch-action CSS property. The -ms-touch-action property allows developers to override IE 10′s default touch behavior.

Like most touchscreen browsers, IE 10 assumes that touch events are related to browser actions — double-tapping to zoom for instance. Most of the time this is what you want, but occasionally developers may want to take over some actions, for example, drag events in a drawing app, while leaving others alone. If you have canvas element as part of your drawing app you could set the -ms-touch-action like this:

canvas {
    -ms-touch-action: double-tap-zoom;
}

As the IEBlog explains, “with this configuration the user can double-tap to zoom in to the canvas element, but sliding a finger on the canvas element will send events to it rather than pan the page.”

For more details on -ms-touch-action, head over to the Microsoft Developer Network website. As far as I’ve been able to determine, Microsoft has not yet submitted -ms-touch-action to the W3C. It looks like a very handy property, so hopefully it will be submitted at some point.

As the IEBlog notes there’s much more to developing for touchscreens than just a few quick tricks. While most sites will work just fine in tablet versions of IE 10 (or any other touch screen browser) with no modifications at all there’s a rather wide gap between “work” and “amazing.” If you’d like your sites to land toward the later end of the spectrum, be sure to check out our earlier post on building a responsive, future-friendly web for some pointers.

File Under: Mobile

Why Jakob Nielsen Is Wrong About Mobile Websites

Make the logo smaller. Photo: Ariel Zambelich/Wired.com

Web usability guru Jakob Nielsen has come under fire for his latest suggestions on building mobile websites. Nielsen’s controversial advice can be distilled down to this nugget: “good mobile user experience requires a different design than what’s needed to satisfy desktop users. Two designs, two sites, and cross-linking to make it all work.”

Among the many negative responses to Nielsen’s latest Alertbox post is that of web developer and mobile specialist Josh Clarke, who calls Nielsen’s questionable advice “180-degrees backward.”

Indeed, much of Nielsen’s advice may seem like a shockingly bad idea not just to developers, but to anyone who uses a mobile device to browse the web.

This isn’t the first time Nielsen has taken a contrarian stand about mobile websites. Last year he suggested that a mobile-first approach to design was wrong because “PCs will remain important,” which is, at best, a false dilemma since a mobile-first design doesn’t mean ignoring the desktop. Just because you’re focused on the future doesn’t mean you’re ignoring the past.

Nielsen’s latest advice has similar false dichotomies. For example much of Nielsen’s advice rests on the premise that a single site cannot serve the wants and needs of both mobile and desktop users. In fact you don’t need to choose between mobile and desktop, the page can adapt and serve the needs of both users. There are plenty of examples of sites that do just that with responsive designs. To be sure there are plenty of websites that claim to be mobile-friendly and obviously aren’t. But that doesn’t mean the solution is to toss out the whole idea of responsive design and go back to separate websites for every device.

In fact what Nielsen considers one of the “main guidelines” for a successful mobile website is something that many people would probably consider the most irritating thing about mobile sites: “If mobile users arrive at your full site’s URL, auto-redirect them to your mobile site” (emphasis in original).

The problem with this advice is that, as Clark puts it, “Nielsen is confusing device context with user intent.” In other words, just because someone visits your site on a small screen doesn’t mean they won’t want access to all the same things they would see on a slightly larger screen. It may be necessary to rearrange elements for smaller screens, but hiding them is a bad idea.

“All that we can really know about mobile users is that they’re on a small screen, and we can’t divine user intent from that,” writes Clark.

Nielsen, however, does just that, divining that — because a user has a small screen — they will want to do less on your site. He suggests you serve up a limited site and then offer a link to the full site “for those (few) users who need special features that are found only on the full site.”

We suggest you don’t do that. You can do better than that.

You can use responsive design patterns to make sure that the same content is always available, but that the experience is tailored to the device at hand. In other words, responsive design means your site works just as well on mobile as it does on the desktop. If it doesn’t that means something is wrong with your site, not the whole approach. Sure, there will be times when a separate mobile site is the right way to go, but those times will likely be few and far between.

Nielsen’s argument is based on copious research and we have no doubt he found plenty of horribly designed websites that completely fail on mobile devices to justify his recommendations. But just because Nielsen is finding a lot of poorly made mobile websites does not, as Clark writes, “mean we should punt on creating great, full-featured mobile experiences.”

File Under: CSS

Build Responsive Websites Like Bruce Lee

A handful of the many screens your site needs to handle. Photo: Ariel Zambelich/Wired.com

Responsive design means making your website readable no matter what screen it might be on. In the words of karate master Bruce Lee, “Don’t get set into one form, adapt it and build your own, and let it grow, be like water.” Lee may have been talking about your mind, but his words apply just as well to your website. To paraphrase the rest of that quote, you put water into a cup, it becomes the cup; so, you put your content on a tablet, it becomes the tablet; you put it on a TV, it becomes the TV.”

On a more practical level, achieving a Bruce Lee-like command of the fluid web means ditching the pixels and points for flexible units like ems or percentages. There’s a lot more to responsive design than just fluid layouts, but it’s definitely a key part of the process.

Curiously, when it comes time to use the other universal element of responsive design — the @media query that applies the actual responsive design — most of us revert right back to pixels with something like @media all and (min-width: 500px) {}. It seems logical; after all, you’re trying to fit your content into a window with specific dimensions, so why not use pixels?

Certainly you can, and most sites we’ve seen up to this point use pixels for the actual media query breakpoints, but it’s worth noting that you can use ems here as well.

Lyza Gardner over at Cloud Four recently posted a look at why Cloud Four’s new responsive design uses ems in its media queries. Here’s her reasoning for Cloud Four’s em-based approach:

Folks who design for traditional reading media — where the content really is king — don’t center design decisions around the absolute width of content-holding elements so much as around the optimal line lengths for the content they’re flowing. There are some tried-and-true numbers one can shoot for that make for the “right” number of letters (and thus words) per line for comfortable human reading.

Thus actual column width is a function of font size and ems-per-line.

The rest of the post walks through how Cloud Four used em-based media queries to create a better navigation experience on their site. Some of the advantages may not apply to every responsive design, but there is one additional benefit that works nearly everywhere — em-based media queries mean that your site will handle user zooming much better, applying media queries instead of allowing content to overflow its container.

But perhaps the best part of an em-based approach is that it seems to work in nearly every web browser. Cloud Four’s post doesn’t get into the specifics of their browser testing so I fired up a couple of virtual machines and tested their site and my own simplified demo page in every major browser.

According to my testing, em-based media queries work properly in all OS X browsers. (I tested the latest versions of Safari, Firefox, Chrome and Opera.) Only Firefox and Opera apply media queries on zoom, though. (Chrome and Safari need a page refresh before the query is applied.)

On Windows 7 Firefox, Opera and Chrome behave the same way they do on OS X. IE 9 also worked fine and, like Firefox and Opera, applies media queries when zooming without needing a page refresh. Judging by the comments on the Cloud Four blog, Chrome on Linux may have some issues, but in my testing Firefox and Chrome on Fedora worked as expected.

All the mobile browsers I tested on Android worked as well (Firefox, Chrome, Opera Mini and the default Android browser). On iOS Mobile Safari applies em-based queries as you would expect.

In the end you certainly don’t need to use em-based media queries. As many sites out there demonstrate, pixel-based queries work. At least for now. However, as a wider range of screen sizes begin to access the web switching to em-based queries may put you ahead of the game. Em-based queries mean addressing the content-width rather than just the screen width and that feels like a more future-friendly approach.