nota-bene.org > Sur le web > Responsive design et Mobile first – ou pas.

Responsive design et Mobile first – ou pas.

À propos de cet article

Un article de Stéphane

Publié le 21 mars 2012

URL courte : http://nota-bene.org/887

18 commentaires

Pour la dernière refonte de nota-bene.org j’ai tenté de faire du Mobile first. Sur le principe, OK ; dans la pratique, pas complètement OK. Profitons-en pour expliquer plus avant toute la démarche de refonte en « design réactif » de cette version 6.

Comme ce site est mon site perso, je m’en sers souvent pour expérimenter des solutions, pour voir si je sais les mettre en pratique (d’une part) et si je peux les préconiser dans le cadre de mon travail (d’autre part). Par exemple pour la version 6 les questions que je me suis posées sont :

  • Peut-on faire du Mobile first qui tienne la route ?
  • Est-ce difficile de faire du Responsive design, combien ça coûte ?
  • Peut-on déjà mettre du HTML5 (notamment figure et figcaption qui permettent de remplacer avantageusement un <img src='bla.png' alt='tu ne vois ce alt que si tu le cherches' />) ?

Le parc cible

En préambule je dois rappeler que ma cible est le parc grand public : tout le monde n’a pas un smartphone-qui-tue, tout le monde ne sait pas installer une version hyper récente de navigateur. Par exemple je tape ce texte sur un Windows XP professionnel (la machine que mon employeur met à ma disposition), donc je n’ai que IE8 et aucune possibilité de le mettre à jour [1].

Je n’ai aucune raison de préjuger que vous allez consulter mon site chez vous, avec une nightly de Firefox ou de Chrome [2]. Je dois donc considérer qu’au moins 50% de mes visiteurs utilisent Internet Explorer, et pas forcément la version la plus récente. Restez avec moi, ça a son importance dans les choix qui vont suivre.

HTML5 est-il mûr ?

Comme vous le savez, le consensus depuis les débuts du web, c’est qu’un navigateur qui ne comprend pas une balise l’ignore : il affiche ses contenus sans autre forme de procès (c’est ce qui nous permet de faire des dégradations élégantes quand un plugin n’est pas chargé, par exemple). Le hic avec Internet Explorer, c’est qu’il fait bien ce qu’on lui demande, sauf que faute de connaître la balise, il est incapable de la styler (donc pas de display:block; et tutti quanti). Un type plus malin que moi a découvert qu’il suffit d’ajouter un élément factice dans le DOM avec ce nom de balise pour qu’IE la considère comme légitime et nous permette de la styler. Par exemple pour faire comprendre à IE qu’il existe bien un élément article il suffit de lui dire qu’on a ajouté des éléments article dans le DOM :

document.createElement('article')

Partant de là, peut-on se dire que tout va bien et qu’on peut donc utiliser toutes les chouettes balises de HTML5 dans un site en production, là, tout de suite ? La réponse est : ça dépend [3]

Pour un site perso comme celui-ci, il suffit d’aller chercher html5shiv.js et le tour est joué. Au pire le Javascript casse, le site est moche. C’est tout à fait supportable.

Pour un site pro, en revanche, la question se pose encore : sachant que le moindre octet compte sur un portail qui prend plusieurs millions de hits par jour, pour le moment ce n’est pas une si bonne idée.

Nous pourrons utiliser sans ennui les éléments sémantiques HTML5 quand IE8 aura disparu. Avant ça, prudence est mère de sûreté.

Media queries

On a dit qu’on faisait un site moderne, on doit donc s’attendre à ce que nos visiteurs accèdent à ce site avec une variété de terminaux différents : de l’écran 24 pouces au smartphone, de l’ordinateur portable à la tablette (je parle de Mobile first plus bas, promis, mais pour l’instant oublions-le le temps que je vous expose ma démarche).

Premier choix : quelle taille pour mon design ? Partant du principe que la plupart des gens qui consultent ce site sur un ordinateur ont un écran d’au moins 1024 pixels de large, j’ai choisi arbitrairement 922 pixels de large, soit 6 colonnes de 112 pixels, des gouttières confortables de 42 pixels, et 20 pixels de chaque côté pour faire un padding de confort. Ce qui nous fait un contenu central de 574px de large avec une police de base à 14px [4], encadré par des jolies marges dans lesquelles poser les figcaption et les pavés de type « à propos de cet article ».

Ensuite, à quel endroit poser les points de rupture de votre design ? En fait il n’existe pas de règle, pas plus qu’on ne peut être sûr qu’un utilisateur navigue en ayant dimensionné son navigateur pour prendre la totalité de l’écran.

La méthode très simple que nous appliquerons est la suivante : redimensionnez votre fenêtre, et dès qu’une barre horizontale apparaît, considérez que c’est un point de rupture. Il faut alors faire une déclaration supplémentaire et commencer à « casser » le design : dans mon cas, en-deçà de 930px disponibles (je ne veux pas attendre le dernier moment pour des questions de confort visuel), réduire la marge gauche, ramener les figcaption dans le flux de l’article puisqu’ils n’auront plus de place dans la marge gauche, commencer à indiquer aux images qu’elles ne doivent pas dépasser des bords en appliquant les bons conseils de tonton Raphaël :

img { max-width:100%; height:auto !important; box-sizing:border-box; }

De la même manière, en-dessous de 600px, je laisse quelques marges, j’enlève tous les float, je ne fais plus appel aux web fonts (ça n’a que peu de sens sur un petit affichage), je fais des polices de titre moins grandes (400% sur un petit écran, ça peut tourner au cauchemar) et j’en profite pour surcontraster les polices.

Prenons deux secondes en passant pour parler de surcontraste : à la demande générale d’Olivier, qui souffrait de mon noir sur blanc très tranché dans la précédente version, j’ai opté pour un gris sombre (#333) sur blanc, voire pour certains contenus « décoratifs » (les exergues [5], les dates, les liens visités) pour un gris plus clair (#666). Profitons donc de nos media queries pour recontraster l’ensemble : allez zou, tout en noir sur blanc sur les petits affichages ! C’est une règle que je n’ai encore jamais vue dans les articles qui parlent de design réactif, et qui à mon avis est tout à fait pertinente [6].

Mobile first

Luke Wroblewski est un mec pas bête, et je suis sûr qu’il a beaucoup de bonnes raisons de prôner le Mobile first (bientôt je lirai son livre sur le sujet), notamment le fait qu’on part du contenu principal, celui dont on est sûr qu’il est demandé par le visiteur, puis on ajoute des choses autour (je résume grossièrement, hein). L’idée serait donc de faire un design pour mobile, puis d’ajouter des règles CSS d’enrichissement au fur et à mesure que la zone d’affichage du navigateur s’élargit, comme l’explique très bien Nicolas Torres dans son article sur Webdesign Friday.

Oui mais, on l’a vu plus haut, une grosse partie de nos visiteurs, jusque-là, n’ont pas encore accès aux media queries : Elles ne sont disponibles qu’à partir... d’IE9 (voir le tableau de support des media queries sur When can I use ?).

Dois-je donc proposer à une partie encore non négligeable de mes visiteurs une version linéaire, pensée pour un petit écran, alors que par ailleurs leur navigateur est tout à fait en mesure d’afficher un design riche ? J’ai choisi de répondre non.

Note liminaire : le support de Windows XP arrive à son terme, la plupart de nos visiteurs vont donc devoir mettre à jour leur parc (et donc leur navigateur). On peut donc raisonnablement supposer que d’ici un an ou deux la réponse sera toute différente, mais pour le moment présent, non.

Donc, en résumé : j’ai une approche « content first » et autour je brode [7], j’ajoute la navigation, un footer riche (commentaires, liens vers twitter, informations légales). Pour le parc de mes visiteurs, là encore, le Mobile first n’est pas mûr.

Vue mobile

Pour autant, toute cette histoire de responsive design m’a permis sans trop d’effort d’avoir au final une CSS pour mobile : il me suffit d’aller jeter un œil dans mon Firebug, de copier/coller le rendu calculé en-deçà de 600px dans un fichier mobile.css et d’y faire appel via un media='handheld'. Ça fait toujours plaisir à Opera Mini et aux vieux navigateurs des téléphones à mi-chemin entre l’entrée de gamme et le smartphone.

Et puis tiens, pendant qu’on y est, regardons ce qui se fait autour de nous : Twitter, Flickr, etc. proposent tous un lien vers la « version mobile ». Qu’est-ce qu’ils changent ? Principalement ils linéarisent la page, servent des contenus avec très peu de styles, très peu d’images (et dans un format plus petit), et pas de scripts.

Je me suis donc nourri de cette idée-là pour proposer aux visiteurs, en opt-in, de choisir une version mobile. On pose un cookie, Spip génère des pages différentes selon le réglage. Profitons-en donc pour adapter le design, mais pas seulement :

  • Fournissons uniquement la CSS mobile.css (qui ne fait pas de requête sur les web fonts, rappelez-vous) ;
  • Supprimons dans notre code tous les appels à Javascript [8] ;
  • Réduisons les contenus : fournissons une image directement bridée en taille (par défaut elles font 574px, soit la largeur de notre colonne en vue « desktop », réduisons-les à 300px, ce qui devrait être suffisant même pour une petite résolution de smartphone à 320px), supprimons la moitié du contenu du footer (tous les liens vers Twitter sont accessoires sur mobile, par contre je conserve la « zone de rebond » des commentaires, des liens avant/après et évidemment les informations légales). Vous allez me dire « oui mais moi j’ai beau avoir un smartphone, je viens de le brancher sur la borne wifi chez moi et je veux tout voir comme si j’avais un navigateur de bureau ». Qu’à cela ne tienne, il vous suffit de ne pas demander expressément la version mobile : les media queries sont là pour ça.

En résumé

La philosophie du mobile first est bonne, mais dans mon environnement cible le parc n’est pas encore mûr. De plus, cette approche me « bridait » un peu trop quand j’en étais à réfléchir à une mise en page pour la version desktop [9]. J’ai donc opté pour une approche content first (une voie moyenne, en somme), puis brodé autour, et fourni à l’utilisateur un moyen de voir le site dans une version très allégée.

On verra ce que ça donne à l’usage, encore une fois c’est une expérimentation. À mon avis un des premiers enseignements à tirer de tout ça, c’est au moins la notion de surcontraste sur petit écran ; c’est toujours ça de pris.


Notes

[1Évidemment je résume grossièrement, vu que pour ma part j’ai un profil « développeur » et que j’ai donc pu installer tous les navigateurs que je veux ; mais c’est mon travail, en même temps. La plupart des utilisateurs ont une configuration « standard » qui ne leur donne aucun droit d’installation : c’est comme ça dans la plupart des entreprises soucieuses d’une bonne gestion de leur parc et conscientes des risques de sécurité.

[2Une nightly c’est une version hyper récente d’un navigateur, en cours de développement.

[3Vous allez voir, tout cet article est un article de Normand.

[4Bien sûr je continue à prôner et à pratiquer les polices en em. Satané IE, me direz-vous.

[5En anglais dans le texte : les pullquotes. Au passage, les exergues génèrent des h3 qui viennent « requalifier » des segments de contenus enfants de h2, ça non plus je ne le vois pas souvent et ça me semble pertinent quand on regarde le plan de la page au final.

[6C’est avec ce genre de petit ajout à votre boîte à outils que j’espère atteindre la postérité, je suis diabolique.

[7D’ailleurs, en passant, pour la première fois le design s’est fait directement dans le navigateur sans passer par Photoshop : j’ai juste utilisé LibreOffice Calc pour mes calculs de colonnage.

[8Le lecteur attentif verra que quelques petits morceaux de Javascript sont encore là, c’est Spip qui les rajoute et je ne me suis pas encore penché sur le problème.

[9Même si le design au final est minimaliste et peut donner à penser que j’aurais pu réellement faire du mobile first et l’enrichir. J’ai toujours considéré qu’un site perso doit être le reflet de son auteur, autrement dit si on n’a que des notions de design et pas plus de talent que ça, tant pis : le site sera au niveau de ce qu’on sait faire. Je n’aime pas l’idée de demander à quelqu’un de faire mon design, c’est contraire à cette notion de cohérence.


Commentaires

    • 21 mars 2012

    Il y a des solutions pour prendre en compte les vieux butineurs en entreprise, et forcément si ça passe par du JS : https://github.com/scottjehl/Respond

    Vu le minimalisme assumé de ton design, c’est pas trop compliqué de faire du mobile first et du responsive clin d'œil

    Répondre à Frank Taillandier

    • 21 mars 2012

    Comme toi, je pense que proposer la version mobile au navigateurs ne supportant pas media-queries semble assez réducteur.

    Aujourd’hui j’opte finalement pour la méthode du début du full css. C’est à dire que je commence du HTML pur et y ajouter un style simple. Ceci de façon fluide pour qu’il s’adapte de lui même à l’espace qu’on lui donne.

    Puis j’utilise les media-queries pour ajuster tailles, position et contraste pour mieux répartir les éléments dans l’écran et améliorer la lecture en fonction du support.

    ltIE9 : design fluide
    mobiles et IE9+ : design ajusté

    Sur ce principe le "content first" me parait effectivement un terme approprié.

    Répondre à Yvain Liechti

    • 21 mars 2012

    Frank :


    Vu le minimalisme assumé de ton design, c’est pas trop compliqué de faire du mobile first et du responsive

    Oui c’est ce que je disais en note, mais j’essaie d’avoir une démarche "théorique" sourire

    Répondre à Stéphane

    • 21 mars 2012

    Salut !

    Je viens donc de tester avec un Nokia E7 (webkit je crois) et ta page d’accueil est bien *sauf* les lettres des titres qui se chevauchent carrément (à cause de l’italique il me semble). Et puis, le gras sur les titres est plutôt alourdissant à mon avis.

    ++

    Répondre à Suske

    • 21 mars 2012

    Ces temps-ci j’ai expérimenté avec une feuille de style où toutes les infos de mise en forme sont au début sans media queries, suivies des infos de mise en page en utilisant les media queries pour gérer au moins 3 types d’écrans : mobiles | desktop (800 1024) | widescreen.
    Je recopie les infos correspondant à la résolution desktop dans les CSS appelées conditionnellement pour gérer les limitations d’IE 8 et -. Pour le moment je trouve que ça marche pas mal.

    Répondre à iSoph

    • 22 mars 2012

    Bel article. Merci pour le lien, je suis honoré !

    Répondre à Nicolas Torres

    • 22 mars 2012
    • en réponse à Suske

    Suske : Je suis preneur d’une saisie d’écran, si tu peux...?

    Répondre à Stéphane

    • 22 mars 2012

    Hello,
    D’accord aussi à propos du « mobile first ». C’est sympa en théorie mais peu – voire, pour pas mal de workflows, pas du tout – applicable en pratique.

    Un truc qui m’a fait sursauter : les éléments < figure> et < figcaption> ne remplacent absolument pas < img /> et encore moins son attribut alt. Je crois qu’il s’agit d’une confusion entre la légende et le texte alternatif.

    ……………
    « Peut-on déjà mettre du HTML5 (notamment figure et figcaption qui permettent de remplacer avantageusement un < img src=’bla.png’ alt=’tu ne vois ce alt que si tu le cherches’ />) ? »
    ……………

    Répondre à AudrasJb

  • AudrasJb : je me plaçais du point de vue accessibilité. La dernière fois que j’ai regardé dans HTML5, on vérifiait l’accessibilité sur la base d’un algo de type :

    1. si l’image comporte un alt, le lire
    2. sinon, regarder si l’image est incluse dans un figure, lire le figcaption

    Je suis d’accord que les usages peuvent différer, mais dans mon cas ils sont identiques, j’aurais dû le dire plus spécifiquement. sourire

    Répondre à Stéphane

  • Stéphane : justement, du point de vue de l’accessibilité, la présence de l’attribut alt est tout simplement obligatoire http://rgaa.net/Presence-de-l-attri.... En fait l’attribut alt d’une image et l’élément <figcaption> n’ont pas la même utilité. Leur contenu ne devrait pas être redondant (texte alternatif ≠ légende).

    D’ailleurs, l’élément < figure> peut par exemple contenir plusieurs images et un seul <figcaption> faisant office de légende pour l’ensemble des images (pour une galerie par exemple). L’attribut alt reste dans tous les cas obligatoire pour chacune des images (quitte à être vide suivant les cas).

    Tout est ici : http://html5doctor.com/the-figure-f... (voir les commentaires également) clin d'œil

    Répondre à AudrasJb

  • AudrasJb : Je regarde vers le futur, disons. sourire

    Je n’ai jamais fait secret du fait que je préfère le pragmatisme à l’adhésion à des règles strictes. Je ne suis pas sujet au RGAA, donc je tente des trucs.

    C’est comme pour HTML5 : je dis qu’il ne faut peut-être pas encore employer les balises structurelles pour un gros site en production, ça n’empêche pas que je les utilise ici.

    Voir les remarques sur le Paciello Blog.

    There is also moves afoot to add a figure role to the iAccessible2 API, and Firefox are making progress (Firefox bug) on the implementation of the labelling relationship for figcaption/figure and role implementation for figcaption.

    Alors voilà, j’avoue ne pas me rappeler où j’ai vu l’algorithme que je résumais, mais ça a du sens.

    Pour ma part comme je le disais j’utilise le figcaption comme j’utilise le alt (d’ailleurs je prends les mêmes composants de mon CMS, le « titre de l’image » comme on dit dans SPIP).

    Note bien que j’utilise un alt vide, ouf le RGAA ne va pas venir égorger des petits chats chez moi clin d'œil

    (voir Le problème de position:fixed par exemple)

    Répondre à Stéphane

  • AudrasJb : Ah, voilà : HTML5 : Techniques for providing useful text alternatives

    The figure and figcaption elements provide a method to explicitly associate a caption with with a variety of content including images. Any content inside the figure element that is not contained within the figcaption element is labelled by the content of the figcaption element. The figcaption content may be an adjunct to the text alternative provided using the alt attribute :

    The figcaption content may be a text alternative for the image, obviating the need for a text alternative provided using the alt attribute. This would only be the case if the figcaption content provides an adequate text alternative for the visual content in the image.

    Répondre à Stéphane

    • 23 mars 2012

    Hello,

    « Pour ma part comme je le disais j’utilise le figcaption comme j’utilise le alt (d’ailleurs je prends les mêmes composants de mon CMS, le « titre de l’image » comme on dit dans SPIP). »

    En fait pour résumer, c’est finalement juste ça qui me faisait tiquer : une légende et un texte alternatif ne sont sémantiquement pas les mêmes choses et n’ont pas le même objectif. Le texte alternatif peut être vide alors que l’image porte une légende (image d’une galerie), et la légende peut ne pas exister alors que l’image doit porter un texte alternatif (contenus textuels au format image).

    J’utilisais le RGAA en tant que référentiel d’accessibilité (puisque c’est de ça dont il est question) mais comme tu n’est pas « sujet » à ce référentiel, j’aurais du prendre WCAG 2 (voire Opquast), ç’eut été pareil…

    Sinon, j’utilise les principaux éléments HTML5 de structuration ainsi que les "nouveaux" rôles ARIA depuis 6 mois en production (avec contrôle de la présence de JS sur les utilisateurs d’IE et failback plus ou moins poussé). Pour l’instant, aucun problème n’est remonté. On en est pas au mobile first (et heureusement… brrr) mais en tout cas ça avance sourire

    Répondre à AudrasJb

  • AudrasJb :

    En fait pour résumer, c’est finalement juste ça qui me faisait tiquer : une légende et un texte alternatif ne sont sémantiquement pas les mêmes choses et n’ont pas le même objectif. Le texte alternatif peut être vide alors que l’image porte une légende (image d’une galerie), et la légende peut ne pas exister alors que l’image doit porter un texte alternatif (contenus textuels au format image).

    Sur le fond tu as effectivement raison, ce n’est pas la même chose. Mais dans mon cas, une et une seule image est associée à une et une seule légende, et le draft de HTML5 comme je le disais le permet, donc je reste à peu près dans les clous.

    Tu imagines bien que ce serait malvenu de ma part de faire des trucs dans une démarche dramatiquement et volontairement inaccessible, vu les efforts que je pousse notamment sur le longdesc sourire

    Répondre à Stéphane

    • 2 octobre 2012

    Dans le derniers Hors Série du magazine "Web Design" (Oracom), je découvre la méthode "mobile first" par un article d’Aurélien Aries. Au début, cela me semblait parfaitement logique et "économique" comme solution. Malheureusement, à cause des media queries et d’IE, l’auteur conseille de copier le contenu des media queries et d’y ajouter les commentaires conditionnels "IE7" et IE8".

    Du coup je m’interroge : sans les anciennes version de IE, la méthode mobile first a ses intérêts c’est indéniable. Cela étant, puisqu’il faut dupliquer le code des média queries, le code devient d’un coup plus lourd (le fichier css à charger aussi) et donc j’ai l’impression que la méthode perd tout son intérêt.

    Je dois avouer ne pas être au fait de toutes les données lorsqu’il s’agit de design responsive. Je partage simplement une interrogation en espérant que vous ayez des éléments à y apporter.

    Merci pour l’article.

    Répondre à Naïa

    • 2 octobre 2012
    • en réponse à Naïa

    Naïa : En fait ce n’est pas hyper coûteux. Dans la logique que tu mentionnes, il te suffit à chaque évolution de copier-coller toutes les instructions CSS et de les coller dans une CSS dédiée aux vieux IE.

    Regarde le commentaire de Sophie, elle abonde dans ce sens.

    Pour ma part je ne suis pas encore complètement passé au Mobile first mais ça a effectivement du sens. C’est (presque) juste une question de maturité des outils et des développeurs. Donc une question de temps avant qu’on y passe systématiquement.

    Répondre à Stéphane

  • Stéphane : Je te remercie pour la réponse. En fait là où je m’interroge pour l’heure actuelle (je ne doute pas que lorsque les navigateurs suivront mieux et seront mieux répandus tout ira bien), c’est en terme de poids de fichier et quantité de travail.

    Dans la méthode "content first", on trouve :
    * le css pour les écrans d’ordinateur compatible IE 7 et 8 (pour la majeur partie du code)
    * le css pour les écrans plus petit (tablette et portable classiquement)
    Soit au total "3 fois le code" si on peut dire.

    Dans la méthode "mobile first", on trouve :
    * le code pour le mobile
    * le code pour la tablette éventuellement
    * la code pour les écrans d’ordinateur
    * le code pour IE 7
    * le code pour IE 8

    Soit au total "5 fois le code".

    On voit bien qu’en terme de longueur la méthode mobile first génère des fichiers potentiellement plus lourd (même si cette méthode a l’avantage de générer un css mobile très léger et "épuré" si j’ose dire). En terme de mise-à-jour, à chaque fois qu’une modification sera faite en "ordinateur" il faudra aussi le changer sur IE 7 et IE 8 (ce qui n’arrive pas en "content first") avec des risques d’oublis et autres. Enfin là me direz-vous, un outil comme Saas pourra très bien prendre le relais et m’éviter ce genre de bourdes et autres redondances au moment d’écrire mon code.

    J’en réfère donc à votre expérience. Est-ce que ça vaut le coup de faire son design en ce sens ? En quoi voyez-vous la méthode "mobile first" comme un gain ? Est-ce que ce n’est pas un peu tôt à cause des version IE qui précèdent l’actuelle ? Ce sont là toutes les questions que je me posais.

    Demain bien sûr, quand tout le monde aura bien intégré tout ce qu’il faut et que tous les ordinateurs et périphériques seront à jour (je rêve oui je crois...) je vois bien que ces questions seront dépassées. Excusez-moi si je me répète.

    Répondre à Naïa

    • 14 novembre 2012

    Un moment que j’avais dans l’idée de répondre à ce billet. Le montage d’un site conséquent au boulot me pousse à poser ici la méthode que j’utilise (peut-être pas la meilleure, m’enfin bon, elle fonctionne pour moi. J’empile ainsi :

    1) une css commune (celle qui passera sur petit terminal finalement) ;

    2) une ou plusieurs autres avec media queries (petit/moyen/grand) en posant la querie sur le link rel="stylesheet" media="screen and (ma querie)" et non dans la css ;

    3) un appel conditionnel pour ie 8 et inférieur appelant sans querie la/les css qui vont bien parmi celles appelées en media querie (vu qu’il ne pige pas l’appel avec queries).

    Hop, le tour est joué !

    Avantage
    je ne me coltine pas plusieurs css pour querie, pour ie etc. Ce sont les mêmes.

    Inconvénient
    le nombre de requêtes. Mais enfin, je trouve que ça reste quand même assez peu.

    Répondre à Emmanuel Clément

Qui êtes-vous ?
Votre message
  • Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.

Ceci est la version Bureau Afficher la version Mobile