• rwd

    « Responsive Web Design »,
    par Ethan Marcotte

    S'adapter, réagir et vaincre.

    Traduction par Magalie Cadiou et Carole Lesimple,
    avec l'aimable permission d'A List Apart et de l'auteur Ethan Marcotte.
    Révision par Caroline Comacle et Philippe Michou.
    Publié originalement le 25 mai 2010 sur A List Apart.

    Le Web Design Réactif
    par ETHAN MARCOTTE

    Le contrôle qu’exercent les designers au sein du média imprimé et qu’ils désirent souvent retrouver au sein du virtuel est simplement le produit d’une limitation de la page imprimée. Nous devrions accepter le fait que le Web n’a pas les mêmes contraintes, et concevoir en fonction de cette flexibilité. Mais avant, nous devons « accepter le flux et le cours des choses.

    John Allsopp, « Le Maître du Web Design ».


    Commentant son métier, l’Anglais Christopher Wren affirmait avec un brin d’ironie que « l’architecture vise l’éternité ». Cette phrase a un côté intrigant : à la différence du Web, dont le contenu change souvent d’une semaine à l’autre, l’architecture est définie par sa permanence. Les fondations d’un bâtiment sont son empreinte. Elles définissent la charpente, qui donne sa forme à la façade. Chaque étape du procédé architectural est plus immuable, plus statique que la précédente. Les décisions créatives forment un espace physique, définissant la façon dont les gens vont évoluer dans cet espace durant des dizaines, voire des centaines d’années.

    Le domaine du Web est une tout autre dimension. Notre travail revêt un caractère éphémère, souvent modifié ou remplacé dans les années qui suivent et son apparence dépend de la taille des fenêtres, de la résolution des écrans, des préférences des utilisateurs, des polices de caractères installées sur leurs machines… Ces éléments ne sont qu’une petite partie des imprévus à prendre en compte lors de la publication de notre travail. Au fil des années, nous sommes devenus des experts en la matière.

    Mais l’environnement change, peut-être plus vite qu’on ne le souhaiterait. La navigation mobile devrait prendre le pas sur celle effectuée à partir d’ordinateurs de bureau d’ici trois à cinq ans. Deux des consoles de jeux vidéo les plus vendues sont équipées d’un navigateur (l’un d’entre eux est excellent). On assiste à la création de nouveaux claviers, classiques ou T9, de souris, de manettes de jeux plus compactes, d’interfaces tactiles. Pour résumer, nous devons, plus que jamais, gérer un nombre croissant de périphériques, de systèmes d’entrée de données, et de navigateurs.

    J’ai récemment rencontré des entreprises ayant pour projet de créer un « site web pour iPhone ». Cette idée est intéressante : à première vue, il s’agit d’utiliser la qualité du moteur WebKit en tant que navigateur, mais aussi en tant qu’outil puissant pour dépasser la sédentarité des ordinateurs de bureau. En tant que créateur de sites Web, je pense que ces demandes explicites sont rassurantes, puisqu’elles permettent une définition claire des problèmes associés. L’expérience mobile peut être divisée en plusieurs sous-domaines, des espaces différents et séparés du site « non accessible aux iPhone ». Oui, mais après ? Un site pour iPad ? Un site pour le Nokia N90 ? Est-il dans nos possibilités de continuer à encourager chaque nouveauté possédant son système sur-mesure ? On finit au bout du compte par avoir l’impression de jouer à un jeu à somme nulle. Mais, en tant que Web designers, comment nous adapter et comment adapter les produits que nous développons ?

    Une base flexible

    Prenons un exemple de mise en page. J’ai créé une page simple pour un hypothétique magazine. La page est organisée en deux colonnes, et basée sur un système de grille fluide. Quelques images flexibles y sont dispersées. En tant que partisan de longue date des mises en page non fixes, j’ai longtemps pensé que leur flexibilité serait un gage de leur persistance. Cela est vrai jusqu’à un certain point : les mises en page flexibles ne tiennent pas compte de la taille de la fenêtre d’un navigateur et s’adaptent de façon esthétique aux écrans qui peuvent s’utiliser en mode portrait ou paysage.

    responsive-web-design

    Les grandes images restent grandes. Notre mise en page, pourtant flexible, s’adapte mal aux changements de résolution ou d’aire d’affichage.

    Aucune mise en page, qu’elle soit fixe ou variable, ne peut s’adapter de façon homogène à un contexte autre que celui pour lequel elle a été conçue. Dans cet exemple, la mise en page s’harmonise avec la taille du navigateur, mais des difficultés se présentent très rapidement en basse résolution. Si l’aire d’affichage est inférieure à 800×600, l’illustration derrière le logo est rognée, le texte peut s’imbriquer, et les images en bas de page deviennent trop compactes pour être correctement lisibles. Les plus basses résolutions ne sont pas les seules affectées : en affichant la page sur un écran large, les images deviennent encombrantes, débordant sur les éléments autour.

    En bref, nos mises en page flexibles fonctionnent bien pour un affichage sur un système classique d’ordinateur de bureau, mais rencontrent des limites au-delà de ces affichages classiques.

    Devenir réactif

    « L’architecture réceptive » est une nouvelle discipline qui étudie l’adaptation des espaces physiques à la présence des personnes qui y évoluent. Grâce à une combinaison de robotique et de matériaux sensibles, les architectes testent des installations artistiques et des structures murales qui se courbent, se fléchissent, et s’élargissent quand la foule s’en approche. Des capteurs de mouvements peuvent être associés à un système de contrôle de la température ambiante pour ajuster l’éclairage et la température d’une pièce au fur et à mesure que des gens y entrent. « Une technologie de verre intelligent » a déjà été mise au point : le verre s’opacifie automatiquement lorsqu’on franchit le seuil d’une pièce afin d’offrir davantage d’intimité à ses occupants.

    Dans Interactive Architecture, Michael Fox et Miles Kamp décrivent ce processus d’adaptation comme « un système basé sur de nombreux circuits, dans lequel on peut entrer en dialogue ; un échange d’informations continuel et constructif ». Je pense qu’il faut noter cette distinction subtile, mais majeure : plutôt que créer des espaces immuables, statiques qui définissent une expérience donnée, l’habitant et la structure peuvent (et doivent) s’influencer mutuellement.

    C’est la voie du progrès. Plutôt que concevoir des systèmes déconnectés les uns des autres en augmentant le nombre de dispositifs Internet, ces systèmes peuvent être considérés comme les facettes d’une expérience commune. Les sites Web peuvent être créés dans le but d’obtenir une visibilité optimale, mais on peut aussi y implanter des technologies standard, pour les rendre à la fois flexibles et plus adaptés au support de lecture. Pour résumer, les sites Web doivent être réactifs. Oui, mais comment les concevoir ?

    Découvrir les requêtes de média

    Depuis l’arrivée du CSS 2.1, nos feuilles de style ont gagné en popularité sous l’effet de la diversité des types de média. Si vous avez déjà rédigé une feuille de style destinée à l’impression, vous connaissez déjà le concept :

    Puisque les feuilles de style ne sont pas uniquement destinées à l’impression, le CSS fournit une myriade de types de média, chacun prévu pour une classe de périphériques Web. Mais la plupart des navigateurs et des outils n’ont pas été conçus dans un esprit de spécialisation, et l’implémentation est souvent imparfaite. Il arrive même que certains types de média soient tout bonnement ignorés.

    Heureusement, le W3C a intégré une requête de médias (“media queries ») au CSS3, ce qui permet d’améliorer la compatibilité avec les différents types de média. Une requête de média permet de viser certaines catégories de média, mais permet également de vérifier les caractéristiques principales du support affichant le travail. Par exemple, concernant la récente ascension de WebKit, les requêtes de média sont utilisées pour adapter la feuille de style aux iPhone, aux téléphones Android, et autres. Pour ce faire, nous pourrions intégrer une requête dans un attribut média lié à une feuille de style :

    La requête comprend deux éléments :

    1. un type de média (screen), et
    2. la requête elle-même, entre parenthèses, contenant une fonction média (max-device-width) à contrôler, suivi de la valeur cible (480px).

    En clair, on interroge le média pour vérifier si sa résolution horizontale (max-device-width) est inférieure ou égale à 480px. Si oui (en d’autres mots, si le travail s’affiche sur un petit écran comme celui de l’iPhone), alors le support charge shetland.css. Sinon, le lien est tout bonnement ignoré.

    Par le passé, les concepteurs de sites Web ont testé des mises en page gérant la résolution, reposant pour la plupart sur des solutions JS comme l’excellent script de Cameron Adams. Mais la requête de média est associée à de nombreuses fonctionnalités, qui vont bien au-delà de la résolution de l’écran, élargissant ainsi le champ des requêtes. De plus, l’insertion du mot-clé and permet de multiplier les valeurs au sein d’une même requête.

    Le nombre de requêtes n’est pas limité et ces dernières peuvent être incluses dans l’attribut @media du CSS :

    Ou dans la commande @import :

    L’effet est le même dans les deux cas : si le support réussit le test imposé par notre requête, la partie correspondante du CSS sera appliquée. Les requêtes de média sont, en résumé, des commentaires conditionnels. Au lieu de viser une version spécifique d’un navigateur, on peut opérer des corrections chirurgicales de la mise en page pour qu’elle s’affiche au-delà de la résolution initiale.

    S’adapter, réagir et vaincre

    Prenons le cas spécifique des images en bas de la page. Dans la mise en page initiale, le CSS ressemble à ceci :

    Il me semble important de préciser quelques propriétés typographiques de la mise en page : Chaque .figure est redimensionné à environ un tiers de la colonne conteneur, la marge de droite étant réduite à zéro pour les deux images à la fin de chaque rangée (li#f-mycroft, li#f-winter). Cela fonctionne assez bien, jusqu’à ce que la zone d’affichage devienne plus petite ou plus grande que celle de la mise page initiale. Grâce aux requêtes de média, on peut appliquer des « adaptateurs de résolution », qui gèrent la mise en page en fonction des changements d’affichage.

    On indique tout d’abord une zone d’affichage en-dessous d’une certaine résolution. Disons 600px. En bas de la feuille de style, créons un nouvel attribut @media, comme ceci :

    Si l’on ouvre la page modifiée dans un navigateur récent et que l’on réduit la taille de la fenêtre en deça de 600px, la requête de média va désactiver la propriété float, et les éléments vont ainsi se positionner les uns au-dessus des autres. Notre mise en page minimaliste s’affiche convenablement, mais les images ne sont toujours pas réduites de façon intelligente. L’intégration d’une nouvelle requête média permet d’influencer l’affichage des images :

    responsive_web_design

    La disposition des images peut être modifiée pour s’adapter aux petits supports.

    Ne faites pas attention aux pourcentages peu esthétiques ; nous sommes simplement en train de redimensionner la grille fluide pour l’adapter à la nouvelle mise en page. En fait, lorsque l’écran franchit le seuil des 400px, nous passons d’une mise en page à trois colonnes à une mise en page à deux colonnes, ce qui rend les images plus visibles.

    On peut conserver la même approche pour les écrans larges. Pour les résolutions plus importantes, on peut mettre en place un traitement permettant d’afficher nos images sur une même ligne :

    Nos images s’organisent parfaitement, de la plus basse à la haute des résolutions, optimisant l’adaptation de la mise en page aux changements de taille et de résolutions.

    responsive_web_design

    L’indication d’une largeur minimale plus élevée dans la requête de média, permet d’ afficher les images sur une seule ligne.

    Mais ce n’est que le début. À partir des requêtes de média intégrées au CSS, on peut jouer sur de multiples facteurs au-delà de la disposition de quelques images : on peut par exemple utiliser des mises en page nouvelles ou alternatives, chacune dédiée à un éventail de résolutions, rendant peut-être les éléments de navigation plus visibles sur un écran large, ou en les repositionnant au-dessus du logo sur les écrans plus petits.

    responsive_web_design

    En faisant de la conception réactive, nous pouvons adapter nos contenus aux petits supports aussi bien qu’optimiser leur présentation sur toute une série de supports.

    La conception réactive ne se limite pas aux modifications de la mise en page. Les requêtes de média permettent des réajustements incroyablement précis pendant la réorganisation des pages : on peut augmenter la taille de la zone cible des liens pour les petits écrans, afin de respecter la loi de Fitts relative aux supports tactiles ; choisir de montrer ou cacher des éléments pouvant améliorer la navigation ; appliquer une composition réactive pour modifier graduellement la taille du texte, optimisant donc la lecture sur les petits supports.

    Quelques notes techniques

    Les requêtes de média sont parfaitement compatibles avec les navigateurs les plus récents, tels que Safari 3+, Chrome, Firefox 3.5+ et Opera 7+, de même que la plupart des navigateurs pour mobiles (Opera mobile et WebKit par exemple). Les versions plus anciennes de ces navigateurs ne sont bien entendu pas compatibles avec les requêtes de média. Bien que Microsoft se soit engagé à intégrer les requêtes de média dans IE9, cette fonction n’est toujours pas intégrée.

    Cependant, si on veut intégrer une fonction requêtes de média dans un navigateur, on peut adopter une solution JavaScript :

    • Un plugin jQuery (2007) permet d’utiliser des fonctions de requêtes de média limitées, appliquant uniquement les propriétés largeur min et largeur max.
    • css3-mediaqueries.js, sorti plus récemment, prétend « rendre IE 5+, Firefox 1+ et Safari 2 complètement transparents et compatibles avec les requêtes de média CSS3 » intégrées par l’attribut @mediablock. Même s’il s’agit seulement de la version 1.0, j’ai trouvé cet outil plutôt bien fait, et je compte suivre son évolution.

    L’utilisation de JavaScript en rebute plus d’un et c’est parfaitement compréhensible. Ce code est néanmoins très utile pour la mise en page basée sur les grilles fluides, assurant la flexibilité de vos pages et leur compatibilité avec des navigateurs ou supports inconnus.

    Allons de l’avant

    Les grilles fluides, les images flexibles et les requêtes de média sont les trois ingrédients indispensables d’un Web design réactif, mais leur utilisation nécessite l’adoption d’un nouveau mode de pensée. Au lieu de laisser notre contenu de côté pour cause d’incompatibilité ou de configuration spécifique des supports, les requêtes de média nous permettent d’améliorer notre travail progressivement pour le publier sur divers supports. Cela n’empêche pas les clients de commander des pages exclusivement destinées à des supports précis. Par exemple, si les contenus des sites pour supports mobiles sont plus limités que leurs équivalents pour PC, alors il pourrait être intéressant de proposer des contenus différents pour chacun d’entre eux.

    Mais cette façon de penser le Web design ne doit pas être systématique. Aujourd’hui plus que jamais, nos créations visent à être exposées sur un maximum de supports. Le Web design réactif nous permet d’aller de l’avant et nous offre enfin un moyen de concevoir le « flux et le cours des choses ».


    36 Responses to “« Responsive Web Design »,
    par Ethan Marcotte”

    1. jonathanulco

      Merci beaucoup pour la traduction :)
      J’espère que ça va continuer comme ça ! et vivement le petit flux rss. Et en plus vous avez mis les conseils de A List Apart en pratique !

      Encore merci :)

      Répondre
      • mellifico

        Merci beaucoup pour ces encouragements.
        Il n’y a pas de flux rss, car pour l’heure nous travaillons trop lentement…
        Nous espérons publier très bientôt deux autres textes du même auteur et qui viennent complèter celui-ci : “Fluid Grids” et “Fluid Images”.

        Répondre
    2. jeromeM

      Merci et bravo pour la traduction de cet article.

      Avec cet prise en compte des différences d’affichage depuis un même design il y a du travail et beaucoup de maquettes à réaliser, le métier se spécialise et se complexifie…

      Pour le côté intégration basé sur media queries j’ai trouvé ce framework : http://lessframework.com/

      Répondre
    3. khat

      Magnifique article et traduction en or.
      Tout ceci donne une puissante envie d’expérimentation!
      Merci à l’équipe

      Répondre
    4. dmsr

      20/20
      Jador! Pile poil ce que je cherchais… attends avec impatience l’article sur les image fluides!

      MERCI!

      Répondre
    5. Christophe

      Bonsoir,
      et standing ovation pour la traduction, et les exemples à l’appui le tout avec une excellente pédagogie.
      Mes respects, vivement le rss pour devenir incollable.
      Merci !

      Répondre
    6. Davadel

      Merci beaucoup pour cette traduction et merci beaucoup à l’auteur pour cette article très intéressant.

      Répondre
    7. yes da fonk

      merci merci et merci pour la traduction. Keep going. Je veux encore plus de traduction :) toujours pluuuuuuus !!!

      Répondre
      • Mellifico

        Nous avons le dernier petit morceau de cette trilogie en réserve (“Fluid Images”), approuvé par Mr.Marcotte lui-même (cet article n’a pas été publié sur A List Apart mais sur le blog d’Ethan). Cette traduction paraitra dans quelques jours.

        Répondre
    8. Jonathan, Webdesigner

      Très bon article !

      J’ai cependant un petit doute sur le redimensionnement des images, dans le cas d’un site pour mobile. En les agrandissant la qualité diminue, en les réduisant on télécharge des données inutiles.

      Répondre
    9. Jean-Michel DAIX

      merci ! Concernant la traduction, est-ce que le terme réactif exprime au mieux l’idée d’adaptation à l’écran de restitution ? Peut-on parler de conception d’interfaces Web adaptatives ? (Je n’ai pas trouver de meilleur traduction) D’autres idées ?

      Répondre

    Leave a Reply

    XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>