Archive for the ‘Responsive Design’ Category

Turning Off Responsive Design

In the bad old days of just four years ago it was pretty common for mobile users to get shunted off to some half-baked, feature-deprived “mobile” version of the website they were trying to visit. This misguided practice was common (and annoying) enough that even today Chrome for Android and other mobile web browsers ship with a feature that allows users to “request desktop site.”

To make that feature work Chrome for Android changes its user agent string. Any site that uses user agent strings to redirect mobile users will no longer because to redirect them and the desktop version is displayed.

Responsive websites don’t rely on user agent strings though. Instead they adapt to screen size based on CSS media queries so even if a user has the option for desktop sites checked in Chrome they still won’t get the “desktop” site (of course with responsive sites there really is no desktop site, just a desktop layout).

Provided your responsive designs are good, this isn’t a problem (and if they aren’t then you have bigger problems). However, Opera web standards evangelist Bruce Lawson raises an interesting edge case: what about users that have never seen the mobile layout and are disoriented when they do? If you were expecting, say, the desktop layout of the and instead saw the mobile layout for the first time you might be understandably confused. Here’s what Lawson has to say:

My reason for wondering [about turning off responsive design] is watching my dad use his Xmas Android phone and seeing his puzzlement that some sites look completely different on that device. Non-RWD sites loaded the layout he was familiar with — the desktop layout — which meant he could verify he was on the right site, he knew where in the layout the content he wanted was, and then scroll and zoom to it. When a site looked radically different, he’d check the URL bar to ensure that he’d typed in the right address. In short, he found RWD to be confusing and it meant he didn’t trust the site – no way would he buy anything from these sites.

The first thing to note is that this isn’t a problem unique to responsive sites. The same thing would crop up with a separate mobile experience. The difference is the inability to opt out of the responsive layout. An edge case? Sure, but Lawson isn’t alone in wondering about turning off responsive designs. CSS guru Chris Coyier tackled that very question last year, writing:

Why don’t we see opt-out responsive design? My guess is two-fold:

  1. It’s a bit technically challenging to implement and there aren’t a lot of precedents.
  2. It’s admitting you didn’t do a very good job on the responsive design.

The latter likely being the bigger factor. Like: why are we creating this responsive design at all if we aren’t sure it’s a better experience?

I would agree with both points, but clearly there are at least a few edge cases where offering an option to turn off responsive design might be a good idea. Of course it may not be worth worrying about the edge case of unfamiliar visitors — that’s the sort of decision you can only really make by looking at your own visitors and doing your own testing.

If you actually want to try it, Coyier has some ideas on how to go about creating an option to opt out of a responsive design.

File Under: Responsive Design

Take Responsive Design Beyond Media Queries

The basic elements of responsive design — fluid grids, flexible media and CSS media queries — are key to building successful websites that work across platforms and devices, but these three components are not the end of the responsive design story. In fact, as developer Brad Frost argues in the talk embedded above, there is, or should be, much more to it than that.

While many would call the broader approach “adaptive” design, Frost wants the phrase “responsive web design” to go the way of Corn Flakes, as he puts it. That is, to become a more general term that can “encompass all the things that go into creating a great multi-device web experience.” That means things that go beyond fluid grids, flexible media and media queries — things like performance, device support, device optimization and future-friendly designs.

In Frost’s analogy responsive design is the tip of the adaptive design iceberg, where all the good stuff is under the water. “Below the waterline, that’s where the true opportunity is,” says Frost, “that is where we actually have the potential to basically reshape what the web is, what it can do, where it can go and who it can reach. And that is powerful.”

Just what’s below the waterline and how do you roll these broader ideas into an actual website? Well, be sure to watch the video — Frost walks through an example of a mobile-first responsive design, which you can also read about on his site. If you prefer a tutorial sans video, Frost’s write-up from last year is available on HTML5Rocks.

The Return of the Progressive JPEG

Unlike progressive JPEGs, you just never know what a baseline image is going to be until it loads. Image:

Everything old eventually becomes new again and lately that’s meant a revival of interest in something most web developers probably abandoned long ago — progressive JPEG images.

Progressive JPEGs offer some advantages over their more common “baseline” counterparts, including potentially smaller file sizes and faster perceived load times. But there are trade offs to bear in mind before you start converting your back catalog of images.

If you happened to have missed the pixelated image loads of the circa 1999 web, here’s a brief refresher: There are two primary types of JPEG images, baseline and progressive. These days the vast majority of photos you encounter are baseline JPEGs, which means they start loading with the fully rendered top of the image and then continue to draw in the rest of the image as the data is received.

Progressive JPGs on the other hand load the full photo right off the bat, but with only some of the pixel data. That means the image briefly looks pixelated and then appears to sharpen focus as the rest of the data loads. This was the generally recommended way to optimize images back in the days when 56K dial up was considered smoking fast.

Lately, with mobile devices bringing bandwidth limitations back to the web, there’s been something of a resurgence of interest in progressive JPEGs. The Web Performance Advent Calendar even ran a piece entitled “Progressive JPEGs: a new best practice.” Here’s developer Ann Robson’s take on why you should use progressive JPEGs instead of baseline:

Progressive JPEGs are better because they are faster. Appearing faster is being faster, and perceived speed is more important that actual speed. Even if we are being greedy about what we are trying to deliver, progressive JPEGs give us as much as possible as soon as possible.

If you’re building responsive websites, progressive JPEGs are also appealing because you can avoid the content reflow that happens when baseline images are loaded after text content. With progressive JPEGs, because some data is loaded right off the bat, text doesn’t jump around (you can avoid this for non-responsive images by specifying the image dimensions).

Be sure to read Robson’s full article for some important caveats regarding progressive JPEGs, including the fact that browser support is less than ideal. All browsers will render progressive JPEGs just fine, but many of them — Safari, Mobile Safari, Opera and IE 8 — render progressive images just like baseline JPEGs, meaning there is no speed difference.

Another strike against progressive JPEGs is that they must be rendered multiple times as more data arrives. So while they may be marginally faster and possibly make users feel like the page has loaded faster, they hit the CPU pretty hard. That makes them potentially slower than baseline JPEGs in one of the use cases they’re supposed to be ideal for — underpowered mobile devices.

But perhaps the most questionable aspect of progressive JPEGs is whether or not users actually perceive a fully loaded, but blurry image that eventually comes into focus as faster than an image that takes longer, but renders all at once. Unfortunately I haven’t been able to find any actual usability studies addressing that question. I suspect that how you feel about progressive JPEGs is probably, among other things, a good indicator of how long you’ve been using the web, which is to say that if you’re all-too-familiar with progressive JPEGs from watching them slowly sharpen into focus over painfully slow dialup it’s hard to see them as anything but an annoying anachronism.

So, should you switch to progressive JPEGs? As with most things in web design there is no right answer. First you should look at your site’s stats, see which browser and devices your visitors are using and whether or not those browsers even render progressive JPEGs progressively. Assuming they do and you want to test progressive JPEGs, check out this old, but still very relevant, post from Yahoo YSlow developer Stoyan Stefanov, who has some data on when, where and how to use progressive JPEGs.

Five Ways to Simplify Responsive Design

Building responsive websites can be daunting. After all, instead of just one desktop layout you’re creating at least two, probably three or even four layouts to handle different breakpoints and screen sizes. That means considerably more work, which can feel overwhelming if you don’t have a good plan of attack.

One of the better plans I’ve seen recently comes from developer David Bushell, who recently outlines 5 Tips for Responsive Builds. Among his suggestions there are two standouts, the first being “utilize breakpoint zero.” For Bushell “breakpoint zero” just means “start by writing HTML in a semantic and hierarchical order. Start simple, with no CSS at all and then “apply the basic styles but don’t go beyond the default vertical flow.”

In other words, keep your layout slate blank as long as you can so that when you do start adding layout rules you can spot problems with different breakpoints early and fix them before changing things becomes a major headache.

The other highlight of Bushell’s post is the suggestion that you maintain a CSS pattern library — reusable snippets of CSS you can drop in for quick styling. There are a ton of ways you can do this, whether it’s something formal like SMACSS (pronounced “smacks”), OOCSS, or just taking the time to write a style guide with some sample code. The point isn’t how you do it or which method you use, but that you do it.

Be sure to check out Bushell’s post for more details on these two suggestions as well as the other three ways you can help make your responsive design process a bit smoother.

Forget JavaScript, It’s Time for Browsers to Speed Up Images

The average webpage is now 1.2 megabytes and around 60 percent of that rather large payload comes from images. That’s a lot of data, whether you’re handling images responsively or just trying to speed up a desktop site.

You might think, if images are the bulk of what your browser is downloading, that browsers would be working hard to speed up the image downloads, perhaps trying alternate, space-saving image formats, but you’d be wrong.

You might also think that, as Google’s Ilya Grigorik writes, “innovating on better image formats would be a top agenda item” for the web. But again you’d be wrong. The web is still using the same image formats it’s been using virtually since the first images appeared online.

Grigorik thinks it’s high time that changed and we agree.

In a recent post looking at what it would take to deploy new image formats on the web, he writes, “if we really want to make an impact on web performance, then image formats is the place to do it… there is absolutely no reason why we shouldn’t have dozens of specialized formats, each tailored for a specific case and type of image.”

Of course no web developer wants to deal with dozens of specialized image formats. Nor should they need to — that’s a job for servers. “In a world with dozens of image formats,” continues Grigorik, “the human solution does not scale — read, markup does not scale… whereas computers are fantastic at doing exactly the kind of optimization work required to solve the problem.”

Grigorik isn’t alone in calling for new image formats, nor is he the first to suggest handing these tasks off to the server. Developer and responsive images proponent Matt Wilcox has argued for a similar solution, as have others.

The basic premise of these arguments is that deciding which image to serve up to which device and browser should be a server-side problem. And in fact there’s already a way to solve this problem with HTTP headers, namely the Accepts header, which tells the server which image formats the browser supports. Based on that information the server could then “re-encode, recompress, resize, strip unnecessary metadata and deliver the optimal format.”

The problem is that web browsers (with the exception of Opera) don’t actually send useful information in the Accepts header.

Thus, the first step in creating a server-side solution for smaller images is to get other browsers to send useful Accepts headers.

The Accepts header isn’t a magic bullet by any means, but it’s a problem that’s not hard to solve provided browser makers prioritize it. But to really get server side image solutions working the web would also need new server tools (fortunately, several already exist). There are other stumbling blocks as well. Grigorik addresses half a dozen potential problems and objections that you can read through in his post.

Even if browser makers come around to the idea and do start improving Accepts headers, bringing better image formats to the web is going to be an uphill battle. But Grigorik is determined to chase the idea. “Some uphill battles are worth fighting,” he writes in a comment, “I think this a good one. Wish me luck.”