Webdesign

Responsive Webdesign – présent et futur de l’adaptation mobile

La problématique du responsive est bien plus complexe que ce qu'on peut lire sur certains blogs qui essaient de nous faire croire qu'il suffit aujourd'hui, pour optimiser un site pour mobile, d'ajouter 2 Media Queries pour l'iPhone et l'iPad et redimensionner toutes les images. Le Responsive Web Design est une technique toute jeune, loin d'être parfaite et en constante évolution. Beaucoup de choses sont aujourd'hui possible, mais hélas il reste encore pas mal de chemin à parcourir dans le domaine.

Article par (Graphiste - Designer Web et mobilité, Strasbourg)
Créé le , mis à jour le (128093 lectures)
Tags : webdesign, media queries, responsive, rwd, retina, xhdpi, srcset, picture

Après plusieurs mois de recherche sur le sujet, j'ai enfin publié mon article sur Smashing Magazine qui s'intitule "The State Of Responsive Web Design". Ce qui suit en est la traduction.

Avertissement avant la lecture : Je n'ai pas la prétention de changer le monde, d'avoir la vérité absolue. Dans cet article – qui est long, je le sais – je souhaitais juste rendre attentif le lecteur au reste de ce gigantesque iceberg dont les Media Queries n'en sont que la surface. Le responsive webdesign reste une technique et une infime partie de ce qui est aujourd'hui appelé "Adaptive Webdesign". Le but de l'article n'est pas non plus de décourager les gens qui optimisent des sites pour mobile, mais de mettre le doigt sur ce qui aujourd'hui pose problème, est bancal, pour ensemble, trouver des solutions à ces différents problèmes. Pour un peu plus de détails sur le pourquoi de l'article, je vous renvoie à mon blog.

On entend parler de "Responsive Webdesign" depuis plusieurs années maintenant, et le sujet s'est vraiment démocratisé et popularisé en 2012. Brad Frost, Luke Wroblewski et d'autres grands noms commencent à avoir une certaine expérience du sujet, et aident au quotidien par leurs publications à son amélioration. Cependant, beaucoup reste encore à faire.

Iceberg

Dans cet article, nous allons nous intéresser à ce qui est aujourd'hui déjà possible en terme d'optimisation de sites pour mobiles, mais également à ce qui sera possible dans le futur. Nous parlerons de propriétés non encore standardisées comme CSS level 4, HTML5 et d'APIs, ainsi que de techniques qui restent à être améliorées. Cet article est loin d'être exhaustif et nous n'aurons pas le temps d'approfondir chaque technique mentionnée, mais vous aurez à la fin de la lecture à votre disposition suffisamment de liens pour pouvoir continuer l'exploration par vous-même.

L'état des images dans le responsive webdesign

Quelle meilleure manière d'aborder le sujet que de commencer par ce qui pose un gros souci : la gestion des images. Ce sujet n'est pas nouveau, il prend de plus en plus d'ampleur avec l'arrivée d'écrans dits "haute définition". Par ce terme j'entends des écrans avec un ratio de pixel supérieur à 2; ils sont appelés Retina chez Apple (iOS) ou encore XHDPI chez Google (Android). Quand on commence à s'intéresser aux images dans le domaine du responsive, on se retrouve confronté à deux difficultés : la taille (entendez par là leur poids en octets) et la performance.

Le site screensiz.es fait l'inventaire de la densité de pixels

Beaucoup de designers adorent le "pixel-perfect", mais les images de taille "normale" sont souvent "pixelisées" lorsqu'elles sont affichées sur des écrans haute définition. L'idée plutôt simpliste de proposer des images qui auraient deux fois (voire plus) la taille de départ pour éviter la dégradation visuelle sur ce genre d'appareil semble bien tentante. Mais qu'en est-il des problématiques de performance ? Des images dont les dimensions seraient doublées verraient leur poids multiplé mathématiquement par 4, et mettraient plus de temps à charger. Même si vos utilisateurs ont un écran haute définition, ils n'ont pas forcément, à l'instant où ils consultent votre page, la connexion qui va avec pour télécharger des images plus lourdes. En fonction du pays où se trouvent vos utilisateurs, la bande passante est d'ailleurs plus ou moins coûteuse.

Le second problème est lié aux petits appareils : pourquoi un téléphone mobile devrait avoir à télécharger une image de 750 pixels de large, alors qu'il n'a que 320 pixels physiques sur son écran pour l'afficher ? Et comment faire pour recadrer ces petites images, pour aller à l'essentiel et mettre en avant seulement la partie que l'on juge importante ?

Deux solutions du côté du code : l'élément <picture> et l'attribut srcset

On pourrait trouver dans le code que nous utilisons quotidiennement pour afficher les images un début de solution au sujet épineux des images responsive.

Le Responsive Images Community Group soutient une proposition d'un nouvel élément HTML <picture> plus flexible que ce que l'on utilise pour le moment. L'idée est d'utiliser la syntaxe des Media Queries que l'on commence à bien connaître pour faire télécharger des images différentes en fonction de l'appareil, de sorte que des petits écrans récupéreraient des images plus petites. La syntaxe de l'élément est proche de celle de <video>, chaque image étant référencée dans un sous élément <source>.

Voici à quoi ressemble le code de cette proposition :

<picture width="500" height="500">  
 <source media="(min-width: 45em)" src="large.jpg">
 <source media="(min-width: 18em)" src="med.jpg">
 <source src="small.jpg">
 <img src="small.jpg" alt="">
 <p>Texte accessible</p>
</picture>

On imagine aisément qu'il serait ainsi facile de proposer la même image en différentes tailles, mais on peut aussi imager proposer plusieurs images pour mettre l'accent sur différents éléments en fonction de la taille de l'appareil. Le use-caseArt Direction” du W3C illustre en quelques exemples de ce qu'il serait alors possible de réaliser.

Choix de DA pour la balise picture

Cette proposition est en cours de discussion auprès du W3C Responsive Images Community Group mais n'est à l'heure actuelle utilisable dans aucun navigateur. Un polyfill appelé Picturefill est disponible et permet d'émuler <picture> en JavaScript à l'aide de <div> et de data-attribute pour éviter les conflits de syntaxe le jour où <picture> sera standardisé.

En parallèle, Apple a également fait une proposition pour la syntaxe d'images responsives au W3C : The srcset Attribute. Elle est l'équivalent en HTML de la proposition CSS Level 4 image-set(). D'après les spécifications, le but de cet attribut est de forcer le navigateur (User Agent) à charger la ressource appropriée, plutôt que de lui proposer une liste de différentes ressources. Il ne s'agit donc ici non pas d'une nouvelle balise, mais de conserver <img> et de lui ajouter un nouvel attribut srcset. Voici la syntaxe décrite dans les spécifications : 

<img alt="The Breakfast Combo" 
 src="banner.jpeg"
 srcset="banner-HD.jpeg 2x, banner-phone.jpeg 640w, banner-phone-HD.jpeg 640w 2x">

Vous l'aurez remarqué, elle est loin d'être intuitive. Les valeurs sont données dans des chaînes de caractère séparées par des virgules. A l'intérieur de ces chaînes on retrouve le chemin vers l'image, une valeur de densité de pixels de l'appareil, et la taille maximum de viewport pour laquelle cette image devrait être utilisée.

En français dans le texte, voici ce que donne le code ci-dessus :

  • Par défaut l'image utilisée est banner.jpeg
  • Les appareils qui ont un ratio de pixel supérieur à 2 utiliseront banner-HD.jpeg
  • Les appareils avec un viewport inférieur à 640px utiliseront banner-phone.jpeg
  • Les appareils avec un viewport inférieur à 640px ET un ratio de pixel supérieur à 2 utiliseront banner-phone-HD.jpeg

La première source donnée dans src est l'image utilisée par défaut si cet attribut n'est pas supporté. Le suffixe 2x pour banner-HD.jpeg signifie que cette image doit être utilisée pour les écrans avec un ratio de pixel supérieur à 2. La valeur 640w pour banner-phone.jpeg représente la taille maximum du viewport pour laquelle cette image sera utilisée. En raison de la complexité technique de sa mise en place, cette syntaxe n'a pas encore été implémentée dans nos navigateurs.

La syntaxe de image-set() en CSS fonctionne de la même manière et permet de charger des images de fond qui vont dépendre des mêmes critères : 

background-image: image-set( "foo.png" 1x,
 "foo-2x.png" 2x,
 "foo-print.png" 600dpi );

La proposition pour la version CSS est pour le moment dans l'état Editor’s Draft au W3C et fonctionne dans Safari 6+ and Chrome 21+. Un article sur picture, src-set et image-set est disponible en français sur le blog Creative Juiz.

Format d'image, compression et SVG : changer la façon dont on travail avec les images sur le web

Vous aurez constaté que ces deux propositions de syntaxe pour les images sont encore au stade expérimental. Ce qui pose la problématique du format d'image en tant que tel : un début de solution serait-il à trouver de côté là ?

La première étape serait de jeter un œil du côté des formats alternatifs d'image qui proposent un meilleur taux de compression. Google par exemple a développé de son côté un nouveau format, le WebP qui propose des compressions plus importantes pour des images 26% plus petites que le PNG et 25 à 34% plus petites que le JPEG. Ce format est supporté dans Chrome, Opera, Yandex, le navigateur natif Android et Safari. Il peut être activé pour Internet Explorer en utilisant le plugin Google Chrome Frame . Cependant, Firefox ne prévoit pas d'implémenter ce format. En sachant cela, il est donc peu probable de voir (actuellement) le WebP être massivement utilisé.

Une autre idée qui gagne de plus en plus en popularité est l'utilisation d'images en JPEG progressif. Comme son nom le suggère, l'image est affichée progressivement; le premier rendu est quelque peu flou, puis l'image s'affine et devient plus nette au fur et à mesure de son téléchargement. Par comparaison, les fichiers JPEG non progressifs s'affichent de haut en bas. Ann Robson met en avant dans son article Progressive JPEGs: A New Best Practice le fait que cette compression d'image donne à l'utilisateur une plus grande impression de vitesse que les JPEG classiques. Elle permet à l'utilisateur d'avoir un premier aperçu global de l'image sans avoir à attendre qu'elle soit totalement chargée. Cette technique ne résout en rien les problèmes techniques de performance et poids de chargement des images, mais améliore, d'après son auteur, l'expérience utilisateur.

Une dernière solution (du moins dans cet article) proposée pour tenter d'améliorer l'optimisation des images est de jouer sur leur taux de compression. Pendant longtemps beaucoup pensaient qu'à trop augmenter le taux de compression d'une image, on perdait (trop) en qualité. Daan Jobsis a fait des recherches plus approfondies sur le sujet et partage ses trouvailles dans son article Retina Revolution. Dans cette expérience, il a testé différentes tailles d'image et taux de compression pour arriver à une solution intéressante : en doublant la taille des images de départ tout en utilisant un taux de compression très élevé, l'image finale a un poids plus petit que l'originale et restera nette sur les écrans "normaux" et haute définition. Avec cette technique, il a été capable de réduire à 75% du poids des images qu'il a testé.

La démonstration de la compression de Daan Jobsis

Vu le casse-tête que représente l'optimisation des images pour un site responsive, devenir indépendant des pixels absolus est une idée qui séduit de plus en plus les designers et intégrateurs. Le format SVG propose par exemple une excellente alternative, et permet de créer des éléments d'interface vectoriels qui vont s'adapter à n'importe quelle résolution d'écran. Les éléments créés en SVG vont être facilement réduits et agrandis sans perte pour les écrans à haute résolution. À cette tendance s'ajoute celle des font-icons qui permet de remplacer les glyphes d'une police d'écriture par des icônes, tout en conservant la flexibilité de la police.

Ces solutions n'étant cependant pas envisageables pour des photos, un meilleur format d'image, ou une syntaxe plus flexibles sont donc attendus avec impatience pour le futur.

Défis de mise en page : réarranger le contenu sans toucher au HTML c'est possible ?

Pour commencer, arrêtons de nous voiler la face plus longtemps : les grilles fluides construites en flottants et éléments en inline-block que l'on utilise aujourd'hui ne sont que des patchs plus ou moins solides, dans l'attente d'une meilleure solution. Jouer avec la mise en page et totalement réarranger les blocs d'une page pour un écran plus petit sans recourir au JavaScript est à l'heure actuelle cauchemardesque. Toutes les solutions à notre disposition manquent cruellement de flexibilité. Et c'est encore plus vrai quand on commence à travailler avec des sites créés sous un CMS : il est impensable de devoir modifier le HTML pour chaque taille d'écran, alors comment peut-on améliorer tout ça ?

Une mise en page plus flexible grâce à 4 solutions utilisant des propriétés CSS3

La solution flexbox

La première solution qui nous vient à l'esprit lorsque l'on pense au concept de mise en page est le module CSS3 flexible box layout model aussi connu sous le nom de flexbox. Pour le moment il a le statut de "Candidate Recommendation" au W3C mais est déjà supporté par la plupart des navigateurs récents (y compris à partir de IE10). Le support des navigateurs mobiles est d'ailleurs particulièrement bon pour ce module. Ce modèle de boîte permet de réordonner les éléments à l'écran de manière simple et totalement indépendante de leur placement dans le code HTML. Il est également possible de changer l'orientation des boîtes (box orientation), la façon dont elles se suivent (box flow) et distribuer l'espace restant et les alignements en fonction du contexte sur la page.

L'image ci-dessous présente ce qui peut être accompli pour une mise en page sur mobile à partir de la version desktop (navigateur classique de "bureau"). Et la syntaxe pour y parvenir ressemblerait à quelque chose comme ceci :

.parent {
 display: flex;
 flex-flow: column; /* afficher les éléments en colonne */
}

.children {
 order: 1; /* modifie l'ordre des éléments */
}

Illustration de flexbox

L'article en anglais CSS3 Flexible Box Layout Explained ainsi que l'article CSS3 Flexbox Layout module devraient vous aider à creuser un peu le sujet. Une autre solution proche de flexbox existe en JavaScript pour ré-ordonner les blocs dans une page : Relocate.

La solution Multi Column Layout

Une seconde technique CSS3 qui est utilisable aujourd'hui pour une mise en page responsive est le CSS3 Multi Column Layout. Ce module est passé en "Candidate Recommendation" et fonctionne pour la majorité des navigateurs récents, à l'exception de IE9 et versions inférieures. L'atout principal de ce module est la possibilité d'avoir du contenu qui va automatiquement glisser d'une colonne à une autre de manière très flexible en fonction de la taille du parent. Pour une optimisation mobile, il est donc très facile de changer la taille de la police en fonction de la taille du viewport.

Il est possible de donner une taille fixe à chaque colonne, et laisser au navigateur le soin de calculer le nombre de colonnes qui vont pouvoir rentrer dans l'espace disponible. Il est également possible de faire l'inverse : fixer un nombre de colonnes prédéfini, avec ou sans espace entre et laisser au navigateur le soin de calculer la largeur optimale pour chacune d'entre elles.

CSS multi colonnes

Voici à quoi ressemble la syntaxe :

.container {
 column-width: 10em ; /* le navigateur crée des colonnes de 10em, le nombre dépend de l'espace disponible */
}
.container {
 columns: 5; /* Le navigateur crée 5 colonnes dont la taille dépend de l'espace disponible */
 column-gap: 2em;
}

Pour en savoir plus sur ce module je vous conseille l'excellent article de David Walsh : CSS Columns et retrouvez également un article en français sur Alsacreations : Les multicolonnes en CSS3.

La solution Grid Layout

Une troisième propriété qui mériterait plus d'attention dans le futur est le module CSS3 grid layout qui propose aux designers et développeurs un système de grilles flexibles avec lesquelles ils peuvent travailler pour construire différentes mises en page. Les éléments peuvent être affichés en colonnes et en lignes sans avoir besoin de définir une structure au préalable. La première chose à faire est de déclarer une grille sur le parent, puis de placer les éléments enfants sur cette grille "virtuelle". Il est ensuite très facile de changer la grille pour des écrans plus petits, ou de changer la position de ces éléments sur la grille. Combiné à des Media Queries, ceci permettrait une gigantesque flexibilité pour l'optimisation mobile mais également les changements d'orientation.

La syntaxe du Working Draft est la suivante (à la date du 2 avril 2013) :

.parent {
  display: grid; /* déclarer la grille */
  grid-definition-columns: 1stgridsize 2ndgridsize …;
  grid-definition-rows: 1strowsize 2ndrowsize …;
}
.element {
  grid-column: 1;
  grid-row: 1
}

.element2 {
  grid-column: 1;
  grid-row: 3;
}

Comme précisé dans les spécifications, plusieurs unités sont utilisables pour exprimer la taille des lignes et colonnes de cette grille virtuelle. Pour placer les éléments sur la grille on va spécifier le numéro de colonne (grid-column) dans lequel on veut le placer, puis le numéro de la ligne (grid-row). Si l'élément s'étend sur plusieurs lignes, il est possible d'utiliser la valeur span pour préciser le nombre de lignes à étendre.

Ce système à l'air prometteur, mais il n'est hélas supporté pour le moment que sur IE10. Si vous souhaitez néanmoins en savoir plus sur cette mise en page, vous pouvez lire l'article de Rachel Andrew intitulé Giving Content Priority With CSS3 Grid Layout. Notez également que les spécifications pour cette syntaxe ont changé le 2 avril 2013 et que Rachel a rédigé une mise à jour se son article intitulée CSS Grid Layout: What Has Changed? Retrouvez également en français un article de Raphaël Goetter : CSS3 Grid layout.

La solution Template layout

La dernière technique de mise en page qui pourrait devenir intéressante dans le futur si un navigateur se décidait à l'implémenter est le module CSS3 template layout. Il permet d'associer un élément avec une zone de mise en page que l'on aura au préalable pris la peine de nommer, puis d'organiser visuellement ces éléments sur une grille invisible, encore une fois. Cette grille peut être soit fixe, soit flexible en fonction de la taille du viewport.

Voici ce à quoi ressemble la syntaxe pour le moment :

.parent {
  display: "ab"
      "cd" /* créer la grille invisible */
}
.child1 {
  position: a;
}
.child2 {
  position: b;
}
.child3 {
  position: c;
}
.child4 {
  position: d;
}

Ce qui visuellement donnerait ceci : 

CSS grid layout en action

Hélas, comme vous l'aurez deviné à mon introduction, le support de cette propriété est pour le moment inexistante. Si des designers, développeurs et intégrateurs montrent de l'intérêt pour cette syntaxe, peut-être sera-elle un jour implémentée (avec des préfixes navigateurs ?), mais en attendant vous pouvez toujours, si elle vous intéresse, la tester avec un polyfill.

De nouvelles unités relatives au viewport et la fin de la mise en page basée sur des pixels ?

Les unités comme vw, vh, vm, vmin et vmax sont proposées dans la partie "Viewport-based percentage lengths" des spécifications et sont des unités de mesure relatives à la dimension du viewport.

Un vw est par exemple égal à 1% de la largeur du conteneur initial. Si la largeur du viewport est de 320px, 1vw est égal à 1x320/100 soit 3,2pixels.

L'unité vh fonctionne de la même manière mais est relative à la hauteur du viewport. 50vh sont donc équivalents à 50% de la hauteur du document. Vous vous demandez sans doute maintenant ce qu'est la différence avec le fait d'utiliser directement une hauteur en pourcentage. Les unités en pourcentage sont relatives à la taille de leur parents, alors que vh et vw seront toujours relatives à la taille du viewport, quelle que soit la taille de leurs éléments HTML parents.

Cela devient particulièrement intéressant si vous souhaitez par exemple créer une boîte et être sûr qu'elle ne pourra jamais passer sous la hauteur du viewport (la ligne de flottaison), pour faire en sorte que l'utilisateur n'ait jamais besoin de faire défiler le contenu pour la voir. Cela permettrait également en théorie de créer des mises en page avec des éléments qui feraient 100% de la taille du navigateur mobile (donc viewport) sans avoir besoin de passer par des hacks de 100% sur tous leurs parents.

L'unité vmin est quant à elle égale à la plus petite d'entre vm ou vh, alors que vmax est égale à la plus grande. Ces unités sont donc flexibles aux changement d'orientation de l'appareil.

Hélas pour le moment ces unité ne sont pas supportées pour les mobiles sur les navigateurs Android natifs. Il va donc peut-être falloir attendre un peu avant de pouvoir les utiliser correctement.

Retrouvez quelques tests de ces unités (sur des éléments textuels et un bloc flexible) en français sur Creative Juiz.

À propos d'une typographie qui s'adapte

Au final, la mise en page d'un site reste très dépendante du contenu que l'on va y mettre. Je ne pouvais donc pas conclure une section dédiée aux possibilités de mise en page sans vous parler de typographie. CSS3 propose une nouvelle unité particulièrement utile pour la gestion de la typographie : l'unité rem. Là où la taille d'une police exprimée en em est relative à la taille de la police de ses ancêtres, la taille d'une police exprimée en rem est, et sera toujours relative à la taille de la police de l'élément racine (à savoir <html>). Pour un site responsive, il est donc possible d'écrire le code suivant, puis d'adapter la taille de toutes les polices du site d'un coup en changeant la taille de police de l'élément html :

html {
  font-size: 14px;
}
p {
  font-size: 1rem /* 14px */
}

@media screen and (max-width:380px) {

  html {
   font-size: 12px; /* rendre les polices plus petites pour mobile */
  }

  p {
   font-size: 1rem /* cet élément est désormais équivalent à 12px */
  }

}

En dehors d'IE8 et Opera mini, le support pour rem est plutôt bon. Si en savoir plus sur les unités rem vous intéresse, l'article de Matthew Lettini In Defense of Rem Units est une excellente ressource. Retrouvez également une ressource sur le sujet en français chez Pompage.net : dimensionner ses fontes avec rem.

Trouver un meilleur moyen de gérer d'autres types de contenus complexes

Nous commençons tout doucement à trouver de meilleures solutions pour gérer les images et les mises en page responsive, mais il faut encore trouver d'autres solutions pour les contenus plus complexes.

Gérer les formulaires sur un site responsive

De manière générale la gestion de formulaire, et tout particulièrement de longs formulaires, est un défi en "mobilité" (entendez par là "dans l'univers du mobile"). Plus long sera le formulaire, plus il sera compliqué à adapter pour des petits appareils. L'adaptation physique visuelle n'est pas bien compliquée ; la plupart des designers vont simplement placer les éléments les uns sous les autres en une seule colonne et élargir les champs pour qu'ils prennent toute la taille de l'écran. Mais rendre ces formulaires visuellement attractifs n'est pas suffisant : il nous faut également les rendre facile d'utilisation sur mobile.

Luke Wroblewski conseille d'éviter les champs texte quand c'est possible, et de proposer des cases à cocher, boutons radios et menus déroulants de sélection de sorte que l'utilisateur ait à entrer le moins d'informations possible au clavier. Un autre conseil important est de proposer à l'utilisateur les retours quant à la validité des champs avant qu'il appuie sur le bouton "envoyer". Vérifier les erreurs au fur et à mesure de la saisie est important sur mobile, car la plupart des formulaires dépassent la hauteur de l'écran. Si l'utilisateur a mal rempli un champ et doit attendre l'envoi pour le savoir, il y a de fortes chances qu'il ait du mal à retrouver où se trouve le(s) champ(s) mal rempli(s).

Les nouveaux types de champs et attributs HTML5 vont être d'une grande aide dans le futur pour construire des formulaires faciles d'utilisation, sans besoins d'avoir recours à (trop) de JavaScript. Il est par exemple possible d'utiliser l'attribut HTML required pour proposer un retour à l'utilisateur sur un champs qu'il doit obligatoirement remplir. Hélas le support mobile de cet attribut est pour le moment très limité.

L'attribut autocomplete peut également être utilisé pour améliorer l'expérience utilisateur lors de la saisie des champs. Dans la mesure où un appareil mobile (de type smartphone) est un objet personnel, on peut imaginer que des données comme le nom, ou encore l'adresse postale ne changeront pas souvent pour son propriétaire. En utilisant l'attribut autocomplete, il serait donc possible d'améliorer la saisie de ces champs pour que l'utilisateur n'ait pas besoin de taper encore une fois en entier ce genre de données.

Il existe également une liste entière de nouveaux types d'inputs HTML5 qui pourront être utilisés dans un futur plus ou moins proche pour aider à l'optimisation des formulaires.

Le cas des dates est un bon exemple de ce qui peut être amélioré à l'aide de HTML5. Nous avons longtemps mis en place des datepickers (calendriers) en JavaScript, facilement utilisables sur navigateur de bureau, mais très difficiles à manier pour un appareil tactile. Appuyer sur la bonne date avec un doigt peut s'avérer assez difficile voire impossible si les zones sont très petites.

Date-picker ou selecteur de date

Comment suis-je supposée arriver à ne toucher qu'une date quand la zone est si petite ?

Les nouveaux types de champs HTML5 input type="date", input type="datetime", etc qui permettent de créer une chaîne de caractère au format de date/heure offrent des possibilités prometteuses ici. Le gros avantage de ces nouveaux types de champs est que leur rendu visuel est contrôlé par le navigateur et le système. De cette manière, leur UI (apparence graphique pour l'utilisateur) est automatiquement optimisée au mieux pour le périphérique utilisé.

Rendu de l'input date

Rendu de input type="date" dans différents navigateurs

Notons également que l'UI s'adapte également à la langue du navigateur. Utiliser des composants natifs permet donc également une adaptation linguistique automatique de certains contenus.

Pour le moment le support de input type="date" est presque absent pour les navigateurs de bureau, à part Opera et Chrome. Les navigateurs natifs Android ne le supportent pas non plus, par contre Chrome pour Android et Safari sur iOS le font. Il va donc falloir encore attendre un peu avant de pouvoir utiliser totalement le potentiel de ces nouveaux champs pour une solution mobile. Si vous êtes impatients, vous pouvez cependant utiliser un polyfill comme Mobiscroll qui va imiter le comportement natif de ces champs en JavaScript.

Au-delà des solutions natives de champs HTML5 d'autres expériences ont été menées pour proposer des patterns de designs plus adaptées comme "Mobile Design Details: Hide/Show Passwords" ou encore "Input Masks Design". Notons ne qu'il s'agit encore une fois que de solutions expérimentales et que là encore, la solution parfaite pour gérer les formulaires en responsive webdesign n'existe pas pour le moment. Il reste encore beaucoup de chemin à parcourir de ce côté.

Consultez également l'article les éléments de formulaire HTML5 sur Alsacréations pour aller plus loin.

La gestion des tableaux sur un site responsive.

Les tableaux sont un autre type de contenu qui reste difficilement gérable. La plupart des tableaux ont une orientation verticale pour présenter le plus de données possibles, il est donc difficile de faire rentrer toutes ces données sur un petit écran. Les tableaux HTML sont plutôt flexibles, il est possible d'utiliser des pourcentages pour la largeur des colonnes. Cependant le contenu en devient très vite illisible.

Personne n'a pour le moment trouvé la solution idéale pour gérer les tableaux sur un site responsive, mais quelques suggestions intéressantes ont été faites.

Une première approche consisterait à cacher ce qui pourrait être considéré comme des colonnes "moins importantes", et proposer un système de checkboxes à l'utilisateur pour qu'il puisse choisir lesquelles il souhaite afficher. Toutes les colonnes seraient affichées sur un navigateur de bureau, alors que sur mobile, leur nombre déprendrait de la taille disponible à l'écran. Le Filament Group explique et propose une démonstration de cette approche dans un de leurs articles. C'est également cette solution qui est proposé dans le module table column toggle de jQuery Mobile.

Quelques exemples de tableaux responsive.

Une seconde approche est basée sur l'idée de tableaux qui défilent. Elle consiste à fixer une seule colonne à gauche, et laisser une barre de défilement sur une petite partie du tableau à droite pour que l'utilisateur puisse afficher le reste des données. David Bushell implémente cette idée  dans un article en utilisant du CSS pour afficher tout le contenu du <thead> sur la partie gauche du tableau, laisse l'utilisateur faire défiler le reste sur la partie de droite. Zurb utilise la même idée dans leur plugin  mais au lieu de coller le header à gauche, c'est la première colonne qui est dupliquée en JavaScript et le reste du tableau passe en dessous de sorte que l'utilisateur voit à gauche une colonne fixe, et à droite le reste des colonnes qu'il peut encore une fois faire défiler.

Deux exemples de tableaux que l'on peut faire défiler

Deux exemples de tableaux que l'on peut faire défiler

Le gros problème avec la propriété CSS overflow:auto est que la barre de défilement créée n'est pas visible sur certains appareils mobiles et tablettes. L'utilisateur peut toujours faire défiler la partie de droite, mais il n'a aucune indication visuelle qu'il peut s'y cacher plus de contenu que ce qu'il voit. Il faut donc, si on utilise ces techniques, trouver un moyen d'indiquer visuellement à l'utilisateur qu'il peut faire défiler le contenu à droite.

Une troisième approche est de ré-agencer les tableaux et de découper les colonnes en ce qui ressemble à des listes avec des titres. Cette technique est utilisée pour le “reflow mode” de jQuery mobile et est expliquée par Chris Coyier dans son article “Responsive Data Tables.”

Des tableaux ré-agencés

Il existe encore plusieurs autres techniques et l'utilisation de l'une ou de l'autre dépendra de votre projet. Aucun projet n'est identique, donc je peux seulement vous montrer ici ce que d'autres personnes ont créé pour contourner le problème des tableaux. Si vous avez vous aussi une solution à proposer, partagez-la avec tout le monde, dans les commentaires, sur Twitter, Github ou n'importe où. Nous sommes dans cette galère ensemble, les tableaux en mobilité sont une plaie, à nous de les améliorer !

Encapsuler des contenus tiers : le problème des iframes

Le contenu de beaucoup de sites dépend aujourd'hui d'applications et services tiers : Youtube ou Vimeo pour les vidéos, des présentations Slideshare, des widgets Facebook, des flux Twitter, des cartes Google maps, etc. Beaucoup de ces services tiers utilisent aujourd'hui des iframes pour proposer leur contenu sur d'autres sites. Mais ne nous voilons pas la face : les iframes sont encore une fois une plaie à utiliser dans un contexte de mobilité. Les largeurs et hauteurs sont fixées en direct dans le code HTML. Forcer une largeur de 100% sur <iframe> pourrait marcher, mais cela voudrait dire perdre le ratio du contenu embarqué. Les vidéos sont souvent en 16:9 par exemple, pour garder ce ratio il va falloir trouver des solutions alternatives.

Du bricolage HTML et CSS

Thierry Koblentz a écrit un très bon article intitulé “Creating Intrinsic Ratios for Video” dans lequel il propose une méthode pour avoir des vidéos dans des iframes tout en préservant le ratio 16:9 de départ. Cette solution peut être étendue à toutes sortes d'iframe : vidéos, présentations SlideShare et même cartes GoogleMaps.

Koblentz entoure son iframe d'un conteneur auquel il va donner une classe pour lui appliquer ensuite du CSS. Ce conteneur permet d'avoir un iframe fluid, même si les valeurs de largeur et hauteur sont données en pixels et en dur dans le HTML. Voici à quoi ressemble ce code adapté par Anders M. Andrers :

.embed-container {
  position: relative;
  padding-bottom: 56.25%; /* 16:9 ratio */
  padding-top: 30px; /* IE 6 workaround*/
  height: 0;
  overflow: hidden;
}

.embed-container iframe,
.embed-container object,
.embed-container embed {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

Ce code va fonctionner pour tous les iframes, à partir du moment où vous les aurez entourées de <div class="embed-container">iframe</div>.

Même si cette solution peut-être facilement mise en place sur un site sur lequel on a un contrôle total, il est difficilement envisageable de demande à un client sans compétences techniques d'ajouter ce HTML à chaque fois qu'il va récupérer une vidéo sur Youtube. Il serait bien sûr possible d'utiliser du JavaScript pour détecter tous les iframes de la page et les encapsuler automatiquement dans notre code. Mais il s'agit hélas encore une fois de bricolage et non pas d'une solution pérenne.

La gestion des vidéos responsive dans le futur

HTML5 propose de nouvelles possibilités pour les vidéos avec l'élément video. La bonne nouvelle : son support est étonnamment bon pour les mobiles. En dehors d'Opera Mini, la majorité des navigateurs supportent la balise <video>. L'autre bonne nouvelle : cette balise est très flexible en CSS. Pour présenter une vidéo responsive, il suffirait d'écrire :

video {
  max-width: 100%;
  height: auto;
}

Et là vous vous demandez : où est le problème alors ?

Le problème vient tout simplement des plateformes qui vont proposer les contenus. Même si Youtube ou encore Vimeo supportent la balise video, ils produisent toujours cet horrible <iframe> lorsque l'on veut afficher la vidéo sur son site. Nous sommes donc condamnés à trouver des bidouilles et des bricolages comme ceux évoqués plus hauts tant que Youtube, Vimeo ou Dailymotion ne se décident pas à proposer un moyen plus propre d'afficher leurs vidéos sans utiliser d'iframe. En attendant ce jour, Chris Coyier propose un plugin jQuery appelé FitVids.js qui utilise la technique proposée plus haut et se charge de faire l'encapsulage de l'iframe dans un conteneur pour améliorer sa fluidité tout en préservant le ratio de la vidéo.

Afficher les cartes Google Maps (ou équivalent)

Si vous décidez à afficher pour votre site une carte Google Maps, la technique décrite plus haut avec le conteneur va fonctionner. Mais encore une fois, c'est une bidouille pas propre du tout. En plus dans le cas des cartes, elles vont se redimensionner en gardant leurs proportions ce qui veut dire que sur un petit écran, vous risquez de vous retrouver avec une carte toute petite qui aura perdu le focus sur l'endroit que vous vouliez montrer à l'utilisateur. La documentation officielle de Google Maps pour mobile stipule qu'il vaut mieux utiliser l'API de cartes statiques pour un affichage sur mobile. Et en effet, utiliser une carte statique (via une balise <img>) fera disparaitre notre souci d'iframe. Brad Frost a écrit un excellent article sur le sujet intitulé adaptive maps dans lequel il propose une démonstration qui illustre cette technique. Un JavaScript détecte la taille de l'écran et en fonction va remplacer l'iframe par une carte statique sur les petits écrans. Et encore une fois en l'absence de meilleure solution native (proposée par Google par exemple), nous avons recours à une bidouille pour pouvoir nous débarrasser de notre problème d'iframe.

Il nous FAUT de meilleures APIS !

J'ai jusque là parlé de bidouille, de bricolage : existe-t-il une meilleurs solution ? Le plus gros souci des iframes est notre manque de contrôle en tant que designers et intégrateurs sur le code et design qu'elles vont générer. Nous sommes totalement dépendants de ces services tiers et par extension, du HTML et CSS qu'ils veulent bien nous fournir. Dans la mesure où le nombre de services et sites qui proposent ce genre de contenus tierces est en constante augmentation, il va rapidement nous falloir de meilleures solutions que les iframes pour afficher leur contenus sur nos sites.

Soyons réalistes deux secondes : utiliser le widget Facebook pour afficher les likes sur son site est une plaie. Le peu de contrôle sur le CSS généré par Facebook rend notre travail hasardeux et peut aller jusqu'à ruiner un joli design. Le web est un endroit libre et ouvert, il est donc peut-être enfin temps de commencer à penser en terme d'APIs! Dans le futur, nous aurons à la fois besoin de plus d'APIs (Application Programming Interface) pour récupérer ces contenus, mais enfin et surtout, besoin d'APIs plus flexibles et surtout d'APIs plus simples d'utilisation pour récupérer ces contenus sans les iframes. Mais jusqu'à ce que ces grands services se décident à nous créer ces APIs, nous sommes coincés avec des iframes hasardeux et condamnés au bricolage et à la bidouille.

La navigation responsive: tour d'horizon des techniques actuelles

Un autre gros défi quand on parle de responsive et d'optimisation est la navigation du site. Point souvent critique pour l'utilisateur, plus elle est complexe et dense, plus il va falloir ruser d'inventivité pour proposer une expérience agréable et simple d'utilisation.

Lorsque le Responsive Web Design n'en était qu'à ses débuts, une première solution était de transformer la navigation en listes déroulantes. Cette solution est hélas loin d'être idéale. Elle devient très compliquée dès que l'on a plusieurs niveaux de navigation, et peut poser des soucis d'accessibilité. Je vous conseille de lire l'excellent article Stop Misusing Select Menus pour en apprendre un peu plus sur cette technique et les problèmes liés.

Quelques personnes comme Brad Frost ou encore Luke Wroblewski ont alors essayé de proposer différentes solutions à ce casse tête. Brad Frost compile quelques techniques de navigation responsive sur son site This Is Responsive.

La navigation qu'il appelle "Toggle" consiste à cacher la navigation pour les petits appareils sous un lien "menu". Quand l'utilisateur clique sur ce lien, le reste de la navigation apparait sous forme de blocs juste en-dessous, poussant le contenu plus bas dans la page.

Une variante de cette technique a été inspirée par les navigations d'applications natives comme celle de Facebook et est appelée off-canvas. Encore une fois on cache la navigation sous une icône "menu". Quand l'utilisateur clique sur cette icône, la navigation sort d'un panneau à gauche ou à droite du site, poussant le contenu de l'autre côté.

Exemples de navigation toggle

Le "problème" de ces techniques est que la navigation reste en haut de l'écran. Dans son article “Responsive Navigation: Optimizing for Touch Across Devices,” Luke Wroblewski illustre de manière visuelle les zones faciles d'accès sur différents appareils. La partie en haut à gauche est la plus compliquée à atteindre sur mobile.

Les zones de l'ecran plus ou moins facilement accessibles

En se basant sur ces recherches, Jason Weaver créa quelques démonstrations de navigations avec les boutons en bas de l'écran. Une des solutions proposées est d'avoir la navigation en pied de page, et d'y renvoyer l'utilisateur lorsqu'il clique sur le bouton "menu" à l'aide d'un système d'ancres HTML.

Bien d'autres solutions ont été proposées pour tenter de régler le problème de la navigation responsive. Comme vous pouvez le voir, encore une fois, il n'existe pas de solution idéale et cela va là encore dépendre non seulement de votre projet, mais également du niveau de profondeur de votre navigation. Heureusement qu'il existe des gens comme ceux cités plus haut qui expérimentent et partagent les expériences avec la communauté.

Il nous faut également encore trouver quelles icônes choisir pour montrer à l'utilisateur de manière pertinente qu'il y a un menu, et qu'il se cache des éléments supplémentaires en dessous. Certains sites utilisent le symbole (+), d'autres une grille, d'autres encore utilisent un symbole de liste ordonnée, ou encore le symbole des 3 lignes (ou burger icon).

icône de menu

Pour voir ces icônes en utilisation je vous conseille l'excellent article “We Need a Standard ‘Show Navigation’ Icon for Responsive Web Design.”

Reste à trouver laquelle de ces icônes est la plus facilement identifiable par un utilisateur comme étant un menu. Si tout le monde s'accordait sur l'utilisation d'une d'entre elles, les utilisateurs (de tous pays) seraient-ils capables de la comprendre ? Et laquelle choisir ? Je suis très curieuse de savoir quelle icônes vous utilisez sur vos sites, donc n'hésitez pas à partager votre expérience dans les commentaires ci-dessous.

Les spécificités du mobile : "Mon utilisateur est-il sur un appareil mobile? Et que peut-il y faire?"

Le monde des mobiles et tablettes est tout nouveau pour nous, loin des navigateurs de bureaux, et avec ses propres règles, comportements et capacités. Il va donc nous falloir penser à adapter nos design à toutes ces nouvelles possibilités.

Détecter la possibilité d'évènement "touch" en JavaScript natif

Je pense que si vous demandez dans la rue à quelqu'un de vous donner la différence entre un navigateur de bureau et mobile, en dehors de la taille, il y a fort à parier que cette personne va vous répondre l'utilisation avec les doigts. Il n'y a pas de souris sur les mobiles (ha bon ? ;)) et en dehors de quelques rares appareils hybrides et ajouts en bluetooth sur des tablettes, il n'est pas possible d'avoir des évènements de souris sur un mobile ou une tablette. Cela implique qu'en fonction du navigateur, la pseudo-classe :hover fonctionnera différemment. Certains navigateurs sont sympatiques et "émulent" cette fonctionnalité, traduisant un effet au survol par un effet au touch. Hélas tous ne sont pas aussi flexibles. Créer un design dont une partie des éléments ne sont révélés qu'au survol de la souris peut s'avérer compliqué sur mobile.

Récupérer les évènements au touch est une solution envisageable. Le W3C a un groupe de travail sur le projet de spécifications touch event. Dans le futur, nous serons donc capables de détecter directement en JavaScript et sans librairie tierce comme Hammer.js ou jGestures des évènements comme touchstart, touchmove ou encore touchend.

JavaScript est une chose, mais qu'en est-il du CSS ?

CSS Level 4 "pointer media query"

Le CSS Level 4 propose une nouvelle Media Query appelée “pointer”. Elle peut être utilisée pour détecter la présence d'un dispositif de pointage comme une souris, et prend 3 valeurs possibles :

  • none : l'appareil n'a pas de dispositif de pointage
  • coarse : l'appareil a un dispositif de pointage avec une précision limitée (un mobile ou une tablette où le dispositif de pointage est un doigt)
  • fine : l'appareil dispose d'un dispositif de pointage précis comme une souris, ou encore un track pad ou le stylet d'une tablette graphique

En utilisant cette requête, on peut imaginer ce genre de code pour élargir la taille des boutons pour des appareils "touch" :

@media (pointer:coarse) {
  input[type="submit"],
    a.button {
    min-width: 30px;
    min-height: 40px;
    background: transparent;
  }
 }

Cette Media Query n'est pour le moment supportée nulle part et est à l'état de proposition. Le potentiel n'en reste pas moins très intéressant puisqu'elle permettrait de détecter des appareils supportant le touch sans devoir passer par une librairie comme Modernizr.

La Media Query CSS Level 4 "hover"

Les spécifications CSS Level 4 proposent également une nouvelle Media Query appelée hover,qui est capable de détecter si le dispositif de pointage de l'appareil peut supporter les effets au survol. Elle renvoie un booléen 1 si l'appareil supporte le survol, 0 si ce n'est pas le cas. Notez ici que cela n'a RIEN à voir avec la pseudo-classe :hover.

En utilisant cette syntaxe, nous pourrions par exemple améliorer les interfaces et ne masquer des fonctionnalités que pour les appareils qui supportent le survol d'éléments. Le code pourrait ressembler à ça :

@media (hover) {
  .hovercontent { display: none; } /* cacher le contenu uniquement pour les appareils qui supporent le survol */
  .hovercontent:hover { display: block; } 
 }

On pourrait imaginer l'utiliser pour créer des menus déroulants au survol uniquement pour les appareils le supportant, et proposer une alternative plus facilement pour les autres sans avoir besoin de détection des capacités de l'appareil.

La Media Query CSS Level 4 "luminosity"

Les appareils mobiles sont aujourd'hui équipés de détecteurs leur permettant de mesurer la luminosité ambiante. CSS Level 4 propose une media-query " luminosity" qui aura accès aux données de ces capteurs. Voici comment la décrivent les spécifications du W3C :

 La Media Query luminosité est utilisée pour récupérer des données sur la luminosité ambiante dans laquelle l'appareil se trouve et permet à l'auteur d'ajuster le style du document en fonction.

Dans le futur nous serons donc capables de créer des sites qui vont réagir à la luminosité ambiante. Nous allons pouvoir grandement améliorer l'expérience utilisateur en leur proposant par exemple plus de contrastes dans un environnement très lumineux avec la valeur "washed". La valeur "dim" est utilisée pour les environnements sombres, et la valeur "normal" si le niveau de luminosité ne requiert pas d'ajustement.

Voici à quoi pourrait ressembler le code :

@media (luminosity: washed) {
  p { background: white; color: black; font-size: 2em; }
}

Si vous êtes curieux et souhaitez en savoir plus sur les nouveautés CSS level 4 pas forcément liées au responsive, vous pouvez lire l'article Sneak Peek Into the Future: Selectors, Level 4.

Plus de capacité mobiles détectables en utilisant les APIs et JavaScript

Beaucoup d'autres fonctionnalités peuvent être détectées pour améliorer l'expérience utilisateur et proposer un site responsive digne de ce nom. Par exemple il serait possible d'accéder nativement au gyroscope, à la boussole ou à l'accéléromètre pour détecter l'orientation de l'appareil en utilisant DeviceOrientationEvent. Le support de cette API s'améliore pour Android et iOS mais elle reste pour le moment à l'état de brouillon. Les possibilités pour les jeux HTML5 qui exploiteraient l'orientation directement dans le navigateur n'en restent pas moins prometteuses.

Une autre API qui commence à être beaucoup utilisée et particulièrement utile est la Géolocalisation. Cette API est d'ailleurs très bien supportée. Elle permet de positionner l'utilisateur en utilisant son GPS, l'adresse IP ou encore les réseaux Wi-Fi ou la triangulation d'antennes relais. On peut imaginer utiliser la géolocalisation sur un site responsive pour proposer des informations contextuelles à l'utilisateur. Une grosse chaîne de restaurants pourrait pas exemple améliorer l'expérience en montrant à l'utilisateur géolocalisé les restaurants de la chaîne qui se trouvent autour de lui.

Le W3C propose également un brouillon pour l'API Vibration. Le navigateur peut alors proposer des retours tactiles sous forme de vibrations à l'utilisateur. Néanmoins on sort là quelque peu du domaine du responsive pour entrer un peu plus dans le domaine du jeu et de l'applicatif web.

Une autre API qui a fait couler beaucoup d'encre est Network Information. La possibilité de pouvoir optimiser des images et un site en fonction de la bande passante de l'utilisateur a de quoi séduire plus d'un développeur. Nous serions en théorie alors capables de proposer des images en haute résolution pour les appareils avec une grosse bande passante, et vice et versa. Avec l'attribut bandwith de l'API network, il serait possible d'estimer la bande passante d'un utilisateur en Mb/s. Le second attribut metered est un Boolean qui nous indique si l'utilisateur a une connexion mesurée, comme c'est le cas pour des mobicartes pré-payées par exemple. Ces deux attributs sont accessibles en JavaScript.

Hélas la mesure de la connexion d'un utilisateur est une chose techniquement complexe. En outre, la connexion peu changer à tout moment. Un utilisateur passant sous un tunnel peut perdre sa connexion, et la vitesse de téléchargement va subitement chuter. Il est donc totalement hypothétique d'imaginer à l'heure actuelle une Media Query "magique" qui permettrait de mesurer la bande passante. Yoav Weiss a écrit un excellent article sur le problème qu'une telle Media Query pourrait engendrer et sur la mesure de la bande passante en général intitulé Bandwidth Media Queries? We Don’t Need ’Em!.

Il existe encore beaucoup d'autres APIs liées aux fonctionnalités mobiles que je ne vais pas détailler ici. Si vous souhaitez en savoir plus, Mozilla a une liste très détaillée. La plupart d'entre elles sont loin d'être standardisées, et beaucoup sont plus orientées vers de l'applicatif web que vers le site responsive. Il n'en reste pas moins passionnant de voir à quel point la mobilité va devenir complexe dans le futur et toutes les possibilités qui vont s'ouvrir à nous.

Repenser la façon dont nous, et nos clients/utilisateurs gérons le contenu.

Il reste encore bons nombres de défis techniques à relever pour gérer du contenu de manière efficace sur mobile. La philosophie "mobile-first" commence à faire de plus en plus d'émules dans la communauté de designers et d'intégrateurs. Il serait par exemple techniquement possible d'envoyer à un mobile le minimum de HTML et données nécessaires, puis d'utiliser du JavaScript et des chargements en AJAX pour charger plus de contenu et d'images de manière conditionnelle pour les navigateurs de bureau, voire les tablettes. Mais pour faire cela, il nous faut d'abord repenser la manière dont nous allons gérer notre contenu. Il nous faut être capable de prioriser et hiérarchiser les contenus pour les générer de la manière la plus flexible et adaptive possible. Un bon exemple ici serait la carte responsive décrite plus haut : nous chargeons pour le mobile une simple image, et améliorons progressivement l'expérience avec une "vraie" carte pour les utilisateurs de navigateur sur bureau. Plus nous allons vouloir rendre un site responsive, et plus la gestion du contenu va se complexifier.

Du code plus flexible peut nous aider à formater un contenu qui s'adapte. Certaines personnes ont suggéré de créer des phrases responsive en morcelant les éléments de balises HTML et de classes pour pouvoir n'en afficher que certaines parties en fonction de la taille de l'écran. L'idée est de masquer certaines parties pour les petits appareils en utilisant des Media Queries. Vous pouvez voir cette technique en action sur le blog de 37signal's Signal vs. Noise ainsi que dans l'article de Frankie Roberto intitulé Responsive Text. Même si cette technique peut être utilisée pour améliorer l'affichage de petites parties du site comme un slogan dans un pied de page, il est totalement impensable de l'appliquer à grande échelle à l'ensemble d'un site web.

On commence ici à mettre le doigt sur un problème qui va prendre de plus en plus d'importance dans le futur : la nécessité de parser son contenu textuel de métadonnées pour lui donner une plus grande structure sémantique. Rappelons-nous, le contenu de notre site ne vient plus uniquement de nos rédacteurs de contenus en interne. Si nous souhaitons à terme, être capable de réutiliser le contenu d'autres site sur le notre, il va falloir préparer la structure de ce contenu pour qu'il soit facilement réutilisable. Les nouveaux éléments HTML5 comme article, section sont un bon point de départ pour faire gagner de la valeur sémantique à nos contenus. Dans le futur, il ne faudra plus penser et structurer le contenu comme une seule entité (une page web) mais le penser comme l'assemblage de multiples blocs réutilisables que l'on va pouvoir afficher dans différents formats sur différents appareils.

Le plus grand défi sera de faire en sorte que la structuration en métadonnées soit facile d'accès et compréhensible par toutes les personnes qui font partie de la chaîne de création d'un site web. Nous allons devoir les éduquer, et leur expliquer comment ces données peuvent être utilisées pour prioriser le contenu et assembler de manière pragmatique différents éléments tout en restant indépendant de la plateforme utilisée. Le grand challenge sera de les aider à penser en terme de blocs réutilisables plutôt qu'en terme de "grosse zone de texte que l'on peut copier/coller depuis Word vers l'éditeur WYSIWYG du CMS". Notre travail sera de les aider à comprendre que le contenu et sa mise en forme sont deux choses séparées et indépendantes, tout comme nous en tant que designers et intégrateurs avons compris que le contenu (HTML) et sa présentation (CSS) sont plus simples à gérer une fois séparés.

Écrire un contenu orienté vers une seule et unique plateforme n'est plus une option. Qui sait sur quels appareils votre contenu sera affiché demain ? Dans 6 mois ? Dans un an ? Il nous faut préparer ce contenu pour l'inattendu. Mais pour arriver à cela, il va nous falloir également créer de meilleurs outils de publication. Karen McGrane a donné une conférence intitulée Adapting Ourselves to Adaptive Content. Elle y parle d'exemples concrets tirés de l'industrie de la publication. Elle détaille le processus pour créer des contenus réutilisables et introduit l'idée de COPE (create once and publish everywhere - en français "créer une fois, publier partout"). Il va nous falloir construire de meilleurs CMSs qui seront capables de générer les métadonnées nécessaires à cette priorisation des contenus. Nous allons également devoir expliquer à nos collègues et rédacteurs de contenu comment ces CMSs fonctionnent et comment penser en terme de contenus réutilisables et non pas de pages WYSIWYG.

Karen McGrane écrit :

"Vous serez peut-être amenés à écrire trois versions différentes de votre titre; deux versions du sommaire, et ajouter plusieurs images dans différentes tailles, différentes coupes, et vous ne serez même pas la personne qui décidera quelle image ou quel titre sera affiché sur telle ou telle plateforme. Cette décision sera faite par une métadonnée. Elle sera faite par les règles de l'industrie […] les métadonnées sont la nouvelle direction artistique."

Masquer des contenus pour des appareils n'est plus une stratégie de gestion de contenu pérenne. Il nous faut des CMS qui puissent nous fournir la structure pour créer du contenu réutilisable. Il nous faut également des meilleurs workflows de publication dans ces CMSs. Les interfaces hasardeuses et complexes font peur aux utilisateurs, et la plupart des personnes qui vont générer les contenus ne sont pas particulièrement à l'aise avec des outils trop compliqués. Il va nous falloir leur fournir des outils qui sont faciles d'accès et de compréhension pour les aider à publier du contenu propre, sémantique et indépendant de la présentation finale.

Content is like water

Conclusion

Cet article peut vous paraître long, mais il n'est que le sommet de l'iceberg. Aujourd'hui notre profession commence à comprendre que le responsive webdesign c'est bien plus que balancer quelques Media Queries dans une feuille de style, choisir des points de rupture et doubler les dimensions des images pour ces nouveaux jouets haute résolution qui nous servent de mobile. Vous l'avez lu, vu, le chemin est long, et nous sommes loin d'être arrivés à destination. Il y a encore tellement de choses à faire et de problèmes à résoudre que la solution responsive magique et miraculeuse n'existe pas encore aujourd'hui.

Nous avons découvert des solutions techniques, d'autres viendront dans le futur en utilisant des nouvelles technologies présentées dans cet article avec l'aide d'organisations comme le W3C, le WHATWG ou encore le Filament Group.

Mais gardons une chose importante à l'esprit : c'est également à nous, designers, nous intégrateurs, nous développeurs d'aider à trouver de meilleures solutions. Des gens géniaux comme Luke WroblewskiBrad Frost, toutes les femmes et les hommes cités dans cet article et ceux que j'ai oublié œuvrent au quotidien, testent et expérimentent différentes techniques et solutions. Succès ou échecs, la chose la plus importante reste le partage ce que nous, designers, développeurs, rédacteurs de contenus et membres de la communauté webdesign créons au quotidien pour aider à surmonter ces défis présentés par le concept de responsive webdesign.

Nous sommes tous dans le même bateau, autant faire ensemble du web un endroit meilleur, non ?

Ressources

Commentaires

jojaba a dit le

Bonjour,

J'ai pas lu l'article encore, mais je suis sûr qu'il va m'intéresser. Ceci dit, je vais plutôt l'imprimer pour cela...
Pour ceux que ça intéresse, le lien vers PrientFriendly afin de l'obtenir également en pdf :
http://www.printfriendly.com/print/?source=ho...

;)

6l20 a dit le

Et dire que je me suis cogné ça dans la langue de Shakespeare...
De manière plus officielle donc, je te renouvelle mes félicitations pour ce colossal travail de recherches, de tests, de week ends et de soirées passés "loin" des tiens (bises à ton homme) et surtout un grand merci pour cet article qui fait déjà référence :)

caroleQui a dit le

Merci pour cet excellent article et pour sa traduction! Merci pour les rappels, les découvertes et les ressources.

noclat a dit le

Une petite erreur s'est glissée dans ton article, lorsque tu parles de l'optimisation des images :
"Avec cette technique, il a été capable de réduire de 75% le poids des images qu'il a testé."
-> Lire plutôt "réduire __À__ 75%".
Technique qui fonctionne à merveille, que j'utilise sur http://eyefracture.com

VincentClair a dit le

Très bon article, bien complet. Le must serait d'avoir un pavé pour chaque problématique, qui met en avant la technique actuelle la plus conseillée (au moins à votre avis).

Stéphanie W. a dit le

@VincentClair : Justement non :) Je ne veux pas conseiller de technique ou en mettre une ou l'autre en avant, car mes projets, mes workflows ne sont pas les votres. La meilleur technique dépend de trop de paramètres pour simplement dire arbitrairement dans un article "je vous conseille ça". Le but était justement de montrer un pannel de ce qui est plus ou moins faisable, avec les problèmes que ça engendre. Ensuite à chaque de voir en fonction de son projet.
Enfin, il reste beaucoup à inventer. J'espère devoir ré-écrire cet article (ou je jeter à la poubelle) dans un an, et pouvoir dire "ce que j'ai dit là c'est désuet, on a une technique bien meilleure que ça...". L'idée est donc de tester, tester, et partager avec le communauté, pour faire avancer tout le monde :)

PhilC a dit le

Sublime article sur le design responsive qui évolue sans cesse et qui commence à se démocratiser. Nous venons de de terminer une boutique en ligne responsive, et ce fut un beau challenge de mixer interfaces mobiles et interfaces ecommerce.

Manumanu a dit le

Encore un article très intéressant à ton actif, bravo !

john_be a dit le

Un énorme bravo pour cette article, très complet, et qui m'en apprend beaucoup d'un coup! Je suis également content de voir que je ne suis pas le seul dans ces problématiques.

Gili a dit le

Super article, merci de le rendre disponible en français !

Caradox a dit le

Excellent article, merci !

guizm0w a dit le

Waow, très bon article, merci encore pour la traduction !

PierGiro a dit le

Super article, merci.
Petite coquille (anglicisme?) dans le passage sur GMaps : «nous avons ressort à» au lieu de -nous avons recours à-

KaySix a dit le

Nice !
Je vais surement le relire plusieurs fois pour tout intégrer...
En tout cas bravo pour ce boulot.

Plus je découvre, plus je me rencontre de toutes les règles qui existent... j'aimerais tellement avoir une pseudo encyclopédie web avec les bonnes pratiques sur toutes les thématiques ! (qui veut monter ce projet ? (avec moi :p)).

KaySix a dit le

rends compte* ! Sorry

Stéphanie W. a dit le

@PierGiro : bah si, ressort, genre un petit marsupilami, boing boing :D Plus sérieusement effectivement c'est un anglicisme je vais corriger ça, merci ;)

Yordi a dit le

Article parfait, merci !

jojaba a dit le

Bon ben j'ai lu attentivement après impression... Très gros boulot (31 pages tout de même au format pdf et en utilisant le lien que j'ai publié dans mon premier commentaire), bravo Stéphanie. Ceci dit, cela ne m'étonne qu'à moitié vu l'activité débordante dont tu faus preuve sur ton compte tweeter par exemple... ;)
Pour en revenir à l'article (qui, j'en suis certain, présage d'un ouvrage plus conséquent à ce sujet), petit commentaire de ce qui m'est venu à l'esprit en le lisant...
J'ai compris que tu ne souhaitais pas que l'on prenne ce que tu (par l'intermédiaire de travaux réalisés par des testeurs en général anglophones) proposais comme LA solution mais bien comme des solutions alternatives ou à venir. Je me suis plus particulièrement intéressé aux "bidouilles" (comme tu le dis assez souvent dans ton article) qui fonctionnent partout et tout de suite, c'est ce qui va nous servir immédiatemment.
J'ai bien noté par exemple pour les images le stratagème (tiens, un synonyme de "bidouille" !) du JPEG progressif et l'astuce (encore un synonyme !!!) de l'image à taille double et compression maximale qui tous deux sont réalisables pour tout type de support, mais pour d'autres subterfuges (:D), comme l'utilisation du rem, on peut, si je ne m'abuse, également utiliser des em en indiquant une taille de police en pourcentage dans le body et le reste des tailles de police en em...
Tu donnes des petites finesses (:p) pour l'insertion d'Iframe et de vidéos applicable dès maintenant et tu parles des nouveaux attributs de balises de formulaires forts pratiques et pris en charge par la plupart des navigateurs modernes et mobiles.
Très bien tout ça, mais qui dit "bidouille" (j'étais à court de synonymes là), dit fonctionnement plus qu'aléatoire au bout d'un certain temps. Je ne dis pas qu'il ne faut pas les utiliser, mais qu'il faut le faire en connaissnace de cause...
En tout cas, cela me conforte dans ce que je pense depuis toujours : tant que l'on fait appel à des techniques "simples" et sans trop de subtilités on pérennise le travail effectué. "Keep it simple to have it work everywhere" serait une maxime à retenir (je ne sais pas si quelqu'un l'a déjà dit, ça m'est venu à l'esprit là).
Merci encore pour ce travail titanesque et également pour la jouer collectif, ça prend du temps, ça ne rapporte rien (hormis des kiwiz ;p) et c'est tout à ton honneur ! :)

Stéphanie W. a dit le

@jojaba : merci pour tes remarques et le proofreading ;) Non pas d'ouvrage en vue sur me sujet, je laisse ça aux gens plus calés que moi.
"J'ai compris que tu ne souhaitais pas que l'on prenne ce que tu (par l'intermédiaire de travaux réalisés par des testeurs en général anglophones) proposais comme LA solution mais bien comme des solutions alternatives ou à venir" en fait je veux surtout mettre l'accent sur le fait de le responsive et l'adaptative multisupport (avec un gros accent mis sur le mobile ici) sont des thématiques encore jeunes, et que malgré ce qu'essaient de nous faire croire les marketeux et certains blogueurs, ce sont des domaines très techniques, faits de hacks et de bidouille. Donc je te rejoins tout à fait sur la mise en garde quant à la pérennité de certaines techniques. Dans l'idéal ces hacks et bidouilles devraient disparaître un jour au profil de solution "standards". Mais on en est trèssss loin. L'idée c'est également qu'en attendant, il faut partager ces astuces pour améliorer le oueb ensemble, et pas bosser chacun dans son coin :)

Noisequik a dit le

En tant qu'utilisateur d'iPhone, j'ai tendance à ne pas apprécier les versions mobiles mais préferer la version originale et zoomer si besoin (pour autant que le site original soit un minimum bien fait).
Hors je constate que de plus en plus de sites ne permettent plus de revenir à cette version, de par l'emploi des media queries.
Qu'en pensez-vous ?

Ne vaudrait-il pas un navigateur encore plus intelligent plutôt que se casser la tête ?

LuCube a dit le

Merci pour l'article vraiment très intéressant ;)

Stéphanie W. a dit le

@Noisequik : bon bah ma longue réponse ayant fini en spam, je recommence. Je me demandais surtout pourquoi ne pas apprécier les versions mobiles ? Est-ce car il manque des fonctionnalités ? Car l'expérience est trop différente de la version non mobile ? Une autre raison ?
J'ai moi même déjà eut le cas avec tumblr : il manque pleins de fonctionnalités sur la version mobile et tellement différente que j'ai fini par passer en version "full site".
Il est techniquement possible de passer un site responsive en full site :
- en retirant les media-queries mais ça veut dire qu'on part du principe que les optimisations mobiles sont dans une feuille de style à part. (http://neilcarpenter.com/2012/05/creating-a-faux-view-full-site-button-for-responsive-sites/)
- retirer la balise meta-viewport du HTML ( http://creativeandcode.com/responsive-view-full-site/), tout en sachant qu'elle n'est pas un standard mais un ajout d'Apple et que la version @viewport se trouve elle aussi dans le CSS(http://www.alsacreations.com/article/lire/1490-comprendre-le-viewport-dans-le-web-mobile.html)

Pour l'intelligence des navigateurs, à voir. Mais on a déjà tellement de différences entre les navigateurs, plateforme et OS que leur laisse plus de chose à faire me parait dangereux. On finira toujours par "hacker" pour ceux qui ne proposent pas telle ou telle fonctionnalité.

Noisequik a dit le

@Stéphanie W : en fait, j'ai toujours l'impression d'avoir une version tronquée (même si ce n'est pas le cas) et d'avoir échangé mon écran haute résolution contre un écran bas de gamme.

Si je prends cette page où nous sommes actuellement, dont la version mobile semble avoir été pourtant très bien travaillée, je me retrouve avec une page longue comme le bras, je perds mes repaires par rapport à la version que j'ai l'habitude de consulter, un texte trop gros (pour moi) etc.

Je trouve que Safari mobile fait vraiment bien son boulot et permet une lecture agréable du web. Maintenant, il est vrai que développer en 960px n'a plus vraiment de sens à l'heure actuelle, quoique...

Transat a dit le

Grandes et appétissantes perspectives pour le web du futur. J'aime particulièrement la partie consacrée à l'évolution du contenu lui-même.

Et là, je lis le premier commentaire, qui propose une version imprimable de l'article! Mais alors, à quoi bon tout ça? Après tout, peut-être que quand le «adaptative web» sera devenu réalité, nos yeux ne seront plus que des plaies sanguinolentes équipés de triples-foyers ;)

Gyzm0 a dit le

Merci pour ce superbe article qui nous montre clairement les challenges présents et à venir pour le web !

Je trouve que le métier de développeur front se complexifie de plus en plus, ce qui en fait un métier passionnant certes mais aussi de plus en plus difficile et qui part dans tous les sens... Je pense qu'il faudra tôt où tard poser certaines limites, car il est clair qu'on ne peut pas être expert dans tous les domaines (UX, SEO, API, gestions de contenus, microformats et j'en passe).

Est ce à l'intégrateur de gérer la gestion de la luminosité du site ou les retours de vibrations ? Es ce à l'intégrateur de décider de masquer tel ou tel contenu dans tel ou tel cas, de gérer l'affichage en fonction de la bande passante ? Le travail en équipe est plus que jamais indispensable selon moi, trop de responsabilités reposent sur l'intégrateur et j'imagine que de nouveaux métiers vont apparaître au fil du temps.

Stéphanie W. a dit le

@Gyzm0 : "Est ce à l'intégrateur de gérer la gestion de la luminosité du site ou les retours de vibrations ? "
=> on en est pas là, j'aurai tendance à dire que non, plus à l'expert accessibilité/utilisabilité ?
"Es ce à l'intégrateur de décider de masquer tel ou tel contenu dans tel ou tel cas, de gérer l'affichage en fonction de la bande passante ? "
=> non, c'est encore une fois des décisions au niveaux de l'ergonomie du site, par contre c'est souvent à l'intégrateur de mettre en place les chargements ajax pour ne charger ces parties que sur les sites qui en auraient besoin.
En effet, le métier d'intégrateur évolue de plus en plus et demande de plus en plus de compétences :)

Gyzm0 a dit le

@Stéphanie W. : On est d'accord :)
Pour le moment le RWD en est encore à son balbutiement mais je pense vraiment que c'est l'avenir du web ! Ça serait sympa d'avoir un "référentiel" des bonnes pratiques (ou bidouilles ^^) qu'on peut mettre en place dès aujourd'hui avec le meilleur compromis accessibilité / compatibilité navigateurs. Comme tu dis, il est important de partager ses expériences et son savoir avec la communauté pour avancer dans le bon sens !

Decoupe2PSD a dit le

Super article :)

Derzone a dit le

Salut,
très bon article qui donne une bonne vision de l'état actuel des choses. Il m'a également amené à faire une corrélation entre ce que l'on est en train de faire aujourd'hui et ce qu'il s'est passé avec IE6.

Ne sommes nous pas en train de reproduire les mêmes erreurs en nous ruant sur des solutions qui ne sont valables qu'à court terme ?
Le responsive n'en est qu'à ses balbutiements et aurait du demander une plus grande maturité avant de devenir un "must-have".

Je suis également d'accord avec certains des derniers commentaires : le travail d'intégrateur demande de plus en plus de polyvalence ; En partant du design jusqu'au back-end et en passant par le SEO, pour n'être souvent pas rémunéré à la valeur du travail fourni.
Surtout si l'on comptabilise le temps nécessaire à la mise à jour de nos connaissances dans chacun de ces domaines.

Et pour finir sur la question posée concernant les icônes de menu de navigation en version mobile, pourquoi ne pas proposer une rose des vents ?
- Ça symbolise la direction et est difficilement associable à une autre action (à part dans une application de boussole...).
- C'est stylisable très facilement et utilisable en monochromie.
- C'est, me semble-t-il, universel.

Encore merci pour l'article et la traduction !

Stéphanie W. a dit le

@Derzone : "Le responsive n'en est qu'à ses balbutiements et aurait du demander une plus grande maturité avant de devenir un "must-have"." ==> hélas les articles marketing bullshit (désolé) qui le présentent comme tel aujourd'hui n'aident hélas pas à faire avancer l'affaire, le responsive est devenu un buzzword comme beaucoup d'autres et très peu de ceux qui l'utilisent savent hélas les implications techniques qui sont derrière :/

"Et pour finir sur la question posée concernant les icônes de menu de navigation en version mobile, pourquoi ne pas proposer une rose des vents ?" ==> là j'avoue avoir vraiment du mal, pour moi la rose des vents = safari = un navigateur et est plus proche d'une bousole. En cliquant sur une telle icône je m'attends plus à être envoyée vers un plan par exemple ou itinéraire qu'une navigation :)

bdut a dit le

Merci pour cet article, aussi intéressant que concis et pertinent...
Bookmarké !
Concernant la remarque sur le métier de l'intégrateur qui évolue, je suis entièrement d'accord ! Et d'ailleurs pour pour moi, je trouve que l'intitulé 'développeur front-end' corresponds bien mieux à ses nouvelles compétences requises.

WavesUp a dit le

Beau boulot, on en revient de loin au dilemme compatibilité IE6/7.

deejay-bee a dit le

Bravo !!! Cet article est très intéressant. Vivement que le support évolue notamment pour ces histoires d'images en fonction des tailles d'écran.

Sauf erreur, je n'ai pas pu trouver une démo de cet exemple :
http://www.alsacreations.com/xmedia/doc/full/...

Merci !!!

imikado a dit le

C'est plus un article c'est un dossier à lui tout seul.
Merci pour le boulot :)
Les animateurs de podsource vous complimente dans un de leur épisode http://www.podsource.ch/2013/06/24/podsource-...

imikado a dit le

Après avoir lu votre article, plusieurs choses
1. très bon article, j'ai beaucoup apris des problèmes peu connu du responsive desgin
2. personnellement j'ai choisi de faire 2 versions de mon site: un pour les mobiles, l'autre pour les ordinateurs pour plusieurs raisons:
a. le site mobile est plus épuré que le site normal pour viser une utilisation différente: mise en avant des jeux et contenu ludique,
b. le site ne propose pas les mêmes contenu: j'ai volontairement enlevé certains jeux injouable en tactile
3. ma question: pourquoi passer du temps sur ce fameux responsive design qui pose tant de problème, pourquoi ne pas faire 2-3 designs de sites un normal, un mobile et un tablette ?
vous pourriez ainsi régler vos problèmes de taille de polices, formulaires, images...

Pour info, mon site de prévention: http://supercapote.com

Stéphanie W. a dit le

@imikado :
3. ma question: pourquoi passer du temps sur ce fameux responsive design qui pose tant de problème, pourquoi ne pas faire 2-3 designs de sites un normal, un mobile et un tablette ?

=> Il n'y a pas de bonne ou de mauvaise réponse : ça dépend. Deux designs ça veut dire 2 codes à maintenir, ça veut dire recourir à des techniques de détection de l'Agent Utilisateur de l'appareil, entre autre, donc ça peut très vite faire grimper les coûts. Ensuite il reste le problème de quel contenu pour quel appareil : les mobiles, ok, soit, petits écrans ? Sur quels critères ? Les tablettes : site mobile ? Oui mais c'est tout petit. Site desktop ? Oui mais ça rentre pas forcément. Et on fait quoi des fablettes, qui ont une taille entre les deux ? On fait quoi des appareils qui vont sortir demain ? On ajoute leur Agent Utilisateur à la liste ? Quelles fonctionnalités garde-t-on ? Et si l'utilisateur voulait finalement quand même cette fonctionnalité non disponible sur mobile, il fait quoi ? On lui propose quand même la version "desktop" ? Tant de questions de complications si on opte pour le site dédié mobile.
Je ne dis pas que l'un ou l'autre est mieux, cela va vraiment dépendre de la situation. Ça sera un casse tête dans les deux cas, le casse tête sera "juste" différent ;)

imikado a dit le

@Stephanie pas forcement le user-agent, plus la résolution de la largeur, mais effectivement ca demande un peu de travail mais moins que le responsive design et ses contraintes :)
Mais effectivement il faut toujours proposer la version mobile/desktop, des fois la version mobile ne propose pas certaines fonctionnalités (par exemple google analitics)

note: ce serait sympa d'être alerté quand on nous répond dans les commentaires ;)
En voyant vos tweets je me suis dit que vous aviez vu qu'ils vous citait dans podsource :)

deejay-bee a dit le

Des nouvelles pour cet exemple (voir mon précédent commentaire):

http://www.alsacreations.com/xmedia/doc/full/...

Quand je cherche table reflow je trouve des exemples mais pas celui qui figure sur la capture.

Merci

Stéphanie W. a dit le

Le bon lien est http://view.jquerymobile.com/1.3.2/dist/demos..., je corrige dans l'article merci :)

yvanobi a dit le

Bonjour à tous, bravo Stéphanie pour cette article, je suis webdesigner et comme souvent, j'integre mes sites. Je suis heureux de voir que le metier d'intégrateur devient de plus en plus " complexe " ( ca m'exite et me stress en meme temps :p ) mais comme dit plus haut, c'est assez terrible de devoir passer au design, à l'intégration, de gerer ca sur plusieurs display et de manipuler un CMS avec tout ses problemes de versions, compatibilité et j'en passe.

J'espere sincerement que plus que les standards, c'est la vision du métier qui va évoluer, en tout cas c'est une très belle conclusion que tu nous donnes !

Christele a dit le

Stéphanie, ce ne sont pas les articles sur ce sujet qui manquent, une véritable mode ces temps-ci, et même chez nous, sur Alsacréations :-)
Mais voilà, "une vrais pépite" ton article tout y est, y compris la mise en avant des questions et des manques, c'est à relire plusieurs fois ! un régal.
Mille mercis à toi pour ce travail de fond.
Christele

dioulde77 a dit le

Un article bien fait merci