The usage trend tends to be more and more focussed on mobiles and tablets. The web is (and will be) more and more mobile and accessible from anywhere, under largely heterogeneous conditions. We cannot rely anymore on site statistics to know for which specific hardware and software configuration a web site should be aimed, as there is no ideal model user anymore (we can safely say there never was any, though).
If the marketing trend is to focus on sites dedicated to iPhone or iPad due to their penetration rate, it is inconceivable not to be aware of all the other devices, whether present or future, which characteristics differ (or will differ more and more).
We now need to adapt to a changing technology landscape, in terms of devices (I specifically think about the already well-established tablets) as well as of way of use (couch surfing in front of the TV for tablets, anywhere for mobiles, and less and less fixed computers in relative proportions).
To follow this evolution, it is time to rethink the way content is architectured to publish the same content on all devices. And first, we need to break the received ideas: the mobile web does not exist, there is only content being displayed differently according to the devices capabilities (and we know it for quite a long time already).
Likewise, it is hard to judge the context of use of mobiles in advance. The mobile user is not, as we imagined them not long ago, someone on the move looking for a precise piece of data in a hurry, quite the contrary.
Responsive web design helps your content being accessible whatever the way it is consumed. As it will be implemented in your organization, from the mere design layout adaptation of your site to the deep rethinking of your content processes, you will see the core meaning value of your site emerging, which are content and service.
First of all, let's quickly go through two definitions.
With the advent of HTML5 and CSS3, and their slow adaptation rate by the browsers on the market (saying nothing about their update rate by the users), two words have appeared in our day-to-day vocabulary: shims and polyfills.
A shim is an application compatibility workaround for backward compatibility (like simulating DOS on Windows).
A polyfill is a shim mimicking a future API to provide a feature not yet supported by old browsers (as defined by Paul Irish).
Generally speaking, a polyfill is a javascript plugin that enables an (old) browser that does not yet support an actual (or future) standard to support it (as it was not existing when it was released). We can cite for instance the rounded corners (border-radius) support for IE6-9 (see CSS3 Pie).
Here is a polyfills list for HTML5 and CSS3/4.
CSS3 media queries enable the adaptation of the displayed content according to the screen size (and its orientation). They directly ask the question of content architecture (what to show on which screens to focus on the more useful information when the space is rare, thus getting rid of the superfluous or pushing it to the bottom of the page), but also the question of ergonomy.
For example, the menu display can change according to the device: tabs or text links on large screens replaced by a select box on smaller ones (see the CSS Tricks solution). Likewise, tabular data can be pushed forward to a secondary screen available on demand (implemented in that example).
Respond.js is a usefull polyfill for the min/max-width media queries (IE6-8 and others).
In the following example, the content layout is reduced alongside the viewport width: picture, then menu, and at last content span, until the design is minified to focus on the content itself. The superfluous moves away to give room to the mere content.
An ideal responsive design solution should adapt to every screen sizes by being totally fluid (think about percentages everywhere). Nevertheless, it is common to support small screen phones (240x320), the iPhone (320x480), small tablets (480x600), the iPad (768x1024), and wider computer (and TV) screens, in both portrait and landscape orientation.
We thus get that series of media queries we could go on with to support even wider screens:
The RESS approach, for Responsive Web Design with Server Side Components, goes further by working also on the server side. We are talking here about fitting the display to the device, including their performances (download speed, pictures size, video support) and the user experience, partly dependent on the interaction model (touch screen, mouse, clickwheel). The device detection is performed via a database of device features (for instance wurfl), and the different variables of the device are stored in a cookie. Only the supported and adapted content is sent to the client. Anders Andersen presents the challenges of it.
In the client-side approach, all the content is sent, and javascript is used to manage the interaction and display parts (I am thinking here about Modernizr).
If the CSS resizing is a viable first-level solution, it goes like HTML resizing via the width and height attributes of the img tag: the image sent is still as heavy as before. The idea is to send a picture of a different size according to the device used (its viewport), but also to the network speed, the screen orientation, the pixels density (dpi)…
The WhatWG (Web Hypertext Application Technology Working Group) is working on the srcset attribute that lists a series of images and screen features.
In parallel, the RICG (Responsive Images Community Group) from W3C is working on other possible proposals, like the <picture> tag for which polyfills have already been developped (see Mat Marquis' article Responsive Images and Web Standards at the Turning Point on A list apart).
Although it is still too early to tell which implementation will be adopted as a standard supported by the browsers, the <picture> tag is already working for the community.
This is a good example of how the web is evolving nowadays, from everywhere at the same time: W3C for standards (and its bias for XHTML), WhatWG (Apple, Mozilla, Opera, or “the manufacturers”) with their own vision of HTML, and the community which no longer seems to agree to be dictated its tools (hence the polyfills built on top of jQuery).
Here are some tools to test a site from the comfort of your computer:
If the marketing trend is to focus on sites dedicated to iPhone or iPad due to their penetration rate, it is inconceivable not to be aware of all the other devices, whether present or future, which characteristics differ (or will differ more and more).
We now need to adapt to a changing technology landscape, in terms of devices (I specifically think about the already well-established tablets) as well as of way of use (couch surfing in front of the TV for tablets, anywhere for mobiles, and less and less fixed computers in relative proportions).
To follow this evolution, it is time to rethink the way content is architectured to publish the same content on all devices. And first, we need to break the received ideas: the mobile web does not exist, there is only content being displayed differently according to the devices capabilities (and we know it for quite a long time already).
Likewise, it is hard to judge the context of use of mobiles in advance. The mobile user is not, as we imagined them not long ago, someone on the move looking for a precise piece of data in a hurry, quite the contrary.
What can we do to adapt ourselves to this moving landscape?
Responsive web design helps your content being accessible whatever the way it is consumed. As it will be implemented in your organization, from the mere design layout adaptation of your site to the deep rethinking of your content processes, you will see the core meaning value of your site emerging, which are content and service.
Definitions
First of all, let's quickly go through two definitions.
With the advent of HTML5 and CSS3, and their slow adaptation rate by the browsers on the market (saying nothing about their update rate by the users), two words have appeared in our day-to-day vocabulary: shims and polyfills.
A shim is an application compatibility workaround for backward compatibility (like simulating DOS on Windows).
A polyfill is a shim mimicking a future API to provide a feature not yet supported by old browsers (as defined by Paul Irish).
Generally speaking, a polyfill is a javascript plugin that enables an (old) browser that does not yet support an actual (or future) standard to support it (as it was not existing when it was released). We can cite for instance the rounded corners (border-radius) support for IE6-9 (see CSS3 Pie).
Here is a polyfills list for HTML5 and CSS3/4.
CSS and media query
CSS3 media queries enable the adaptation of the displayed content according to the screen size (and its orientation). They directly ask the question of content architecture (what to show on which screens to focus on the more useful information when the space is rare, thus getting rid of the superfluous or pushing it to the bottom of the page), but also the question of ergonomy.
For example, the menu display can change according to the device: tabs or text links on large screens replaced by a select box on smaller ones (see the CSS Tricks solution). Likewise, tabular data can be pushed forward to a secondary screen available on demand (implemented in that example).
Respond.js is a usefull polyfill for the min/max-width media queries (IE6-8 and others).
An example in picture
In the following example, the content layout is reduced alongside the viewport width: picture, then menu, and at last content span, until the design is minified to focus on the content itself. The superfluous moves away to give room to the mere content.
Which screens width support?
An ideal responsive design solution should adapt to every screen sizes by being totally fluid (think about percentages everywhere). Nevertheless, it is common to support small screen phones (240x320), the iPhone (320x480), small tablets (480x600), the iPad (768x1024), and wider computer (and TV) screens, in both portrait and landscape orientation.
We thus get that series of media queries we could go on with to support even wider screens:
@media only screen and (min-width: 240px) and (max-width: 319px) {}
@media only screen and (min-width: 320px) and (max-width: 479px) {}
@media only screen and (min-width: 480px) and (max-width: 599px) {}
@media only screen and (min-width: 600px) and (max-width: 767px) {}
@media only screen and (min-width: 768px) and (max-width: 799px) {}
@media only screen and (min-width: 800px) and (max-width: 1023px) {}
@media only screen and (min-width: 1024px) {}
Going further
RESS
The RESS approach, for Responsive Web Design with Server Side Components, goes further by working also on the server side. We are talking here about fitting the display to the device, including their performances (download speed, pictures size, video support) and the user experience, partly dependent on the interaction model (touch screen, mouse, clickwheel). The device detection is performed via a database of device features (for instance wurfl), and the different variables of the device are stored in a cookie. Only the supported and adapted content is sent to the client. Anders Andersen presents the challenges of it.
In the client-side approach, all the content is sent, and javascript is used to manage the interaction and display parts (I am thinking here about Modernizr).
The challenge of adaptative images
If the CSS resizing is a viable first-level solution, it goes like HTML resizing via the width and height attributes of the img tag: the image sent is still as heavy as before. The idea is to send a picture of a different size according to the device used (its viewport), but also to the network speed, the screen orientation, the pixels density (dpi)…
The WhatWG (Web Hypertext Application Technology Working Group) is working on the srcset attribute that lists a series of images and screen features.
In parallel, the RICG (Responsive Images Community Group) from W3C is working on other possible proposals, like the <picture> tag for which polyfills have already been developped (see Mat Marquis' article Responsive Images and Web Standards at the Turning Point on A list apart).
Although it is still too early to tell which implementation will be adopted as a standard supported by the browsers, the <picture> tag is already working for the community.
This is a good example of how the web is evolving nowadays, from everywhere at the same time: W3C for standards (and its bias for XHTML), WhatWG (Apple, Mozilla, Opera, or “the manufacturers”) with their own vision of HTML, and the community which no longer seems to agree to be dictated its tools (hence the polyfills built on top of jQuery).
A bit of reading
- Responsive Web Design, by Ethan Marcotte, published by A Book Apart, is the book to read to get the whole view on this subject.
- Mobile First, by Luke Wroblewski, in the same collection, is a rather good companion book.
Bookmarks
Here are some tools to test a site from the comfort of your computer:
Conception web adaptative (in French)
El diseño web adaptativo (in Spanish)
O web design responsivo (in Portuguese)
No comments:
Post a Comment