L'évolution des usages s'oriente de plus en plus vers les dispositifs mobiles et les tablettes. Le web est (et sera) de plus en plus mobile et accessible de n'importe où, dans des conditions largement hétérogènes. On ne peut maintenant plus se baser sur les statistiques de visite des sites pour savoir pour quelle configuration particulière de matériel et de logiciel un site doit être conçu, puisqu'il n'y a plus d'utilisateur modèle idéal (y en a-t-il d'ailleurs jamais eu ?).
Si la tendance du marketing est de s'orienter vers des sites spécialement dédiés à l'iPhone ou à l'iPad vu leur taux de pénétration, il est inconcevable de se fermer à tous les autres dispositifs actuels et à venir dont les caractéristiques diffèrent et diffèreront de plus en plus.
Il faut maintenant s'adapter à un paysage technologique changeant, tant en terme des dispositifs utilisés (je pense notamment aux tablettes d'ores et déjà bien implantées) que des modalités d'usage (couch surfing devant la télé pour les tablettes, n'importe où pour les mobiles, et de moins en moins d'ordinateurs fixes en parts relatives).
Pour suivre cette évolution, il est temps de repenser celle du contenu et de son architecture pour publier le même contenu sur tous les dispositifs. Et d'abord, briser les idées reçues : le web mobile n'existe pas, il n'y a que du contenu qui s'affiche différemment selon les dispositifs utilisés (et on le sait depuis quelques temps déjà).
De même, il est difficile de préjuger du contexte d'utilisation des mobiles. L'utilisateur mobile n'est pas comme on l'imaginait il y a peu une personne en déplacement qui cherche une information précise dans une certaine urgence, bien au contraire.
La conception web adaptative (ou responsive web design) permet à votre contenu d'être accessible quelle que soit la situation d'usage. Au fur et à mesure de sa mise en place dans votre organisation, de la simple adaptation du design de votre site à la refonte en profondeur de votre gestion de contenu, vous verrez émerger le cœur de votre raison d'être : le contenu et le service.
Tout d'abord, voyons rapidement deux définitions.
Avec l'avènement du HTML5 et du CSS3, et la lenteur d'adaptation des navigateurs sur le marché (et de leur mise à jour par les utilisateurs), deux mots sont apparus dans notre vocabulaire : les shims et les polyfills.
Un shim est une solution de contournement de compatibilité des applications pour leur assurer une compatibilité descendante (comme simuler le DOS sous Windows).
Un polyfill est un shim qui imite une API future en fournissant une fonctionnalité non supportée par les anciens navigateurs (définition de Paul Irish).
Généralement, un polyfill est un plugin javascript qui permet à un navigateur ancien ou qui ne supporte pas encore un standard actuel ou à venir de le supporter (puisqu'il n'existait pas à son époque). On peut citer par exemple le support des coins arrondis (border-radius) sous IE6-9 (CSS3 Pie).
Voici une liste de polyfills HTML5 et CSS3/4.
Les media queries du CSS3 permettent l'adaptation du contenu affiché suivant la taille des écrans (et leur orientation). Elles posent directement la question de l'architecture du contenu (quoi afficher sur quels écrans afin de se concentrer sur l'information la plus utile lorsque la place manque et donc supprimer le superflu ou le repousser plus bas), mais aussi celle de l'ergonomie.
Par exemple, le type de menu peut varier suivant le dispositif : onglets ou liens texte sur écrans larges, remplacés par une boîte de sélection sur les écrans plus petits (voir la solution de CSS Tricks). Ou encore, des données tabulaires peuvent être repoussées dans un écran secondaire accessible sur demande (voir cet exemple).
Respond.js est un polyfill pour les media queries min/max-width (IE6-8 et autres).
Dans l'exemple suivant, le contenu se réduit en même temps que la largeur de la fenêtre : image, puis menu, et enfin surface utile, jusqu'à la minimalisation du design pour se concentrer sur le contenu lui-même. Le superflu s'efface et laisse la place au contenu.
Une solution de responsive design idéale devrait s'adapter à toutes les tailles d'écran en étant complètement fluide (pensez pourcentages à tous les étages). Cependant, il est courant de supporter les téléphones de petite taille (240x320), l'iPhone (320x480), les petites tablettes (480x600), l'iPad (768x1024) et les écrans d'ordinateurs (ou de télévision) plus grands, que ce soit en mode portrait ou paysage.
On obtient donc la série de media queries suivante, que l'on pourrait continuer pour supporter des écrans plus grands :
L'approche RESS, pour Responsive Web Design with Server Side Components, va plus loin en travaillant aussi côté serveur. Il s'agit d'ajuster l'affichage suivant les dispositifs utilisés, mais aussi leur performance (vitesse de téléchargement, taille des images, support vidéo) et l'expérience utilisateur, en partie dépendant du modèle d'interaction (écran tactile, souris, molette cliquable ou clickwheel). La détection du dispositif se fait via une base de données (par exemple wurfl), et les différentes variables du dispositif sont stockées sous forme de cookie. Seuls les contenus supportés et adaptés sont envoyés au client. Cette présentation de Anders Andersen en fait un exposé rapide.
Par opposition, dans l'approche côté client, tout le contenu est envoyé, à charge au javascript par exemple (je pense ici à Modernizr) de gérer la partie interaction et affichage.
Si le redimensionnement en CSS est une première solution viable, il en va comme pour le redimensionnement HTML via les attributs width et height de la balise img : l'image envoyée est toujours aussi lourde. L'approche consiste donc à envoyer des images de taille différente suivant le dispositif utilisé (sa zone d'affichage utile, ou viewport), mais aussi la vitesse du réseau, l'orientation de l'écran, la densité de pixels (dpi)…
Le WhatWG (Web Hypertext Application Technology Working Group) travaille actuellement sur l'attribut srcset qui liste une série d'images suivant la taille de l'écran.
En parallèle, le RICG (Responsive Images Community Group) du W3C planche sur d'autres propositions possibles, dont la balise <picture> pour laquelle des polyfills ont déjà été développés (voir l'article Responsive Images and Web Standards at the Turning Point de Mat Marquis sur A list apart).
Bien qu'il soit encore trop tôt pour se prononcer sur quelle implémentation sera proposée comme standard et supportée par les navigateurs, la balise <picture> est d'ores et déjà viable pour la communauté. On notera d'ailleurs que le HTML évolue de tous les côtés en même temps : le W3C pour les standards (et son biais vers le XHTML), le WhatWG (Apple, Mozilla, Opera, ou les « constructeurs ») avec leur propre vision du HTML, et la communauté qui ne semble plus vouloir se faire dicter ses outils (d'où les polyfills bâtis sur jQuery).
Voici quelques outils de test en ligne :
Si la tendance du marketing est de s'orienter vers des sites spécialement dédiés à l'iPhone ou à l'iPad vu leur taux de pénétration, il est inconcevable de se fermer à tous les autres dispositifs actuels et à venir dont les caractéristiques diffèrent et diffèreront de plus en plus.
Il faut maintenant s'adapter à un paysage technologique changeant, tant en terme des dispositifs utilisés (je pense notamment aux tablettes d'ores et déjà bien implantées) que des modalités d'usage (couch surfing devant la télé pour les tablettes, n'importe où pour les mobiles, et de moins en moins d'ordinateurs fixes en parts relatives).
Pour suivre cette évolution, il est temps de repenser celle du contenu et de son architecture pour publier le même contenu sur tous les dispositifs. Et d'abord, briser les idées reçues : le web mobile n'existe pas, il n'y a que du contenu qui s'affiche différemment selon les dispositifs utilisés (et on le sait depuis quelques temps déjà).
De même, il est difficile de préjuger du contexte d'utilisation des mobiles. L'utilisateur mobile n'est pas comme on l'imaginait il y a peu une personne en déplacement qui cherche une information précise dans une certaine urgence, bien au contraire.
Que faire alors pour s'adapter à ce paysage changeant ?
La conception web adaptative (ou responsive web design) permet à votre contenu d'être accessible quelle que soit la situation d'usage. Au fur et à mesure de sa mise en place dans votre organisation, de la simple adaptation du design de votre site à la refonte en profondeur de votre gestion de contenu, vous verrez émerger le cœur de votre raison d'être : le contenu et le service.
Définitions
Tout d'abord, voyons rapidement deux définitions.
Avec l'avènement du HTML5 et du CSS3, et la lenteur d'adaptation des navigateurs sur le marché (et de leur mise à jour par les utilisateurs), deux mots sont apparus dans notre vocabulaire : les shims et les polyfills.
Un shim est une solution de contournement de compatibilité des applications pour leur assurer une compatibilité descendante (comme simuler le DOS sous Windows).
Un polyfill est un shim qui imite une API future en fournissant une fonctionnalité non supportée par les anciens navigateurs (définition de Paul Irish).
Généralement, un polyfill est un plugin javascript qui permet à un navigateur ancien ou qui ne supporte pas encore un standard actuel ou à venir de le supporter (puisqu'il n'existait pas à son époque). On peut citer par exemple le support des coins arrondis (border-radius) sous IE6-9 (CSS3 Pie).
Voici une liste de polyfills HTML5 et CSS3/4.
CSS et media query
Les media queries du CSS3 permettent l'adaptation du contenu affiché suivant la taille des écrans (et leur orientation). Elles posent directement la question de l'architecture du contenu (quoi afficher sur quels écrans afin de se concentrer sur l'information la plus utile lorsque la place manque et donc supprimer le superflu ou le repousser plus bas), mais aussi celle de l'ergonomie.
Par exemple, le type de menu peut varier suivant le dispositif : onglets ou liens texte sur écrans larges, remplacés par une boîte de sélection sur les écrans plus petits (voir la solution de CSS Tricks). Ou encore, des données tabulaires peuvent être repoussées dans un écran secondaire accessible sur demande (voir cet exemple).
Respond.js est un polyfill pour les media queries min/max-width (IE6-8 et autres).
Un exemple en image
Dans l'exemple suivant, le contenu se réduit en même temps que la largeur de la fenêtre : image, puis menu, et enfin surface utile, jusqu'à la minimalisation du design pour se concentrer sur le contenu lui-même. Le superflu s'efface et laisse la place au contenu.
Quelles largeurs d'écran supporter ?
Une solution de responsive design idéale devrait s'adapter à toutes les tailles d'écran en étant complètement fluide (pensez pourcentages à tous les étages). Cependant, il est courant de supporter les téléphones de petite taille (240x320), l'iPhone (320x480), les petites tablettes (480x600), l'iPad (768x1024) et les écrans d'ordinateurs (ou de télévision) plus grands, que ce soit en mode portrait ou paysage.
On obtient donc la série de media queries suivante, que l'on pourrait continuer pour supporter des écrans plus grands :
@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) {}
Aller plus loin
RESS
L'approche RESS, pour Responsive Web Design with Server Side Components, va plus loin en travaillant aussi côté serveur. Il s'agit d'ajuster l'affichage suivant les dispositifs utilisés, mais aussi leur performance (vitesse de téléchargement, taille des images, support vidéo) et l'expérience utilisateur, en partie dépendant du modèle d'interaction (écran tactile, souris, molette cliquable ou clickwheel). La détection du dispositif se fait via une base de données (par exemple wurfl), et les différentes variables du dispositif sont stockées sous forme de cookie. Seuls les contenus supportés et adaptés sont envoyés au client. Cette présentation de Anders Andersen en fait un exposé rapide.
Par opposition, dans l'approche côté client, tout le contenu est envoyé, à charge au javascript par exemple (je pense ici à Modernizr) de gérer la partie interaction et affichage.
Le challenge des images adaptatives
Si le redimensionnement en CSS est une première solution viable, il en va comme pour le redimensionnement HTML via les attributs width et height de la balise img : l'image envoyée est toujours aussi lourde. L'approche consiste donc à envoyer des images de taille différente suivant le dispositif utilisé (sa zone d'affichage utile, ou viewport), mais aussi la vitesse du réseau, l'orientation de l'écran, la densité de pixels (dpi)…
Le WhatWG (Web Hypertext Application Technology Working Group) travaille actuellement sur l'attribut srcset qui liste une série d'images suivant la taille de l'écran.
En parallèle, le RICG (Responsive Images Community Group) du W3C planche sur d'autres propositions possibles, dont la balise <picture> pour laquelle des polyfills ont déjà été développés (voir l'article Responsive Images and Web Standards at the Turning Point de Mat Marquis sur A list apart).
Bien qu'il soit encore trop tôt pour se prononcer sur quelle implémentation sera proposée comme standard et supportée par les navigateurs, la balise <picture> est d'ores et déjà viable pour la communauté. On notera d'ailleurs que le HTML évolue de tous les côtés en même temps : le W3C pour les standards (et son biais vers le XHTML), le WhatWG (Apple, Mozilla, Opera, ou les « constructeurs ») avec leur propre vision du HTML, et la communauté qui ne semble plus vouloir se faire dicter ses outils (d'où les polyfills bâtis sur jQuery).
Un peu de lecture
- Responsive Web Design (en anglais), par Ethan Marcotte, aux éditions A Book Apart, est un ouvrage à lire absolument pour faire le tour de la question (version française aux éditions Eyrolles).
- Mobile First (en anglais), par Luke Wroblewski, dans la même collection, le complète plutôt bien.
Bookmarks
Voici quelques outils de test en ligne :
Responsive web design (en anglais)
El diseño web adaptativo (en espagnol)
O web design responsivo (en portugais)
Aucun commentaire:
Enregistrer un commentaire