Skip navigation
Help

responsive design

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Addy Osmani

  

Today we’ll discuss how to improve the paint performance of your websites and Web apps. This is an area that we Web developers have only recently started looking at more closely, and it’s important because it could have an impact on your user engagement and user experience.

Frame Rate Applies To The Web, Too

Frame rate is the rate at which a device produces consecutive images to the screen. A low frames per second (FPS) means that individual frames can be made out by the eye. A high FPS gives users a more responsive feel. You’re probably used to this concept from the world of gaming, but it applies to the Web, too.

Long image decoding, unnecessary image resizing, heavy animation and data processing can all lead to dropped frames, which reduces the frame rate, resulting in janky pages. We’ll explain what exactly we mean by “jank” shortly.

Why Care About Frame Rate?

Smooth, high frame rates drive user engagement and can affect how much users interact with your website or app.

At EdgeConf earlier this year, Facebook confirmed this when it mentioned that in an A/B test, it slowed down scrolling from 60 FPS to 30 FPS, causing engagement to collapse. That said, if you can’t do high frame rates and 60 FPS is out of reach, then you’d at least want something smooth. If you’re doing your own animation, this is one benefit of using requestAnimationFrame: the browser can dynamically adjust to keep the frame rate normal.

In cases where you’re concerned about scrolling, the browser can manage the frame rate for you. But if you introduce a large amount of jank, then it won’t be able to do as good a job. So, try to avoid big hitches, such as long paints, long JavaScript execution times, long anything.

Don’t Guess It, Test It!

Before getting started, we need to step back and look at our approach. We all want our websites and apps to run more quickly. In fact, we’re arguably paid to write code that runs not only correctly, but quickly. As busy developers with deadlines, we find it very easy to rely on snippets of advice that we’ve read or heard. Problems arise when we do that, though, because the internals of browsers change very rapidly, and something that’s slow today could be quick tomorrow.

Another point to remember is that your app or website is unique, and, therefore, the performance issues you face will depend heavily on what you’re building. Optimizing a game is a very different beast to optimizing an app that users will have open for 200+ hours. If it’s a game, then you’ll likely need to focus your attention on the main loop and heavily optimize the chunk of code that is going to run every frame. With a DOM-heavy application, the memory usage might be the biggest performance bottleneck.

Your best option is to learn how to measure your application and understand what the code is doing. That way, when browsers change, you will still be clear about what matters to you and your team and will be able to make informed decisions. So, no matter what, don’t guess it, test it!

We’re going to discuss how to measure frame rate and paint performance shortly, so hold onto your seats!

Note: Some of the tools mentioned in this article require Chrome Canary, with the “Developer Tools experiments” enabled in about:flags. (We — Addy Osmani and Paul Lewis — are engineers on the Developer Relations team at Chrome.)

Case Study: Pinterest

The other day we were on Pinterest, trying to find some ponies to add to our pony board (Addy loves ponies!). So, we went over to the Pinterest feed and started scrolling through, looking for some ponies to add.

Screen Shot 2013-03-25 at 14.30.57-500
Addy adding some ponies to his Pinterest board, as one does. Larger view.

Jank Affects User Experience

The first thing we noticed as we scrolled was that scrolling on this page doesn’t perform very well — scrolling up and down takes effort, and the experience just feels sluggish. When they come up against this, users get frustrated, which means they’re more likely to leave. Of course, this is the last thing we want them to do!

Screen Shot 2013-03-25 at 14.31.27-500
Pinterest showing a performance bottleneck when a user scrolls. Larger view.

This break in consistent frame rate is something the Chrome team calls “jank,” and we’re not sure what’s causing it here. You can actually notice some of the frames being drawn as we scroll. But let’s visualize it! We’re going to open up Frames mode and show what slow looks like there in just a moment.

Note: What we’re really looking for is a consistently high FPS, ideally matching the refresh rate of the screen. In many cases, this will be 60 FPS, but it’s not guaranteed, so check the devices you’re targeting.

Now, as JavaScript developers, our first instinct is to suspect a memory leak as being the cause. Perhaps some objects are being held around after a round of garbage collection. The reality, however, is that very often these days JavaScript is not a bottleneck. Our major performance problems come down to slow painting and rendering times. The DOM needs to be turned into pixels on the screen, and a lot of paint work when the user scrolls could result in a lot of slowing down.

Note: HTML5 Rocks specifically discusses some of the causes of slow scrolling. If you think you’re running into this problem, it’s worth a read.

Measuring Paint Performance

Frame Rate

We suspect that something on this page is affecting the frame rate. So, let’s go open up Chrome’s Developer Tools and head to the “Timeline” and “Frames” mode to record a new session. We’ll click the record button and start scrolling the page the way a normal user would. Now, to simulate a few minutes of usage, we’re going to scroll just a little faster.

Screen Shot 2013-05-15 at 17.57.48-500
Using Chrome’s Developer Tools to profile scrolling interactions. Larger view.

Up, down, up, down. What you’ll notice now in the summary view up at the top is a lot of purple and green, corresponding to painting and rendering times. Let’s stop recording for now. As we flip through these various frames, we see some pretty hefty “Recalculate Styles” and a lot of “Layout.”

If you look at the legend to the very right, you’ll see that we’ve actually blown our budget of 60 FPS, and we’re not even hitting 30 FPS either in many cases. It’s just performing quite poorly. Now, each of these bars in the summary view correspond to one frame — i.e. all of the work that Chrome has to do in order to be able to draw an app to the screen.

screen434343-500
Chrome’s Developer Tools showing a long paint time. Larger view.

Frame Budget

If you’re targeting 60 FPS, which is generally the optimal number of frames to target these days, then to match the refresh rate of the devices we commonly use, you’ll have a 16.7-millisecond budget in which to complete everything — JavaScript, layout, image decoding and resizing, painting, compositing — everything.

Note: A constant frame rate is our ideal here. If you can’t hit 60 FPS for whatever reason, then you’re likely better off targeting 30 FPS, rather than allowing a variable frame rate between 30 and 60 FPS. In practice, this can be challenging to code because when the JavaScript finishes executing, all of the layout, paint and compositing work still has to be done, and predicting that ahead of time is very difficult. In any case, whatever your frame rate, ensure that it is consistent and doesn’t fluctuate (which would appear as stuttering).

If you’re aiming for low-end devices, such as mobile phones, then that frame budget of 16 milliseconds is really more like 8 to 10 milliseconds. This could be true on desktop as well, where your frame budget might be lowered as a result of miscellaneous browser processes. If you blow this budget, you will miss frames and see jank on the page. So, you likely have somewhere nearer 8 to 10 milliseconds, but be sure to test the devices you’re supporting to get a realistic idea of your budget.

Screen Shot 2013-03-25 at 14.34.26-500
An extremely costly layout operation of over 500 milliseconds. Larger view.

Note: We’ve also got an article on how to use the Chrome Developer Tools to find and fix rendering performance issues that focuses more on the timeline.

Going back to scrolling, we have a sneaking suspicion that a number of unnecessary repaints are occurring on this page with onscroll.

One common mistake is to stuff just way too much JavaScript into the onscroll handlers of a page — making it difficult to meet the frame budget at all. Aligning the work to the rendering pipeline (for example, by placing it in requestAnimationFrame) gives you a little more headroom, but you still have only those few milliseconds in which to get everything done.

The best thing you can do is just capture values such as scrollTop in your scroll handlers, and then use the most recent value inside a requestAnimationFrame callback.

Paint Rectangles

Let’s go back to Developer Tools → Settings and enable “Show paint rectangles.” This visualizes the areas of the screen that are being painted with a nice red highlight. Now look at what happens as we scroll through Pinterest.

Screen Shot 2013-03-25 at 14.35.17-500
Enabling Chrome Developer Tools’ “Paint Rectangles” feature. Larger view.

Every few milliseconds, we experience a big bright flash of red across the entire screen. There seems to be a paint of the whole screen every time we scroll, which is potentially very expensive. What we want to see is the browser just painting what is new to the page — so, typically just the bottom or top of the page as it gets scrolled into view. The cause of this issue seems to be the little “scroll to top” button in the lower-right corner. As the user scrolls, the fixed header at the top needs to be repainted, but so does the button. The way that Chrome deals with this is to create a union of the two areas that need to be repainted.

Screen Shot 2013-05-15 at 19.00.12-500
Chrome shows freshly painted areas with a red box. Larger view.

In this case, there is a rectangle from the top left to top right, but not very tall, plus a rectangle in the lower-right corner. This leaves us with a rectangle from the top left to bottom right, which is essentially the whole screen! If you inspect the button element in Developer Tools and either hide it (using the H key) or delete it and then scroll again, you will see that only the header area is repainted. The way to solve this particular problem is to move the scroll button to its own layer so that it doesn’t get unioned with the header. This essentially isolates the button so that it can be composited on top of the rest of the page. But we’ll talk about layers and compositing in more detail in a little bit.

The next thing we notice has to do with hovering. When we hover over a pin, Pinterest paints an action bar containing “Repin, comment and like” buttons — let’s call this the action bar. When we hover over a single pin, it paints not just the bar but also the elements underlying it. Painting should happen only on those elements that you expect to change visually.

Screen Shot 2013-03-25 at 14.35.46-500
A cause for concern: full-screen flashes of red indicate a lot of painting. Larger view.

There’s another interesting thing about scrolling here. Let’s keep our cursor hovered over this pin and start scrolling the page again.

Every time we scroll through a new row of images, this action bar gets painted on yet another pin, even though we don’t mean to hover over it. This comes down more to UX than anything else, but scrolling performance in this case might be more important than the hover effect during scrolling. Hovering amplifies jank during scrolling because the browser essentially pauses to go off and paint the effect (the same is true when we roll out of the element!). One option here is to use a setTimeout with a delay to ensure that the bar is painted only when the user really intends to use it, an approach we covered in “Avoiding Unnecessary Paints.” A more aggressive approach would be to measure the mouseenter or the mouse’s trajectory before enabling hover behaviors. While this measure might seem rather extreme, remember that we are trying to avoid unnecessary paints at all costs, especially when the user is scrolling.

Overall Paint Cost

We now have a really great workflow for looking at the overall cost of painting on a page; go back into Developer Tools and “Enable continuous page repainting.” This feature will constantly paint to your screen so that you can find out what elements have costly paint times. You’ll get this really nice black box in the top corner that summarizes paint times, with the minimum and maximum also displayed.

screenshot43234242-500
Chrome’s “Continuous Page Repainting” mode helps you to assess the overall cost of a page. Larger view.

Let’s head back to the “Elements” panel. Here, we can select a node and just use the keyboard to walk the DOM tree. If we suspect that an element has an expensive paint, we can use the H shortcut key (something recently added to Chrome) to toggle visibility on that element. Using the continuous paint box, we can instantly see whether this has a positive effect on our pages’ paint times. We should expect it to in many cases, because if we hide an element, we should expect a corresponding reduction in paint times. But by doing this, we might see one element that is especially expensive, which would bear further scrutiny!

Screen Shot 2013-06-10 at 09.46.31_500_mini
The “Continuous Page Repainting” chart showing the time taken to paint the page.

For Pinterest’s website, we can do it to the categories bar or to the header, and, as you’d expect, because we don’t have to paint these elements at all, we see a drop in the time it takes to paint to the screen. If we want even more detailed insight, we can go right back to the timeline and record a new session to measure the impact. Isn’t that great? Now, while this workflow should work great for most pages, there might be times when it isn’t as useful. In Pinterest’s case, the pins are actually quite deeply nested in the page, making it hard for us to measure paint times in this workflow.

Luckily, we can still get some good mileage by selecting an element (such as a pin here), going to the “Styles” panel and looking at what CSS styles are being used. We can toggle properties on and off to see how they effect the paint times. This gives us much finer-grained insight into the paint profile of the page.

Here, we see that Pinterest is using box-shadow on these pins. We’ve optimized the performance of box-shadow in Chrome over the past two years, but in combination with other styles and when heavily used, it could cause a bottleneck, so it’s worth looking at.

Pinterest has reduced continuous paint mode times by 40% by moving box-shadow to a separate element that doesn’t have border-radius. The side effect is slightly fuzzy-looking corners; however, it is barely noticeable due to the color scheme and the low border-radius values.

Note: You can read more about this topic in “CSS Paint Times and Page Render Weight.”

Screen Shot 2013-03-25 at 15.47.40-500
Toggling styles to measure their effect on page-rendering weight. Larger view.

Let’s disable box-shadow to see whether it makes a difference. As you can see, it’s no longer visible on any of the pins. So, let’s go back to the timeline and record a new session in which we scroll the same way as we did before (up and down, up and down, up and down). We’re getting closer to 60 FPS now, and that’s just from one change.

Public service announcement: We’re absolutely not saying don’t use box-shadow — by all means, do! Just make sure that if you have a performance problem, measure correctly to find out what your own bottlenecks are. Always measure! Your website or application is unique, as will any performance bottleneck be. Browser internals change almost daily, so measuring is the smartest way to stay up to date on the changes, and Chrome’s Developer Tools makes this really easy to do.

Screen Shot 2013-03-25 at 15.50.25-500
Using Chrome Developer Tools to profile is the best way to track browser performance changes. Larger view.

Note: Eberhard Grather recently wrote a detailed post on “Profiling Long Paint Times With DevTools’ Continuous Painting Mode,” which you should spend some quality time with.

Another thing we noticed is that if you click on the “Repin” button, do you see the animated effect and the lightbox being painted? There’s a big red flash of repaint in the background. It’s not clear from the tooling if the paint is the white cover or some other affected being area. Be sure to double check that the paint rectangles correspond to the element or elements that you think are being repainted, and not just what it looks like. In this case, it looks like the whole screen is being repainted, but it could well be just the white cover, which might not be all that expensive. It’s nuanced; the important thing is to understand what you’re seeing and why.

Hardware Compositing (GPU Acceleration)

The last thing we’re going to look at on Pinterest is GPU acceleration. In the past, Web browsers have relied pretty heavily on the CPU to render pages. This involved two things: firstly, painting elements into a bunch of textures, called layers; and secondly, compositing all of those layers together to the final picture seen on screen.

Over the past few years, however, we’ve found that getting the GPU involved in the compositing process can lead to some significant speeding up. The premise is that, while the textures are still painted on the CPU, they can be uploaded to the GPU for compositing. Assuming that all we do on future frames is move elements around (using CSS transitions or animations) or change their opacity, we simply provide these changes to the GPU and it takes care of the rest. We essentially avoid having to give the GPU any new graphics; rather, we just ask it to move existing ones around. This is something that the GPU is exceptionally quick at doing, thus improving performance overall.

There is no guarantee that this hardware compositing will be available and enabled on a given platform, but if it is available the first time you use, say, a 3D transform on an element, then it will be enabled in Chrome. Many developers use the translateZ hack to do just that. The other side effect of using this hack is that the element in question will get its own layer, which may or may not be what you want. It can be very useful to effectively isolate an element so that it doesn’t affect others as and when it gets repainted. It’s worth remembering that the uploading of these textures from system memory to the video memory is not necessarily very quick. The more layers you have, the more textures need to be uploaded and the more layers that will need to be managed, so it’s best not to overdo it.

Note: Tom Wiltzius has written about the layer model in Chrome, which is a relevant read if you are interested in understanding how compositing works behind the scenes. Paul has also written a post about the translateZ hack and how to make sure you’re using it in the right ways.

Another great setting in Developer Tools that can help here is “Show composited layer borders.” This feature will give you insight into those DOM elements that are being manipulated at the GPU level.

layer_folders_addy_500_mini
Switching on composited layer borders will indicate Chrome’s rendering layers. Larger view.

If an element is taking advantage of the GPU acceleration, you’ll see an orange border around it with this on. Now as we scroll through, we don’t really see any use of composited layers on this page — not when we click “Scroll to top” or otherwise.

Chrome is getting better at automatically handling layer promotion in the background; but, as mentioned, developers sometimes use the translateZ hack to create a composited layer. Below is Pinterest’s feed with translateZ(0) applied to all pins. It’s not hitting 60 FPS, but it is getting closer to a consistent 30 FPS on desktop, which is actually not bad.

Screen Shot 2013-05-15 at 19.03.13-500
Using the translateZ(0) hack on all Pinterest pins. Note the orange borders. Larger view.

Remember to test on both desktop and mobile, though; their performance characteristics vary wildly. Use the timeline in both, and watch your paint time chart in Continuous Paint mode to evaluate how fast you’re busting your budget.

Again, don’t use this hack on every element on the page — it might pass muster on desktop, but it won’t on mobile. The reason is that there is increased video memory usage and an increased layer management cost, both of which could have a negative impact on performance. Instead, use hardware compositing only to isolate elements where the paint cost is measurably high.

Note: In the WebKit nightlies, the Web Inspector now also gives you the reasons for layers being composited. To enable this, switch off the “Use WebKit Web Inspector” option and you’ll get the front end with this feature in there. Switch it on using the “Layers” button.

A Find-and-Fix Workflow

Now that we’ve concluded our Pinterest case study, what about the workflow for diagnosing and addressing your own paint problems?

Finding the Problem

  • Make sure you’re in “Incognito” mode. Extensions and apps can skew the figures that are reported when profiling performance.
  • Open the page and the Developer Tools.
  • In the timeline, record and interact with your page.
  • Check for frames that go over budget (i.e. over 60 FPS).
  • If you’re close to budget, then you’re likely way over the budget on mobile.
  • Check the cause of the jank. Long paint? CSS layout? JavaScript?

Screen Shot 2013-05-15 at 19.36.22-500
Spend some quality time with Frame mode in Chrome Developer Tools to understand your website’s runtime profile. Larger view.

Fixing the Problem

  • Go to “Settings” and enable “Continuous Page Repainting.”
  • In the “Elements” panel, hide anything non-essential using the hide (H) shortcut.
  • Walk through the DOM tree, hiding elements and checking the FPS in the timeline.
  • See which element(s) are causing long paints.
  • Uncheck styles that could affect paint time, and track the FPS.
  • Continue until you’ve located the elements and styles responsible for the slow-down.

fixing-500_mini
Switch on extra Developer Tools features for more insight. Larger view.

What About Other Browsers?

Although at the time of writing, Chrome has the best tools to profile paint performance, we strongly recommend testing and measuring your pages in other browsers to get a feel for what your own users might experience (where feasible). Performance can vary massively between them, and a performance smell in one browser might not be present in another.

As we said earlier, don’t guess it, test it! Measure for yourself, understand the abstractions, know your browser’s internals. In time, we hope that the cross- browser tooling for this area improves so that developers can get an accurate picture of rendering performance, regardless of the browser being used.

Conclusion

Performance is important. Not all machines are created equal, and the fast machines that developers work on might not have the performance problems encountered on the devices of real users. Frame rate in particular can have a big impact on engagement and, consequently, on a project’s success. Luckily, a lot of great tools out there can help with that.

Be sure to measure paint performance on both desktop and mobile. If all goes well, your users will end up with snappier, more silky-smooth experiences, regardless of the device they’re using.

Further Reading

About the Authors

Addy Osmani and Paul Lewis are engineers on the Developer Relations team at Chrome, with a focus on tooling and rendering performance, respectively. When they’re not causing trouble, they have a passion for helping developers build snappy, fluid experiences on the Web.

(al)

© Addy Osmani for Smashing Magazine, 2013.

0
Your rating: None
Original author: 
Scott Gilbertson

Hybrids. Image: Screenshot/Webmonkey.

The advent of hybrid laptops that double as tablets or offer some sort of touch input has greatly complicated the life of web developers.

A big part of developing for today’s myriad screens is knowing when to adjust the interface, based not just on screen size, but other details like input device. Fingers are far less precise than a mouse, which means bigger buttons, form fields and other input areas.

But with hybrid devices like touch screen Windows 8 laptops or dockable Android tablets with keyboards, how do you know whether the user is browsing with a mouse or a finger?

Over on the Mozilla Hacks blog Patrick Lauke tackles that question in an article on detecting touch-capable devices. Lauke covers the relatively simple case of touch-only, like iOS devices, before diving into the far more complex problem of hybrid devices.

Lauke’s answer? If developing for the web hasn’t already taught you this lesson, perhaps hybrid devices will — learn to live with uncertainty and accept that you can’t control everything.

What’s the solution to this new conundrum of touch-capable devices that may also have other input methods? While some developers have started to look at complementing a touch feature detection with additional user agent sniffing, I believe that the answer – as in so many other cases in web development – is to accept that we can’t fully detect or control how our users will interact with our web sites and applications, and to be input-agnostic. Instead of making assumptions, our code should cater for all eventualities.

While learning to live with uncertainty and providing interfaces that work with any input sounds nice in theory, developers are bound to want something a bit more concrete. There’s some hope on the horizon. Microsoft has proposed the Pointer Events spec (and created a build of Webkit that supports it). And the CSS Media Queries Level 4 spec will offer a pointer query to see what sort of input device is being used (mouse, finger, stylus etc).

Unfortunately, neither Pointer Events nor Media Queries Level 4 are supported in today’s browsers. Eventually there probably will be some way to easily detect and know for certain which input device is being used, but for the time being you’re going to have to live with some level of uncertainty. Be sure to read through Lauke’s post for more details and some sample code.

0
Your rating: None
Original author: 
Scott Gilbertson

Photo: Ariel Zambelich/Wired.com

Building responsive websites means that your design has to adapt to different screen sizes. We’ve covered a number of ways to do that in the past, including working with percentage widths, em-based type and other flexible techniques of responsive design.

There’s another way to achieve flexibility that doesn’t involve keeping track of ems or percentages — the new CSS REM unit. REMs are just like ems — REM stands for Root Em — but instead of being relative to the parent element like Ems, REMs are relative to the document root’s font size. Most of the time that means the html element.

We’ve previously looked at REMs as a way to achieve fluid typography, but REMs can help with more than just type sizing.

Mobify’s Roman Rudenko has an article on CSS-Tricks that shows how to use REM units to scale specific page elements while leaving others unaffected. Rudenko even shows how you can use REM units as a replacement for the very powerful, but not very well supported, viewport width unit.

For those wondering why you might want to resize some elements and not others, here’s Rudenko’s use case:

This style of sizing can be useful for user-driven customization, or to adapt layouts for cases that require secondary elements to be more touchable (tablet) or visible (TV). Without REM, every adjustable element would have to be resized separately.

This technique can be applied to whole pages as well. For example, if your type is all sized in REMs and you want it to be a bit larger as screen sizes get bigger, all you need to do is adjust the font size on the html element with each media query and all your REM-sized type will get bigger based on that single line of code.

For more on REMs and what you can do with them be sure to check out Rudenko’s post and our earlier write up.

0
Your rating: None

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

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 BostonGlobe.com 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.

0
Your rating: None

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.

0
Your rating: None

A handful of the many screens your responsive designs must handle. Photo: Ariel Zambelich/Wired.com

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.

0
Your rating: None

A handful of the many canvases your site will adorn. Photo: Ariel Zambelich/Wired.com

When most of us see the phrase responsive design we think of Ethan Marcotte’s original definition — fluid grids, flexible images and media queries. While those are the essential elements of responsive design, developer Jeremy Keith says that designing responsively also means approaching your designs with a different mindset.

There’s a video (regrettably not embeddable) of Keith’s talk on “responsive enhancement” at the recent Webdagene conference in Oslo where he argues that, to design responsively, we need to drop our “consensual hallucination” about what a website is. Much as we might like it to be, a website is not a fixed canvas. It’s not the 600px-wide canvas we used in the 1990s, nor is it the 960px-wide canvas that’s de rigueur today. A website has no width and never has.

Part of the reason responsive design sometimes feels foreign is that legacy of thinking that websites are things with widths. As Keith says “we didn’t embrace the inherent flexibility of the web, we didn’t see it as a feature, we saw it as a bug.” And so we built fixed-width sites for what was and still is an inherently flexible medium.

Keith’s talk gives a great overview of why responsive design is actually what the web has always been and how you can embrace that inherent flexibility in the web. It’s a must-watch for anyone interested in building great websites.

0
Your rating: None

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.

0
Your rating: None

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.

0
Your rating: None

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.”

0
Your rating: None