Archive for the ‘Responsive Design’ Category

The Two Flavors of a ‘One Web’ Approach: Responsive vs. Adaptive

[Editor’s note: The following is a guest post from Igor Faletski, CEO of Mobify, which provides tools for adapting web sites for smartphones and tablets.]

You’ve probably heard people say we’re living in a “post-PC world.” What does that mean for web developers? It means that 30% to 50% of your website’s traffic now comes from mobile devices. It means that soon, desktop and laptop users will be in a minority on the web.

How do we deal with this tectonic shift in user behavior? We’ve moved beyond the era of m-dot or t-dot hacks, into one where responsive and adaptive design techniques rule the day — what the W3C calls a One Web approach. The key part of the W3C’s recommendation is that “One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using.”

For developers that means that taking a One Web approach ensures that not only does your site work on the smartphones and tablets of today, but it can be future-proofed for the unimagined screens of tomorrow.

There are currently three popular approaches to developing a One Web site: using a responsive design; client-side adaptive designs; and server-side adaptive designs.

One is not better or worse than the other; each has its own strengths and weaknesses and the wise web developer will consider the benefits and drawbacks of each before picking the one that works for their next project.

Responsive Web Design

Responsive web design is the most common One Web approach. The approach uses CSS media queries to modify the presentation of a website based on the size of the device display. The number of responsive sites is rapidly increasing, from the Boston Globe to Disney to Indochino.

A key advantage of this approach is that designers can use a single template for all devices, and just use CSS to determine how content is rendered on different screen sizes. Plus, those designers can still work in HTML and CSS, technologies they’re already familiar with. Additionally, there’s a growing number of responsive-friendly, open-source toolkits like Bootstrap or Foundation which help simplify the process of building responsive sites.

On the other hand, there are few shortcuts to a sound responsive design. To go responsive, organizations often have to undertake a complete site rebuild.

The design and testing phase can be quite fussy, as it can be difficult to customize the user experience for every possible device or context. We’ve all seen responsive site layouts that look like a bunch of puzzle pieces that don’t quite fit together. Responsive web design works best in combination with a mobile-first approach, where the mobile use case is prioritized during development. Progressive enhancement is then used to address tablet and desktop use cases.

Performance can also be a bugbear for responsive sites. At Mobify, we recently completed an analysis of 15 popular responsive e-commerce sites. Among these sites, the home pages loaded an average of 87 resources and 1.9 MB of data. Some responsive pages were as big as 15MB.

The numbers are that high because a responsive approach covers all devices. Your user is only using one device, but they have to wait for all of the page elements and resources to load before they can use it. Put simply, performance affects your bottom line. On smartphones, the conversion rate drops by an extra 3.5 percent when users have to wait just one second. By the three second mark, 57 percent of users will have left your site completely.

While responsive design is fast becoming the de facto standard, it also creates new challenges for online businesses, including how to handle images, how to optimize mobile performance and often means sites need to be rebuilt from the ground up with a mobile first approach.

Client-Side Adaptive

Adaptive design builds on the principles of responsive design to deliver user experiences that are targeted at specific devices and contexts. It uses JavaScript to enrich websites with advanced functionality and customization. For example, adaptive websites deliver Retina-quality images only to Retina displays (such as the new iPad) while standard-definition displays receive lower-quality images.

There are two approaches to adaptive design — one where the adaptations occur on the client side, in the user’s browser, and another where the web server does the heavy lifting of detecting various devices and loading the correct template. Examples of client-side adaptive sites include Threadless and ideeli. One of the strengths of the adaptive templating approach is the ability to reuse one set of HTML and JavaScript across devices, simplifying change management and testing.

A client-side adaptive approach means you don’t have to rebuild your site from the ground up. Instead you can build on existing content while still delivering a mobile-responsive layout. For expert developers, this approach also enables you to specifically target particular devices or screen resolutions. For example, for many of Mobify’s online fashion retail clients, 95% of their mobile traffic comes from iPhones. Client-side adaptive means they can optimize specifically for Apple smartphones.

Unlike responsive design, adaptive templates ensure that only the required resources are loaded by the client’s device. Because device and feature detection is shifted to the mobile device itself, CDN networks like Akamai and Edgecast can use most of their caching functionality without disrupting the user experience.

The client-side adaptive approach has a higher barrier to entry than responsive design. Developers need to have a solid grasp of JavaScript to use this technique. It also depends on a site’s existing templates as the foundation. Finally, because the client-side adaptations are a kind of layer on top of your existing code base, you need to maintain them as your site as a whole evolves.

Server-Side Adaptive

We can achieve the server-side adaptive approach in a variety of ways, through server-side plugins and custom user agent detection. Sites that use server-side adaptive include Etsy, One Kings Lane and OnlineShoes.com.

Why choose server-side adaptive? It typically offers distinct templates for each devices, enabling more customization, and it keeps device-detection logic on the server, enabling smaller mobile pages that load faster. Additionally, there are numerous server-side plugins available for common CMSs and eCommerce systems such as Magento.

This approach isn’t for the faint of heart–it typically requires significant changes to your back-end systems, which can result in a lengthy (and costly) implementation. The requirement to manage multiple templates raises ongoing maintenance costs. Finally, this approach can encounter performance issues when servers are under heavy load. When mobile user agent detection is performed on the server, a lot of common caching mechanisms deployed by CDNs like Akamai need to be turned off. This can result in a slower user experience for mobile and desktop visitors.

Of course, many companies are still wrestling with the basics of responsive, and they’re not ready to confront the more sophisticated flavors of adaptive. Increasingly, competition and mobile traffic, however, will drive more and more organizations to kick the tires on all three approaches, and pick the one that works best for their users.

File Under: Responsive Design, UI/UX

What the Tablet-Laptop Hybrid Means for Web Developers

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.

File Under: CSS, Responsive Design

Resizing Responsive Designs with CSS REMs

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.

Mobile Browsers Help Users Avoid Bloated Webpages

Stop feeding your website donuts. Image: D. Sharon Pruitt/Flickr.

Websites are getting fatter, dramatically fatter, with the average page size of sites tracked by the HTTPArchive now nearly 1.3 MB. If the current rate of page size increase continues, that number will reach 2MB sometime early next year.

That’s bad for pretty much everyone, but doubly so for mobile users with constrained bandwidth.

Fortunately for mobile users, the network increasingly seems to see large page sizes as damage to route around.

Services like Instapaper, Pocket or Safari’s Reader have long offered an easy way to strip out extraneous content. Now mobile web browsers are increasingly taking it upon themselves to speed up the bloated web.

The recently unveiled WebKit-based Opera Mobile borrows Opera Mini’s proxy-based Turbo Mode, or “Off Road” mode as it’s known now. Once only deemed necessary for feature phones (Opera Mini’s primary market) proxy-based browsing will soon be available in all Opera browsers.

Google’s Chrome for Android browser is getting ready to follow suit.

The beta channel release of Chrome for Android recently introduced an experimental data compression feature which Google says will “yield substantial bandwidth savings.” Chrome’s compression is nowhere near the level of Opera’s, but it does roughly the same thing — puts a proxy server between the user and the bloated site in question and then applies various speed improvements like using the SPDY protocol and compressing images with WebP.

To turn on the compression head to chrome:flags and look for the “enable experimental data compression” option.

Here’s Google’s description of the various optimizations:

For an average web page, over 60% of the transferred bytes are images. The proxy optimizes and transcodes all images to the WebP format, which requires fewer bytes than other popular formats, such as JPEG and PNG. The proxy also performs intelligent compression and minification of HTML, JavaScript and CSS resources, which removes unnecessary whitespace, comments, and other metadata which are not essential to render the page. These optimizations, combined with mandatory gzip compression for all resources, can result in substantial bandwidth savings.

In other words, Google and Opera are doing what web developers ought to be doing but aren’t. Just like developers should have been making reader-friendly pages, but weren’t, so “reader” modes were born.

It works too. In the video embedded below Google’s Pete Le Page shows how Chrome’s new proxy options take a page from The Verge and reduce it from a husky 1.9MB to a still fat, but somewhat better 1.2MB.

Want to make sure the internet doesn’t see your site as damage it needs to route around? Check out developer Brad Frost’s article Prioritizing Performance in Responsive Design, which has a ton of great advice and links, including what I think is the most important thing developers can do: Treat Performance As Design. In other words, if your site isn’t svelte and fast, it’s not well designed no matter how pretty it might look.

[Note: It is not ironic to post about web page bloat on a page that is, arguably, pretty bloated.]

Stop Squinting at Your Screen Thanks to This Responsive Type Experiment

Tracking Webmonkey. Image: Screenshot/Webmonkey.

Responsive design typically focuses on screen sizes, but that’s just the practical application of the larger goal — making a website function well no matter how or where you are viewing it. The emphasis ultimately is on you, not your device.

Developer Marko Dugonjić takes responsive design’s emphasis on you to new levels of interactivity with his experiment in typesetting by face detection.

Using a very cool JavaScript headtracking library — which taps WebRTC and getUserMedia to access your webcam — Dugonjić’s app calculates how close you are to the screen and adjusts the font size to make text more readable.

To see it in action, head on over to the demo page and grant it permission to use your webcam. For the most useful example, check out the onload-based implementation, but for a better sense of how it works be sure to try the “Realtime” version.

It may not be the most practical experiment and how well it works depends on plenty of factors well beyond the control of the site (how good your eyes are, whether or not you’re wearing your glasses and so on), but it’s not hard to imagine how this could be very useful in some situations — for example, bumping up font-size when your site is displayed on a television.

When you’re done playing with the resizing demo be sure to check out Dugonjić’s more practical and more immediately useful Typetester.