Résumé

Alors que le responsive design évolue, il devient crucial que nous voyions au-delà du mobile, de la tablette et de l’ordinateur de bureau pour résoudre les problèmes de design web. Lorsqu’ils sont bien conçus et planifiés, les design patterns – petits modules réutilisables – peuvent plus que jamais aider un site responsive à toucher plus d’appareils (et de personnes).

Au sommaire Du plus petit au plus grand * Navigation * L’interrupteur afficher/masquer * Le menu hors canvas * Menus à chargement conditionnel * Houston, nous avons un problème de hamburger * Le dilemme du tiroir * Modèles alternatifs * Images et vidéos * Vers des vidéos fluides * Travailler avec des arrière-plans flexibles * Redimensionnement responsable : srcset et sizes * Un contrôle plus fin : picture et source * Designers, recadrez-vous ! * Publicité responsive * Chargement conditionnel * Repenser la hiérarchie * Nous avons besoin de nouveaux modèles * Concevoir la grille infinie * Frameworks * Trouver les mots * Trouver les coutures * Façonner nos coutures : au-delà des classes * Les coutures intérieures *

Biographie auteur

Ethan Marcotte nous montre ici comment procéder, en mettant l’accent sur les systèmes de navigation responsive, le redimensionnement et l’adaptation d’images, la gestion de la publicité dans un contexte responsive et en énonçant des principes plus généraux afin de concevoir des présentations plus flexibles qui s’adaptent à tous les appareils.

www.editions-eyrolles.com

ÉDITIONS EYROLLES

61, bld Saint-Germain

75240 Paris Cedex 05

www.editions-eyrolles.com

Attention : pour lire les exemples de lignes de code, réduisez la police de votre support au maximum.

Attention : la version originale de cet ebook est en couleur, lire ce livre numérique sur un support de lecture noir et blanc peut en réduire la pertinence et la compréhension.

Traduction autorisée de l’ouvrage en langue anglaise intitulé Responsive design: patterns and principles d’Ethan Marcotte (ISBN : 978-1-9375573-4-8), publié par A Book Apart LLC

Adapté de l’anglais par Charles Robert

© 2015 Ethan Marcotte pour l’édition en langue anglaise

© Groupe Eyrolles, 2016, pour la présente édition, ISBN : 978-2-212-11766-0

Dans la même collection

HTML5 pour les web designers - n°1, 2e edition, Jeremy Keith et Rachel Andrew, 2016.

CSS3 pour les web designers - n°2, 2e edition, Dan Cederholm, 2016.

Stratégie de contenu web - n°3, Erin Kissane, 2011.

Responsive web design - n°4, Ethan Marcotte, 2011.

Design émotionnel - n°5, Aarron Walter, 2012.

Mobile first - n°6, Luke Wroblewski, 2012.

Métier web designer - n°7, Mike Monteiro, 2012.

Stratégie de contenu mobile - n°8, Karen McGrane, 2013.

La phase de recherche en web design - n°9, Erika Hall, 2015.

Sass pour les web designers - n°10, Dan Cederholm, 2015.

Typographie web - n°11, Jason Santa Maria, 2015.

Web designer cherche client idéal - n°12, Mike Monteiro, 2015.

Design web responsive et responsable - n°13, Scott Jehl, 2015.

Design tactile - n°14, Josh Clark, 2016.

Le code de la propriété intellectuelle du 1er juillet 1992 interdit en effet expressément la photocopie à usage collectif sans autorisation des ayants droit. Or, cette pratique s’est généralisée notamment dans les établissements d’enseignement, provoquant une baisse brutale des achats de livres, au point que la possibilité même pour les auteurs de créer des œuvres nouvelles et de les faire éditer correctement est aujourd’hui menacée. En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation de l’éditeur ou du Centre Français d’Exploitation du Droit de Copie, 20, rue des Grands Augustins, 75006 Paris.

TABLE DES MATIÈRES

Avant-propos

CHAPITRE 1

Du plus petit au plus grand

CHAPITRE 2

Navigation

CHAPITRE 3

Images et vidéos

CHAPITRE 4

Publicité responsive

CHAPITRE 5

Concevoir la grille infinie

Ressources

Remerciements

Références

Index

AVANT-PROPOS

ETHAN MARCOTTE N’A PAS INVENTÉ le responsive web design, mais il a fait quelque chose de plus important encore : il lui a donné un nom. En observant ce qui n’était à l’époque qu’un amas de tactiques balbutiantes, il a identifié une stratégie sous-jacente qui, une fois nommée, n’est pas seulement devenue une méthode de web design parmi d’autres, mais la méthode. Dans les années qui ont suivi, l’expression « responsive web design » est devenue l’une des rares entrées de notre jargon à être largement adoptée au-delà de la discipline, démontrant non seulement le bien-fondé de la méthode, mais également la clarté et le pouvoir de persuasion de l’expression. Dernièrement, je parlais à un menuisier lorsqu’il m’a confié – spontanément – qu’il voulait avant tout que son site web soit responsive.

Voilà le pouvoir d’un nom bien trouvé.

Marcotte reprend aujourd’hui la plume, mais cette fois-ci pour rayer un mot du lexique : la page est morte. Elle était en phase terminale depuis la mise en ligne du premier site web, bien sûr, mais elle a connu un long et lent déclin, marqué par de nombreux moments où elle a semblé reprendre du poil de la bête. Il y a seulement cinq ans, à l’époque de la première publication de Responsive web design, il était entendu que concevoir des « pages » web était le cœur du métier. Depuis lors, une transformation subtile mais bien réelle s’est opérée : nous avons abandonné les pages au profit de composants modulaires, laissant tomber cette métaphore poussiéreuse pour adopter un système d’organisation mieux adapté à l’univers mouvant des écrans. Cette transformation, comme d’autres avant elle, nécessite que nous fassions évoluer à la fois notre approche technique et notre modèle mental de la conception d’expériences sur le Web – c’est-à-dire à la fois le code et le langage que nous utilisons pour le décrire.

Marcotte peut vous aider sur les deux fronts. Comme Responsive web design, ce livre décrit un ensemble de stratégies techniques intelligentes et efficaces que vous pouvez appliquer dès maintenant (et vous y avez tout intérêt). Mais il suggère également un nouveau cadre conceptuel pour considérer le Web d’une façon plus modulaire et abandonner la page pour de bon. Avec ces millions d’appareils et de types d’écrans différents, il était grand temps.

Mandy Brown

Ce n’est pas de penser au futur qui me rend anxieux, mais de vouloir le contrôler.

HUGH PRATHER, Notes to Myself: My Struggle to Become a Person

JE VOUDRAIS VOUS MONTRER un arbre.

Cet arbre se trouve à Pando, dans la Fishlake National Forest, dans l’Utah, à l’ouest des États-Unis (FIG 1.1) (à deux ou trois kilomètres au sud de Fish Lake, si vous connaissez le coin). En parcourant Pando à la recherche de notre arbre, vous croiserez des centaines de trembles d’une beauté époustouflante, avec leur écorce blanche douce au toucher, leur cime arborée de feuilles dorées en automne, ou se parant d’un vert riche et profond pendant les mois d’été. Si magnifiques ces arbres soient-ils, il ne vous faudra sans doute qu’une heure ou deux à déambuler en vous demandant où se trouve donc cet arbre si spécial, et ce qui pourrait bien le distinguer des milliers d’autres arbres à Pando.

FIG 1.1 : Bienvenue à Pando, où nous cherchons un arbre très spécial. Photographie de J. Zapell (http://bkaprt.com/rdpp/01-01/)

Seulement voilà, je ne vous ai pas tout dit. Pando n’est pas une forêt : c’est un arbre. Pour être précis, c’est un peuplier faux-tremble.

Voyez-vous, en latin, pando signifie « je m’étends ». Scientifiquement, c’est ce que l’on appelle une « colonie clonale » : les « arbres » qui vous entourent ne sont que des branches, chacune émergeant d’un réseau de racines souterrain massif qu’elles ont toutes en commun. Au total, Pando pèse six millions de kilogrammes et recouvre plus de 40 hectares. Son âge est encore débattu – le National Park Service estime que Pando existe depuis plus de 80 000 ans (http://bkaprt.com/rdpp/01-02), tandis que certains scientifiques pensent qu’il approche du million d’années (http://bkaprt.com/rdpp/01-03/) –, mais quoi qu’il en soit, Pando est sans conteste l’organisme le plus grand, le plus lourd et le plus âgé sur Terre.

... je vous promets qu’il s’agit d’un livre sur le responsive design.

Ces dernières années, nous avons commencé à voir tous les arbres qui composent la forêt du web design. Avec l’explosion de l’informatique mobile, nous nous sommes rendu compte que notre vision du Web centrée sur les ordinateurs de bureau était beaucoup trop étriquée. Nos petits écrans sont venus nous rappeler que le Web était le premier support de design véritablement fluide : un support pouvant être digéré sur une infinité de combinaisons de navigateurs, de résolutions, de modes de saisie et de classes d’appareil. Le responsive design – une combinaison de grilles fluides, d’images flexibles et de media queries – peut nous aider à façonner un Web flexible, utile et esthétique.

Il y a quelque temps, Trent Walton, de Paravel, décrivait comment il s’était mis au responsive design : il avait fait la transition depuis l’époque où il jugeait les mises en page flexibles avec scepticisme, jusqu’à concevoir des sites responsive parmi les plus beaux du Web. Dans son essai, il évoque ainsi cette transition (http://bkaprt.com/rdpp/01-04/) :

J’ai troqué le contrôle que j’avais dans Photoshop contre une nouvelle sorte de contrôle, en utilisant des grilles flexibles, des images flexibles et des media queries pour construire non pas une page, mais un réseau de contenu qui peut être réorganisé en fonction de la taille de l’écran pour communiquer au mieux le message.

Vous remarquerez probablement que Trent dit « une nouvelle sorte de contrôle », et pas « moins de contrôle », ce que j’apprécie. Il suggère que la flexibilité inhérente au responsive design – ou disons-le carrément, la flexibilité inhérente au Web – n’exige pas de sacrifier le contrôle, l’esthétique ou la narration. Et ces quelques dernières années sont venues le démontrer : des organisations à but non lucratif aux éditeurs en passant par les grandes entreprises et les gouvernements, le Web a connu une explosion de sites responsive spectaculaires, accessibles à tous quelle que soit la taille de son écran (FIG 1.2-1.5).

Alors que le responsive design prolifère, l’idée de « réseaux de contenu » de Trent est plus pertinente que jamais. En fait, l’idée même de « page », ce mot merveilleux que nous avons emprunté au monde de l’imprimerie, est de moins en moins pertinente dans notre travail. J’irais jusqu’à dire que nous ne construisons plus de pages du tout – au de lieu de ça, nous devons penser nos designs responsive comme un réseau de petits systèmes de présentation (small layout systems) (FIG 1.6). De petites poches de design qui peuvent, comme le dit Trent, « être réorganisées en fonction de la taille de l’écran pour communiquer au mieux le message ».

FIG 1.2 : Le Field Museum (http://bkaprt.com/rdpp/01-05/) et la National Audubon Society (http://bkaprt.com/rdpp/01-06/) sont de superbes exemples de sites responsive à but non lucratif bien conçus.

FIG 1.3 : Le New York Times (http://bkaprt.com/rdpp/01-07/) et le Lapham’s Quarterly (http://bkaprt.com/rdpp/01-08/) font partie des nombreux éditeurs qui se sont mis au responsive design.

FIG 1.4 : Microsoft (http://bkaprt.com/rdpp/01-09/), Virgin America (http://bkaprt.com/rdpp/01-10/) et Adobe (http://bkaprt.com/rdpp/01-11/) sont quelques-unes des marques connues qui se sont lancées dans la course au responsive design.

FIG 1.5 : Des sites gouvernementaux comme AIDS.gov, GOV.UK (http://bkaprt.com/rdpp/01-12/) et US Digital Service (http://bkaprt.com/rdpp/01-13/) investissent énormément dans le responsive design.

FIG 1.6 : Au-delà de la page : nos interfaces se composent de minuscules composants, ou petits systèmes de présentation.

Voici un petit exemple : ouvrez « L’année en recherches 2014 » de Google (http://bkaprt.com/rdpp/01-14/) dans un navigateur redimensionnable (FIG 1.7).

Redimensionnez la fenêtre afin d’élargir le design, puis de le rétrécir, puis de l’agrandir à nouveau. En redimensionnant le navigateur, vous remarquerez que le design tout entier se réorganise, sa mise en page en grille fluide s’associant à des media queries pour répondre au format changeant du viewport. Le moins qu’on puisse dire, c’est que c’est un beau morceau de responsive design.

Après avoir redimensionné la fenêtre plusieurs fois, vous remarquerez que tout ne change pas en même temps : le design des articles principaux reste relativement le même, tandis que les articles secondaires basculent entre un affichage à une et à deux colonnes (FIG 1.8-1.9). La navigation au sommet de l’écran subit plusieurs changements, indépendamment du contenu placé en dessous (FIG 1.10). En d’autres termes, ce sont les différents composants du design qui changent individuellement, et pas seulement l’agencement général. Il en va de même pour la plupart des mises en page responsive : nos interfaces se composent de petits systèmes de présentation, chacun disposant de ses propres règles pour changer, évoluer et grandir en fonction des besoins de son contenu interne. Ces petits systèmes de présentation sont superficiellement liés aux éléments qui les entourent, mais chacun d’entre eux s’adapte indépendamment du reste du design.

FIG 1.7 : « L’année en recherches 2014 » de Google est un magnifique exemple de modules responsive autonomes qui s’adaptent selon leurs propres besoins.

Si vous avez lu Responsive web design, le propos vous semblera peut-être bien différent. Après tout, mon précédent livre traitait de la construction d’une page, pas des différents composants qui la composent (http://bkaprt.com/rdpp/01-15/ ou http://www.editions-eyrolles.com/Livre/9782212133318/responsive-web-design pour l’édition française). En seulement quelques chapitres, il expliquait comment traduire des designs fixés en pixels en mises en page fluides, comment redimensionner des images au sein de ces mises en page flexibles et enfin, comment utiliser des media queries pour transformer ces designs fluides et tentaculaires en mises en page responsive finies.

FIG 1.8 : Les articles principaux sur « L’année en recherches 2014 » de Google n’ont qu’un seul point de rupture.

FIG 1.9 : Les articles secondaires changent de mise en page selon le point de rupture.

FIG 1.10 : La navigation subit quelques changements mineurs mais visibles et sa densité visuelle augmente à mesure que le viewport s’élargit.

Mais de bien des façons, les modules qui composent nos pages responsive présentent plus de difficultés que les mises en page elles-mêmes. C’est bien beau de concevoir une grille responsive, mais comment être sûr que nos images soient aussi reconnaissables sur les petits écrans que sur les plus grands ? Comment pouvons-nous faire rentrer des menus de navigation denses et complexes dans des mises en page fluides ? Pouvons-nous incorporer de la publicité dans nos grilles responsive sans s’arracher les cheveux ?

Si les grilles flexibles et les media queries peuvent apporter une réponse à certaines de ces questions, elles ne sont qu’une partie de la solution. C’est pour cette raison que ce livre aborde les défis de ces petits systèmes de présentation, des modules et des éléments contenus au sein de la page. Dans chacun des chapitres qui suivent, nous examinerons un composant particulièrement problématique – en commençant par la navigation, puis en explorant les images et la vidéo, et enfin la publicité. Nous étudierons des approches de design courantes (et moins courantes) pour chacun de ces modules, ainsi que des stratégies permettant d’incorporer ces éléments dans vos propres designs responsive. Ce faisant, nous serons mieux à même de comprendre les défis qui nous attendent en adoptant une approche plus modulaire de la conception, mais également les bénéfices de cette approche.

De bien des façons, le design modulaire nous apporte, à nous et à nos projets, des avantages bien tangibles. Le développeur Scott Childs, décrivant comment il a, avec son équipe, transformé le design de Capital One en quatre semaines, avance que la clé était de se focaliser sur les composants, et non sur les pages (http://bkaprt.com/rdpp/01-16/) :

Bien qu’il s’agisse d’un nombre de pages énorme, quand vous avez 2 500 pages réparties sur 4 000 configurations différentes, on peut résumer le tout à bien peu de choses. Combien de composants différents avons-nous au total ? Environ vingt.

Cette approche de design axée sur les composants est née d’un besoin de modularité dans notre travail – particulièrement à mesure que l’étendue et la complexité de ce travail augmentent. Joe Stewart, un designer qui a collaboré à la refonte responsive du design de Virgin America, suggère que la modularité n’est qu’un avantage parmi d’autres (http://bkaprt.com/rdpp/01-17/) :

Nous avons construit un système de legos. Nous avons conçu différents types de boîtes et de modules qui pouvaient fonctionner dans différentes tailles. Ceux-ci pouvaient fonctionner sur une tablette comme sur un téléphone et à partir de là, le contenu pouvait varier. Il y a plusieurs avantages à procéder de la sorte :

1. Tout ce que vous créez sera automatiquement responsive. Si le contenu rentre dans l’un de ces modules, il sera responsive puisque le système de modules lui-même est responsive par nature.

2. Le deuxième avantage, c’est que Virgin America peut désormais créer n’importe quelle page à partir de ces legos. Ils peuvent choisir et mélanger ce dont ils ont besoin, de sorte à avoir deux gros modules, trois petits modules ou autre. Ils auront toujours accès à cette boîte à outils naturellement responsive pour développer leur site.

Cette tendance à construire des interfaces à partir de blocs plus petits s’est accompagnée, ces dernières années, d’un regain d’intérêt pour la création de bibliothèques de modèles ou de guides de style. J’utilise ces deux termes de façon interchangeable, car quel que soit celui que vous préférez, ils signifient la même chose : ce sont des inventaires de tous les « blocs » utilisés pour construire des interfaces plus complexes. Ces composants réutilisables – qu’il s’agisse de couleurs, de polices de caractères, d’éléments de formulaire ou d’une grille de mise en page – sont souvent regroupés sous l’appellation design patterns ou modèles de design, une allusion à leur nature modulaire et réutilisable. Starbucks a été l’une des premières grandes organisations à publier une bibliothèque de modèles publique pour son site responsive, et d’autres entreprises lui ont emboîté le pas dans les années qui ont suivi (FIG 1.11).

FIG 1.11 : D’Ushahidi (http://bkaprt.com/rdpp/01-18/) à MailChimp (http://bkaprt.com/rdpp/01-19/) en passant par Starbucks (http://bkaprt.com/rdpp/01-20/) ou A List Apart (http://bkaprt.com/rdpp/01-21/), des bibliothèques de modèles nous aident à gérer les composants de nos interfaces responsive.

Cette approche du design plus modulaire et axée sur des systèmes peut sembler être un changement radical, surtout comparée à nos vieux modèles de mise en page basés sur des pages, mais d’autres secteurs l’ont adoptée depuis des années. Comme le fait remarquer Federico Holgado, designer de MailChimp (http://bkaprt.com/rdpp/01-23/), des domaines aussi divers que l’architecture, l’automobile et la construction navale se sont depuis longtemps réorganisés pour devenir des assembleurs de composants finis : construire des machines plus grandes et plus complexes à partir de pièces plus petites et plus spécialisées (FIG 1.12). Pour nous autres qui travaillons sur le Web, le changement peut paraître brusque, mais il est aussi incroyablement utile : nous pouvons construire des interfaces responsive complexes axées sur le contenu et non sur les types d’appareils, préparant ainsi nos designs à s’adapter à un nombre croissant de contextes de navigation.

Et franchement, nous en avons bien besoin. Le Web a connu quelques années bizarres.

FIG 1.12 : Une petite section d’un énorme navire en construction. Photographie d’Adrian Jones (http://bkaprt.com/rdpp/01-22/)

Oui, je sais, j’aurais pu dire la même chose de n’importe quel moment de la courte histoire du Web. Après tout, la seule constante de ce drôle de support, c’est qu’il est en perpétuel changement. Mais pour ma part, j’ai l’impression que ces quelques dernières années ont été particulièrement folles en ce qui concerne la prolifération des appareils. Un petit rappel des faits :

• Le marché des mobiles est en pleine explosion : on estime le nombre total d’appareils dans le monde à 7,4 milliards (http://bkaprt.com/rdpp/01-24/). Les appareils mobiles sont rapidement devenus le principal mode d’accès au Web – et dans de nombreuses régions du monde, ils constituent le seul moyen d’y accéder. Si le boom des mobiles ne semble pas prêt de ralentir, il n’a pas, contrairement à ce que certains prédisaient, signé l’arrêt de mort de l’ordinateur de bureau. L’agence d’étude et d’analyse comScore a constaté que la croissance mobile « ne se faisait pas au détriment des ordinateurs de bureau. [Une grande partie de cette croissance] est due à des activités [...] qui viennent s’ajouter à ce qui se passe sur les plateformes existantes » (http://bkaprt.com/rdpp/01-25/).

• Les mobiles ne sont pas les seuls à avoir défié nos attentes. Depuis le lancement de l’iPad en 2010, nous avons vu le marché des tablettes exploser, les vendeurs de matériel se précipitant pour capitaliser sur la popularité massive de la tablette d’Apple. Lors du seul Consumer Electronics Show de 2011, plus de 80 nouveaux PC tablettes ont été présentés (http://bkaprt.com/rdpp/01-26/). Plus récemment, on a vu les premiers signes d’une perte de vitesse du marché des tablettes, les analystes mobiles (http://bkaprt.com/rdpp/01-27/) comme le PDG de Best Buy (http://bkaprt.com/rdpp/01-28/) suggérant que les ventes de tablettes commençaient à s’aplanir, voire à décliner.

• 2014 a été l’année où les Google Glass, l’ordinateur qui se porte sur le nez, ont fait un flop monumental (http://bkaprt.com/rdpp/01-29/). Quand bien même, tout le monde s’évertue à prédire quel sera le prochain grand développement post-informatique de bureau, des smart TV connectées à Internet aux montres intelligentes apparues plus récemment. Personnellement, je suis sceptique quant aux montres intelligentes en tant qu’environnement de navigation. Je suis sûr que personne ne voudra interagir avec de longs documents sur des écrans aussi minuscules et que ces petits appareils seront probablement plus utiles comme centres de notification, en les connectant à d’autres appareils situés à proximité. Mais quand je m’entends dire ces choses-là, je me reprends – parce que je disais la même chose au sujet des téléphones. J’étais persuadé que personne ne voudrait jamais surfer sur le Web sur un minuscule écran de mobile. Et nous connaissons déjà la suite. Et d’ailleurs, de nombreux sites utilisent déjà des navigateurs de « poignet » avec d’excellents résultats (FIG 1.13).

Clairement, il semble qu’à chaque fois que nous commençons à comprendre le Web, ne serait-ce qu’un tout petit peu, le terrain glisse complètement.

FIG 1.13 : Vous voulez consulter un site responsive sur une smartwatch Android ? Avec le navigateur Wear Internet, c’est possible (http://bkaprt.com/rdpp/01-30/). Image tirée d’une vidéo YouTube (http://bkaprt.com/rdpp/01-31/)

Enfin, il ne glisse pas autant qu’il explose. Chaque mois ou presque, des fabricants de logiciels et de matériel présentent de nouveaux modèles d’interaction que nous devons prendre en charge dans nos designs (FIG 1.14). De nouveaux appareils et contextes de navigation ne cessent de faire leur apparition et nous avons du mal à suivre la cadence (FIG 1.15). Et le réseau que nous utilisons pour parcourir le Web, publier notre travail et communiquer avec notre public est aujourd’hui utilisé par plus de personnes qu’à n’importe quel autre moment de sa courte histoire. Mais comme les connexions inférieures à la 3G composent encore l’écrasante majorité des forfaits de données mobiles, le réseau est également beaucoup plus lent, plus volatile et moins fiable que nous aimerions le penser (FIG 1.16). Comment le responsive design peut-il nous aider à rester dans le coup ? Ou plutôt : en tant que designers web, comment pouvons-nous rester dans le coup ?

FIG 1.14 : Windows 8.1 de Microsoft permet aux utilisateurs de diviser leur écran et de redimensionner les applications à l’envi (http://bkaprt.com/rdpp/01-32/).

FIG 1.15 : Dans une étude réalisée par Ofcom en 2009, 20 % des 16-24 ans au Royaume-Uni utilisaient une console de jeu pour consulter des sites web (http://bkaprt.com/rdpp/01-33/). Photographie d’Anna Debenham (http://bkaprt.com/rdpp/01-34/)

FIG 1.16 : Pas si rapide que ça : Ericsson estime que plus de 80 % des connexions de données dans le monde sont plus lentes que la 3G (http://bkaprt.com/rdpp/01-35/, PDF). Image tirée du rapport sur la mobilité d’Ericsson paru en novembre 2014 (http://bkaprt.com/rdpp/01-36).

Dans ce livre, nous allons essayer de répondre à ces questions. Chacun des chapitres suivants se focalisera sur un problème particulier que pose le responsive design – la navigation, les images et la vidéo, ainsi que la publicité, mais nous ne nous contenterons pas de disséquer des techniques de mise en page et des bouts de code. (Ne vous inquiétez pas, vous en aurez quand même pour votre argent.) En étudiant ces modèles, nous verrons pourquoi ils fonctionnent, quelles sont leurs forces et leurs faiblesses, et comment vous pouvez les améliorer. Dans le chapitre final, nous passerons en revue ce que nous avons appris et nous verrons comment combiner le tout pour créer des mises en page plus légères et flexibles – et peut-être devenir des designers plus flexibles nous-mêmes. Si nous faisons bien notre travail, nous pourrons enfin sortir du brouillard et avoir une vision plus claire du passé et du futur de notre métier.

Et maintenant, au boulot.

Je ne suis peut-être pas allé là où je voulais aller, mais je pense que je suis arrivé là où je devais être.

DOUGLAS ADAMS, Beau comme un aéroport

JE ME SUIS RÉCEMMENT INTÉRESSÉ à un homme, Pius « Mau » Piailug, qui, en 1976, a traversé l’océan Pacifique en canoë, parcourant près des 5 000 kilomètres qui séparent Hawaï et Tahiti. Piailug naviguait sans l’aide de cartes, d’outils de navigation informatisés ou de quelque équipement que ce soit ; au lieu de ça, il se laissait guider par les étoiles, le soleil et la lune. D’ailleurs, il n’a même pas emporté l’instrument qui lui aurait été le plus utile à bord : une boussole à étoiles, un cercle composé de coquillages, de corail et de cailloux placés autour d’un point central (FIG 2.1). Cet instrument d’apparence rudimentaire aidait les jeunes navigateurs de la tradition de Piailug à comprendre la relation entre l’horizon – le cercle extérieur de la boussole – et le canoë situé au centre. C’est la connaissance de cet instrument, couplée à des années de pratique en mer, qui a aidé Piailug à effectuer sa traversée, prouvant que la navigation traditionnelle avait toujours sa place dans le monde moderne.

FIG 2.1 : Mau Piailug utilisant une boussole à étoiles pour enseigner la navigation, comme il l’a appris dans sa jeunesse. Photographie de Monte Costa (http://bkaprt.com/rdpp/02-01/)

Je pense souvent au voyage de Piailug, et en particulier à sa boussole. Car si nous faisons bien notre boulot, la navigation d’un site web doit être une sorte de boussole : elle doit aider les nouveaux utilisateurs à s’orienter au sein de la hiérarchie du site et les guider vers leur destination. Mais avec toutes les sections et tous les types de menus que nos sites contiennent, il peut s’avérer extrêmement difficile de concevoir une navigation intuitive et ergonomique.

Et tous ces problèmes s’additionnent lorsque vous concevez un site responsive. Comment adapter un menu complexe aux plus petits écrans ? Que faire si nous souhaitons afficher plus (ou moins) d’informations en fonction des dimensions de l’écran ? Le plus important pour un système de navigation responsive n’est pas de fonctionner de la même façon sur tous les appareils, mais d’offrir l’accès au même contenu.

FIG 2.2 : La navigation responsive du site Happy Cog sur petit et grand écran (http://bkaprt.com/rdpp/02-02/)

Ces questions peuvent sembler intimidantes, mais elles démontrent pourquoi la navigation est un excellent exemple des petits systèmes de présentation que nous allons aborder dans ce livre. Le design responsive de la navigation d’un site représente un défi presque totalement différent de la grille principale d’une page. En affrontant ces problèmes de mise en page, d’interaction et de densité visuelle, nous sommes obligés de nous demander : comment concevoir une navigation utilisable et responsive ?

Par chance, beaucoup de gens se sont attelés à cette question et ont trouvé d’excellentes solutions. Dans ce chapitre, nous étudierons des modèles de design patterns et moins courants, et nous verrons comment surmonter les défis que pose la conception d’une navigation responsive.

L’INTERRUPTEUR AFFICHER/MASQUER

Ouvrez le site responsive de l’agence de design Happy Cog (FIG 2.2). Sur les écrans plus larges, toute la navigation est visible, mais sur les viewports plus petits, où l’espace est restreint, seul un lien « Menu » figure au sommet de la page. Si vous touchez, cliquez ou sélectionnez ce lien avec votre clavier, le menu complet s’affiche.

FIG 2.3 : L’en-tête responsive de responsivewebdesign.com. Un design clair avec un simple interrupteur permettant d’afficher (ou de masquer) la navigation.

Voilà l’un des moyens les plus courants de gérer un système de navigation complexe dans un design responsive : s’il n’y a pas assez de place pour le menu, on le cache. Ce modèle demande un minimum de deux éléments : la navigation, qui est masquée à certains points de rupture, et un élément déclencheur, avec lequel l’utilisateur interagit pour révéler la navigation. Nous avons utilisé cette même approche avec le menu de responsive webdesign.com (FIG 2.3). Le design est plutôt modeste, mais je vais brièvement détailler le code afin de démontrer comment ce modèle est souvent implémenté...

Tout d’abord, au sommet de la page, nous avons le balisage suivant :

<div class="head">

<h1 class="logo">

<a href="/"><img src="/images/logo-rwd.png"

alt="Responsive Web Design" /></a>

</h1>

<div id="nav" class="nav">

<nav>

<h1><a class="skip" href="#menu">Explore this

site:</a></h1>

<ul id="menu">

<li><a href="/workshop/">Workshop</a></li>

<li><a href="/events/">Public Events</a>

</li>

<li><a href="/podcast/">Podcast</a></li>

<li><a href="/newsletter/">Newsletter</a>

</li>

<li><a href="/about/">About</a></li>

</ul>

</nav>

</div><!-- /end .nav -->

</div>

<!-- [ Contenu principal de la page. ] -->

J’ai un peu simplifié les choses, mais c’est à peu près tout ce dont on a besoin : notre logo apparaît au sommet du document, s’ensuit un lien qui permet d’afficher la navigation, puis la navigation elle-même, balisée comme une liste non ordonnée. Mais ce code HTML n’est, comme vous l’avez sans doute deviné, que la base. Pour enrichir le menu, commençons par un simple test en JavaScript :

// Ce navigateur est-il assez moderne pour continuer ?

if ( !( "querySelector" in document

&& "addEventListener" in window

&& "getComputedStyle" in window) ) {

return;

}

window.document.documentElement.className +=

" enhanced";

FIG 2.4 : Pas de JavaScript ? Pas de problème : notre navigation est toujours accessible, même sur les navigateurs modernes qui ne peuvent pas charger notre code.

Nous demandons au navigateur de l’utilisateur s’il prend en charge les commandes DOM dont nous aurons besoin ailleurs dans notre JavaScript – des commandes telles que document.querySelector, window.addEventListener et window.getComputedStyle. Si ces commandes ne sont pas détectées, alors la fonction return; fait en sorte que le navigateur n’exécute pas le reste de notre JavaScript. Ainsi, les navigateurs plus anciens bénéficient d’une expérience parfaitement utilisable, sans l’aide toutefois du JavaScript (FIG 2.4). Et lorsque ces commandes sont présentes, notre JavaScript applique la classe enhanced à l’élément HTML (window.document.documentElement.className += " enhanced";).

Pourquoi effectuer ce test ? Celui-ci nous permet de construire notre navigation avec une pincée d’amélioration progressive : nous pouvons concevoir une expérience plus simple mais utilisable qui est universellement accessible par défaut, puis enrichir cette expérience uniquement pour les navigateurs et les appareils qui pourront véritablement en bénéficier. Si le test est réussi, la classe enhanced attribuée à l’élément HTML nous fait savoir qu’un navigateur donné peut recevoir l’expérience « améliorée ».

FIG 2.5 : Le site BBC News est accessible – et responsive – sur tous les appareils connectés à Internet, mais l’expérience est légèrement enrichie sur les navigateurs plus modernes. Photographie reproduite avec l’aimable autorisation de Responsive News (http://bkaprt.com/rdpp/02-04/)

C’est une approche plutôt courante pour les sites responsive, surtout à une certaine échelle. Par exemple, l’équipe de BBC News a construit son design responsive sur la base de l’amélioration progressive (FIG 2.5), en utilisant un petit test en JavaScript similaire à celui que nous avons utilisé ci-dessus, qui permet de déterminer si un navigateur est « à la hauteur » (http://bkaprt.com/rdpp/02-03/) :

Nous rendons [le paysage des navigateurs] gérable de la même [façon] que vous et tous les autres acteurs du secteur : en établissant un plus petit dénominateur commun servant de point de départ au développement. Nous avons donc décidé de scinder le marché des navigateurs en deux catégories, que nous appelons « navigateurs à fonctionnalités » (feature browsers) et « navigateurs intelligents » (smart browsers). [...] pendant que le site se charge, nous identifions les navigateurs « incapables » à l’aide du code susmentionné et nous en excluons les principaux éléments de l’interface utilisateur reposant sur le JavaScript, afin de leur offrir une expérience essentielle et concise.

Au lieu d’essayer de satisfaire une infinité de combinaisons de navigateurs et d’appareils, le design de la BBC présente deux niveaux d’expérience principaux : une expérience responsive de base, et une expérience légèrement plus avancée uniquement servie aux navigateurs capables de la prendre en charge.

À une échelle beaucoup plus petite, c’est exactement ce que nous faisons avec la navigation de responsivewebdesign.com. Une fois cette classe enhanced en place, nous pouvons rédiger des styles plus avancés destinés aux navigateurs qui passent notre test, et développer ainsi une navigation plus poussée :

.enhanced .nav .skip {

position: absolute;

right: 0;

top: 1.4em;

background: #363636;

border-radius: 50%;

width: 2.5em;

height: 2.5em;

}

.enhanced .nav ul {

max-height: 0;

overflow: hidden;

}

FIG 2.6 : Notre CSS nous permet d’afficher ou de masquer la navigation. Mais comment la rendre interactive ?

Si un navigateur passe notre test en JavaScript, cette règle utilisera la bonne vieille propriété position: absolute pour déplacer le saut de navigation – .nav .skip – placé avant notre navigation au sommet de la page. Simultanément, en appliquant les propriétés background: #363636 et border-radius: 50%, nous transformons ce lien en un gros bouton circulaire gris. Mais c’est à partir de la seconde règle que les choses deviennent intéressantes : celle-ci sélectionne la balise ul placée dans l’élément .nav – c’est-à-dire la liste non ordonnée qui contient nos liens de navigation – et utilise les propriétés overflow: hidden et max-height: 0 pour transformer la liste en une boîte de 0px de haut, masquant de fait nos liens. Du moins, jusqu’à ce que la classe .open soit appliquée à la liste :

.enhanced .nav ul.open {

max-height: 20em;

}

Avec ces règles, notre navigation peut prendre deux états : complètement masquée ou développée (FIG 2.6). C’est bien beau tout ça, mais vous vous demandez peut-être comment appliquer cette classe à notre ul. Eh bien, c’est là que JavaScript vient à la rescousse :

var nav = document.querySelector( ".nav ul" ),

navToggle = document.querySelector( ".nav .skip" );

if ( navToggle ) {

navToggle.addEventListener( "click",

function( e ) {

if ( nav.className == "open" ) {

nav.className = "";

} else {

nav.className = "open";

}

e.preventDefault();

}, false );

}

Si vous n’êtes pas trop branché JavaScript, ne vous inquiétez pas – le code est plus simple qu’il n’y paraît, je vous assure. Vous vous souvenez de notre saut de navigation à l’intérieur de notre élément .nav ? Nous utilisons une fonction JavaScript pour le chercher (document.querySelector( ".nav .skip" )), et si nous le trouvons, nous ajoutons quelques fonctionnalités lorsqu’il est cliqué ou touché sur un écran tactile (navToggle.addEventListener( "click", ... );). Lorsqu’un utilisateur touche ce lien ou clique dessus, notre code vérifie si notre liste non ordonnée comporte la classe open (if ( nav.className === "open" ) { ... }). Si la classe open est absente, le JavaScript l’ajoute pour révéler les liens ; si elle est présente, il la supprime et masque la navigation de la page.

Et si nous voulons apporter une touche de fantaisie – et nous voulons bien sûr de la fantaisie – nous pouvons ajouter une transition CSS sur la propriété max-height, afin que la liste se déroule et s’enroule de façon fluide (FIG 2.7) :

.enhanced .nav ul {

max-height: 0;

overflow: hidden;

transition: max-height 0.25s ease-out;

}

FIG 2.7 : Pourquoi ne pas inclure une petite transition avec la propriété max-height, me dites-vous ? Excellente idée !

Et nous en avons fini ! Avec un peu de JavaScript, nous pouvons afficher (ou masquer) un élément de notre design lorsque l’utilisateur clique dessus, simplement en ajoutant (ou en supprimant) une classe.

(Petite parenthèse : overflow a beau être une propriété CSS d’un grand âge, il convient de noter qu’un nombre effarant de navigateurs mobiles ne l’implémentent pas correctement. Si votre design utilise overflow: auto pour créer des zones scrollables, je vous conseille d’utiliser la bibliothèque Overthrow.js du Filament Group (http://bkaprt.com/rdpp/02-05/), qui détecte la prise en charge de la propriété overflow tout en écartant les navigateurs qui prétendent la supporter alors que ce n’est pas le cas.)

Si le bouton afficher/masquer fonctionne si bien, cela ne veut pas dire que l’effet sera nécessairement adapté à tous les points de rupture. Ce bouton n’est vraiment utile que sur les viewports de plus petite taille, où la mise en page est plus restreinte ; sur les viewports plus larges, nous pouvons afficher la navigation tout entière (FIG 2.8). Mais comme l’effet entier est produit par notre CSS, nous pouvons le supprimer au-delà d’un certain point de rupture à l’aide d’une media query :

@media screen and (min-width: 39em) {

.page .nav ul {

overflow: auto;

max-height: inherit;

}

}

FIG 2.8 : Sur les écrans plus grands, nous pouvons désactiver le bouton afficher/masquer et garder nos liens visibles.

Désormais, lorsque le viewport atteint une largeur minimale de 39em, nous désactivons la propriété overflow: hidden de la liste, et nous rétablissons la valeur par défaut de la propriété max-height. Ainsi, notre liste n’est plus masquée, ce qui nous permet de la styler comme un en-tête plus traditionnel.

... pfiou !

Vous pensez peut-être que cela représente beaucoup de travail, mais nous ne faisons qu’ajouter ou supprimer une classe avec un peu de JavaScript, et nous utilisons cette classe pour contrôler la visibilité de notre navigation. Et vraiment, c’est le mécanisme de base de tous les interrupteurs de ce type ou presque. Le site responsive de MSNBC.com fait exactement la même chose, d’ailleurs (FIG 2.9) : sur les grands écrans, vous pouvez toucher ou cliquer sur l’une des catégories principales pour afficher les menus secondaires ; mais sur les plus petits écrans, vous devez toucher une icône pour révéler la navigation entière, puis sélectionner une catégorie pour afficher les sous-menus.

FIG 2.9 : Sur le site responsive de MSNBC, un interrupteur placé au sommet de la page permet de révéler le menu sur les petits écrans. Par ailleurs, les utilisateurs peuvent ouvrir les menus imbriqués en touchant ou en cliquant sur les sections correspondantes.

LE MENU HORS CANVAS

Il existe une variante du bouton afficher/masquer que l’on appelle familièrement menu hors canvas. À l’origine, ce modèle était principalement utilisé dans les applications mobiles natives, mais il a récemment fait son apparition sur les sites web mobiles et responsive (http://bkaprt.com/rdpp/02-06/). Par exemple, le site Walmart.ca a adopté cette approche lors de la refonte responsive de son design (FIG 2.10). Sur les écrans plus larges, la navigation est visible à gauche. Mais sur les écrans plus petits, vous devez toucher ou cliquer sur l’icône Shop pour faire glisser la barre de navigation qui se cache au-delà du bord gauche de l’écran.

D’un point de vue mécanique, ce n’est pas si différent de notre fidèle bouton afficher/masquer : nous masquons là aussi notre navigation, puis nous demandons à nos utilisateurs d’interagir avec un élément pour l’afficher. S’il est bien exécuté, le menu hors canvas peut apporter une dimension supplémentaire à votre design. Il faut toutefois veiller à ce que le menu reste accessible, et pas seulement sur les navigateurs les plus récents (http://bkaprt.com/rdpp/02-07/).

FIG 2.10 : La navigation de Walmart.ca est masquée « hors canvas » sur les viewports plus étroits, mais est visible par défaut sur les grands écrans.

MENUS À CHARGEMENT CONDITIONNEL

FiveThirtyEight.com, site américain d’actualités et de divertissement, a lancé un nouveau design responsive en 2014 (FIG 2.11). Pour parcourir le site sur les plus petits écrans, l’équipe du site a opté pour un bouton afficher/masquer. Ce bouton est également présent sur les viewports plus larges, mais les liens vers les catégories d’articles principales – politique, économie, science, etc. – sont rendus visibles pas défaut. Mais ce n’est pas tout : sur les grands écrans, un clic sur les liens de l’en-tête révèle un menu déroulant qui détaille le contenu de chaque section du site (FIG 2.12).

FIG 2.11 : Le nouveau design responsive de FiveThirtyEight.com. Pour un site d’actualités, il est plutôt imposant et riche en analyses.

FIG 2.12 : La navigation responsive de FiveThirtyEight comprend un simple bouton afficher/masquer sur tous les écrans, les liens principaux étant déplacés vers l’en-tête sur les grands écrans.

Voici comme se présente un élément du menu de FiveThirtyEight :

<ul class="menu">

<li class="menu-item">

<a href="http://fivethirtyeight.com">Menu</a>

<div class="dropdown">

<!-- Contenu de la sous-navigation -->

</div>

</li>

<!-- Contenu de la sous-navigation -->

</ul>

Chaque lien de premier niveau est placé dans un élément de liste (li.menu-item), qui contient également un div avec la classe dropdown. Et ces div contiennent – vous l’aurez deviné – le menu déroulant qui apparaît sur les grands écrans. Le balisage est simple, c’est sûr, mais il constitue la base pour que le CSS affiche les menus déroulants sur grand écran :

li.menu-item {

position: relative;

}

.dropdown {

display: none;

position: absolute;

}

@media screen and (min-width: 768px) {

li.menu-item:hover .dropdown {

display: block;

}

}

Je simplifie un peu les styles de FiveThirtyEight, mais la mécanique sous-jacente est la même : sur les petits écrans, les blocs .dropdown sont masqués par défaut avec la propriété display: none, mais à l’aide d’une media query, les menus s’affichent sur les grands écrans lorsque quelqu’un survole l’élément li (li.menu-item:hover .dropdown).

L’approche employée par FiveThirtyEight est répandue, mais elle présente quelques inconvénients. Il est risqué de se reposer sur :hover, car le CSS suppose que tous les appareils à grand écran disposent d’une souris, alors qu’il existe plein d’appareils qui ne correspondent pas à cette définition, des tablettes aux ordinateurs portables tactiles. Mais plus généralement, il y a un inconvénient considérable à utiliser le CSS pour masquer des informations sur les petits écrans : notamment, le navigateur téléchargera tout l’HTML de l’élément, même s’il est masqué par le CSS. En d’autres termes, les utilisateurs de FiveThirtyEight.com – et d’autres sites qui utilisent le modèle display: none – qui disposent d’un petit écran devront télécharger des données supplémentaires qu’ils n’utiliseront pas. Et si vos lecteurs accèdent à votre site sur une connexion de données limitée, c’est une décision de design qui peut leur être coûteuse.

Une alternative plus responsable consisterait à utiliser le chargement conditionnel : à charger ce contenu supplémentaire sous certaines conditions, afin de s’assurer qu’il soit uniquement chargé sur les écrans qui s’en serviront. Lors du lancement du site responsive du Boston Globe, l’équipe de design et moi-même avons adopté un modèle similaire pour l’en-tête du site : sur les petits écrans, la navigation entière du site peut être affichée en cliquant sur un bouton (FIG 2.13). Mais à mesure que le design s’agrandit et que l’espace disponible augmente, nous en profitons pour promouvoir les gros titres de chaque section.

Ces panneaux ne sont pas visibles sur les petits écrans, mais surtout, leur balisage n’est pas inclus dans la page par défaut, puis masqué en CSS. Au lieu de cela, l’HTML excédentaire est chargé sous certaines conditions grâce à un petit script. Personnellement, j’aime beaucoup utiliser le modèle Ajax-Include du Filament Group (http://bkaprt.com/rdpp/02-08/) pour gérer le contenu à chargement conditionnel :

<ul>

<li data-append="/politics/latest-stories.html"

data-media="(min-width: 39em)">

<a href=”/politics/”>Politics</a>

</li>

</ul>

FIG 2.13 : Au lancement du site, la navigation responsive du Boston Globe était masquée derrière un bouton sur les petits écrans. Mais sur les grands écrans, la navigation était visible – et incluait des teasers pour les gros titres de chaque section.

Le modèle Ajax-Include fonctionne en appliquant à une partie de votre HTML un attribut HTML5 data- qui décrit l’emplacement où le contenu à chargement conditionnel doit être placé (data-before, data-after, data-append ou data-replace) ; si vous le souhaitez, vous pouvez également spécifier une media query (via l’attribut facultatif data-media) pour préciser que le contenu doit uniquement être chargé si certaines conditions sont remplies par le client. Dans le morceau de code ci-dessus, le modèle JavaScript Ajax-Include rapatrie le contenu de /politics/latest-stories.html, vraisemblablement un petit bout d’HTML, et l’annexe à notre élément de liste – mais uniquement si le viewport présente une largeur minimale de 39em.

Comme vous l’aurez deviné, le chargement conditionnel n’est pas seulement pratique pour la navigation – il peut également profiter à d’autres types de contenu. Une version précédente du site du Guardian, par exemple, comportait plusieurs types de contenu à chargement conditionnel. Visionnés sur un grand écran, certains des articles à la une s’accompagnaient d’une colonne d’articles apparentés. Mais lorsqu’on regardait ce même module sur un écran plus petit, seuls les gros titres étaient visibles. Et surtout, ces articles secondaires n’étaient pas masqués avec du CSS. Au lieu de forcer tous les appareils à télécharger tout le contenu au prix d’une perte de performances, le site chargeait les articles apparentés uniquement si le navigateur de l’utilisateur prenait en charge JavaScript et dépassait une certaine largeur (FIG 2.14). Autrement, le contenu le plus important – les gros titres – était visible de tous.

FIG 2.14 : Certains modules sur le site du Guardian utilisent le chargement conditionnel pour réduire la densité d’informations sur tous les écrans.

On notera bien que le chargement conditionnel ne consiste pas à offrir plus de contenu aux utilisateurs de « bureau », ou moins de contenu aux utilisateurs « mobiles ». Le chargement conditionnel permet plutôt de traiter la question de la densité dans votre design, afin de veiller à ce que vos lecteurs ne soient jamais saturés d’informations. Le Guardian et le Boston Globe ont identifié le contenu qui est important pour tous leurs utilisateurs, et se sont basés là-dessus pour créer les versions grand et petit écran de chaque module.

En clair, il ne s’agit pas de supprimer ni de masquer des informations sur les petits écrans. Essayez plutôt de penser votre contenu de la façon suivante :

1. Identifiez le contenu essentiel pour les petits écrans.

2. Considérez que ce contenu représente les informations qui seront accessibles à tous vos lecteurs, quelle que soit la taille de leur écran.

3. Si vous souhaitez inclure des informations supplémentaires sur les grands écrans, considérez qu’il s’agit d’une amélioration.

Cette mentalité « mobile first » ne changera pas nécessairement l’implémentation, mais elle influencera votre façon de planifier la conception de votre contenu à chargement conditionnel. Elle vous aidera à éviter le piège consistant à considérer que les petits écrans méritent « moins » de contenu – surtout à une époque où nos visiteurs utilisent de plus en plus (si ce n’est exclusivement) des appareils mobiles.

HOUSTON, NOUS AVONS UN PROBLÈME DE HAMBURGER

Comme vous l’avez vu jusqu’à présent, il n’existe pas de modèle idéal pour gérer la navigation. Et je ne prétends pas donner une liste exhaustive des modèles de navigation : du Filament Group (http://bkaprt.com/rdpp/02-09/) à Mozilla (http://bkaprt.com/rdpp/02-10/), beaucoup ont donné leur avis quant à l’approche à adopter pour construire des systèmes de navigation responsive qui s’adaptent à tous les appareils.

Si ces approches sont toutes différentes, il se trouve que bon nombre d’entre elles ont au moins un élément en commun (FIG 2.15) : une icône représentant trois barres horizontales empilées, communément désignée sous l’appellation (malheureuse ?) de « hamburger » : .

D’après Quora (http://bkaprt.com/rdpp/02-11/) et la BBC (http://bkaprt.com/rdpp/02-12/), notre petite icône de hamburger a fait sa première apparition numérique sur le Xerox Star, un petit poste de travail sorti en 1981 qui a établi beaucoup de normes de l’informatique personnelle moderne : une souris à plusieurs boutons, des interfaces graphiques avec un système de fenêtres, et autres (FIG 2.16).

FIG 2.15 : Je vous présente le « hamburger » : une icône couramment utilisée dans les systèmes de navigation responsive.

FIG 2.16 : Le hamburger a pris du galon ces derniers temps, mais il a fait sa première apparition sur les écrans au début des années 1980, au sein de l’interface graphique du Xerox Star (http://bkaprt.com/rdpp/02-11).

À l’époque, l’icône servait à ouvrir un menu contextuel. Mais plus récemment, elle est devenue le symbole de l’interrupteur qui permet d’afficher la navigation d’un site, particulièrement pour les plus petites résolutions. Et cette icône présente de véritables avantages : elle est extrêmement compacte et parfaitement lisible, même sur les plus petits écrans ; et de plus, elle est très facile à inclure dans vos designs, en utilisant SVG (http://bkaprt.com/rdpp/02-13/), une jolie animation CSS (http://bkaprt.com/rdpp/02-14/) ou une bonne vieille entité HTML (&#9776;).

FIG 2.17 : Le nouveau site responsive du Time, chic et flexible

Mais le hamburger a beau être omniprésent, je suis là pour suggérer qu’il pose peut-être quelques problèmes. Et que nous devrions nous y attaquer rapidement, de préférence avant d’avoir placardé cette icône sur tous nos sites responsive.

Commençons par le site web responsive du magazine Time (http://bkaprt.com/rdpp/02-15/). Lancé en 2014, sa mise en page est aussi flexible que son esthétique est audacieuse (FIG 2.17). Et si les pages du Time sont toujours riches en contenu, elles ne tombent jamais dans l’excès : la palette simple du design et la clarté de la hiérarchie permettent au lecteur d’identifier rapidement les articles qui l’intéressent le plus, quelle que soit la taille de son écran.

FIG 2.18 : Le menu au sommet de la page est chargé conditionnellement sur les viewports plus larges ; il est donc traité comme une amélioration pour les grands écrans.

FIG 2.19 : Le footer du Time : dense, peut-être, mais regorgeant de liens pertinents.

Un aspect du nouveau design que je trouve particulièrement impressionnant est le nombre d’éléments de navigation présents sur chaque page. (Je dois faire remarquer qu’on ne m’a jamais accusé d’être particulièrement « cool ».) D’après ce que je peux voir, on trouve sur la page d’accueil quatre éléments de navigation séparés :

1. Sur les viewports les plus larges, une barre de navigation apparaît tout au sommet de la page, permettant à l’utilisateur de se rendre sur d’autres sites du réseau Times Inc. (FIG 2.18).

2. Le pied de page contient une liste de liens vers les sections principales du site web (FIG 2.19).

FIG 2.20 : Le contenu moins important est placé dans un tiroir qui est affiché par défaut sur les grands écrans, mais masqué par défaut sur les petits écrans jusqu’à ce que l’utilisateur le touche ou clique dessus pour le révéler.

3. Le contenu secondaire apparaît sur le rebord gauche de la page. Sur la page d’accueil, par exemple, vous pouvez voir un flux d’articles récents, un compteur boursier et la barre de recherche du site. Mais il ne s’agit que de la vue pour grand écran de cette partie du design. Sur les plus petits écrans, on trouve un onglet marqué « TAP » qui permet à l’utilisateur d’ouvrir le contenu dans un panneau qui vient recouvrir la page. Lorsqu’il a fini, l’utilisateur peut toucher ou cliquer sur l’onglet pour le refermer (FIG 2.20).

4. La navigation principale est masquée jusqu’à ce qu’un utilisateur touche ou clique sur le hamburger. Sur les viewports plus petits, la navigation recouvre tout le design. Sur les écrans plus larges, l’encadré recouvre le bord gauche de la page (FIG 2.21).

Ça fait beaucoup de choses à première vue, mais je crois pourtant que le Time parvient à équilibrer parfaitement la densité. Les menus de navigation plus chargés sont masqués lorsque l’espace se fait rare, et à mesure que l’écran s’élargit, chaque menu s’affiche par défaut seulement si l’espace est suffisant. Mais il est intéressant de noter que le seul élément de navigation qui est toujours masqué est la navigation principale du site. Vous avez bien lu : elle est rangée bien au chaud derrière notre cher hamburger.

FIG 2.21 : La navigation principale du Time est le joyau du site, caché derrière une icône de hamburger.

En fait, lorsque le site responsive TIME.com a été mis en ligne, le hamburger était traité de façon assez novatrice : lorsque la page se chargeait pour la première fois, un encadré apparaissait à côté de l’icône, indiquant au lecteur qu’il pouvait s’en servir pour afficher la navigation du site. Par ailleurs, si l’utilisateur avait une souris, il pouvait également survoler l’icône pour afficher une bulle indiquant « Cliquer pour afficher la navigation du site » (FIG 2.22). En d’autres termes, l’icône avait trois sortes de légendes : la mention « Menu », l’encadré et la bulle d’information. Je ne dispose pas d’informations internes sur le processus de design, mais une telle quantité d’explications suggère deux motifs possibles : soit les parties prenantes étaient sceptiques quant à la capacité de l’icône à s’identifier clairement comme un élément de navigation essentiel, soit l’icône de hamburger n’avait pas eu beaucoup de succès lors des tests d’utilisabilité qui ont précédé le lancement.

FIG 2.22 : Le hamburger du Time, avec une bulle d’information qui flotte en dessous

Là encore, je spécule. Mais si le Time avait découvert des problèmes d’utilisabilité avec le hamburger, il n’aurait pas été le premier. Le designer James Foster a réalisé une étude d’utilisabilité complète sur la navigation responsive d’un grand site, et il a constaté que le mot « Menu » obtenait systématiquement de meilleurs scores que l’icône seule, avec un taux de conversion supérieur de 12,9 % (http://bkaprt.com/rdpp/02-16/). Son équipe a donc abandonné le hamburger au profit d’un bouton plus textuel pour leur navigation responsive. Cela ne concerne pas que les sites web, d’ailleurs. Les designers de l’application native de Beamly se sont aperçus qu’en laissant tomber les tiroirs escamotables au profit d’une navigation toujours visible, l’engagement et la satisfaction des utilisateurs s’en trouvaient considérablement améliorés (http://bkaprt.com/rdpp/02-17/).

Cela ne veut pas nécessairement dire que notre petite icône omniprésente n’a pas sa place. (J’imagine que ça ne doit pas trop mal marcher pour le Time.) D’ailleurs, l’équipe d’UX de Booking.com a récemment sondé ses utilisateurs et a constaté que le hamburger fonctionnait parfaitement pour son site et son public (http://bkaprt.com/rdpp/02-18/). Remplacer l’icône par le mot « Menu » n’avait aucune incidence sur le comportement des utilisateurs.

Certains sites disent que le hamburger ne leur convient pas, alors qu’il convient parfaitement à d’autres – alors, qui croire ? Vu ces résultats apparemment incompatibles, je crois que cela prouve que le hamburger, comme tous les design patterns, vaut le coup d’être testé sur votre site. En faisant part de son attrait pour le hamburger, Michel Ferreira, de Booking.com, résume cela ainsi :

Nous en avons tous une leçon à tirer sur la nature des tests A/B. Vous ne testez pas seulement un élément d’interface, un modèle ou une fonctionnalité. Vous les testez auprès d’une base d’utilisateurs très spécifique, dans un scénario très particulier. Ce qui fonctionne pour Booking.com pourra ne pas convenir à vous et vos utilisateurs. C’est pour cette raison que nous effectuons des tests A/B, parce que les résultats des autres... restent à prouver tant qu’ils n’ont pas été expérimentés auprès de nos clients, sur notre plateforme.

Je ne pourrais pas mieux dire. Le hamburger n’est pas foncièrement mauvais, mais il est problématique de penser que c’est une bonne icône par défaut pour tous les systèmes de navigation responsive. Après tout, ce qui fonctionne pour un site peut ne pas marcher sur le vôtre. Alors surtout, n’hésitez pas à utiliser le hamburger ! Mais n’oubliez pas de le goûter avant de le servir à vos convives.

LE DILEMME DU TIROIR

Oublions nos histoires d’icônes un instant. Car notre capacité à masquer la navigation présente un autre problème, potentiellement plus grave.

FIG 2.23 : Disney.com : un nouveau design responsive et joli comme tout.

Voyons plutôt le site responsive de Disney.com, lancé en 2012. En matière de design responsive, c’est plutôt joli : le site regorge d’images et de vidéos somptueuses, et offre du contenu des différentes entreprises de Disney. C’est un site responsive immersif et bien présenté, particulièrement pour une marque aussi connue (FIG 2.23). Et comme la plupart des sites responsive à l’époque, Disney a décidé de cacher sa navigation derrière un hamburger. Sur les viewports de petite taille et de taille intermédiaire, on peut toucher le hamburger pour afficher la navigation du site qui, si vous regardez bien, contient tous les liens de la création (FIG 2.24). En creusant un peu, je suis tombé sur une page Geocities que j’ai conçue en 1998.

FIG 2.24 : Le dévoilement progressif de la navigation de Disney, vu ici avec le hamburger.

... bon d’accord, je trolle. (Pardon Mickey.) Mais sachez que je trolle par amour. Car si la mise en page et l’esthétique de la navigation du site sont exécutées avec brio, son design illustre un problème lié à la dissimulation de la navigation : dès que l’on nous donne la possibilité de les cacher, nos menus peuvent rapidement se remplir d’une tonne de liens probablement inutiles. En discutant des problèmes de design courants dans les applications pour iOS, Mike Stern, un évangéliste de l’expérience utilisateur chez Apple, a abordé un certain nombre de problèmes que posent les tiroirs de navigation masqués (http://bkaprt.com/rdpp/02-19/). Si la plupart de ses critiques de design sont pertinentes pour les applications iOS, sa dernière constatation concerne tous les designers numériques, qu’ils conçoivent des applications ou des sites web :

Et enfin, l’inconvénient de pouvoir afficher beaucoup d’options, c’est que vous pouvez afficher beaucoup options. Et c’est certainement ce que vous ferez. Le potentiel d’abus est énorme... Vous voyez bien que les tiroirs de toutes sortes ont une fâcheuse tendance à se remplir de trucs inutiles.

Je suis tout à fait d’accord. Comme bon nombre de sites responsive qui réduisent leur navigation, le tiroir de navigation de Disney est visuellement agréable, mais souffre d’un trop-plein de contenu. C’est pour cela que les modèles de navigation à dévoilement conditionnel fonctionnent mieux lorsqu’ils sont combinés à une curation presque agressive du contenu qu’ils contiennent. Dans son essai original sur l’approche « mobile first », Luke Wroblewski note que commencer un projet de design par les plus petits écrans est une aubaine pour les produits – et pour leurs utilisateurs (http://bkaprt.com/rdpp/02-20/) (l’emphase est de mon fait) :

Les appareils mobiles exigent que les équipes de développement se focalisent strictement sur les données et les actions les plus importantes d’une application. Il n’y a tout simplement pas de place sur un écran de 320 par 480 pixels pour des éléments superflus. Vous devez établir des priorités. Ainsi, lorsqu’une équipe conçoit selon l’approche mobile first, le résultat final est une expérience axée sur les tâches principales que les utilisateurs veulent pouvoir accomplir sans les détours superflus et les débris d’interface qui parsèment les sites web de bureau aujourd’hui. C’est bon pour l’expérience utilisateur et c’est bon pour les affaires.

« Vous devez établir des priorités » : voici le point essentiel. Nous devons nous servir des petits écrans comme d’un objectif à travers lequel nous visualisons chaque aspect de nos designs, y compris notre navigation. Et au lieu de systématiquement réduire ou masquer tout ce qui ne « tient » pas sur la page, prenons le temps de nous demander s’il n’y a pas un problème d’ordre plus général : si nous masquons ou supprimons un élément parce qu’il n’a pas de valeur sur les petits écrans, pouvons-nous simplifier le design et le contenu de cet élément jusqu’à ce qu’il marche sur les petits écrans ? Ou alternativement, peut-être n’a-t-il aucune valeur sur aucun écran ?

Et vraiment, je pense que c’est la raison principale pour laquelle il est si difficile de travailler avec des systèmes de navigation responsive : ils sont souvent conçus suivant l’approche « desktop first », et nous nous retrouvons à devoir les faire « tenir » sur de plus petits écrans. Si nos utilisateurs ouvrent nos tiroirs de navigation et trouvent tous les trucs inutiles que nous n’avons pas pris la peine de trier, ce bouton afficher/masquer a-t-il encore une utilité ?

Soyons clairs : je pense qu’il est extrêmement utile de pouvoir masquer certaines parties d’un design de façon conditionnelle, surtout pour la navigation. En déplaçant les informations et les fonctionnalités superflues, on peut réduire la charge cognitive de nos utilisateurs et rendre nos sites plus abordables. Mais on a vite fait d’en abuser. Si nous concevons vraiment « mobile first », nous ne devrions pas avoir à utiliser de bouton afficher/masquer pour éviter toute discussion potentiellement difficile quant à la véritable valeur de notre contenu.

Après tout, si notre public est de plus en plus mobile, nous devrions arrêter d’essayer de faire rentrer des éléments complexes conçus pour les grands écrans sur de plus petits écrans – et nous devrions plutôt prendre en compte les besoins des petits écrans en premier.

MODÈLES ALTERNATIFS

Bien sûr, il y a de vrais avantages à employer des design patterns largement répandus. Si vos utilisateurs savent reconnaître un symbole comme le hamburger parce qu’ils l’ont vu ailleurs, cela peut rendre votre site plus accessible et votre navigation plus intuitive. Et nous ne devons pas prendre ça à la légère : la familiarité d’un élément peut être un puissant avantage, à la fois pour nos sites et notre public.

Cependant, nous ne devons pas non plus penser qu’un design pattern est utile parce qu’il est répandu. Après tout, il ne s’agit ni d’une règle, ni d’une norme. D’ailleurs, il existe des patterns de navigation alternatifs plutôt innovants, et nous allons en voir quelques uns.

Le dévoilement progressif

L’état de notre navigation responsive est souvent traité de façon binaire : soit elle est entièrement visible, soit elle est complètement cachée. Mais quelques sites remettent en question cette approche, et conçoivent des systèmes de navigation qui tirent le meilleur parti de l’espace disponible.

FIG 2.25 : Flexible, rapide et résilient : le site responsive de BBC News était à l’origine destiné aux seuls mobiles, puis il est devenu l’expérience par défaut pour tous les utilisateurs.

La BBC expérimente avec le design responsive depuis quelque temps déjà ; au départ, BBC News disposait d’un site mobile séparé, qui a été transformé en un site entièrement responsive. Le design responsive était initialement accessible au public mobile uniquement, mais il a fini par devenir l’expérience par défaut pour tous les utilisateurs – qu’ils se servent d’un mobile, d’une tablette, d’un ordinateur ou de n’importe quel autre appareil (http://bkaprt.com/rdp/02-21/ ; FIG 2.25).

Le site comporte deux niveaux de navigation : une navigation globale au sommet pour accéder aux autres sites du réseau BBC, et un menu en dessous pour les liens spécifiques à BBC News (FIG 2.26). On peut dire qu’aucun des deux menus n’est léger en contenu, mais au lieu de masquer la navigation, la BBC a adopté un modèle de dévoilement progressif. Sur les plus petits écrans, chaque menu contient un seul élément qui permet d’afficher des liens supplémentaires : le menu au sommet comporte un lien « More », tandis que la navigation de BBC News offre un lien « Sections » agrémenté d’un hamburger.

FIG 2.26 : Les deux niveaux de navigation sur le site BBC News, vus dans différents viewports

Mais à mesure que les menus de navigation s’élargissent, les choses deviennent intéressantes : au lieu de déplacer simplement le bouton déclencheur, chaque barre de navigation révèle progressivement les liens de son panneau masqué. Tous les éléments qui sont encore masqués sont accessibles en touchant ou en cliquant sur le lien « More » ou sur le bouton « Sections » – et à mesure que le design s’élargit, de plus en plus de liens sont progressivement révélés. Ainsi, le menu de navigation global peut afficher les liens « News » et « Sport » à un point de rupture plus petit, mais un viewport légèrement plus large pourra également comporter les liens « Weather », « Shop » et « Earth » (FIG 2.27).

FIG 2.27 : Comme pour la navigation globale, le menu du site BBC News révèle les liens progressivement – tout en veillant à ce que les liens masqués restent accessibles dans le menu déroulant « More ».

Vous aurez peut-être deviné qu’il s’agit d’une solution en JavaScript. Lorsque la page est chargée, redimensionnée ou réorientée dans un navigateur portable, la BBC mesure la largeur du viewport du navigateur, puis, en fonction de celle-ci, affiche ou masque certains liens dans chaque menu. Les panneaux qui se déroulent lorsque vous touchez ou cliquez sur « More » ou « Sections » sont également générés via JavaScript, puis remplis des liens qui se trouvent être masqués dans le menu parent pour ce point de rupture.

FIG 2.28 : Le Guardian a adopté une approche de dévoilement progressif différente pour sa barre de navigation.

Le Guardian emploie une approche similaire pour sa navigation. Son menu repose plus sur CSS que sur JavaScript, mais il adopte certains des principes qui consistent à dévoiler les liens progressivement. Dans un billet publié sur son blog dédié au développement, le chef de produit Chris Mulholland décrit le menu comme une solution hybride : elle combine le bouton afficher/masquer que l’on retrouve sur la plupart des sites responsive, tout en gardant les éléments clés visibles en toutes circonstances (http://bkaprt.com/rdpp/02-22/) :

Nous avons donné la priorité à la signalétique sur les plus petits écrans, mais le scrolling latéral vous permet d’accéder à n’importe quelle section sœur ou parente.

Si vous n’aimez pas scroller, le bouton All Sections sert de « filet de sécurité » et vous donne accès à tout le site, en commençant par la section dans laquelle vous vous trouvez.

Nous avons également essayé de faciliter la navigation à travers les sous-sections ; par exemple, dans la section Culture, vous voyez toujours la section suivante de la séquence. Les liens tournent en boucle, un peu comme un manège – facilitant ainsi la navigation entre les sections.

Plutôt que de simplement masquer toute la navigation, le Guardian a choisi de présenter les catégories principales dans un conteneur scrollable (FIG 2.28). Comme vous pouvez l’imaginer, ce bandeau scrollable est considérablement rétréci sur les viewports plus étroits, mais permet tout de même à l’utilisateur de le parcourir pour trouver les informations qui l’intéressent. Mais s’il ne trouve pas ce qu’il cherche, quelle que soit la taille de son viewport, il peut cliquer sur le lien « All Sections » qui révèle une structure de navigation complexe à plusieurs niveaux pour parcourir le site tout entier (FIG 2.29).

FIG 2.29 : Sur les viewports de toutes tailles, la navigation du Guardian comporte un bouton qui permet d’afficher la carte complexe de la structure du site.

En règle générale, la structure de la navigation ne change pas beaucoup à mesure que le design se transforme. Vous pouvez visualiser le site sur le plus petit des smartphones ou sur le plus grand des écrans plats, et vous aurez toujours ce même bandeau scrollable, avec le menu déroulant à droite. Au vu des autres modèles de navigation que nous avons abordés dans ce chapitre, celui du Guardian est presque révolutionnaire de cohérence.

Devenir plus responsive

Outre les détails techniques, ce que j’aime particulièrement avec la navigation du Guardian, c’est son processus de développement. Si on lit la présentation de la navigation par Chris Mulholland, il attribue la conception du menu à trois facteurs : une analyse approfondie des objectifs de design, une itération rapide d’un certain nombre de solutions potentielles, et surtout une implication précoce des utilisateurs dans le processus de design (http://bkaprt.com/rdpp/02-22/) :

Nous pouvons toujours essayer de deviner ce que veulent nos lecteurs, mais il n’y a rien de mieux que de leur présenter des prototypes dès que possible. Sur le site du Guardian, nous avons invité les visiteurs quotidiens à rejoindre un panel d’utilisateurs pour nous aider à créer le nouveau site web et donner leur feedback. Envoyer des prototypes basse définition à ce panel d’utilisateurs nous a été vraiment bénéfique... [Ensuite,] nous avons développé un prototype qui marchait avec du contenu et était complètement réaliste... Les tests utilisateur ont produit des résultats surprenants et nous ont emmenés sur une autre voie, mais pour finir, nous avions l’assurance que les utilisateurs ordinaires et les nouveaux utilisateurs pouvaient accéder aux sections les plus apparentes comme aux plus cachées.

En décrivant son travail sur le design du nouveau site responsive de Virgin America, Joe Stewart, partenaire de l’agence de design Work & Co, s’exprime de façon similaire – à savoir que le prototypage n’influence pas seulement le processus de design, il est le processus de design. Par ailleurs, le client n’a jamais vu de maquette statique d’une page web (http://bkaprt.com/rdpp/02-23/) :

En clair, le prototypage est notre outil principal. Notre philosophie pour aborder un projet comme [Virgin America], c’est de développer un prototype aussi vite que possible. Nous n’avons jamais donné de présentation, mais nous avons travaillé sans relâche sur des protypes. Même la toute première fois que nous avons rencontré Dean et l’équipe de Virgin America, nous leur avons montré un prototype responsive.

Ces dernières années, la question « faut-il commencer à concevoir dans le navigateur », directement en HTML et en CSS, a fait l’objet de vives discussions ; il ne s’agit pas de créer des prototypes de mise en page, mais de commencer véritablement notre travail créatif directement dans le navigateur. Et il y a de vrais avantages à cela : le navigateur est, après tout, une toile complètement flexible, et aucune application de design de bureau existant actuellement ne peut battre son adaptabilité intrinsèque.

Je suis d’accord sur ce principe, jusqu’à un certain point. Je pense que l’approche doit avant tout convenir au designer. Si vous êtes plus à l’aise en pensant en HTML et en CSS, super ! Mais si vous travaillez plus rapidement dans une application de design traditionnelle, rien ne vous oblige à abandonner une application testée et éprouvée pour un éditeur de code. Il est plus important de reconnaître que chaque outil présente des forces et des faiblesses, et que vous avez intérêt à emprunter la voie la plus rapide. Voilà ce que Joe Stewart a déclaré lors de l’interview sur Virgin America :

J’utilise toujours Photoshop parce que c’est l’outil avec lequel je suis le plus rapide. Je sais que beaucoup de gens sont passés à des outils comme Sketch, qui a l’air super, mais pour moi, ce n’est pas le plus rapide. Mon partenaire de design, Felipe, utilise Illustrator pour tout, parce que c’est l’outil le plus rapide pour lui. Selon moi, peu importe comment vous arrivez au résultat final. Si vous obtenez quelque chose à mettre entre les mains de quelqu’un pour recevoir du feedback, vous avez atteint votre objectif. La méthode employée importe peu.

On parle peut-être beaucoup de la conception dans le navigateur, mais nous ne sommes pas prêts de voir les maquettes disparaître comme outils de design. Comme le montre la refonte de Virgin America, les applications comme Photoshop et Sketch sont toujours indispensables pour dessiner, réfléchir à une mise en page, la peaufiner et parler esthétique. En revanche, je crois que les maquettes perdent leur statut de point final, c’est-à-dire de document de design destiné au client ou de livrable définitif. Les agences numériques et les équipes de design utilisent toujours des maquettes réalisées sous Photoshop ou Illustrator pour discuter de l’esthétique ou des options de composition – mais notre métier manque encore d’un outil de design qui reflète l’instabilité des réseaux pour lesquels nous concevons, les divers modes d’interaction disponibles sur les appareils de nos utilisateurs, et la flexibilité de la toile.

Personnellement, je partage l’avis de mon collègue Dan Mall : il ne s’agit pas tant de concevoir dans le navigateur que de prendre des décisions dans le navigateur (http://bkaprt.com/rdpp/02-24/). Si vous avez l’habitude de dessiner dans Illustrator ou de prototyper des interactions dans Keynote, continuez comme ça. Mais comme le dit Mulholland, l’essentiel est de faire rapidement parvenir vos designs sur les appareils et les navigateurs que vous, vos clients et vos utilisateurs pourrez tenir entre vos mains et avec lesquels vous pourrez interagir :

Nous pouvons toujours essayer de deviner ce que veulent nos lecteurs, mais il n’y a rien de mieux que de leur présenter des prototypes dès que possible.

Rien n’est plus vrai. Dans la mesure du possible, nous devrions toujours donner la priorité aux prototypes plutôt qu’aux documents Photoshop. Aussi utiles les maquettes puissent-elles être – et elles le sont – il n’y a rien de tel que d’essayer des prototypes en « direct » dans autant de navigateurs et d’appareils que possible. Vous pourrez ainsi vérifier vos hypothèses de design et vous assurer que vous êtes sur la bonne voie.

Adapter la mise en page

Même avec les meilleures intentions, les meilleurs plans et les meilleurs processus, nos hypothèses de design ne se vérifient pas toujours. Dans ce cas, nous devons souvent revoir une partie de notre travail – et cela s’applique tout particulièrement aux systèmes de navigation responsive. L’équipe du Guardian a fini par adopter son approche actuelle après un nombre d’itérations considérable. (Et je suis sûr qu’ils n’en ont pas fini.) Le prestataire de messagerie électronique MailChimp a constaté que la navigation responsive de son application web, qui comporte une barre d’outils fixe, avait tendance à masquer d’autres éléments de l’interface (http://bkaprt.com/rdpp/02-25/). En simplifiant la mise en page, ils ont non seulement réglé ce problème, mais aussi considérablement amélioré l’utilisabilité du menu (FIG 2.30).

FIG 2.30 : Navigation de l’application MailChimp, avant et après sa simplification (http://bkaprt.com/rdpp/02-25/)

Plus important encore, le travail de MailChimp suggère une alternative aux modèles de navigation que nous avons étudiés jusqu’à présent : plutôt que d’adopter une approche complexe, nous devrions peut-être chercher des occasions d’en faire moins. Il ne faut peut-être pas systématiquement masquer la navigation si un simple changement de mise en page peut s’avérer efficace.

Le site responsive du Filament Group fait cela de façon admirable. Sur la page d’accueil, la navigation est toujours visible. Sur les grands écrans, elle occupe le sommet de la page, mais sur les viewports plus petits, les liens du menu sont empilés directement sous le logo et le slogan de l’entreprise (FIG 2.31). Les options de navigation étant réduites, cela semble être un choix naturel : les liens constituent une signalétique précieuse, donc ils sont traités comme des citoyens de première catégorie.

Vous remarquerez que ce format ne concerne que la page d’accueil. Sur les pages internes, le Filament Group a adopté un bouton afficher/masquer sur les petits écrans, leur permettant ainsi de conserver l’espace dont ils ont grandement besoin (FIG 2.32). Là encore, je pense que c’est un choix qui se défend : comme le contenu doit occuper une place centrale sur les pages internes, il paraît judicieux de déplacer la navigation derrière un élément escamotable. Mais surtout, cela démontre élégamment que les modèles de navigation ne doivent pas nécessairement être appliqués uniformément sur un site web. Nous pouvons déterminer de façon plus sélective et nuancée comment, où et pourquoi nous utilisons ces modèles dans notre travail.

FIG 2.31 : La navigation du Filament Group n’est pas seulement attrayante – elle est toujours visible sur la page d’accueil (http://bkaprt.com/rdpp/02-26/).

FIG 2.32 : Afin de donner la priorité au contenu sur les petits écrans, le site du Filament Group utilise un menu déroulant pour masquer la navigation dans ses pages internes.

FIG 2.33 : Le magnifique site responsive de Frank Chimero, avec une navigation qui ne se cache jamais (http://bkaprt.com/rdpp/02-27/)

Le design responsive de Frank Chimero est l’un de mes favoris – non, mais vraiment, regardez-le – et j’apprécie particulièrement qu’il ait adopté une approche tout aussi réservée pour sa navigation (FIG 2.33). Que votre écran soit gigantesque ou minuscule, la navigation est toujours visible. Par ailleurs, Frank a passé un temps considérable à s’assurer que la navigation ne soit pas simplement bien placée, mais qu’elle se sente chez elle.

Par rapport à la moyenne des menus, la navigation de ces deux sites est plutôt légère – il n’y a qu’une poignée de liens, vraiment. Mais c’est peut-être là qu’ils gagnent en flexibilité. Une liste de liens plus complète pourrait demander d’avoir la main plus lourde, voire d’adopter un design pattern complexe – qui sait, peut-être un hamburger ! (Glups.) Mais je pense que la touche plus légère qu’ils ont adoptée n’est pas le fruit d’un design intelligent, mais plutôt d’un contenu distillé et focalisé.

Cela ne veut pas dire qu’un système de navigation responsive ne peut pas être élégant et complexe, comme l’ont démontré la BBC et le Guardian. Mais avec tous les défis que nous rencontrons sur le Web, nous avons tout intérêt à simplifier nos interfaces dès que l’occasion se présente. Nos utilisateurs nous en remercieront.

Tant de films réalisés aujourd’hui ne sont que des photographies de gens qui parlent.

ALFRED HITCHCOCK (http://bkaprt.com/rdpp/03-01/)

BEAUCOUP D’ENCRE A COULÉ sur la meilleure façon de produire des images aussi flexibles que nos mises en page. En fait, cela ne demande qu’une seule ligne de CSS :

img {

max-width: 100%;

}

Découverte par le designer Richard Rutter, cette simple règle indique que nos images peuvent être rendues dans n’importe quelle taille, du moment que leur largeur n’excède jamais la largeur de leur conteneur. En d’autres termes, la propriété max-width de chaque image est désormais fixée à 100 % de la largeur de son conteneur (http://bkaprt.com/rdpp/03-02/). Si ce conteneur est réduit au-delà de la largeur de l’image qu’il contient, notre brave petite img se redimensionnera proportionnellement pour ne pas sortir de sa colonne flexible.

FIG 3.1 : Image principale d’un article sur le site BBC News. À mesure que la largeur de l’article change, la propriété max-width: 100% de l’image lui permet de se redimensionner proportionnellement (http://bkaprt.com/rdpp/03-03/).

Avec les grilles fluides et les media queries, les images fluides sont l’un des trois tenants d’une mise en page responsive. Et par conséquent, elles sont quasi-omniprésentes – ouvrez n’importe quel site responsive comme celui de BBC News, et vous y trouverez des images qui s’agrandissent et se rétrécissent avec leur conteneur (FIG 3.1).

Selon moi, il vaut mieux considérer que max-width: 100% n’est qu’une partie de l’équation : il y a aussi des problèmes de performances, de transmission et de design qui se posent, et nous les aborderons tous dans ce chapitre. En d’autres termes, créer des images fluides n’est que la première étape vers la création d’images plus responsive. Mais avant d’abandonner complètement la mise en page, il convient de mentionner que les images ne sont pas les seules à se disputer notre attention ; après tout, nos designs doivent incorporer d’autres sortes de médias, comme la vidéo. Alors, prenons un instant pour rendre nos vidéos aussi flexibles que nos images, et continuons sur cette lancée.

FIG 3.2 : Sur le Web, rien n’est jamais simple : la propriété max-width: 100% ne marche pas tout à fait avec nos vidéos intégrées (http://bkaprt.com/rdpp/03-04/).

VERS DES VIDÉOS FLUIDES

Après plusieurs années à utiliser des images flexibles, la propriété max-width: 100% peut sembler être une solution naturelle pour des vidéos fluides. Malheureusement, ce n’est pas tout à fait aussi simple que ça :

img,

object,

video {

max-width: 100%;

}

Nous avons légèrement élargi notre CSS en incluant les éléments object et video dans notre règle flexible. À première vue, cela semble marcher, mais ça ne marche pas vraiment. Si l’on applique cette règle à toutes les vidéos de notre mise en page responsive, la largeur de ces vidéos variera en même temps que notre grille fluide, mais leur hauteur restera inchangée (FIG 3.2). Pour comprendre pourquoi, observons le balisage de notre film :

<video src="video-main.mp4" height="547"

width="972"></video>

(Petite remarque : certains services tiers vous demanderont parfois d’utiliser un élément object ou iframe pour intégrer leur vidéo. La technique suivante fonctionne aussi avec ces éléments, mais nous nous limiterons à video pour cette démonstration.)

Le balisage semble plutôt clair : l’attribut src de notre élément video renvoie vers un fichier vidéo (video-main.mp4), tandis que les attributs width et height déterminent les dimensions de rendu de notre film. Mais avec les vidéos, ces deux derniers attributs ne sont pas facultatifs – car contrairement aux images, les vidéos et autres objets intégrés n’ont pas de dimensions intrinsèques, et nous devons donc préciser celles-ci dans notre HTML. Et si nous pouvons nous servir de max-width: 100% pour remplacer la largeur de la vidéo, nous ne pouvons pas faire la même chose avec height : par exemple, si nous utilisons height: auto, nos vidéos se verront appliquer une hauteur de zéro et seront invisibles. Et bon sang, Internet a besoin de voir ses vidéos de chats.

Mais par chance, il existe tout un tas de méthodes pour faire en sorte que nos vidéos se redimensionnent correctement, et la plupart nécessitent un peu de JavaScript. Par exemple, regardez le site responsive de Made By Hand, une série de courts-métrages magnifique qui met en scène des individus particulièrement touchants (FIG 3.3). (Responsive ou pas, cette série est émouvante et visuellement saisissante. Je vous la conseille fortement.) Comme le site est responsive, vous pouvez lire les vidéos directement dans votre navigateur, quelle que soit la taille de votre écran. Pour ce faire, les concepteurs du site ont ajouté une pincée de JavaScript afin de mesurer la vidéo lorsque la page se charge pour la première fois, puis d’enregistrer ces dimensions pour les réutiliser plus tard. Ensuite, quand la page est redimensionnée – ou que l’appareil change d’orientation – la vidéo est redimensionnée proportionnellement, à l’aide de calculs basés sur ces mesures initiales.

FIG 3.3 : Made By Hand, un design responsive exquis pour une série de courts-métrages émouvants (http://bkaprt.com/rdpp/03-05/)

FIG 3.4 Il est possible d’utiliser JavaScript pour préserver les proportions d’une vidéo, mais ce n’est pas aussi fluide qu’une approche qui emploie uniquement CSS – notre script saccade légèrement lorsque notre page est redimensionnée.

Beaucoup de sites responsive ont adopté des stratégies similaires à base de JavaScript. Malheureusement, si vous redimensionnez votre navigateur pendant que vous lisez une vidéo sur l’un de ces sites, vous remarquerez peut-être de légères saccades visuelles. Lorsque vous redimensionnez la page, la vidéo saute une fraction de seconde avant de reprendre (FIG 3.4). C’est partiellement un problème de performances : en liant JavaScript à l’événement resize, on risque de ralentir le navigateur, voire de le faire planter. Mais cela souligne également le problème de l’utilisation de JavaScript pour les parties critiques de nos mises en page. Une proportion non négligeable d’utilisateurs mobiles dispose de navigateurs qui offrent une prise en charge limitée voire nulle de JavaScript – et sur un réseau cellulaire instable, rien ne garantit que notre JavaScript pourra même parvenir à nos utilisateurs.

FIG 3.5 : Admirez cette vidéo, parfaitement intégrée dans son écosystème naturel. (J’ai l’impression de commenter un documentaire animalier.)

Par chance, ce problème de fluidité des vidéos a été résolu. Et en prime, la solution ne demande pas un poil de JavaScript. Voyez-vous, en 2009, Thierry Koblentz a écrit un article démontrant comment créer des vidéos qui se redimensionnent proportionnellement dans une mise en page flexible (http://bkaprt.com/rdpp/03-06/). Et son approche est pour le moins ingénieuse.

Arrêtons-nous un instant pour observer une vidéo sur un site web. Cela pourrait être n’importe quel site web, mais la page d’accueil de la série Made By Hand fera très bien l’affaire (FIG 3.5). Si nous visualisons cette page sur un viewport de 1024px de largeur, par exemple, les dimensions de la vidéo seront 972x547 – c’est-à-dire 972px de large et 547px de haut.

FIG 3.6 : Le ratio d’aspect des images et des vidéos décrit le rapport entre la largeur et la hauteur de l’élément.

Mais au-delà des pixels, nous voulons simplement préserver la relation entre deux caractéristiques de notre vidéo – en l’occurrence, sa largeur et sa hauteur. Et il se trouve que ces deux mesures ont un lien fondamental : le ratio d’aspect, mesuré d’un coin à l’autre de la vidéo (FIG 3.6). Nous pouvons calculer ce ratio d’aspect à l’aide d’une simple formule :

hauteur / largeur = ratio d’aspect

Avec les dimensions de notre vidéo de 972x547, on obtient le calcul suivant :

547 / 972 = 0,562757202

En divisant la hauteur de notre vidéo (547px) par sa largeur (972px), il nous reste un ratio d’aspect de 56,2757202%. Par conséquent, la hauteur de la vidéo doit mesurer environ 56 % de sa largeur.

Nous reviendrons à ce pourcentage dans un moment, alors mettez-le bien au chaud dans la poche de votre pantalon en attendant. (Ou de votre bermuda, si c’est votre vêtement métaphorique de prédilection. Je ne juge pas.) Maintenant que nous avons évacué les mathématiques, revenons à l’élément video de notre HTML :

<video src="video-main.mp4" height="547"

width="972"></video>

Jusque là, rien de bien compliqué, alors apportons deux petits ajustements à notre balisage :

<div class="player">

<video src="video-main.mp4" height="168"

width="300"></video>

</div>

Pas grand-chose n’a changé, mais nous avons considérablement réduit la vidéo en réglant ses attributs width et height afin qu’elle soit adaptée par défaut aux petits écrans. (Autant éviter de balancer une vidéo énorme sur un écran de smartphone.) Ce qui est plus important, c’est que nous avons ajouté une balise : en l’occurrence, nous avons enveloppé notre élément video dans un autre élément. Nous avons choisi un div portant la classe player, mais vous pouvez choisir le conteneur que vous voulez.

Mais une fois combiné au ratio d’aspect que nous avons mesuré précédemment, ce modeste conteneur devient la clé de notre vidéo responsive. Commençons par appliquer quelques styles au div extérieur :

.player {

padding-top: 56.2757202%;

}

OK, peut-être pas « quelques styles », mais plutôt un style : avec une simple règle, nous avons ajouté un attribut padding-top correspondant au ratio d’aspect que nous avons calculé précédemment. Mais pourquoi, me demandez-vous ? Eh bien, selon la spécification CSS, les pourcentages de padding-top et de padding-bottom sont relatifs à la largeur du bloc conteneur, pas à sa hauteur (http://bkaprt.com/rdpp/03-07/). Ainsi, cette marge verticale sera toujours égale à 56,2757202% de la largeur de la boîte.

FIG 3.7 : En appliquant le ratio d’aspect à notre conteneur à l’aide d’un attribut padding-top basé sur des pourcentages, nous avons créé une « boîte fantôme » vide.

Prenons un rapide exemple : je me suis plongé dans l’inspecteur de mon navigateur et j’ai supprimé la vidéo de la page d’accueil de Made By Hand. J’ai également désactivé le code JavaScript qui redimensionne la vidéo, puis j’ai ajouté cet attribut padding-top à son conteneur. Et pour finir, comme je suis un web designer très professionnel, j’ai ajouté une couleur d’arrière-plan pas du tout criarde (FIG 3.7). Mais à mesure qu’on redimensionne le design, l’attribut padding-top change également : il correspond toujours à environ 56 % de la largeur du conteneur. En d’autres termes, notre conteneur div peut être complètement vide, mais il a un ratio d’aspect intrinsèque. Quelle que soit la largeur de ce bloc, sa hauteur correspondra toujours à 56,2757202% de sa largeur. La zone vide créée par notre padding-top est conforme au ratio d’aspect (FIG 3.8).

Plutôt cool, non ? Enfin moi, je trouve ça cool. (Je crois que je viens de comprendre pourquoi on ne m’invitait jamais aux soirées.) Mais ce n’est que la base de notre vidéo flexible. Une fois mis en place cet attribut padding-top basé sur un pourcentage, nous pouvons revenir à notre CSS et ajouter quelques styles de plus :

.player {

position: relative;

padding-top: 56.2757202%;

}

.player video {

position: absolute;

left: 0;

top: 0;

height: 100%;

width: 100%;

}

FIG 3.8 : À mesure qu’on redimensionne cette boîte affublée de l’attribut padding-top, elle conserve la forme et les proportions dont notre vidéo a besoin, sans contenir le moindre contenu.

Pour commencer, nous avons ajouté position: relative au conteneur .player. Cela permet de créer ce que l’on appelle un contexte de positionnement : tout élément positionné de façon absolue dans le contexte de ce conteneur sera maintenant positionné relativement à .player, plutôt qu’au viewport. Et c’est ce qui permet à la seconde règle de fonctionner : nous positionnons la balise video dans le coin supérieur gauche de .player. Immédiatement après, nous fixons les attributs width et height de la vidéo à 100%, afin qu’elle occupe tout son conteneur.

FIG 3.9 : Avec un peu de maths et quelques balises supplémentaires, notre vidéo se redimensionne correctement, le tout sans une ligne de JavaScript.

En revenant dans notre navigateur et en rétablissant la vidéo, nous pouvons observer l’effet final en action (FIG 3.9). Souvenez-vous que ce conteneur possède un ratio d’aspect intrinsèque : grâce à la propriété padding-top basée sur un pourcentage, la hauteur de notre boîte .player se redimensionnera proportionnellement, quelle que soit sa largeur. Une fois ces règles en place, nous avons pris notre vidéo et – à l’aide du positionnement absolu – nous l’avons étirée pour couvrir l’intégralité de notre conteneur. Et l’effet est beaucoup plus fluide que si nous avions utilisé JavaScript. Avec seulement quelques bases de maths et un conteneur supplémentaire, nous avons des vidéos fluides qui se redimensionnent de façon complètement transparente au sein d’un design responsive.

TRAVAILLER AVEC DES ARRIÈRE-PLANS FLEXIBLES

La règle max-width: 100% est géniale, ça ne fait aucun doute – mais seulement pour les images de premier plan. Pour les images d’arrière-plan flexibles, nous avons un certain nombre de propriétés CSS utiles – et notamment background-size.

Généralement, lorsque nous appliquons des images d’arrière-plan à un élément, nous demandons au navigateur de rendre cette image dans sa résolution native. Voici une règle back-ground plutôt basique :

.intro {

background: url("bg-demo.jpg") no-repeat;

}

Le navigateur appliquera l’image bg-demo.jpg à notre bloc .intro, et rendra cette image dans ses dimensions natives. Et le résultat sera le même que l’image mesure quatre mille pixels ou quatorze – si l’image s’avère être plus large ou plus haute que le bloc conteneur, les pixels en trop ne seront pas affichés.

Cependant, nous pouvons éviter ce comportement à l’aide de la propriété background-size, qui nous permet de spécifier les dimensions que nous souhaitons appliquer à notre image. Nous pouvons également spécifier la longueur afin de nous assurer que notre image s’affiche en 250x400 :

.intro {

background: url("bg-demo.jpg") no-repeat;

background-size: 250px 400px;

}

De plus, si l’on donne la valeur auto à l’une des dimensions, l’image se redimensionnera proportionnellement à une largeur ou à une hauteur spécifique. Par exemple, une propriété background-size de 250px auto fixera la largeur de notre image à 250px sans modifier le ratio d’aspect :

.intro {

background: url("bg-demo.jpg") no-repeat;

background-size: 250px auto;

}

On peut même définir notre background-size en pourcentages, afin de redimensionner l’image en fonction des dimensions de son conteneur. Ainsi, s’il faut que la largeur et la hauteur de notre image soient égales à 50 % des dimensions de notre bloc .intro, notre règle ressemblera à ça :

.intro {

background: url("bg-demo.jpg") no-repeat;

background-size: 50% 50%;

}

La propriété background-size est certes intéressante, mais sachez que les versions plus anciennes d’Internet Explorer (versions 8 et inférieures) ne la prennent pas en charge. Si vous souhaitez une méthode de secours pour ces vieux navigateurs, je peux vous suggérer une variante de la technique de commentaires conditionnels de Paul Irish (http://bkaprt.com/rdpp/03-08/). Vous pouvez voir cette méthode à l’œuvre dans le code HTML de http://responsivewebdesign.com/ :

<!DOCTYPE html>

<!--[if IE]><![endif]-->

<!--[if lt IE 9]> <html class="oldie ie">

<![endif]-->

<!--[if IE 9]> <html class="ie ie9">

<![endif]-->

<!--[if gt IE 9]> <html class="ie"><![endif]-->

<!--[if !IE]><!--> <html> <!—<![endif]-->

Une fois ces commentaires conditionnels en place, les anciennes versions d’IE se verront appliquer la classe oldie dans leur balise <html> d’ouverture. Ainsi, je peux appliquer un style de secours acceptable en démarrant un second sélecteur avec .oldie :

.intro {

background: url("bg-demo.jpg") no-repeat;

background-size: 50% 50%;

}

.oldie .intro {

background-image: url("bg-demo-noresize.jpg");

}

Une fois notre solution de secours établie, intéressons-nous à deux mots-clés extrêmement utiles que nous pouvons appliquer à la propriété background-size : cover et contain. Commençons par cover :

.intro {

background: url("bg-demo.jpg") no-repeat;

background-size: cover;

}

FIG 3.10 : En utilisant background-size: cover, la photo de la page d’accueil responsive de Virb se redimensionne proportionnellement pour recouvrir entièrement son conteneur.

Le navigateur évaluera la largeur et la hauteur de l’image d’arrière-plan, et trouvera la plus petite des deux valeurs. Ensuite, il redimensionnera l’image proportionnellement, afin de faire en sorte que la dimension la plus petite – qu’il s’agisse de la largeur ou de la hauteur – recouvre son conteneur. Vous pouvez voir cette technique à l’œuvre sur la page d’accueil responsive de Virb (http://bkaprt.com/rdpp/03-09/). Les dimensions natives de l’image principale sont de 1600x600. Comme la hauteur (600 pixels) est inférieure à la largeur (1 600 pixels), l’image est étirée verticalement sur la hauteur de son conteneur (FIG 3.10). Quelle que soit la taille de cette boîte, l’arrière-plan sera redimensionné proportionnellement pour la recouvrir parfaitement.

La règle background-size: contain permet également de redimensionner l’arrière-plan, mais le résultat est très différent :

.intro {

background: url("bg-demo.jpg") no-repeat;

background-size: contain;

}

FIG 3.11 : Vous souhaitez que votre image d’arrière-plan soit complètement visible et flexible ? La règle background-size: contain est là pour ça.

FIG 3.12 : La page d’accueil responsive de Vox est une magnifique combinaison d’images d’arrière-plan et de texte superbement composé (http://bkaprt.com/rdpp/03-10/).

Alors que la règle background-size: cover risque parfois masquer une partie de l’image, background-size: contain s’assure que l’arrière-plan entier soit toujours visible au sein de son conteneur (FIG 3.11).

Combinée à background-position, la propriété background-size permet de créer des traitements d’image vraiment époustouflants. La page d’accueil de Vox.com combine parfaitement ces deux propriétés (FIG 3.12). Chaque bloc présente les articles à la une et les titres accompagnés d’une image d’arrière-plan :

FIG 3.13 : En appliquant la règle background-size: cover à des images d’arrière-plan centrées, Vox.com peut présenter son contenu accompagné d’images plutôt évocatrices – et complètement flexibles.

.content {

background: url("beyonce_grammy.jpg") no-repeat;

background-size: cover;

background-position: center, center;

height: 600px;

}

Plutôt que d’ancrer ses images dans le coin supérieur gauche de chaque bloc, Vox utilise la règle background-position: center, center pour les centrer au sein de leur conteneur (FIG 3.13). Et une fois ce positionnement établi, background-size: cover permet de s’assurer que chaque bloc est couvert par un arrière-plan flexible parfaitement centré.

En théorie, Vox pourrait utiliser des media queries pour charger différentes images selon la taille du viewport, par exemple en chargeant des images recadrées convenant mieux aux grands écrans lorsque le viewport s’agrandit :

.content {

background: url("beyonce_grammy.jpg") no-repeat;

background-size: cover;

background-position: center, center;

height: 600px;

}

@media screen and (min-width: 39em) {

.content {

background-image:

url("beyonce_grammy-medium.jpg");

}

}

@media screen and (min-width: 60em) {

.content {

background-image:

url("beyonce_grammy-wide.jpg");

background-position: 0 0;

}

}

Vous l’aurez compris, les possibilités sont infinies.

REDIMENSIONNEMENT RESPONSABLE : SRCSET ET SIZES

Il y a de véritables inconvénients à simplement redimensionner ou recadrer des images avec un peu de CSS. Mais heureusement, quelques outils peuvent nous venir en aide. Voyons ce qu’il en est.

Pour commencer, le redimensionnement des images en CSS a tendance à alourdir nos pages web. À la mi-2015, le poids moyen d’une page web était de 2,1 Mo (http://bkaprt.com/rdpp/03-11/), contre un misérable 320 Ko en 2010 (http://bkaprt.com/rdpp/03-12/). Et qui est le coupable ? Je vous le donne en mille : les images. Nos chers JPG, PNG et GIF représente plus de 60 % de cette empreinte de 2,1 Mo – plus de 1,2 Mo par page en moyenne.

Cette évolution est essentiellement due à l’avènement des écrans haute densité. En 2012, le développeur web Jason Grigsby s’est aperçu que la page d’accueil d’Apple.com avait fait un bond de 500 Ko à plus de 2 Mo, simplement en augmentant la résolution des images pour qu’elles soient plus nettes sur les écrans haute densité (http://bkaprt.com/rdpp/03-13/). Et Apple n’est pas le seul – à mesure que nos écrans ont gagné en définition, nos images ont pris du poids, et nos pages s’en sont trouvées alourdies.

Au vu de cette augmentation constante de la taille de nos pages, nous devrions faire attention à la quantité de données que nous demandons à nos utilisateurs de télécharger, plutôt que d’essayer de faire tenir des images énormes sur de tout petits écrans. Pour être très clair, « petit écran » ne signifie pas nécessairement « connexion lente ». Loin de là. En fait, il n’y a aucune corrélation entre la largeur d’un écran et la bande passante disponible. Mon ordinateur portable pourrait être connecté à l’aide de la connexion 3G de mon téléphone, d’une connexion Ethernet stable ou du réseau Wi-Fi calamiteux d’un hôtel ; de même, mon téléphone pourrait tout aussi bien être connecté à un réseau Wi-Fi stable et rapide qu’à un signal cellulaire intermittent. À l’heure actuelle, il n’existe aucun moyen de détecter la quantité de bande passante disponible sur les appareils de nos utilisateurs.

À leur décharge, les fabricants de navigateurs et de matériel informatique travaillent sur plusieurs moyens de détecter la vitesse de connexion d’un utilisateur, comme l’API Network Information (http://bkaprt.com/rdpp/03-14), mais aucune solution standard n’a encore été établie. À court terme, cette incertitude a peut-être du bon, car elle nous incitera à réduire la quantité de données que nous servons à nos utilisateurs, quelle que soit la taille de leur écran. Jake Archibald, « développeur évangéliste » pour Google Chrome, suggère que les réseaux les plus lents devraient être notre véritable priorité (http://bkaprt.com/rdpp/03-15/) :

Il est important de se focaliser sur les temps de chargement en 3G, car même si nous avons la 4G aujourd’hui, nos utilisateurs utilisent encore très souvent la 3G (ou pire) : un quart du temps aux États-Unis, la moitié du temps dans une grande partie de l’Europe.

Les avantages commerciaux de pages plus légères sont légion. GQ (http://bkaprt.com/rdpp/03-16/) a récemment constaté que son nouveau design responsive était beaucoup trop lent – mais qu’en réduisant le temps de chargement des pages de 80 %, son nombre de visiteurs uniques bondissait de 80 % (http://bkaprt.com/rdpp/03-17/). Si nous partons du principe que tous nos utilisateurs disposent de peu de bande passante, nous devons alléger nos sites et créer des interfaces qui sont rapides pour tout le monde – que ce soit sur un mobile, un ordinateur de bureau, ou un appareil entièrement différent.

Et cela nous ramène aux images flexibles. Ces images massives peuvent être redimensionnées pour tenir sur les petits écrans, mais même si ces appareils minuscules sont reliés à une connexion rapide, ils téléchargeront un gros paquet de pixels qu’ils n’utiliseront pas. C’est un excédent invisible que nous devons nous efforcer de réduire dans la mesure du possible. Par chance, des outils ont été créés par le Responsive Issues Community Group (http://bkaprt.com/rdpp/03-18/) pour nous aider à résoudre ce problème. Ce groupe a collaboré avec les constructeurs de navigateurs pour produire quelques ajouts à la spécification HTML, notamment certains attributs destinés à rendre nos images un peu plus intelligentes.

Pour commencer, intéressons-nous à l’humble élément img :

<img src="img/main.jpg" alt="Un chien à l’air sympa"

/>

Rien de bien sorcier jusque là. Notre élément img comporte un attribut src qui désigne l’URL d’un fichier image (img/main.jpg), accompagné d’un texte alternatif (alt) accessible qui décrit le contenu de notre image ("Un chien à l’air sympa"). Et si nous avons bien fait notre travail, l’image main.jpg devrait s’afficher dans notre navigateur. Mais il y a un hic : ce fichier image va être transmis à chaque navigateur et appareil qui accède à notre page, quelle que soit la vitesse du réseau, la densité de l’écran ou la taille du viewport.

Pour que notre image soit redimensionnée de façon plus efficace, nous allons ajouter l’un de ces nouveaux outils conçus pour les images responsive, j’ai nommé l’attribut srcset.

<img srcset="img/main-200.jpg 2x, img/main-300.jpg

3x" src="img/main.jpg" alt="Un chien qui a l’air

sympa" />

... OK, attendez une seconde. On dirait qu’un script Perl a vomi son déjeuner sur notre élément img immaculé. Quel est donc ce charabia qui s’est insinué dans notre attribut srcset ? Des virgules ? 2x ? 3x ? Qu’est-ce qui se passe ici ?!

Heureusement, ce n’est pas si terrible que ça en a l’air. Pour déchiffrer notre attribut srcset, rendons-le plus lisible :

<img srcset="img/retina.jpg 2x,

img/retinarok.jpg 3x"

src="img/normal.jpg" alt="Un chien qui a l’air sympa"

/>

Voilà qui est un peu mieux. Nous avons en fait créé trois différentes versions de notre image, toutes identiques, mais avec différentes densités de pixels : leurs dimensions apparentes sont les mêmes, mais elles sont adaptées à des écrans de différentes résolutions. Et à l’intérieur de notre srcset, nous incluons simplement le chemin de chaque image, puis nous décrivons sa densité de pixels idéale – 2x, 3x, etc.

Une fois ces images et leur résolution précisées, notre balise img ne charge plus une seule image pour tous les écrans : notre attribut srcset est rempli d’options d’images à charger selon ce qui convient le mieux à l’utilisateur. Armé de ces informations, le navigateur peut sélectionner l’image la plus adaptée à la densité de l’affichage. Cela nous évite de surcharger les écrans basse résolution avec des images complexes, et permet d’économiser un peu de bande passante au passage.

Plutôt chouette, non ? Malheureusement, ces descripteurs x sont conçus pour les images à largeur fixe, un concept complètement has-been. Mais tout n’est pas perdu : nous pouvons utiliser srcset pour choisir les images en fonction de la largeur disponible dans la mise en page. Voyons un autre élément img :

<img srcset="img/main-large.jpg 1440w,

img/main-medium.jpg 720w, img/main-small.jpg 360w"

src="img/main-medium.jpg" alt="Un chien qui a l’air

sympa " />

Je sais, là encore, c’est un peu terrifiant. Désolé ! Quand vous serez redescendu du lampadaire, vous pourrez ajouter quelques sauts de ligne bien placés pour produire un code plus avenant :

<img srcset="img/main-large.jpg 1440w,

img/main-medium.jpg 720w,

img/main-small.jpg 360w"

src="img/main-small.jpg" alt="Un chien qui a l’air

sympa" />

Comme précédemment, nous avons créé trois versions différentes de notre image – mais cette fois, elles sont toutes identiques à l’exception de leur échelle : seule leur taille varie (FIG 3.14). Là aussi, srcset spécifie le chemin de chaque image, avec des virgules comme séparateurs. Mais cette fois-ci, au lieu d’utiliser des modificateurs comme 2x ou 3x pour décrire la densité de l’image, on décrit la largeur de chaque image en pixels, suivie d’un w. Comme l’image main-large.jpg fait 1440px de large, l’attribut 1440w permet de dire au navigateur quelle est sa largeur native. Il en va de même pour l’image main-medium.jpg de 720px de large et pour main-small.jpg, de 360px de large – chaque image est décrite comme ayant une largeur de 720w et de 360w, respectivement.

(Petite parenthèse : les lecteurs avisés auront remarqué que dans chaque petit bout de code, nos éléments img comportent toujours un attribut src. À proprement parler, src est requis par la spécification sur les images responsive – vos images doivent comporter un attribut src, même si vous utilisez srcset (http://bkaprt.com/rdpp/03-19/). Cela peut sembler redondant, mais c’est essentiel pour la rétrocompatibilité. Si un navigateur ne comprend pas srcset, il pourra tout de même télécharger une image.)

FIG 3.14 : Nos trois nouvelles images, toutes identiques à l’exception de leurs dimensions : l’image d’origine a simplement été réduite.

Après avoir spécifié trois largeurs différentes pour l’image principale, vous vous demanderez peut-être comment faire pour que le navigateur choisisse la bonne. Et c’est une question parfaitement légitime ! Mais seulement voilà : il n’y a rien à faire. Si vous lisez la spécification, rien n’indique aux navigateurs comment choisir la meilleure option dans srcset (http://bkaprt.com/rdpp/03-20/). C’est au navigateur de choisir la meilleure image – pas à nous.

... je sais, ça n’a pas l’air terrible dit comme ça. Vous commencez peut-être à paniquer légèrement. Ou un peu plus que légèrement. Après tout, c’est vous le designer ! Ça devrait être à vous d’avoir le dernier mot en ce qui concerne les images que vos utilisateurs verront, pas vrai ?

Mais sérieusement : ne paniquez pas. Ce manque de contrôle est une bonne chose. Songez que ces images ne sont pas seulement choisies en fonction de celles qui « collent » à notre mise en page : une image de srcset pourrait être sélectionnée parce qu’elle convient à la vitesse du réseau de l’utilisateur, à la résolution de son écran, etc. D’innombrables facteurs peuvent déterminer quelle image convient le mieux. Et si nous avons certains outils pour images responsive qui nous offrent un plus grand degré de contrôle, il vaut mieux laisser au navigateur le soin de déterminer quelle est la meilleure résolution pour notre image. Notre balisage s’en trouvera allégé, et nos utilisateurs seront satisfaits.

On ne peut pas choisir la meilleure option dans l’attribut srcset, mais on peut aider le navigateur à faire un choix plus intelligent. Pour cela, nous ajouterons un attribut sizes :

<img srcset="img/main-large.jpg 1440w,

img/main-medium.jpg 720w,

img/main-small.jpg 360w"

sizes="(min-width: 50em) 250px,

(min-width: 35em) 33vw,

100vw"

src="img/main-medium.jpg" alt="Un chien qui a l’air

sympa" />

Là encore, je vois bien que (min-width: 50em) 250px, (min-width: 35em) 33vw, 100vw ressemble à du pur baragouin de robot. Mais comme avec srcset, on crée une liste d’éléments dans notre navigateur séparés par des virgules. En clair, chaque entrée de notre liste décrit la largeur physique de notre image à différents points de notre design responsive – c’est-à-dire la place qu’elle occupera dans la mise en page.

Essayons ensemble de déchiffrer notre attribut sizes :

1. (min-width: 50em) 250px ressemble beaucoup à une media query, n’est-ce pas ? Eh bien, c’est essentiellement ce qu’elle est : nous indiquons au navigateur que si le viewport présente une largeur minimale de 50em, l’image fera 250px de large.

2. (min-width: 35em) 33vw fonctionne grosso modo de la même façon : si le viewport présente une largeur minimale de 35em, l’image fera 33vw de large. Mais qu’est-ce qu’un vw, me demandez-vous ? Eh bien, le vw est une unité de longueur en CSS qui équivaut à 1 % de la largeur du viewport. Ainsi, 33vw est une autre façon de dire que l’image occupera 33 % de la largeur du viewport.

3. 100vw est la valeur par défaut de l’attribut sizes. Cette valeur signifie que l’image occupera toute la largeur du viewport. Ainsi, si la condition de notre première entrée dans l’attribut sizes n’est pas satisfaite – c’est-à-dire si la largeur du viewport est inférieure à notre seuil de min-width: 40em, alors notre image sera redimensionnée à 100 % de la largeur du viewport.

Les dimensions listées dans notre attribut sizes ne doivent pas nécessairement correspondre à la taille de l’image pour chaque point de rupture. Nous essayons de définir une approximation de la largeur de l’image à mesure que la mise en page change. Une fois équipé de ces informations sur la présentation d’une image, le navigateur peut chercher une image intelligemment à partir de notre liste srcset et choisir la meilleure option à charger.

(Petite astuce : si vous êtes un fan d’HTML valide, l’attribut sizes est requis par la spécification. En d’autres termes, si vous utilisez l’attribut srcset, il doit s’accompagner de l’attribut sizes correspondant. À l’heure où j’écris ces lignes, srcset marchera tout de même sans l’attribut sizes, mais votre balisage sera considéré non valide. Alors soyez prudent.)

Une remarque sur la compatibilité, avant de poursuivre.

• Un certain nombre de navigateurs mobiles sont compatibles avec les attributs srcset et sizes. Sur iOS comme sur Mac OS X, Safari supporte partiellement ces deux attributs. Il prend en charge le changement de résolution avec le descripteur x, mais pas le descripteur w. Les navigateurs récents par défaut pour Android – Chrome et le navigateur Android par défaut – prennent intégralement en charge ces attributs.

Cependant, il n’y a pas que des bonnes nouvelles : ni le navigateur par défaut d’Android (jusqu’à Android 4.4.4 au moins), ni Opera Mini (jusqu’à la version 8, au moins) ne prennent en charge srcset ou sizes. Et d’ailleurs, ils ne prennent en charge aucune autre partie de la spécification sur les images responsive – et c’est dommage pour nous, car ces deux navigateurs sont immensément populaires.

• Sur une note plus positive, la plupart des navigateurs de bureau modernes prennent plutôt bien en charge les attributs srcset et sizes. Chrome, par exemple, supporte ces attributs depuis la version 38, tandis qu’Opera les supporte depuis la version 26. À l’heure actuelle, Firefox est toujours en train de finaliser l’implémentation de srcset et de sizes, mais vous permet d’activer les attributs si vous fouillez un peu dans les préférences pour développeur. Et alors qu’Internet Explorer n’a pas encore livré une version compatible, il travaille activement à prendre en charge les nouveaux attributs (http://bkaprt.com/rdpp/03-21/).

Globalement, la prise en charge des images responsive est impressionnante, mais n’en est qu’à ses balbutiements – un nombre important de navigateurs ne prennent pas encore en charge srcset ou sizes de façon native. Cependant, vous pouvez utiliser une bibliothèque JavaScript comme Picturefill (http://bkaprt.com/rdpp/03-22/) pour apporter la prise en charge des images responsive dans les navigateurs plus anciens. Téléchargez simplement Picturefill dans vos projets et incluez les deux lignes de code suivantes dans la balise head de votre document :

<script>document.createElement( "picture" );</script>

<script src="/path/to/picturefill.js" async></script>

Avec tout ça, vous aurez des images responsive qui fonctionnent parfaitement dans vos mises en page flexibles, et qui se redimensionnent de façon responsable avec un peu d’aide de srcset et de sizes.

Mais faites attention, chers lecteurs : si srcset et sizes peuvent permettre d’alléger un peu vos images redimensionnées en CSS, cette approche est parfois loin d’être idéale. Dans certains cas, les images flexibles font plus de mal que de bien.

Vous allez le regretter

... bon, désolé pour cette note tragique. Il n’y a rien de mal à utiliser max-width: 100% pour rendre vos éléments img plus flexibles – et cette règle marchera parfaitement avec la plupart de vos images. Mais parfois, redimensionner des images peut leur faire perdre en clarté.

FIG 3.15 : Vox présente des citations de façon très esthétique, en superposant le texte à des images.

Prenons un petit exemple : ouvrez l’article « What is Paul Krugman Afraid Of? » (http://bkaprt.com/rdpp/03-23/) sur un écran de taille raisonnable, un ordinateur portable ou une tablette, par exemple. Au fil de l’interview, vous remarquerez plusieurs photos avec du texte en surimpression (FIG 3.15). Un certain nombre de problèmes d’accessibilité peuvent se poser en incrustant des citations sur des images – celles-ci devront comporter des attributs alt pour être accessibles aux lecteurs malvoyants – mais oublions ces problèmes un instant pour nous concentrer sur la mise en page responsive elle-même.

Comme la mise en page de l’article est responsive, Vox a utilisé max-width: 100% pour s’assurer qu’à mesure que la grille flexible se transforme, les images n’échappent jamais à leur conteneur. Par conséquent, si vous ouvrez le même article sur un écran plus petit, les images seront redimensionnées, mais les citations seront considérablement moins lisibles que sur un grand écran (FIG 3.16).

Cela vaut autant pour les graphiques que pour les images complexes, si ce n’est plus. Par exemple, prenez la carte sur le site de la Columbia School of Engineering (http://bkaprt.com/rdpp/03-24/ ; FIG 3.17). En plus des blocs de couleur représentant la consommation d’énergie dans tous les quartiers de New York, il y a le titre du graphique, une légende pour vous aider à déchiffrer la carte, des diagrammes circulaires pour certains territoires, etc. En d’autres termes, l’image est extrêmement dense. Elle pourrait donc être redimensionnée, mais tous ces détails fins seraient perdus, et le sens de l’image en serait affecté.

FIG 3.16 : Sur les petits écrans, le redimensionnement des images complique la lecture du texte. Flexible, mais frustrant.

FIG 3.17 : Une carte interactive et très utile de New York. Existe-t-il un moyen efficace de redimensionner quelque chose d’aussi dense ?

FIG 3.18 : Dans son livre Designing Programmes, Karl Gerstner démontre comment un système de design bien pensé peut préserver l’intégrité d’un logo sur différents formats papier, des publicités grand format aux cartes de vœux (http://bkaprt.com/rdpp/03-26/).

Le cadre, la structure et la forme des images

Le problème avec le redimensionnement en CSS, c’est qu’il ne tient pas compte du contenu : il se focalise sur la forme du conteneur qui contient l’image, pas sur l’image elle-même. Et parfois, si l’on ne fait pas attention, ces images peuvent être redimensionnées au point d’en devenir complètement inutiles.

Ce problème n’a rien de nouveau. Bien avant l’avènement du web, les photographes et les graphistes devaient se soucier de redimensionner leur travail tout en en préservant l’intégrité sur des supports de différentes tailles. Vers la moitié du XX^5 siècle, le designer suisse Karl Gerstner a appliqué une approche systématique pour résoudre le problème, démontrant comment un système de design pouvait permettre d’adapter un logo de sorte qu’il s’épanouisse dans tous les contextes (FIG 3.18).

Plus récemment, le designer Raymond Brigleb a créé un graphique décrivant la hausse de popularité des cassettes dans les années 1980 et le défi que cela représentait pour les concepteurs de pochettes de vinyles. Contraints par la petite taille et le format impitoyable des cassettes, les designers devaient changer la mise en page, les dimensions et la position des éléments clés afin de préserver le message qu’ils souhaitaient communiquer (FIG 3.19).

FIG 3.19 : En cherchant à adapter l’artwork des vinyles au format cassette, Raymond Brigleb démontre que nous avons besoin d’images responsive (http://bkaprt.com/rdpp/03-27/). (Ce qui laisse entendre que nos problèmes sur le Web n’ont rien de nouveau.)

Même le processus de recadrage d’une photographie nécessite de comprendre le contenu de l’image, et pas seulement ses dimensions. Un photographe identifie le sujet principal d’une photo – son point focal – et supprime les parties inutiles de l’image. Différents cadrages d’une même photographie peuvent montrer plus ou moins de détails, mais le sujet est généralement constant. Tous ces cadrages, aussi différents qu’ils puissent paraître, restent essentiellement la même photo (FIG 3.20).

Afin que les images ne soient pas seulement redimensionnables, mais adaptatives, plusieurs personnes se sont attelées à automatiser le recadrage. Par exemple, Adam Bradley a construit un framework qui permet aux designers d’appliquer des classes CSS au conteneur d’une image afin de préserver le point focal à mesure que l’image est agrandie ou réduite (http://bkaprt.com/rdpp/03-25/).

Il est donc tout à fait possible – et souvent idéal – de redimensionner simplement vos images avec une mixture de max-width: 100%, srcset et sizes. Mais il peut être bon de se souvenir que les images figurant dans nos documents sont elles-mêmes des documents. Après tout, elles sont là pour communiquer des informations à nos lecteurs, donc nous devons veiller à ce que le message survive, quelle que soit l’échelle.

FIG 3.20 : Si les dimensions d’une photographie peuvent varier selon le cadrage, le point focal reste intact. Photographie de Tim Evanson (http://bkaprt.com/rdpp/03-28/)

UN CONTRÔLE PLUS FIN : PICTURE ET SOURCE

En d’autres termes, vous tomberez parfois sur des situations où les images ne doivent pas être redimensionnées, mais remplacées par des fichiers alternatifs optimisés pour différents points de rupture, afin de préserver leur clarté alors que leur conteneur se dilate ou se contracte. Dans ce cas-là, vous devrez spécifier une image complètement différente à charger.

Bien sûr, on ne parle ici que des images d’arrière-plan. Les images de premier plan, comme celles spécifiées par notre laborieux élément img, ont besoin d’un petit coup de pouce supplémentaire. Et c’est là que le nouvel élément picture entre en jeu. Le site responsive de Shopify est un excellent exemple de picture à l’œuvre. Vers le sommet de la page d’accueil se trouve la photo d’un client Shopify, qui est placée à différents endroits selon le point de rupture (FIG 3.21). Mais si vous jetez un œil sous le capot, vous verrez qu’il n’y a pas une, mais trois photos dont les dimensions et le cadrage sont légèrement différents (FIG 3.22). Et si vous regardez le code source de la page, vous verrez notre premier exemple d’utilisation de l’élément picture :

FIG 3.21 : Suivez la photo : l’image principale de la page d’accueil responsive de Shopify change de position selon le point de rupture (http://bkaprt.com/rdpp/03-29/).

FIG 3.22 : On dirait une seule et même image, mais il y en a trois : le même sujet figure sur chaque photo, mais le cadrage est légèrement différent.

<picture>

<source

srcset="homepage-person@desktop.png"

media="(min-width: 990px)">

<source

srcset="homepage-person@tablet.png"

media="(min-width: 750px)">

<img

srcset="homepage-person@mobile.png"

alt="A featured Shopify Merchant">

</picture>

J’ai légèrement simplifié le balisage, mais la structure est la même. Comme vous pouvez le voir, un élément picture peut contenir plusieurs éléments source, et exactement un élément img. Dans chaque élément source, on trouve une media query spécifiée à l’aide du bien nommé attribut media. Le navigateur parcourt tous les éléments source jusqu’à en trouver un dont la media query correspond aux conditions du navigateur. Une fois la bonne image trouvée, il renvoie l’attribut srcset de cet élément source vers l’élément img et charge l’image.

De fait, cette relation entre les éléments source et img est très importante : l’élément source correspondant n’est jamais rendu par le navigateur. D’ailleurs, l’élément picture non plus : l’attribut srcset de l’élément source correspondant est renvoyé vers l’élément img interne, et c’est ça qui se retrouve affiché. Ainsi, sur les grands écrans, l’élément source qui comporte la media query (min-width: 990px) renverra la version la plus volumineuse de la photo de Shopify vers l’élément img ; sur les viewports de taille intermédiaire, l’image homepage-person@tablet.png sera rendue à l’aide de la media query (min-width: 750px). Et pour finir, si aucune media query ne correspond, le navigateur se contentera de charger l’élément img.

Au lieu d’utiliser srcset et sizes pour charger des versions plus grandes et plus petites de la même image, picture nous permet de fournir l’image qui convient le mieux à chaque viewport. Dans le langage de la spécification sur les images responsive, c’est ce que l’on appelle de la direction artistique. Plutôt que de simplement redimensionner l’image, on la recadre ou on l’optimise d’une façon ou d’une autre pour l’adapter à chaque point de rupture. Ce faisant, nous nous assurons qu’elle communique toujours son message, même si ses détails sont susceptibles de changer.

Mais l’élément picture a d’autres tours dans son sac. Allez jeter un œil à la page http://responsivewebdesign.com/workshop. Vers la moitié de la page, vous verrez une liste de logos (FIG 3.23). Si vous ouvrez le code source, chaque logo ressemble à peu près à ça :

<picture>

<source srcset="/logos/cibc.svg"

type="image/svg+xml" />

<img src="/logos/cibc.png" alt="CIBC" />

</picture>

FIG 3.23 : Une petite liste de logos employant l’élément picture

Vous aurez peut-être remarqué que notre élément picture ne comporte aucune media query. À la place, il y a un seul attribut type dans l’élément source, indiquant que l’image qu’il référence est une image vectorielle au format SVG (image/svg+xml). Au lieu d’utiliser des media queries pour choisir une image, notre navigateur vérifie les éléments source pour voir s’il peut prendre en charge leur type. Dans le cas présent, nous voulons savoir si le format SVG est pris en charge : si un navigateur prend en charge ce format image/svg+xml, il chargera la version vectorielle de l’image ; sinon, il chargera simplement le fichier PNG spécifié dans notre élément img.

Théoriquement, nous pourrions aller plus loin en enrichissant l’attribut srcset avec les descripteurs répondant à la résolution, w et x, dont nous avons parlé précédemment. L’attribut type nous permet d’utiliser l’élément picture pour demander à un navigateur quels sont les formats qu’il supporte. Et il s’avère particulièrement puissant lorsqu’il est combiné à des media queries, comme vous le verrez si vous observez le logo au sommet du site Responsive Web Design (http://responsivewebdesign.com/workshop) :

<picture>

<source

media="(min-width: 50em)"

type="image/svg+xml"

srcset="/img/logo-rwd-sq.svg" />

<source

media="(min-width: 50em)"

srcset="/img/logo-rwd-sq.png" />

<source

media="(min-width: 39em)"

type="image/svg+xml"

srcset="/img/logo-rwd.svg" />

<source

media="(min-width: 39em)"

srcset="/img/logo-rwd.png" />

<source

type="image/svg+xml"

srcset="/img/logo-rwd-sq.svg" />

<img src="/img/logo-rwd-sq.png" alt="Responsive

Web Design" />

</picture>

Nous combinons ici des media queries sur chaque élément source avec un attribut type, ce qui nous permet de détecter non seulement la largeur du viewport, mais également la prise en charge du format SVG par le navigateur (type="image/svg+xml"). Et nous faisons cela pour plusieurs points de rupture. Au point le plus large ((min-width: 50em)) et le plus étroit de la mise en page, l’en-tête comporte une version sur deux lignes de l’image, au format SVG (logo-rwd.svg) ou PNG (logo-rwd.png). Mais au point de rupture intermédiaire ((min-width: 39em)), le texte tient sur une seule ligne ; et là encore, nous utilisons l’attribut type pour vérifier si le navigateur prend en charge le format SVG.

Tout ce code supplémentaire peut paraître complexe, mais le processus reste le même : notre navigateur part du premier élément source et descend en cherchant une source dont la media query correspond au viewport et dont l’attribut type correspond aux formats d’images supportés par le navigateur. Une fois la bonne image trouvée, le navigateur la renvoie vers l’élément img pour qu’elle soit rendue : s’il ne trouve aucune image qui convient, il chargera simplement notre img.

DESIGNERS, RECADREZ-VOUS !

Nous avons abordé une vaste palette de techniques dans ce chapitre. Mais pour résumer, nous devons réfréner notre envie de tout contrôler – avec les attributs background-position et back-ground-size dans notre CSS, ou picture dans notre HTML – et laisser le navigateur résoudre certains problèmes pour nous avec srcset et sizes. C’est ce point, plus qu’une quelconque technique de programmation, qui semble le plus important : nous devons recadrer le débat pour ne plus nous focaliser sur une technologie particulière, et renoncer à vouloir contrôler parfaitement l’expérience.

LA PUBLICITÉ EST AUSSI VIEILLE que l’imprimerie. Plus vieille, même : on a découvert des slogans de campagne et des publicités sur les murs de Pompéi. En Égypte antique, des messages commerciaux étaient souvent rédigés sur papyrus et affichés à la vue de tous. Mais à l’avènement du papier, la publicité a véritablement pris son envol. La plus vieille publicité sur papier connue est un prospectus chinois qui date du X^5 siècle (FIG 4.1).

La publicité papier, celle qui figure dans les magazines, les journaux et autres périodiques, est sûrement celle que vous connaissez le mieux. Elle a toutefois connu des débuts modestes. Voyez plutôt la première publicité connue pour du café, publiée dans les pages du Publick Adviser au XVII^5 siècle (FIG 4.2). C’est une publicité strictement textuelle, sobre, quoique poétique, vantant les mérites d’un torréfacteur. Un siècle plus tard, si vous plissiez les yeux en regardant la une du Times of London, vous pouviez discerner des annonces pour des entreprises de marine marchande (FIG 4.3). Mais évidemment, au fil du temps, les placards publicitaires ont évolué et ont acquis cette nature plus flamboyante que nous leur connaissons (FIG 4.4).

FIG 4.1 : Des murs de pierre aux prospectus, du papyrus aux journaux, la publicité existe depuis bien longtemps déjà (http://bkaprt.com/rdpp/04-01/ ; http://bkaprt.com/rdpp/04-02/ ; http://bkaprt.com/rdpp/04-03/).

FIG 4.2 : À ses débuts, la publicité préférait généralement la prose aux illustrations, comme ici dans le Publick Adviser de Londres (http://bkaprt.com/rdpp/04-04/ ; http://bkaprt.com/rdpp/04-05/).

FIG 4.3 : Outre quelques ornements visuels et une composition un peu plus aventureuse, les placards publicitaires restent plutôt minimalistes un siècle plus tard (http://bkaprt.com/rdpp/04-06/).

FIG 4.4 : Évidemment, les publicités sont devenues un peu plus... colorées par la suite. (http://bkaprt.com/rdpp/04-07/ ; http://bkaprt.com/rdpp/04-08/ ; http://bkaprt.com/rdpp/04-09/ ; http://bkaprt.com/rdpp/04-10/ ; http://bkaprt.com/rdpp/04-11/).

Lorsque le Web a fait son apparition, il est tout naturel que nous ayons voulu y appliquer les pratiques publicitaires qui semblaient marcher sur le papier. La trajectoire de la publicité numérique était, de bien des façons, similaire à celle de la publicité papier. De simples bandeaux publicitaires aux publicités interactives complexes qui existent aujourd’hui, la conception de publicités numériques est devenue une discipline à part entière (FIG 4.5-4.6). Pour le meilleur et pour le pire, une grande partie de notre medium est financé par la publicité, et celle-ci pose un sérieux problème pour les mises en page responsive : en effet, la plupart des publicités sur le web sont à largeur fixe.

Je sais, je suis aussi choqué que vous, mais c’est vrai ! Prenez par exemple l’Interactive Advertising Bureau (IAB), le consortium qui définit la plupart des normes en matière de publicité en ligne. Si vous lisez ses directives pour les ordinateurs de bureau (http://bkaprt.com/rdpp/04-12/) ou les appareils mobiles (http://bkaprt.com/rdpp/04-13/), vous verrez que chaque entrée dans la liste – le « rectangle moyen » de 300 × 250 pixels, le « gratte-ciel » de 160 × 600, etc. – s’accompagne d’une largeur et d’une hauteur spécifiques, définies en pixels parfaitement inflexibles (FIG 4.7).

FIG 4.5 : Que vous les aimiez ou non, ces vieux bandeaux publicitaires sur O’Reilly et HotWired ont marqué les débuts de l’industrie de la publicité numérique – et plus tard, l’avènement des bloqueurs de publicité.

FIG 4.6 : Des bannières, des vidéos et des rollovers – nous sommes gâtés !

FIG 4.7 : Il y a des formats de publicité pour tous les goûts. (Du moment que vous aimez les pixels.)

Si je vous raconte ça, ce n’est pas parce que je déteste les pixels (quoique), mais parce que c’est problématique pour un design responsive. Nos mises en page sont devenues plus flexibles et adaptables à tous les appareils, et pourtant nos publicités se voient encore affublées de dimensions fixes. Comment sommes-nous alors censés les incorporer dans des designs résolument fluides ?

Je vous donne la chute de l’histoire tout de suite : on n’a pas encore trouvé la réponse parfaite. La publicité responsive est un domaine en chantier, mais il y a un certain nombre de modèles émergents que nous pouvons utiliser. Voyons plutôt.

(Attendez un peu : ce n’est pas censé être drôle, une chute ?)

CHARGEMENT CONDITIONNEL

En 2012, Smashing Magazine, une publication en ligne pour web designers et développeurs, a lancé un nouveau site responsive saisissant (FIG 4.8). Avec sa palette de couleurs aérée et sa typographie élégante et réfléchie, le site conçu par Elliott Jay Stocks est un vrai bonheur à lire sur n’importe quel appareil. Si votre écran est assez large, vous verrez un certain nombre de publicités dans un encadré latéral à largeur fixe, sur la droite de l’écran. Mais si vous ouvrez le site sur un plus petit écran, comme un téléphone ou une petite tablette, les publicités ne seront pas visibles. En dessous d’un certain point, elles sont complètement masquées.

FIG 4.8 : Smashing Magazine, avec son design responsive qui en jette

Voici un extrait du CSS qui crée cet effet :

.sb {

display: none;

}

@media screen and (min-width: 63.75em) {

.sb {

display: block;

}

}

Le bloc qui contient les publicités – un div comportant la classe .sb – se voit appliquer la règle display: none par défaut. Mais dès que le viewport dépasse 63.75em de large, soit environ 1020px, la propriété display de l’encadré prend la valeur block, et les publicités réapparaissent triomphalement sur le côté droit de la page.

FIG 4.9 : Les publicités de Smashing sont masquées, mais tout de même chargées.

On dirait une approche raisonnable, non ? Après tout, en dessous d’une certaine largeur, les publicités seraient difficiles à intégrer dans une mise en page responsive. Mais si vous fouinez dans l’inspecteur de votre navigateur, vous verrez que les publicités sont tout de même chargées : le code permettant d’afficher et de télécharger les publicités est exécuté dans tous les cas (FIG 4.9). Elles sont simplement masquées avec quelques lignes de CSS.

Plusieurs problèmes se posent lorsque vous masquez du contenu qui ne tient pas sur la page. Du point de vue de la publicité, ce sont les lecteurs sur grand écran qui financent l’expérience des utilisateurs de petits écrans. (À supposer, bien sûr, que les publicités cachées ne soient pas comptées comme « visionnées » par l’annonceur.) Et comme nous l’avons vu précédemment, un excédent de code masqué peut introduire une surcharge inutile dans nos designs. Si une certaine catégorie d’utilisateurs – sur mobile, tablette, ordinateur ou autre – n’a pas accès à un contenu particulier, masquer ces informations en CSS ajoute un poids de plus sans bénéficier au lecteur.

Outre les publicités, cet encadré contient d’autres éléments de contenu potentiellement importants – petits textes promotionnels concernant des livres, formulaire d’inscription à la newsletter, etc. – qui sont invisibles sur les plus petits écrans (FIG 4.10). Je me hâte de préciser qu’il ne s’agit pas là d’une critique de Smashing Magazine : cacher du contenu qui ne « rentre pas » est une technique courante sur de nombreux sites responsive. Mais que l’on conçoive du texte, de la vidéo, des images ou de la publicité, il faudrait toujours chercher des occasions de simplifier nos designs, plutôt que de dissimuler des informations. Une meilleure approche consisterait à charger uniquement ce qui est nécessaire pour un viewport donné, plutôt que de cacher les excès avec CSS. Plus précisément, nous pouvons commencer par identifier les publicités les mieux adaptées à chaque point de rupture, et les charger uniquement si l’espace est suffisant.

Au chapitre 2, nous avons abordé un système de navigation responsive qui applique le chargement conditionnel pour (hum !) charger des menus plus complexes de façon conditionnelle, par exemple lorsque le viewport dépasse une certaine largeur. Actuellement, le balisage de l’encadré – notre div .sb – est inclus directement dans la page, et caché à l’aide de CSS :

<div class="sb">

<!-- Code de l’encadré -->

…

</div>

En théorie, nous pourrions utiliser le modèle Ajax-Include (http://bkaprt.com/rdpp/02-08/) pour charger le balisage de l’encadré de façon conditionnelle, en supprimant le contenu et en le déplaçant vers un fichier externe – appelons-le sidebar-contents.html :

<div class="sb"

data-append="/include/sidebar-contents.html"

data-media="(min-width: 63.75em)"></div>

FIG 4.10 : Ce n’est pas que la pub : d’autres éléments de contenu intéressants sont masqués sur les petits écrans.

FIG 4.11 : Sur les petits écrans, les publicités peuvent apparaître sous les articles principaux.

Ce n’est qu’une ébauche, mais c’est pour vous donner une idée du fonctionnement d’Ajax-Include. L’attribut data-append renvoie vers l’URL de notre bout de code, qui contient le contenu à ajouter au div ; data-media, lui, déclare que le code doit uniquement être chargé si notre viewport fait au moins 63.75em de large. Si le viewport est plus petit, le div reste vide.

REPENSER LA HIÉRARCHIE

Lors de la refonte de son site web en 2011, le Boston Globe a mis au point un modèle pour résoudre ses problèmes de publicité responsive : en l’occurrence, le placement d’une publicité serait déterminé par la largeur de la page. Lorsque le site était rendu sur une seule colonne, les publicités pouvaient être insérées à des points stratégiques au milieu du contenu. Une publicité de grande taille pouvait apparaître immédiatement après les articles principaux sur la page d’accueil – mais seulement sur les écrans les plus étroits (FIG 4.11). En agrandissant la page sur deux colonnes, la publicité passait en haut de la nouvelle colonne. De même, lorsqu’une troisième colonne faisait son apparition sur les viewports les plus larges, la publicité passait sur la colonne suivante (FIG 4.12-4.13).

FIG 4.12 : Au point de rupture intermédiaire, la publicité passe sur la seconde colonne.

FIG 4.13 : À mesure que le design s’élargit, la publicité passe sur la troisième colonne.

Je faisais partie de l’équipe qui travaillait sur le nouveau design, et nous avons tous su que le modèle suggéré par le Globe était une approche véritablement innovante pour rendre la publicité responsive. Cependant, ce modèle exigeait de s’écarter légèrement de la méthode traditionnellement employée pour insérer des publicités sur une page web. À l’origine, les producteurs inséraient un bout de JavaScript dans l’HTML d’une page, comme ceci :

<script>insertAd( 'MAIN_AD' );</script>

Si ça a l’air plutôt simple, c’est parce que c’est fait pour : la fonction insertAd() est chargée d’insérer une publicité d’un certain type (en l’occurrence MAIN_AD) à un endroit spécifique sur la page. Mais cette simplicité ne dure pas longtemps. Une fois ce code exécuté par le navigateur, il devient plus complexe – une série de déclarations document.write() :

<script>

document.write( »

'<script src="ad-load.js"></script>' );

document.write( »

'<style>.ad { border: 1px solid; … }</style>' );

…

</script>

C’est un peu plus compliqué, mais l’esprit est le même : ces déclarations document.write() sont chargées d’insérer la publicité MAIN_AD dans le design, avec les fichiers JavaScript et CSS dont elle a besoin. Cette approche est très courante sur le Web, car elle a le mérite d’être fiable : vous savez exactement où chaque publicité sera placée. Mais malheureusement, elle ne convient pas à une solution plus responsive comme celle du Globe, qui peut faire apparaître une publicité à plusieurs endroits potentiels.

La fonction document.write() elle-même complique les choses. Pour commencer, elle nuit fortement aux performances : pendant que le navigateur télécharge les images, styles et ressources externes nécessaires pour afficher la pub, tout le contenu apparaissant après ces déclarations document.write() attend son tour (FIG 4.14). L’effet peut être terrible pour l’expérience utilisateur, surtout sur les appareils ou les réseaux les plus lents. De plus, une fois que le contenu a été inscrit sur la page avec document.write(), il ne peut pas être déplacé avec JavaScript. Si nous avions utilisé cette méthode, notre publicité aurait été fixée à un endroit précis. Le contenu généré avec document.write() est donc incompatible avec notre modèle de publicité responsive.

FIG 4.14 : document.write() : excellent pour insérer du contenu à un endroit précis ; pas terrible pour les performances.

Pour rendre notre publicité plus adaptative, nous avons commencé par supprimer tout le JavaScript figurant dans le code HTML. Ensuite, nous avons cherché les endroits où les publicités pouvaient potentiellement apparaître – sous les articles principaux, au sommet de la deuxième, puis de la troisième colonne, et nous avons inséré un div vide à chaque emplacement :

<div data-adname="MAIN_AD" class="ad-slot-a"></div>

…

<div data-adname="MAIN_AD" class="ad-slot-b"></div>

…

<div data-adname="MAIN_AD" class="ad-slot-c"></div>

Ces div sont complètement vides, à l’exception de deux attributs descriptifs. Le premier est data-adname, un attribut data- HTML5 qui spécifie le nom de la publicité que le bloc contiendra (je suis un véritable génie pour trouver des noms). L’autre petit morceau de métadonnées présent est un modeste attribut class, qui nous permet de distinguer chaque conteneur de publicité des autres.

Le balisage est plutôt simple, mais il constitue la base de notre modèle de publicité responsive. Dans les exemples ci-dessous, nous utiliserons un attribut class comme une sorte de « hameçon » pour appliquer des styles simples afin de masquer ou d’afficher sélectivement chaque bloc selon le point de rupture. Une fois cet « interrupteur » display en place, il reste à écrire un peu de JavaScript pour non seulement insérer les publicités, mais les déplacer à l’envi d’un endroit à un autre :

1. Le script commence par parcourir tous les div qui partagent la même valeur data-adname, et cherche le premier qui présente la valeur display: block.

2. Une fois ce bloc trouvé, notre JavaScript y insère la publicité.

3. Lorsque la fenêtre du navigateur est redimensionnée ou que l’orientation de l’appareil change, le JavaScript redémarre le processus : il cherche le bloc visible, puis déplace la publicité dans ce conteneur.

En affichant un seul conteneur par point de rupture, notre JavaScript peut placer la publicité dans le conteneur approprié selon la largeur du viewport. Nous commençons par afficher uniquement le bloc publicitaire qui apparaît immédiatement après les articles principaux – c’est-à-dire le conteneur dont l’attribut class est ad-slot-a :

.ad-slot-a {

display: block;

}

.ad-slot-b,

.ad-slot-c {

display: none;

}

Nous avons masqué ad-slot-b et ad-slot-c, de sorte que notre JavaScript parcoure tous les conteneurs MAIN_AD et constate que seul ad-slot-a est visible. Et comme le div inclut la règle display: block, notre script insère la publicité dans ce conteneur, comme ceci :

<div data-adname="MAIN_AD" class="ad-slot-a">

<a class="ad" href="http://example.com/">

<img src="http://example.com/ad-main.gif"

alt="" />

</a>

</div>

…

<div data-adname="MAIN_AD" class="ad-slot-b"></div>

…

<div data-adname="MAIN_AD" class=“ad-slot-c"></div>

Lorsque le viewport devient un peu plus large (autour de 30em), la deuxième colonne fait son apparition. À ce stade, nous changeons légèrement notre CSS afin d’afficher uniquement ad-slot-b, le deuxième conteneur publicitaire :

@media (min-width: 30em) {

.ad-slot-b {

display: block;

}

.ad-slot-a,

.ad-slot-c {

display: none;

}

}

Une fois le bloc ad-slot-a masqué, notre JavaScript s’exécute à nouveau, et remarque que ad-slot-b est visible. Il insère alors la publicité dans ce conteneur :

<div data-adname="MAIN_AD" class="ad-slot-a"></div>

…

<div data-adname="MAIN_AD" class="ad-slot-b">

<a class="ad" href="http://example.com/">

<img src="http://example.com/ad-main.gif"

alt="" />

</a>

</div>

…

<div data-adname="MAIN_AD" class="ad-slot-c"></div>

Enfin, pour le point de rupture le plus large, nous pouvons cacher tous nos conteneurs, sauf celui de la troisième colonne, j’ai nommé ad-slot-c :

@media (min-width: 50em) {

.ad-slot-c {

display: block;

}

.ad-slot-a,

.ad-slot-b {

display: none;

}

}

Une fois ces deux règles simples en place, notre JavaScript déplacera la publicité dans notre troisième et dernier conteneur :

<div data-adname="MAIN_AD" class="ad-slot-a"></div>

…

<div data-adname="MAIN_AD" class="ad-slot-b"></div>

…

<div data-adname="MAIN_AD" class="ad-slot-c">

<a class="ad" href="http://example.com/">

<img src="http://example.com/ad-main.gif"

alt="" />

</a>

</div>

Avec notre modeste interrupteur en CSS et un petit peu de JavaScript, notre publicité reçoit enfin un traitement responsive convenable (FIG 4.15). Elle n’est jamais redimensionnée ni coupée, mais elle est repositionnée afin de rester visible et d’occuper au mieux l’espace disponible. Cette approche ne se limite pas au design responsive du Boston Globe. En fait, ce modèle est devenu la bibliothèque AppendAround du Filament Group (http://bkaprt.com/rdpp/04-15/), qui permet de transplanter n’importe quel contenu – et pas seulement des publicités – d’un conteneur à un autre.

FIG 4.15 : Le Boston Globe combine un peu de JavaScript et de CSS pour déplacer la publicité sur la page.

Le déplacement des publicités au sein d’un design responsive est rapidement devenu la norme pour de nombreux éditeurs. Plusieurs des sites responsive de Vox Media, y compris Vox.com, ont adopté ce modèle (FIG 4.16). Leur approche, cependant, est légèrement différente. D’après Jesse Young, un membre de l’équipe de production de Vox Media, ils ont choisi de ne pas déplacer les publicités, mais tout le reste (http://bkaprt.com/rdpp/04-16/) :

Le placement des publicités est un peu plus délicat. Imaginons par exemple que nous souhations que le bandeau publicitaire apparaisse uniquement à droite de l’écran et nulle part ailleurs. Afin de nous en assurer, nous utilisons du JavaScript pour repositionner des éléments. Cependant, ce n’est pas la publicité que l’on déplace, mais le contenu qui l’entoure. Car une fois qu’une publicité est rendue, toute manipulation du DOM qui l’affecte directement crée des comportements indésirables, comme des erreurs de tracking, voire la disparition de la publicité.

FIG 4.16 : Vox Media organise le contenu autour de la publicité, pas l’inverse.

Mais ce qu’il faut savoir, c’est qu’en matière de publicité responsive, la mise en page est la partie la plus simple. Des défis bien plus grands nous attendent.

NOUS AVONS BESOIN DE NOUVEAUX MODÈLES

Il y a quelque temps, le designer Mark Boulton, prenant un peu de distance par rapport aux histoires de mise en page, a décrit plusieurs véritables défis à relever pour rendre nos publicités responsive (http://bkaprt.com/rdpp/04-17/) :

Voilà comment je vois le problème :

• Un grand nombre de sites tirent leurs revenus de la publicité. Une approche de responsive web design pourrait être un avantage pour nombre d’entre eux.

• La publicité en ligne est une industrie à part entière.

• Les unités publicitaires sont des dimensions fixes et standardisées.

• Elles sont commandées, vendues et créées selon leurs dimensions et leur position sur la page.

• Beaucoup de publicités sont riches (avec des takeovers, de la vidéo, des pop-overs, des flyouts et diverses interactions).

Nous avons déjà abordé certains des problèmes que pose la mise en page, notamment le fait que les publicités sont fixes et inflexibles, et ne produisent pas le même résultat selon la classe de l’appareil ou la taille de l’écran. Mais Boulton s’attaque à la racine de problèmes plus profonds, de nature commerciale – à savoir que le secteur de la publicité opère indépendamment du reste du Web et considère toujours la vente de publicité numérique sous l’angle du papier et d’un positionnement fixe.

Dans deux essais écrits sur le sujet, le designer et directeur artistique Roger Black aborde le problème sous un autre angle : il pense que le secteur de la publicité en ligne est loin de s’être adapté à la nature multiappareils du Web (http://bkaprt.com/rdpp/04-18/ ; http://bkaprt.com/rdpp/04-19/) :

Le Web, les tablettes et les mobiles sont vendus et servis séparément, et il n’existe encore aucun service de statistiques permettant de suivre une campagne multiplateforme. Pour le moment, le seul moyen d’avoir de la publicité responsive, c’est de vendre une création et un emplacement personnalisés. [...] Il n’y a aucun moyen d’acheter et d’insérer des publicités adaptatives qui marchent sur toutes les plateformes. L’Interactive Advertising Bureau, qui s’évertue depuis des années à promouvoir des dimensions standards pour les publicités sur le Web de bureau, ne liste même pas de dimensions pour mobiles dans ses unités publicitaires.

Black évoquait la question en 2011, mais les problèmes sous-jacents n’ont pas beaucoup changé. De nombreux réseaux d’annonceurs voient encore les « mobiles », les « tablettes » et les « ordinateurs » comme des produits distincts à gérer et à vendre, ce qui complique la tâche pour les entreprises qui souhaitent coordonner des campagnes publicitaires sur plusieurs types d’appareils. Ce problème ne fera qu’empirer au fil du temps, évidemment – car bientôt, mobiles, tablettes et ordinateurs ne seront plus les seules catégories pour lesquelles nous devrons concevoir. (Et c’est tant mieux.) Si l’on se fie à une étude publiée par Google, cette approche compartimentée a désespérément besoin de rattraper notre réalité à écrans multiples (http://bkaprt.com/rdpp/04-20/). Il est de plus en plus rare de commencer et de finir un processus particulier sur le même appareil ; on peut par exemple faire notre shopping sur un téléphone, avant de régler la facture sur une tablette ou un ordinateur portable.

Comme nos mises en page responsive, nos publicités doivent devenir plus fluides, non seulement par leur forme, mais aussi par leur transmission. Et si le secteur de la publicité doit encore moderniser ses normes de mise en page ou ses pratiques commerciales, de nombreuses organisations ont choisi d’essayer de développer leur propre publicité responsive, en concevant des formats publicitaires sur mesure plus flexibles en interne (FIG 4.17). D’après Trei Brundrett, de Vox Media, cette approche n’a pas seulement permis de créer des publicités responsive, elle a permis de créer des publicités moins intrusives et plus rentables (http://bkaprt.com/rdpp/04-21/) :

Notre ligne directrice consiste à considérer que la publicité fait partie intégrante de l’expérience utilisateur. Combinez une excellente expérience utilisateur avec une publicité bien intégrée, et votre publicité obtiendra de meilleurs résultats. Tout le monde y gagne.

Cette formule est très séduisante. Plutôt que de voir la publicité numérique comme étant incompatible avec un design élégant et lisible, des éditeurs suggèrent maintenant que des publicités plus flexibles et responsive satisfont à la fois les annonceurs et les lecteurs.

FIG 4.17 : De nombreux éditeurs, comme le Boston Globe, se sont rebellés contre les normes du secteur et ont commencé à concevoir des publicités flexibles en interne.

L’équipe préposée à la publicité numérique au Guardian décrit ses expériences de publicités interappareils en des termes similaires, déclarant que ses nouvelles unités publicitaires responsive sont « meilleures pour les annonceurs, pour le Guardian et pour nos lecteurs » (http://bkaprt.com/rdpp/04-23/). Comme son site est consulté chaque mois par une grande variété d’appareils et d’écrans différents (« plus de 6 000 à l’heure actuelle »), l’équipe du Guardian a créé des versions flexibles d’encarts publicitaires standard (FIG 4.18). Pour cela, elle a décomposé chaque publicité en ses éléments de base, et les a traités comme un design responsive à petite échelle :

Pour construire cette unité, nous avons extrait les différents éléments d’une publicité : l’arrière-plan, l’image du sujet, la marque et l’appel à l’action. Ceux-ci sont ensuite insérés individuellement dans une unité publicitaire en HTML5 pour permettre à l’unité de s’adapter au mieux à l’espace disponible.

En traitant leurs publicités comme de petites mises en page responsive au lieu de blocs fixes et inflexibles, des éditeurs comme le Guardian peuvent repositionner ces éléments au sein d’une structure responsive flexible.

FIG 4.18 : En l’absence de formats standards, le Guardian a créé plusieurs unités publicitaires responsive en interne (http://bkaprt.com/rdpp/04-22/).

Bien sûr, tous les sites n’ont pas les ressources pour concevoir leurs propres formats publicitaires responsive et les vendre à des annonceurs potentiels. Par chance, Monotype a développé des démonstrations de divers formats publicitaires responsive employant des technologies légères et basées sur des standards – chacun conçu dès le départ pour un maximum de flexibilité (FIG 4.19). Et Google – le petit moteur de recherche teigneux – a sorti une unité responsive pour son service publicitaire AdSense, ce qui devrait contribuer à rendre la publicité responsive plus largement accessible (http://bkaprt.com/rdpp/04-25/).

La publicité responsive en est encore à ses balbutiements. À l’heure où j’écris ces lignes, le secteur de la publicité n’a pas fait beaucoup de progrès en matière de publicité interappareils, se focalisant plutôt sur le développement d’un langage contractuel pour améliorer la visibilité des publicités, et investissant lourdement dans la conception de formats publicitaires distincts pour les « mobiles » et les « ordinateurs » (http://bkaprt.com/rdpp/04-26/). Et les éditeurs sont pleinement conscients de ce fossé, comme l’a récemment fait remarquer Peter Bale, vice-président de CNN International Digital (http://bkaprt.com/rdpp/04-27/) :

FIG 4.19 : Les divers formats publicitaires responsive de Monotype sont d’excellentes démonstrations (http://bkaprt.com/rdpp/04-24/).

Le secteur de la publicité n’a pas encore trouvé le moyen de concevoir des publicités responsive qui apportent le même niveau de monétisation sur tous les appareils – il y a là un retard à rattraper. Nous devons prendre les devants et c’est très difficile.

D’ici là, c’est à nous de régler les problèmes que rencontrent les utilisateurs en matière de performances ou de mise en page, et de développer notre propre méthode pour rendre la publicité plus légère, flexible et responsive.

Ce qui fonctionne vaut mieux que ce qui est beau. La beauté est subjective, mais ce qui fonctionne fonctionne.

RAY EAMES

LES QUELQUES CHAPITRES PRÉCÉDENTS vous ont peut-être donné l’impression de tout passer au microscope. Nous avons examiné les composants les plus problématiques d’un design responsive, et abordé quelques principes courants pour gérer la navigation, les images et la publicité. Mais aucun élément de votre design n’est isolé. Il arrive un moment où tous ces petits systèmes de présentation doivent être cousus ensemble pour créer quelque chose de plus grand, mais aussi de plus flexible, responsive et (espérons-le) beau.

Ce livre s’ouvre sur une citation de Trent Walton, et c’est le bon moment pour y revenir (http://bkaprt.com/rdpp/05-01/) :

J’ai troqué le contrôle que j’avais dans Photoshop contre une nouvelle sorte de contrôle, en utilisant des grilles flexibles, des images flexibles et des media queries pour construire non pas une page, mais un réseau de contenu qui peut être réorganisé en fonction de la taille de l’écran pour communiquer au mieux le message.

« Un réseau de contenu » : charmante image, n’est-ce pas ? Mais pendant que nous nous focalisons sur les composants discrets de nos mises en page responsive – le contenu – il est important de ne pas perdre de vue l’autre moitié de la phrase : le réseau qui contient ces composants. En tant que designers responsive, nous devons nous concentrer non seulement sur les composants individuels du design, mais aussi sur la relation entre ces éléments au sein d’un système de mise en page plus vaste. Joe Stewart décrit le nouveau design responsive de Virgin America en des termes similaires, sans se focaliser exclusivement sur les différents points de rupture, mais en ayant une vision plus large et globale (http://bkaprt.com/rdpp/05-02/) :

Pour je ne sais quelle raison, les gens pensent qu’il est bon d’avoir une expérience utilisateur plus ciblée sur mobile, mais ce principe passe à la trappe dès qu’ils conçoivent pour les ordinateurs de bureau. L’un des avantages du responsive design, c’est qu’il vous force à prendre pour les ordinateurs de bureau les décisions que vous prenez pour les mobiles... Quand il faut envisager le design, le processus de design ou le responsive design dans leur globalité, certains aiment dire que les mobiles doivent passer en premier, mais avec le responsive design, c’est tout qui passe en premier.

Tito Bottita, partenaire de l’agence de design Upstatement, déclare que bien que « mobile first » soit un principe directeur extrêmement important, la mise en page du Boston Globe a été planifiée d’une façon légèrement différente (http://bkaprt.com/rdpp/05-03/) :

Nos designs sont partis de 960px, qui est probablement le point de rupture le plus compliqué, avec plusieurs colonnes de contenu. Cela nous est peut-être venu naturellement après des années à concevoir pour cette largeur, mais ce n’est pas la seule raison. Il est plus facile de concevoir quand vous avez plus d’espace : vous pouvez voir plus de choses simultanément, la hiérarchie est plus nuancée... Nous avons donc commencé à 960px, puis nous avons progressivement réduit la largeur. Chaque décision éclairait la précédente et la suivante ; nous basculions régulièrement entre les différents points de rupture. Comme le mantra Mobile First le suggère, concevoir pour les mobiles a été très instructif, car cela nous a obligés à choisir ce qui était le plus important. Et comme nous refusions de masquer du contenu d’un point de rupture à un autre, la mise en page mobile pouvait nous renvoyer aussi sec à la mise en page de bureau en nous incitant à la simplifier. Le processus s’apparentait un peu à de la sculpture.

Comme Upstatement a pu le constater, partir de la mise en page la plus large et la plus complexe ne les a pas empêchés de peaufiner la plus petite mise en page du design – et bien souvent, le travail réalisé sur un point de rupture influençait la forme des autres. Vous pouvez utiliser InDesign, comme l’a fait Upstatement, pour concevoir rapidement différents points de rupture et les équilibrer entre eux. Ou vous pouvez vous plonger dans HTML et CSS et créer un prototype responsive. Les outils sont secondaires, car une question plus vaste se pose : comment assembler tous ces composants distincts en un design responsive unifié et pratique ?

Sur cette note, nous devrions probablement aborder la question sulfureuse des frameworks.

FRAMEWORKS

Un certain nombre de frameworks CSS responsive sont apparus ces dernières années. Bootstrap (http://bkaprt.com/rdpp/05-04/) et Foundation (http://bkaprt.com/rdpp/05-05/) comptent parmi les plus populaires et vous permettent de créer rapidement des mises en page responsive en utilisant leur balisage établi (FIG 5.1). Voici par exemple comment créer une grille comprenant une ligne et trois colonnes avec Foundation :

FIG 5.1 : Des frameworks CSS tiers, comme Bootstrap et Foundation, peuvent vous aider à construire une mise en page responsive plus rapidement.

<div class="row">

<div class="small-4 columns">...</div>

<div class="small-4 columns">...</div>

<div class="small-4 columns">...</div>

</div>

Par défaut, les mises en page de Foundation sont construites sur une grille à douze colonnes. En utilisant small-4, une classe qui décrit le nombre de colonnes que chaque élément doit occuper, le code CSS de Foundation agencera nos trois éléments en colonnes sur chaque ligne (FIG 5.2-5.3). Et si nous voulons modifier la répartition à un point de rupture supérieur, il suffit de décrire ce changement dans le balisage :

<div class="row">

<div class="small-12 medium-3 columns">...</div>

<div class="small-12 medium-6 columns">...</div>

<div class="small-12 medium-3 columns">...</div>

</div>

FIG 5.2 : Une ligne comportant trois colonnes, construite à l’aide d’un balisage simple et du framework Foundation

FIG 5.3 : Avec quelques-uns des modèles de balisage de Foundation, nous avons une mise en page responsive en forme de grille.

Au-delà d’un point de rupture spécifique – dans Foundation, la largeur du viewport doit être supérieure à 650px par défaut – nos classes medium- permettent au div du milieu d’occuper six colonnes, tandis que les div extérieurs sont réduits à trois colonnes chacun. Et tout cela se fait en changeant simplement quelques classes dans notre HTML.

Plutôt chouette, non ? Je trouve que les frameworks CSS, responsive ou pas, sont fantastiques. Si vous travaillez en équipe, un framework CSS – qu’il s’agisse d’un outil tiers ou développé en interne – peut éliminer une grande part de subjectivité dans la création de mises en page, éviter l’usage de noms de classes et de structures HTML arbitraires, et faire en sorte que tous les collaborateurs partagent les mêmes conventions. Et pour créer des prototypes, il n’y a rien de tel : lorsque je parle de responsive design avec un client, j’utilise souvent un framework CSS tiers pour concevoir rapidement des ébauches de pages et pouvoir passer au navigateur aussi vite que possible. Mais surtout, ces frameworks CSS tiers sont de fantastiques ressources d’apprentissage qui permettent aux designers de mieux comprendre les fondements de la mise en page.

Mais qu’est-ce qu’ils sont lourds !

Et quand je dis « lourds », je ne parle pas du poids du code utilisé dans les frameworks, bien que cela puisse être un motif d’inquiétude valable ; leurs classes supplémentaires et leur balisage peuvent être pour le moins encombrants. Et comme nous le verrons dans la suite de ce chapitre, de nombreuses méthodes basées sur CSS nous permettent de créer des systèmes de mise en page robustes sans avoir à décrire de colonnes ou de lignes dans notre balisage.

Outre les octets en trop, ce qui m’inquiète plutôt, c’est que les frameworks CSS sont lourds conceptuellement. Les mises en page qu’ils offrent sont liées à une grille idéale, comportant souvent douze ou seize colonnes de largeur égale. À partir de là, les classes figurant dans le balisage décrivent comment cette grille doit s’adapter à chaque point de rupture. Et pour ce qui est de Foundation et de Boostrap, les points de rupture qu’ils utilisent sont calqués sur des appareils spécifiques (FIG 5.4).

Notez qu’il s’agit là de valeurs par défaut, et qu’elles sont faciles à changer. Mais les points de rupture par défaut sont associés à des appareils courants : 768px est une largeur courante sur les tablettes 10", comme l’iPad tenu en mode portrait ; 640px correspond à de nombreux smartphones, comme le Samsung Galaxy ou le HTC One en mode paysage.

FIG 5.4 : Bootstrap et Foundation, deux frameworks responsive populaires, définissent leurs points de rupture en pixels, en employant des valeurs qui correspondent aux tailles d’appareils les plus courantes.

Aussi bien conçus et extensibles que soient ces frameworks, les points de rupture qu’ils utilisent sont un instantané du Web tel que nous le comprenons aujourd’hui. Vu la prolifération de nouveaux navigateurs, types d’écrans et d’appareils, nous avons besoin de frameworks plus légers – de frameworks capables de s’adapter aussi agilement que nos designs eux-mêmes, afin de survivre au-delà du simple triptyque « mobile, tablette et ordinateur ».

En 2013, le musée Whitney a complètement revu son image de marque, lançant un site web élégant (http://bkaprt.com/rdpp/05-06/) pour accompagner sa nouvelle identité (FIG 5.5). Tous deux présentent une esthétique fraîche et contemporaine, avec des marges spacieuses et des traits francs et géométriques. Le logo peut paraître rudimentaire, mais il couvre une palette d’applications vertigineuse. Il peut incorporer des œuvres d’art du musée et se retrouver sur des supports de différentes formes et dans différents contextes de la vie de tous les jours (FIG 5.6-5.7). Sur le site web semi-responsive de Whitney, le logo change radicalement selon le point de rupture. Mais en dépit de toutes ces variations de forme et de support, la marque est toujours reconnaissable comme étant le « W » de Whitney (FIG 5.8).

FIG 5.5 : Le nouveau logo de Whitney en action, fortuitement surnommé « responsive W » (http://bkaprt.com/rdpp/05-07/)

FIG 5.6 : Aussi polyvalent que minimal, le logo de Whitney peut incorporer des œuvres d’art du musée (http://bkaprt.com/rdpp/05-07/).

FIG 5.7 : Le logo vit également dans le monde physique, comme ici sur un abribus (http://bkaprt.com/rdpp/05-07/).

FIG 5.8 : Fait assez rare pour être souligné, le logo de Whitney est aussi adaptatif que son site web.

FIG 5.9 : Un framework simple peut permettre de créer des centaines, voire des milliers de variations d’un logo (http://bkaprt.com/rdpp/05-07/).

On pourrait penser que ces centaines, voire ces milliers de variations sont produites par un ordinateur géant, émettant des colonnes de fumée pendant qu’il génère frénétiquement des variations algorithmiquement parfaites du logo. (Je ne peux plus le cacher maintenant : je n’ai jamais vu d’ordinateur de ma vie.) Mais non ! Il se trouve que les concepteurs du logo ont inventé une technique simple pour générer un nombre d’adaptations quasi infini (FIG 5.9) :

1. Vous avez des éléments à incorporer dans une zone spécifique – un morceau de papier ou une section d’une page web.

2. Divisez l’espace restant en quatre colonnes égales.

3. De là, il suffit de relier les points : du sommet de la première colonne au bas de la suivante ; du bas de la deuxième colonne au sommet de la troisième ; et ainsi de suite, jusqu’à ce que le « W » soit complet (FIG 5.9).

Voilà un framework dans tous les sens du terme, mais un framework beaucoup plus léger que ceux que nous utilisons sur le Web. Il porte moins sur l’exécution – la mise en page d’éléments spécifiques ou l’arrangement de lignes et de colonnes – et cherche plutôt à définir les caractéristiques d’un résultat souhaité : à modeler les conditions de la réussite. Et avec tous les défis que nous devons relever – et ceux qui nous attendent, c’est un excellent modèle pour les types de frameworks dont nous avons vraiment besoin sur le Web.

J’ai une anecdote qui pourrait bien être pertinente. C’est l’histoire de deux artistes, d’un garçon qui rêvait et de dessins qui bougeaient.

FIG 5.10 : La bande dessinée Little Nemo in Slumberland de Winsor McKay est stupéfiante, même plus d’un siècle après sa publication. Et par chance, elle est disponible gratuitement sur l’Internet Archive (http://bkaprt.com/rdpp/05-08/).

FIG 5.11 : Pour son premier court-métrage animé, Winsor McKay a adapté Little Nemo à l’écran. Image extraite d’une vidéo YouTube (http://bkaprt.com/rdpp/05-09/)

Au début du XX^5 siècle, le dessinateur Winsor McCay était l’un des artistes les plus distribués aux États-Unis. Son chef d’œuvre, Little Nemo in Slumberland, avait rencontré un énorme succès, et à raison : ses bandes dessinées en grand format regorgeaient de couleurs et de détails, avec des mises en scène cinématographiques qui n’avaient plus leur place dans les pages des journaux modernes (FIG 5.10).

Inspiré semble-t-il par les flipbooks de son fils, McCay a décidé d’essayer de créer des « images en mouvement ». Dans son premier essai, qui a nécessité plus de quatre mille images méticuleusement dessinées à la main, on peut voir les personnages de Little Nemo en train de danser, de se battre et de fumer le cigare (FIG 5.11). Au fil des dix années suivantes, McKay a créé dix films dans son style inimitable, animant ses dessins avec amour. Et chacun d’entre eux est une petite merveille (FIG 5.12).

FIG 5.12 : Les films artisanaux de McKay font partie des tout premiers dessins animés et couvrent des sujets qui vont du légèrement macabre (http://bkaprt.com/rdpp/05-10/) au carrément adorable (http://bkaprt.com/rdpp/05-11/), en passant par le dramatique The Sinking of the Lusitania (http://bkaprt.com/rdpp/05-12/).

Je ne crois pas déconsidérer les efforts de McCay en faisant remarquer que son animation est un peu rudimentaire. Avec notre regard moderne, on devine facilement où les images ont été réutilisées ou inversées, permettant à McCay d’économiser un peu ses efforts, et les mouvements de ses personnages sont souvent un peu mécaniques. Ce n’est pas une critique – avec d’autres animateurs comme Émile Cohl, James Stuart Blackton et Max Fleischer, McCay a joué un rôle de premier plan dans les débuts de l’animation.

Mais c’est seulement lorsque Walt Disney a fondé un studio, plusieurs décennies plus tard, que les gens ont commencé à considérer l’animation comme une forme d’expression artistique sérieuse. Cela peut sembler un peu exagéré, mais c’est vrai : l’animation des personnages de Disney était d’une élégance inégalée jusqu’alors. Marc Davis, l’un des premiers animateurs du studio, disait que lorsque Walt Disney a lancé son studio, « on faisait déjà de l’animation, mais on ne racontait jamais d’histoires ». Davis descend gentiment tous ceux qui se sont essayés à l’animation avant Disney, mais je crois qu’il y a une part de vérité. Pour être honnête, il est difficile d’exagérer l’effet que le travail du studio a eu sur le public. Une fois que ces dessins simples étaient colorisés et animés, ils paraissaient réels. Ils paraissaient humains. Et cela ne s’était jamais vraiment produit auparavant.

Le succès du studio était dû, en partie, à Disney lui-même, mais ce n’était pas parce qu’il était un animateur plus talentueux que ses employés ou ses concurrents. C’est plutôt parce qu’il était un réalisateur extrêmement exigeant ; il exigeait que les animations produites par son studio présentent une « caricature de réalisme » ou une « illusion de vie » à laquelle son public pouvait se rattacher et s’identifier. Quelques décennies plus tard, deux des animateurs d’origine de Disney, Frank Thomas et Ollie Johnston, ont emprunté cette phrase pour en faire le titre de leur merveilleux livre, The Illusion of Life. Dans celui-ci, Thomas et Johnston définissent ce qu’ils appellent « Les douze principes de base de l’animation », qui permettaient aux animateurs de Disney de répondre aux exigences plutôt strictes de Walt. Ces principes – abordant des concepts d’animation comme la mise en scène, le timing, les arcs, etc. – constituaient la base du travail du studio et sont devenus le fondement de ce que nous considérons comme de l’animation de qualité à l’époque moderne (FIG 5.13).

FIG 5.13 : Les principes d’animation de Disney ont été récemment adaptés par Cento Lodigiani en un petit guide animé qui les démontre en toute simplicité (http://bkaprt.com/rdpp/05-13/). Image extraite d’une vidéo sur Tumblr (http://bkaprt.com/rdpp/05-14/)

Sur une note personnelle, je ne peux que vous recommander le livre de Thomas et Johnston – c’est une lecture fabuleuse, surtout pour un livre aussi technique. Mais si vous manquez de temps, vous trouverez une version paraphrasée de leurs principes sur leur site web (http://bkaprt.com/rdpp/05-15/). En les lisant, vous remarquerez que ces principes ne sont pas particulièrement techniques. Plutôt que d’employer un jargon obtus, ils expliquent comment juger si un dessin possède ou non cette illusion de vie qui définissait le travail de Disney. Est-ce que le bras d’un personnage « anticipe » correctement le fait qu’il s’apprête à lancer un ballon ? Est-ce que la démarche d’un personnage présente suffisamment de « compression et d’étirement » alors qu’il traverse l’écran ?

Ces principes formaient une sorte de vocabulaire commun qui permettait aux animateurs du studio de s’assurer que leur travail réponde aux fameuses exigences de Disney. Plutôt que d’imposer l’usage de certaines techniques d’animation ou de mettre l’accent sur certaines étapes dans leur workflow de production, ces principes permettaient au studio de discuter et d’évaluer la qualité de son travail.

Ces dernières années, nous avons appris à adapter nos mises en page à la toile infinie du Web. Nos sites peuvent être visualisés sur n’importe quel écran, à n’importe quel moment, et le responsive design est une approche qui nous permet de nous adapter au format variable du Web. Mais face à tous ces défis présents et à venir, nous devons commencer à construire non plus seulement des patterns, mais des principes de responsive design – des principes qui nous aideront à nous focaliser non seulement sur la mise en page, mais aussi sur la qualité de notre travail.

Si chaque partie de votre interface responsive est plus ou moins autonome – avec ses propres règles de présentation, besoins en contenu et points de rupture – accordez moins d’importance au code de chaque élément et songez soigneusement à comment et pourquoi un élément doit s’adapter. En d’autres termes, comment pouvons-nous cesser de penser en termes de lignes et de colonnes, et commencer à parler de la qualité de nos designs responsive ? Et à quoi ressembleraient des frameworks qui viendraient appuyer ce travail ?

TROUVER LES MOTS

Honnêtement, il n’y a aucune réponse parfaite à cette question. Mais récemment, un certain nombre de designers et d’organisations ont commencé à partager le vocabulaire qu’ils utilisent pour déterminer comment et quand leurs designs responsive doivent s’adapter. Vox Media, par exemple, imagine son contenu s’écoulant dans une rivière – et pour filer la métaphore, le flot de ce contenu peut être interrompu à certains endroits. Voici comment Vox Media décrit les pages de garde de Vox.com (http://bkaprt.com/rdpp/05-16/) :

Le contenu s’écoule autour de « rochers » et de « brisants », qui sont des modules tels qu’une liste des articles les plus commentés ou une colonne de vidéos populaires. Bon nombre de ces comportements se retrouvent dans le nouveau système de mise en page, mais la différence principale est l’ajout d’une couche contextuelle. Les éléments de la rivière sont agencés de sorte à mieux mettre en évidence la diversité du contenu sur Vox – articles, reportages, vidéos, applications éditoriales, piles de cartes, pour en nommer quelques-uns. Chacun s’affiche différemment selon son type et les éléments qui l’entourent.

Nulle mention de lignes, de colonnes ou de grilles. Pour Vox, le processus de design commence par la priorisation du contenu, et évolue en une mise en page. En mesurant le poids et l’importance de chaque élément de contenu qui s’écoule dans la rivière, l’équipe de Vox peut générer de façon algorithmique une mise en page responsive qui reflète au mieux l’importance des informations qu’elle contient.

Commencer avec un système abstrait de lignes et de colonnes ne leur conviendrait pas – ni à aucun autre web designer, selon moi. Après tout, d’après Mark Boulton, un système de grille présente trois avantages fondamentaux (http://bkaprt.com/rdpp/05-17/) :

• Les grilles créent de l’interconnexion. Une grille bien conçue peut relier visuellement des morceaux de contenu apparentés, mais aussi séparer les éléments de contenu sans rapport, ce qui est tout aussi important. En d’autres termes, les grilles nous aident à créer une narration à partir de notre mise en page.

• En établissant des points d’alignement prédéfinis, les systèmes de grille aident les designers à résoudre leurs problèmes de mise en page.

• Un système de grille bien conçue sert de guide visuel au lecteur, et lui permet de mieux comprendre la hiérarchie visuelle.

Comme le fait remarquer Boulton, nous avons à l’origine créé les systèmes de grille en adoptant une méthode dite « canvas in ». En partant des bords de la page, les designers subdivisaient la page en un système de colonnes et de lignes, et plaçaient des images et du texte sur cette grille en un agencement plaisant et rationnel. Mais le Web n’a aucune limite de ce genre – après tout, c’est le premier support de design véritablement fluide. Par conséquent, Boulton soutient que nous devrions plutôt adopter une approche « content out » pour concevoir nos grilles : construire des systèmes de mise en page plus complexes à partir d’une base de petits éléments de contenu modulaires. Et pour cela, Boulton propose trois principes directeurs :

• Définir les relations de votre contenu. Une grille pour le Web doit être définie par le contenu, pas par le bord d’une page imaginaire.

• Utiliser des proportions ou des mesures relatives plutôt que des mesures fixes.

• Rendre le contenu indépendant du type d’appareil. Utiliser des media queries CSS et des techniques telles que le responsive design pour créer des mises en page qui répondent au viewport.

En comprenant la forme de notre contenu, nous pouvons créer des mises en page flexibles qui facilitent l’interconnexion – non seulement entre les informations connexes, mais aussi entre nos mises en page et l’appareil. Nous pouvons créer des systèmes de grille responsive qui ne se contentent pas de s’adapter à un nombre d’écrans en perpétuelle augmentation, mais qui fonctionnent naturellement, où que vous les utilisiez.

TROUVER LES COUTURES

Les principes sont merveilleux, mais encore faut-il trouver un moyen de les mettre en œuvre ; de traduire ces idéaux en modèles et en mises en page responsive pratiques. Pour moi, ce processus « content out » commence en regardant la plus petite version d’un élément de contenu, puis en l’élargissant jusqu’à ce que ses coutures commencent à se défaire et qu’il commence à perdre sa forme. Lorsque cela se produit, c’est le moment d’effectuer un changement – d’introduire un point de rupture qui remodèle l’élément tout en préservant son intégrité.

Mais tout d’abord, nous avons besoin d’une méthode pour trouver les coutures d’un élément et comprendre comment il perd sa forme. Pour moi, ce processus démarre en observant quatre caractéristiques : la largeur, la hiérarchie, l’interaction et la densité.

Largeur

Ce point n’a rien de mystérieux. La largeur d’un design responsive change à mesure que la largeur du viewport change. Mais les éléments du design sont eux aussi redimensionnés, et à mesure que ces modules s’élargissent ou se contractent, des points de rupture peuvent se manifester (FIG 5.14).

Hiérarchie

La largeur est, vous en conviendrez, la caractéristique la plus courante d’un design responsive – mais ce n’est pas la seule. À mesure que la forme d’un élément change, il est possible que la hiérarchie des éléments doive changer elle aussi.

FIG 5.14 : Sur son magnifique portfolio responsive, Meagan Fisher ajuste la typographie de certains éléments – et pas seulement leur mise en page – à mesure qu’ils grandissent ou rétrécissent (http://bkaprt.com/rdpp/05-18/).

Jetons un œil à un page produit sur le site de vente en ligne responsive de Tattly (http://bkaprt.com/rdpp/05-19/). Lorsqu’elle est visualisée sur un grand écran, la zone de contenu principale comprend deux informations clés : un carrousel de photos présentant le produit sur la gauche, et un appel à acheter le produit sur la droite (FIG 5.15). Mais ce n’est qu’une vue de cette partie particulière du design, car à mesure que l’écran rétrécit, nous perdons la capacité à placer plusieurs colonnes côte à côte. C’est là qu’un problème de hiérarchie se pose : dans une mise en page sur une seule colonne, quel contenu doit apparaître en premier ? Tattly a choisi, à raison, de mettre les photos du produit en premier – mais vous pouvez choisir de répondre aux questions de hiérarchie différemment sur votre propre site (FIG 5.16).

FIG 5.15 : Sur le site de vente en ligne responsive de Tattly, le contenu du produit est présenté sur une grille à deux colonnes agréable sur les grands écrans.

FIG 5.16 : Sur les viewports plus étroits, la hiérarchie des informations change, car celles-ci passent sur une colonne.

La hiérarchie sert généralement à nous rappeler que nous devons prêter attention à la verticalité de nos designs. Après tout, nous avons les media queries min-width et max-width, mais nous pourrions aussi utiliser les media queries min-height et max-height plus souvent. Je trouve que le menu de navigation du Field Museum (http://bkaprt.com/rdpp/05-20/) équilibre parfaitement mises en page horizontale et verticale (FIG 5.17). Sur les écrans plus larges, la navigation est ancrée à gauche de la page, et couvre toute la hauteur du viewport. Vous remarquerez peut-être que le site utilise le modèle de boîte flexible, ou flexbox, une méthode de mise en page en CSS avancée que nous aborderons dans la suite de ce chapitre (http://bkaprt.com/rdpp/05-21/). Mais comme la flexbox permet aux éléments de remplir automatiquement l’espace dont ils disposent, à mesure que le menu grandit ou rétrécit, les éléments de navigation se redimensionnent verticalement ; mais en dessous d’une certaine hauteur ou d’une certaine largeur, le menu est placé au sommet de la page.

FIG 5.17 : La navigation responsive du Field Museum, qui occupe toute la hauteur du design. En dessous d’une certaine largeur, elle passe au sommet de l’écran pour éviter d’être coupée.

En prenant en compte les rebords verticaux de la navigation, le Field Museum a créé un système de mise en page alternatif qui garantit que le contenu du menu de navigation n’est jamais masqué, voilé ou coupé. En d’autres termes, les points de rupture que nous introduisons dans nos designs responsive ne sont pas liés à la forme de l’écran d’un appareil. Au lieu de cela, nos media queries défendent l’intégrité du contenu que nous concevons.

Interaction

Notre façon d’interagir avec un élément peut changer avec le design. Les systèmes de navigation responsive en sont probablement l’exemple le plus flagrant. Comme nous l’avons vu au chapitre 2, les menus sont souvent affichés au complet sur les points de rupture les plus larges, mais masqués sur les plus petits viewports, parfois derrière des icônes ou des liens lorsque l’espace se fait rare (FIG 5.18).

FIG 5.18 : Le site de l’entreprise de Karen McGrane offre une navigation traditionnelle sur les points de rupture plus larges, mais sur les plus petits viewports, c’est à l’utilisateur d’afficher ou de masquer le menu. Mêmes liens, nouveau modèle d’interaction (http://bkaprt.com/rdpp/05-22/)

Mais la navigation n’est pas le seul type de contenu qui peut nécessiter des changements d’interaction. Par exemple, prenez les tableaux de compétition responsive conçus par SB Nation (http://bkaprt.com/rdpp/05-23/). Sur les grands écrans, ces tableaux ont l’air complexes, mais une vue plus simple et linéaire des tableaux est affichée sur les petits écrans (FIG 5.19). En plus de la mise en page simplifiée, les tableaux sont présentés sous la forme de carrousels sur les petits écrans, là où l’espace vient à manquer. Chacune des quatre régions du tableau correspond à une image du carrousel, permettant à l’utilisateur de parcourir la liste pour plus de détails. Les informations sont identiques dans les deux modes visuels, mais le modèle d’interaction change.

FIG 5.19 : Je ne connais rien au sport, mais j’aime les tableaux de compétition responsive de SB Nation : un format complexe sur grand écran, mais un carrousel de rencontres sur les petits viewports. Mêmes informations, interaction différente.

Densité

Enfin, la quantité d’informations que vous affichez dans un élément peut varier, ou si vous préférez, la densité des informations peut changer. Le reportage du Guardian sur les Oscars 2015 regorge d’exemples du type, avec des frises chronologiques responsive qui affichent une quantité considérable de données sur les films. Au-delà d’une certaine largeur, des images miniatures sont chargées, augmentant légèrement la densité visuelle (et informationnelle) de la frise (FIG 5.20).

La densité est, comme vous l’aurez peut-être deviné, un domaine dans lequel vous devez faire preuve de beaucoup de prudence. Comme nous l’avons vu auparavant, supprimer ou masquer des informations qui ne tiennent pas sur la page peut s’avérer problématique (FIG 5.21). Personnellement, je pense que si les frises chronologiques du Guardian fonctionnent aussi bien, c’est parce que les images affichées sur les viewports plus larges sont des améliorations : elles ne sont pas essentielles pour comprendre les informations. Auraient-ils pu concevoir des versions alternatives des frises pour afficher les images sur tous les points de rupture ? Peut-être. Mais je trouve que c’est un magnifique exemple d’utilisation de la densité pour alléger l’impact visuel d’un design, éliminant ainsi des informations superflues sans empêcher l’accès au contenu.

FIG 5.20 : Les frises chronologiques responsive du Guardian augmentent progressivement en densité, affichant une image supplémentaire au-delà d’une certaine largeur (http://bkaprt.com/rdpp/05-24/).

FIG 5.21 Tattly masque complètement ses sous-menus, réduisant sa navigation à une liste de sections principales sur les plus petits écrans.

FIG 5.22 : Sept, dérives et pincements – Nathan Ford suggère un différents endroits où votre design est susceptible de se dégrader (http://bkaprt.com/rdpp/05-25/).

FIG 5.23 : Le tableau de bord responsive d’Editorially utilisait un framework personnalisé et léger pour créer des points de rupture adaptés au contenu.

FAÇONNER NOS COUTURES : AU-DELÀ DES CLASSES

La largeur, la hiérarchie, l’interaction et la densité fonctionnent extrêmement bien pour identifier les limites extérieures de nos minuscules systèmes de présentation, mais vous voudrez peut-être leur adjoindre d’autres concepts. Récemment, le designer Nathan Ford a suggéré un certain nombre de modèles utiles pour identifier à quel moemnt les relations entre éléments commencent à se désagréger, incluant des anti-modèles de mise en page comme les sept, les dérives et les pincements (FIG 5.22). Mais quelle que soit la façon dont vous choisissez de trouver les coutures de votre mise en page, vous gagnerez considérablement en flexibilité en allant au-delà des simples classes de balisage.

Editorially, un service web (malheureusement défunt) pour écrivains et éditeurs que j’ai cofondé, utilisait un framework de mise en page personnalisé pour les parties les plus complexes de son interface. L’exemple le plus visible de celui-ci se trouvait sur le tableau de bord d’Editorially, qui affichait une liste de documents détenus et partagés par l’utilisateur (FIG 5.23). Faisant partie de l’équipe qui a conçu le tableau de bord, j’ai commencé par une mise en page adaptée aux petits écrans : une série de tâches et de contenus, agencée verticalement en une grille hiérarchisée sur une seule colonne (FIG 5.24).

Un site basé sur une mise en page adaptée aux mobiles est le signe d’un design responsive conçu de façon responsable – mais nous ne sommes pas obligés de nous arrêter à une colonne. Par exemple, lorsque le tableau de bord d’Editorially atteignait une largeur de 31em, il passait sur deux colonnes, grâce à un petit bout de CSS (FIG 5.25) :

@media screen and (min-width: 31em) {

/* Fixer les largeurs */

.doc-cell {

float: left;

width: 47.602739726027397260%;

/* 278px / 584px */

}

/* Construire la nouvelle mise en page */

.doc-cell:nth-child(2n) {

margin-right: 0;

}

.doc-cell:nth-child(2n+1) {

clear: left;

}

}

FIG 5.24 : La base de la mise en page d’Editorially ? Une grille sur une seule colonne.

FIG 5.25 : Avec la pseudo-classe :nth-child() et un peu de magie, nous pouvons rapidement créer une mise en page sur deux colonnes.

Attendez, qu’est-ce qui vient de se passer ? Trois sélecteurs, et nous avons une nouvelle grille de mise en page ? Ouaip, et tout ça grâce à la pseudo-classe :nth-child(). Au lieu de nous appuyer sur un framework CSS qui nécessite d’utiliser des classes HTML pour décrire notre mise en page, :nth-child() nous offre un moyen incroyablement puissant de traiter des éléments spécifiques de notre design en fonction de leur position dans la structure de notre document. Par exemple, si j’écris .doc-cell:nth-child(4), mon CSS sélectionnera le quatrième élément .doc-cell dans son élément parent :

<div class="doc-grid">

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

</div>

De même, si j’écris .doc-cell:nth-child(2), ma règle sélectionnera le deuxième élément .doc-cell de notre grille :

<div class="doc-grid">

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

<div class="doc-cell">…</div>

</div>

Ça a l’air plutôt simple, non ? Eh bien, les choses deviennent vraiment intéressantes lorsque n fait son apparition dans :nth-child(). La variable n sert de compteur : sa valeur part de zéro, puis elle est incrémentée d’un à chaque tour. Ainsi, :nth-child(2n) devient une simple multiplication : multipliez simplement la valeur de n par le nombre qui y est adjoint, puis ajoutez un à n et répétez le processus.

2 × 0 = 0

2 × 1 = 2

2 × 2 = 4

2 × 3 = 6

…

Dans notre CSS ci-dessus, .doc-cell:nth-child(2n) permet de sélectionner chaque cellule de notre grille présentant un chiffre pair, qu’il y en ait vingt ou vingt mille. Une fois que nous avons effectué cette sélection, nous appliquons la règle margin-right: 0; pour nous assurer qu’une cellule sur deux de notre grille à deux colonnes soit alignée sur le bord droit de la page.

Le sélecteur .doc-cell:nth-child(2n+1), lui, sélectionne aussi une cellule sur deux – mais le +1 indique que nous devons partir de un, et non de zéro. Le calcul ressemble à cela :

(2 × 0) + 1 = 1

(2 × 1) + 1 = 3

(2 × 2) + 1 = 5

(2 × 3) + 1 = 7

…

FIG 5.26 : Un autre point de rupture, une autre grille de mise en page : cette fois-ci, trois colonnes avec :nth-child(3n).

Ainsi, le sélecteur .doc-cell:nth-child(2n+1) applique la règle clear: left à chaque cellule présentant un chiffre impair, afin de faire en sorte que les deux documents soient joliment regroupés sur chaque ligne (FIG 5.25).

En utilisant nth-child() plutôt que des classes spécifiques présentes dans notre balisage, on peut rapidement – radicalement – réviser la mise en page de la grille à chaque point de rupture. Par exemple, à mesure que le viewport du tableau de bord s’élargit, on peut introduire une mise en page à trois colonnes au point de rupture 44em (FIG 5.26).

/* 3 colonnes */

@media screen and (min-width: 44em) {

/* Fixer les nouvelles largeurs */

.doc-cell,

.doc-cell:nth-child(n) {

margin-right: 3.043968432919954904%; /* 27 /

887 (per comp) */

width: 31.003382187147688838%;

/* 278px / 887px (per comp) */

}

/* Réinitialiser le clear du point de rupture précédent */

.doc-cell:nth-child(n) {

clear: none;

}

/* Construire la nouvelle mise en page */

.doc-cell:nth-child(3n) {

margin-right: 0;

}

.doc-cell:nth-child(3n+1) {

clear: left;

}

}

Cette media query peut paraître un peu complexe, mais elle répète simplement le processus de notre mise en page à deux colonnes.

1. De nouvelles largeurs et marges flexibles sont affectées aux éléments doc-cell de notre grille.

2. Nous pouvons utiliser :nth-child(n) pour réinitialiser les styles hérités des points de rupture précédents. (Dans ce cas, nous supprimons la règle clear: left; appliquée au début de chaque ligne.)

3. Nous utilisons ensuite :nth-child(3n) pour supprimer la marge de droite d’une cellule sur trois dans notre tableau de bord.

4. Enfin, :nth-child(3n+1) indique à la première cellule de chaque ligne à trois colonnes d’effacer les cellules qui la précèdent.

FIG 5.27 : Tout est possible : un balisage léger et un CSS puissant permettent de transformer nos grilles responsive en une mise en page à quatre, cinq et enfin six colonnes. (Et théoriquement, autant de colonnes que nous le souhaitons.)

Vous voyez où je veux en venir. Au fil du temps, le tableau de bord d’Editorially a évolué d’une grille à une colonne en des variantes à deux, puis trois colonnes, jusqu’à une mise en page finale à six colonnes (FIG 5.27). Pour être réalistes, nos seules contraintes étaient le temps et les ressources investis dans le design. En sortant la logique de présentation du balisage pour l’introduire dans le CSS, nous avons gagné infiniment plus de flexibilité (FIG 5.28).

Et par chance, il n’y a pas que :nth-child(). Nous avons une tonne d’outils de présentation tout aussi agiles mis à notre disposition par la spécification CSS. Flexbox, qui place les éléments en piles horizontales ou verticales, est l’un des plus populaires. L’en-tête du blog de Frank Chimero en est un merveilleux exemple. En ajoutant la règle display: flex dans l’en-tête, les deux éléments qu’il contient – la navigation et son logo – sont immédiatement agencés à l’horizontale, chaque élément devenant une colonne qui occupe toute la largeur de cette ligne (FIG 5.29).

FIG 5.28 : Les pages d’index de notre site Responsive Design Podcast utilisent un framework de mise en page similaire basé sur :nth-child() (http://bkaprt.com/rdpp/05-26/).

FIG 5.29 : Le joli site responsive de Frank Chimero inclut une petite flexbox dans sa mise en page (http://bkaprt.com/rdpp/02-27/).

Hypothétiquement, si Chimero le souhaitait, il pourrait inverser l’ordre des deux éléments en ajoutant la règle flex-direction: row-reverse dans l’en-tête – le tout sans toucher au balisage (FIG 5.30). C’est un peu comme un changement de gravité : les deux éléments sont toujours alignés, mais leur ordre est instantanément inversé.

FIG 5.30 : En changeant la propriété flex-direction d’une boîte flexible, vous pouvez rapidement inverser l’ordre des éléments qu’elle contient.

FIG 5.31 : La documentation de la plateforme Chrome (http://bkaprt.com/rdpp/05-27/), la conférence ConvergeSE (http://bkaprt.com/rdpp/05-28/) et le Guardian (http://bkaprt.com/rdpp/05-29/) : tous trois de superbes exemples d’une flexbox appliquée avec amour à une mise en page multiappareils.

Ces modèles de mise en page plus légers sont devenus incroyablement populaires et ont été adoptés par un certain nombre de designs responsive (FIG 5.31). Mais si flexibles soient-ils, flexbox et :nth-child() ne présentent pas que des avantages. Comme le fait remarquer Jake Archibald, la flexbox est idéale pour les mises en page à petite échelle, mais peut avoir des répercussions négatives sur le rendu de la page si elle est utilisée sur une page entière (http://bkaprt.com/rdpp/05-30/). Par ailleurs, certaines de ces propriétés ne fonctionneront pas dans les vieux navigateurs – :nth-child() n’est pas pris en charge par Internet Explorer 8 et les versions antérieures, et display: flex ne fonctionnera pas du tout dans IE9 et les versions antérieures. (Et curieusement, il existe différentes implémentations de flexbox dans IE10, Safari et de nombreuses versions d’Android.)

Mais si nous prenons ces considérations à cœur, et si nous concevons des méthodes alternatives pour les navigateurs qui en ont besoin, ces outils de mise en page légers nous permettent de concevoir des systèmes de grille de dimensions pratiquement infinies. En nous éloignant des points de rupture spécifiques aux appareils et en adaptant nos systèmes de mise en page en fonction de l’emplacement de leurs coutures, nous pourrons créer des mises en page plus robustes et évolutives. En d’autres termes, nous serons mieux préparés pour les appareils et les navigateurs du futur.

LES COUTURES INTÉRIEURES

Et c’est bien là le point sensible, non ? Nous sommes rendus bien loin de l’ordinateur de bureau, mais nous peinons encore à trouver les mots qui englobent toute l’envergure de ce que nous concevons et les contextes pour lesquels nous concevons. Malgré cette évolution majeure, les trois mots que j’entends le plus souvent sur un projet responsive – « mobile », « tablette » et « ordinateur » – sont également les moins utiles. Ce ne sont pas littéralement de mauvais mots, mais ils ne sont que des raccourcis qui masquent bien souvent les défis de design auxquels nous faisons face.

Par exemple, demandez à un collègue de décrire ce que « mobile » veut dire pour lui. Selon la personne à qui vous posez la question, ce terme évoquera peut-être un petit appareil tactile qui utilise un réseau cellulaire plus lent pour accéder au Web. Mais qu’en est-il si l’appareil en question est connecté à un réseau Wi-Fi ? De même, « ordinateur » peut évoquer un appareil à grand écran, disposant d’une souris ou d’un pavé tactile. Mais que dire d’un ordinateur portable relié à la connexion 3G d’un téléphone ? Ou d’un ordinateur qui dispose également d’une interface tactile ?

FIG 5.32 : Design responsive au poignet : le joli site responsive de GOV.UK rendu sur une smartwatch Moto 360. Captures d’écran reproduites avec l’aimable permission d’Anna Debenham.

En d’autres termes, le problème n’est pas que nous devions concevoir pour de plus en plus d’appareils différents, mais plutôt que la frontière entre « mobile », « tablette » et « ordinateur » est de plus en plus floue : nous avons des téléphones qui font pratiquement la taille d’une petite tablette (et vice versa) ; nos sites peuvent être consultés sur une smartwatch, avec un viewport presque aussi grand que sur bon nombre de smartphones (FIG 5.32) ; et puis tant qu’on y est, il existe même des voitures qui ont un navigateur intégré dans leur tableau de bord (FIG 5.33).

Voilà quelques-unes des raisons pour lesquelles je préfère parler de fonctionnalités, plutôt que de classes d’appareils. Par exemple, lorsque je présente un design responsive à un client, je lui explique généralement comment celui-ci fonctionne sur différentes catégories d’appareils, mais en me focalisant sur les modes de saisie, la taille de l’écran, la vitesse du réseau et l’état du réseau (FIG 5.34).

FIG 5.33 : Facebook au volant, mort au tournant : La Model S, voiture électrique de Tesla, dispose d’un écran tactile qui inclut un navigateur WebKit. Photographie de Chris Martin (http://bkaprt.com/rdpp/05-31/)

FIG 5.34 : Plutôt que de parler de classes d’appareils, il est préférable de se focaliser sur les fonctionnalités et les conditions susceptibles d’affecter votre design responsive.

Évidemment, cette liste n’est pas exhaustive : un projet riche en animations devra peut-être ajouter une ligne indiquant la qualité du processeur graphique de chaque appareil, un autre exigera des options plus détaillées pour décrire les conditions du réseau. Et ma ligne de modes de saisie est souvent trop succincte – il vous arrivera peut-être de concevoir pour des interfaces gestuelles, des appareils dotés de pavés directionnels tels qu’une télécommande ou une manette de jeu, ou encore des écrans à stylet.

Mais un tableau de ce type me permet de dissocier les discussions touchant à la mise en page et à la taille de l’écran des questions liées à la qualité du réseau de l’utilisateur, ou au mode de saisie qu’il utilise pour interagir avec son appareil, par exemple. Ainsi, je peux éviter de me retrouver dans une situation où l’on suppose que tous les appareils à grand écran disposent d’une souris, ou que tous les petits appareils n’ont accès à rien de mieux qu’une connexion 3G intermittente.

Dans ce livre, vous aurez appris à décomposer la page en ses éléments constitutifs, compris comment nos petits systèmes de présentation doivent s’adapter, puis vu comment utiliser ces modules pour créer des systèmes de mise en page responsive de plus en plus complexes. Nos mises en page sont de plus en plus flexibles et de moins en moins rattachées à des appareils spécifiques, et les mots que nous employons pour parler de nos designs responsive doivent suivre l’exemple. Car si nous voulons prendre en compte tous les contextes dans lesquels nos designs sont susceptibles d’être visionnés – les innombrables conditions de réseau, modes de saisie et tailles d’écrans – nous avons besoin d’un langage de design aussi maniable et modulaire que nos systèmes de présentation.

Après tout, ces défis n’ont rien de nouveau. En un sens, nous traversons la forêt depuis un certain temps déjà, et il nous reste un bout de chemin à parcourir. Mais à mesure que nous avançons, souvenons-nous que nous serons toujours entourés d’arbres, et que nous parviendrons toujours à construire des designs responsive flexibles et esthétiques.

Alors, au travail !

RESSOURCES

Bibliothèques de modèles responsive

Si vous souhaitez en apprendre davantage sur les organisations qui utilisent des bibliothèques de modèles dans leur design responsive, le Responsive Web Design Podcast, que j’anime avec Karen McGrane, comprend plusieurs épisodes qui sont susceptibles de vous intéresser. Les interviews avec Marriott (http://bkaprt.com/rdpp/06-01/), Code for America (http://bkaprt.com/rdpp/06-02/), Capital One (http://bkaprt.com/rdpp/06-03/ ; http://bkaprt.com/rdpp/01-16/), Virgin America (http://bkaprt.com/rdpp/02-23/) et Ushahidi (http://bkaprt.com/rdpp/06-04/) sont particulièrement pertinents.

Si vous vous intéressez au processus de développement d’un guide de style ou d’une bibliothèque de modèles, l’article « Creating Style Guides » de Susan Robertson (http://bkaprt.com/rdpp/06-05/) est une excellente introduction. Par ailleurs, le livre Front-end Style Guides d’Anna Debenham est aussi bien écrit que succinct, et offre une excellente introduction au pourquoi et au comment du développement d’une bibliothèque de modèles (http://bkaprt.com/rdpp/06-06/).

Et tant que nous parlons de Debenham : Anna anime avec Brad Frost le Style Guide Podcast, qui aborde les questions techniques, visuelles et organisationnelles de la conception et de l’entretien de bibliothèques de modèles (http://bkaprt.com/rdpp/06-07/).

Images responsive

Mat Marquis a écrit le premier article qui a lancé la discussion sur les images responsive, et il vaut le coup d’être lu (http://bkaprt.com/rdpp/06-08/). Si vous souhaitez en apprendre davantage sur les différentes parties de la spécification sur les images responsive, deux articles en particulier m’ont été précieux : « Responsive Images in Practice » d’Eric Portis (http://bkaprt.com/rdpp/06-09/) et « Native Responsive Images » de Yoav Weiss (http://bkaprt.com/rdpp/06-10/).

Et pour finir, l’excellent Design web responsive et responsable, de Scott Jehl, aborde les éléments picture, srcset et sizes en détail, mais explique également pourquoi ils sont si essentiels en matière de performances (http://bkaprt.com/rdpp/06-11/ ou http://www.editions-eyrolles.com/Livre/9782212143911/design-tactile pour l’édition française.).

Plus de modules de mise en page

Cet ouvrage était trop court pour y aborder toutes les merveilleuses techniques de mise en page qui s’offrent à nous. Le module de boîte flexible, ou « flexbox », a été brièvement abordé au chapitre 5. Pour en savoir plus, je vous recommande ce bref tour interactif (http://bkaprt.com/rdpp/06-12/), cette présentation du Mozilla Developer Network (http://bkaprt.com/rdpp/06-13/) ou cette documentation complète de CSS Tricks (http://bkaprt.com/rdpp/06-14/).

Comme je l’ai évoqué au chapitre 5, flexbox est idéal pour les détails d’une page, mais pas pour la page elle-même. Par chance, il existe un module CSS complet, CSS Grid Layout, qui permet de créer des grilles de mise en page. La spécification du module est dense, mais mérite d’être lue (http://bkaprt.com/rdpp/06-15/). Si CSS Grid Layout vous intéresse autant que moi, je vous recommande chaudement les ressources de Rachel Andrews (http://bkaprt.com/rdpp/06-16/ ; http://bkaprt.com/rdpp/06-17/) sur le sujet, ainsi que sa collection exceptionnelle d’exemples pour CSS Grid Layout (http://bkaprt.com/rdpp/06-18/).

Intérêt général

Si vous souhaitez en savoir plus sur Pius « Mau » Piailug, qui a traversé des océans avec le ciel pour seul repère, je vous conseille de lire cette page sur son voyage à Tahiti en 1976 (http://bkaprt.com/rdpp/06-19/), ou cet article du Smithsonian sur le profil des navigateurs traditionnels (http://bkaprt.com/rdpp/06-20/). Wikipedia offre également une excellente explication de sa boussole à étoiles et de son fonctionnement (http://bkaprt.com/rdpp/06-21/).

Si vous souhaitez plus d’informations sur Pando, l’arbre extraordinaire qui ouvre ce livre, le Web regorge de ressources. Commencez par Atlas Obscura (http://bkaprt.com/rdpp/06-22/) et découvrez ici pourquoi le futur de Pando risque d’être compromis par le changement climatique, la sécheresse, la maladie et les espèces invasives (http://bkaprt.com/rdpp/06-23/).

REMERCIEMENTS

Comme toujours, mes sincères remerciements à A Book Apart. Katel LeDû, Jeffrey Zeldman et Jason Santa Maria font partie des gens les plus brillants et inspirants que je connaisse. Ils ont bâti une maison d’édition fantastique, et je suis honoré que ce livre en fasse désormais partie.

Certes, j’étais enthousiaste à l’idée d’écrire ce livre ; mais quand Erin Kissane a accepté de l’éditer, c’était carrément l’extase. Outre son travail sur OpenNews, Erin est l’une des meilleures auteurs et éditrices que je connaisse. Elle a le don unique de savoir démêler les phrases les plus tarabiscotées, et répond aux questions stupides des auteurs avec grâce, patience et intelligence. Si vous avez apprécié ce livre, c’est vraisemblablement grâce à son coup de baguette magique.

Beaucoup de gens connaissent Mandy Brown pour ses écrits, ses designs frappants ou ses années passées à travailler avec des entreprises et des éditeurs. Peu de gens savent que Mandy est responsable de la propagation du responsive design auprès de son public actuel. Après avoir entendu ma première présentation sur le responsive design, elle m’a invité à écrire l’article original pour A List Apart ; environ un an plus tard, elle a édité et publié Responsive Web Design, mon premier livre en solo. Voilà pourquoi je suis plus qu’enchanté qu’elle ait accepté d’écrire l’avant-propos de ce livre.

J’ai eu l’honneur de travailler avec de nombreux éditeurs techniques, mais Anna Debenham fait partie des meilleures. Son feedback était à la fois brillant, stimulant et instructif. Ce livre a bénéficié considérablement de ses efforts incessants.

Livia Labate, Scott Jehl, Mat Marquis et Karen McGrane ont donné leur avis sur les premiers brouillons. J’ai une dette envers eux pour tout le temps, les conseils et l’amitié qu’ils m’ont accordés.

J’ai entendu parler de Pando pour la première fois lors d’une présentation de Matthew Battles à une mini-conférence organisée par Deb Chachra. Je leur en dois une à tous les deux.

J’ai gardé le plus important pour la fin : merci du fond du cœur à ma femme Elizabeth pour sa patience, son soutien et son amour. Ce livre, ainsi que tout le reste, lui est dédié.

RÉFÉRENCES

Les URL abrégées sont numérotées dans l’ordre ; les URL complètes sont listées ci-dessous à titre de référence.

Chapitre 1

01-01 https://commons.wikimedia.org/wiki/File:FallPando02.jpg

01-02 http://www.nps.gov/brca/naturescience/quakingaspen.htm

01-03 http://www.jstor.org/stable/1312652

01-04 http://trentwalton.com/2012/02/02/redefined/

01-05 http://www.fieldmuseum.org/

01-06 http://www.audubon.org/

01-07 http://cooking.nytimes.com/guides/how-to-make-pie-crust

01-08 http://laphamsquarterly.org/

01-09 http://www.microsoft.com/

01-10 https://www.virginamerica.com/

01-11 http://www.adobe.com/

01-12 https://www.gov.uk/

01-13 https://playbook.cio.gov/

01-14 http://www.google.com/trends/2014/

01-15 http://abookapart.com/products/responsive-web-design

01-16 http://responsivewebdesign.com/podcast/capital-one-part-two.html

01-17 http://responsivewebdesign.com/podcast/virgin-america.html

01-18 http://ushahidi.github.io/platform-pattern-library/

01-19 http://ux.mailchimp.com/patterns

01-20 http://www.starbucks.com/static/reference/styleguide/

01-21 http://patterns.alistapart.com/

01-22 https://commons.wikimedia.org/wiki/File:HMS_Dauntless_D33.jpg

01-23 http://us5.campaign-archive2.com/?u=7e093c5cf4&id=ead8a72012&e=ecb25a3f93

01-24 http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visual-networking-index-vni/white_paper_c11-520862.html

01-25 http://www.comscore.com/Insights/Blog/Is-Mobile-Bringing-About-the-Death-of-the-PC-Not-Exactly

01-26 http://www.pcmag.com/article2/0,2817,2375047,00.asp

01-27 http://ben-evans.com/benedictevans/2014/4/25/ipad-growth

01-28 http://recode.net/2014/07/30/exclusive-interview-best-buy-ceo-says-tablet-sales-are-crashing-sees-hope-for-pcs/

01-29 http://www.reuters.com/article/us-google-glass-insight-idUSKCN0IY18E20141114

01-30 https://play.google.com/store/apps/details?id=com.appfour.wearbrowser

01-31 https://www.youtube.com/watch?v=sGo08-SP_Ww

01-32 http://www.digitaltrends.com/computing/windows-8-1-preview-review/

01-33 http://www.ofcom.org.uk/static/cmr-10/UKCM-4.13.html

01-34 https://www.flickr.com/photos/anna_debenham/19700844223

01-35 http://www.ericsson.com/res/docs/2014/ericsson-mobility-report-november-2014.pdf

01-36 https://www.flickr.com/photos/ericsson_images/15626948657/in/set-72157649326666221

Chapitre 2

02-01 http://www.nlm.nih.gov/exhibition/avoyagetohealth/exhibition-legacy.html

02-02 http://happycog.com/

02-03 http://responsivenews.co.uk/post/18948466399/cutting-the-mustard

02-04 http://responsivenews.co.uk/post/50028612882/responsive-news-testing

02-05 https://github.com/filamentgroup/Overthrow/

02-06 http://www.lukew.com/ff/entry.asp?1514

02-07 https://web.archive.org/web/20130819090807/http://stephanierieger.com/a-plea-for-progressive-enhancement

02-08 https://github.com/filamentgroup/Ajax-Include-Pattern/

02-09 http://www.filamentgroup.com/lab/responsive-design-approach-for-navigation.html

02-10 https://developer.mozilla.org/en-US/Apps/Design/UI_layout_basics/Responsive_Navigation_Patterns

02-11 https://www.quora.com/Who-started-the-trend-of-using-the-hamburger-icon-%E2%98%B0-as-a-menu-button

02-12 http://www.bbc.com/news/magazine-31602745

02-13 https://raygun.io/blog/2014/07/making-svg-html-burger-button/

02-14 http://sarasoueidan.com/blog/navicon-transformicons/

02-15 http://time.com

02-16 http://exisweb.net/mobile-menu-abtest

02-17 http://thenextweb.com/dd/2014/04/08/ux-designers-side-drawer-navigation-costing-half-user-engagement/

02-18 http://blog.booking.com/hamburger-menu.html

02-19 http://blog.manbolo.com/2014/06/30/apple-on-hamburger-menus

02-20 http://www.lukew.com/ff/entry.asp?933

02-21 http://www.bbc.com/news

02-22 http://www.theguardian.com/help/insideguardian/2014/jul/11/-sp-navigating-the-guardian

02-23 http://responsivewebdesign.com/podcast/virgin-america.html

02-24 https://the-pastry-box-project.net/dan-mall/2012-september-12

02-25 http://blog.mailchimp.com/redesigning-mailchimps-app-navigation/

02-26 https://www.filamentgroup.com/

02-27 http://frankchimero.com/blog/

Chapitre 3

03-01 http://the.hitchcock.zone/wiki/Alfred_Hitchcock_and_Fran%C3%A7ois_Truffaut_%28Aug/1962%29_-_Part_2

03-02 http://clagnut.com/blog/268/

03-03 http://www.bbc.com/news/business-33436021

03-04 http://unstoppablerobotninja.com/entry/hand-over-the-ring/

03-05 http://thisismadebyhand.com/

03-06 http://alistapart.com/article/creating-intrinsic-ratios-for-video

03-07 http://www.w3.org/TR/css3-box/#padding1

03-08 http://www.paulirish.com/2008/conditional-stylesheets-vs-css-hacks-answer-neither/

03-09 http://virb.com/

03-10 http://vox.com/

03-11 http://httparchive.org/interesting.php?a=All&l=Jul%201%202015

03-12 http://googlesystem.blogspot.com/2010/07/googles-stats-about-web.html

03-13 http://blog.cloudfour.com/how-apple-com-will-serve-retina-images-to-new-ipads/

03-14 https://w3c.github.io/netinfo/

03-15 https://youtube.com/watch?v=d5_6yHixpsQ

03-16 http://www.gq.com/

03-17 http://digiday.com/publishers/gq-com-cut-page-load-time-80-percent/

03-18 http://ricg.io/

03-19 https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-srcset

03-20 https://html.spec.whatwg.org/multipage/embedded-content.html#introduction-3:viewport-based-selection-2

03-21 https://status.modern.ie/imgsrcset

03-22 https://github.com/scottjehl/picturefill

03-23 http://www.vox.com/2014/12/29/7458807/paul-krugman-economist

03-24 http://engineering.columbia.edu/model-created-map-energy-use-nyc-buildings

03-25 https://github.com/adamdbradley/focal-point

03-26 https://www.lars-mueller-publishers.com/node/4660

03-27 http://needmoredesigns.com/blog/early-responsive-design/

03-28 https://flic.kr/p/s7maT2

03-29 https://www.shopify.com/

Chapitre 4

04-01 http://depts.washington.edu/chinaciv/graph/tcommain.htm

04-02 http://www.teleactivities.com/advertising-history/

04-03 http://blogs.ubc.ca/etec540sept10/2010/11/29/the-evolution-of-advertising-from-papyrus-to-youtube/

04-04 http://espressocoffee.quora.com/Coffee-timeline-A-literary-record

04-05 http://www.web-books.com/Classics/ON/B0/B701/15MB701.html

04-06 https://commons.wikimedia.org/wiki/File:Times_1788.12.04.jpg

04-07 https://www.flickr.com/photos/nesster/5511185739/

04-08 https://www.flickr.com/photos/42072348@N00/3049739879/

04-09 https://www.flickr.com/photos/91591049@N00/16587189580/

04-10 https://www.flickr.com/photos/nesster/14959218130/

04-11 https://www.flickr.com/photos/nesster/4822903313/

04-12 http://www.iab.net/guidelines/508676/508767/displayguidelines

04-13 http://www.iab.net/guidelines/508676/508767/mobileguidelines

04-14 https://github.com/filamentgroup/AppendAround

04-15 http://product.voxmedia.com/2014/12/17/7405131/algorithmic-design-how-vox-picks-a-winning-layout-out-of-thousands

04-16 http://markboulton.co.uk/journal/responsive-advertising

04-17 http://rogerblack.com/blog/post/the_holy_grail_part_i

04-18 http://rogerblack.com/blog/post/the_holy_grail_part_2

04-19 https://www.thinkwithgoogle.com/research-studies/the-new-multi-screen-world-study.html

04-20 http://responsivewebdesign.com/podcast/vox.html

04-21 http://advertising.theguardian.com/gallery/

04-22 http://next.theguardian.com/blog/responsive-takeover/

04-23 http://htmlads.monotype.com/

04-24 https://support.google.com/adsense/answer/3543893

04-25 http://www.iab.net/iablog/2014/03/viewability-has-arrived-what-you-need-to-know-to-see-through-this-sea-change.html

04-26 http://www.thedrum.com/news/2014/02/25/mwc-advertisers-lag-behind-publishers-creating-responsive-design-experiences-says

Chapitre 5

05-01 http://trentwalton.com/2012/02/02/redefined/

05-02 http://responsivewebdesign.com/podcast/virgin-america.html

05-03 http://upstatement.com/blog/2012/01/how-to-approach-a-responsive-design/

05-04 http://getbootstrap.com/

05-05 http://foundation.zurb.com/

05-06 http://whitney.org/

05-07 http://www.experimentaljetset.nl/archive/whitney-museum-identity

05-08 https://archive.org/details/LittleNemo1905-1914ByWinsorMccay

05-09 https://www.youtube.com/watch?v=I-9FIFDHjLg

05-10 https://www.youtube.com/watch?v=1uLWbuButIE

05-11 https://www.youtube.com/watch?v=lmVra1mW7LU

05-12 https://www.youtube.com/watch?v=ws5kGs_J-CM

05-13 https://vimeo.com/93206523

05-14 http://the12principles.tumblr.com/

05-15 http://www.frankanollie.com/PhysicalAnimation.html

05-16 http://product.voxmedia.com/2014/12/17/7405131/algorithmic-design-how-vox-picks-a-winning-layout-out-of-thousands

05-17 http://www.markboulton.co.uk/journal/anewcanon

05-18 http://owltastic.com/

05-19 http://tattly.com/products/burger

05-20 http://www.fieldmuseum.org/

05-21 https://developer.mozilla.org/en-US/docs/Web/CSS/flex

05-22 http://www.bondartscience.com

05-23 http://www.sbnation.com/a/march-madness-2014

05-24 http://alistapart.com/article/content-out-layout

05-25 http://www.theguardian.com/film/ng-interactive/2015/feb/20/what-it-really-means-to-win-the-oscars-best-director

05-26 http://responsivewebdesign.com/podcast/

05-27 https://developer.chrome.com/home/platform-pillar

05-28 http://convergese.com/

05-29 http://www.theguardian.com/

05-30 http://jakearchibald.com/2014/dont-use-flexbox-for-page-layout/

05-31 https://www.flickr.com/photos/cjmartin/8916609941/

Ressources

06-01 http://responsivewebdesign.com/podcast/marriott.html

06-02 http://responsivewebdesign.com/podcast/code-for-america.html

06-03 http://responsivewebdesign.com/podcast/capital-one.html

06-04 http://responsivewebdesign.com/podcast/ushahidi.html

06-05 http://alistapart.com/article/creating-style-guides

06-06 http://maban.co.uk/projects/front-end-style-guides/

06-07 http://styleguides.io/podcast/index.html

06-08 http://alistapart.com/article/responsive-images-how-they-almost-worked-and-what-we-need

06-09 http://alistapart.com/article/responsive-images-in-practice

06-10 https://dev.opera.com/articles/native-responsive-images/

06-11 http://www.abookapart.com/products/responsible-responsive-design

06-12 http://www.flexboxin5.com/

06-13 https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Flexible_boxes

06-14 https://css-tricks.com/snippets/css/a-guide-to-flexbox/

06-15 http://www.w3.org/TR/css3-grid-layout/

06-16 http://rachelandrew.co.uk/presentations/css-grid

06-17 http://rachelandrew.co.uk/archives/2014/06/27/css-grid-layout-getting-to-grips-with-the-chrome-implementation/

06-18 http://gridbyexample.com/

06-19 http://pvs.kcc.hawaii.edu/holokai/1976/ben_finney.html

06-20 http://www.smithsonianmag.com/smithsonian-institution/how-voyage-kon-tiki-misled-world-about-navigating-pacific-180952478/?no-ist

06-21 http://en.wikipedia.org/wiki/Mau_Piailug

06-22 http://www.atlasobscura.com/places/pando-the-trembling-giant

06-23 http://www.smithsonianmag.com/science-nature/whats-killing-the-aspen-93130832/?all

INDEX

A

Adobe 11

AdSense 122

AIDS.gov 11

Ajax-Include 39

A List Apart 17, 164

API Network Information 83

AppendAround 117

Apple 51

Archibald, Jake 83

arrière-plans flexibles 76

attribut

sizes 82

srcset 82

B

Bale, Peter 122

bande passante faible 84

BBC News 29

Beamly 48

bibliothèque de modèles 16

Booking.com 49

Bootstrap 126

Boston Globe 39, 110, 117, 121, 125

Bottita, Tito 125

Boulton, Mark 118, 139

Bradley, Adam 94

Brigleb, Raymond 93, 94

Brundrett, Trei 120

C

Capital One 162

chargement conditionnel 105

Childs, Scott 15

Chimero, Frank 64, 155

CNN International Digital 122

Code for America 162

commentaire conditionnel 78

D

Davis, Marc 136

Debenham, Anna 162

déclarations document.write() 112

densité des informations 146

dévoilement progressif 53

Disney, Walt 136

E

Editorially 148

Ericsson 22

F

Ferreira, Michel 49

Field Museum 10, 143, 144

Filament Group 33, 39, 42, 62, 63, 117

Fisher, Meagan 142

Fishlake National Forest 7

FiveThirtyEight 36

flexbox 144, 157, 163

Ford, Nathan 148

Foster, James 48

Foundation 126

frameworks 126

G

Gerstner, Karl 93

Google 120, 122

GOV.UK 11

Grigsby, Jason 83

Guardian 40, 41, 57, 58, 59, 61, 65, 121, 122, 146, 147, 157

guide de style 16

H

hamburger 42

Happy Cog 25

hiérarchie des éléments 141

Holgado, Federico 17

HotWired 104

I

Interactive Advertising Bureau 103

iOS 51, 89

Irish, Paul 78

J

Johnston, Ollie 137

K

Koblentz, Thierry 71

L

L’année en recherches 13

Lapham’s Quarterly 10

Little Nemo in Slumberland 135

Lodigiani, Cento 137

M

Made By Hand 70

MailChimp 17

Mall, Dan 61

maquette 60

Marriott 162

McCay, Winsor 135

McGrane, Karen 145

menu

à chargement conditionnel 36

hors canvas 35

Microsoft 11, 21

mode de saisie 159

Monotype 122

Mozilla 42

MSNBC 34

Mulholland, Chris 57

musée Whitney 130

N

National Audubon Society 10

navigateur de poignet 19

New York Times 10

O

Ofcom 21

O’Reilly 104

overflow 33

Overthrow.js 33

P

Pando 7

Paravel 9

Photoshop 60

Piailug, Pius « Mau » 23

Publick Adviser 101

R

ratio d’aspect 72

redimensionnement responsable 82

Responsive Issues Community Group 84

Robertson, Susan 162

Rutter, Richard 66

S

SB Nation 145

Shopify 95

Sketch 60

Smashing Magazine 105

Starbucks 17

Stern, Mike 51

Stewart, Joe 16, 59, 60, 125

Stocks, Elliott Jay 106

studio d’animation Disney 136

style de secours 78

T

Tattly 141

Tesla 160

Thomas, Frank 137

Time 44

tiroir de navigation 49

U

Upstatement 125

US Digital Service 11

Ushahidi 17, 162

V

vidéo fluide 68

Virb 79

Virgin America 11, 162

Vox 80, 81, 91, 117, 118, 120, 139

W

Walmart.ca 36

Walton, Trent 9

Windows 8.1 21

Work & Co 59

Wroblewski, Luke 52

X

Xerox Star 42

Y

Young, Jesse 117

À PROPOS DE A BOOK APART

Nous couvrons les sujets émergents et essentiels du design et du développement web avec style, clarté et surtout brièveté – car les professionnels du design et du développement n’ont pas de temps à perdre !

À PROPOS DE L’AUTEUR

Auteur et designer indépendant, Ethan Marcotte vit à Boston, aux États-Unis. Il est à l’origine du terme « responsive web design », servant à décrire une nouvelle façon de concevoir sur un Web en constante évolution et a écrit l’ouvrage faisant autorité sur le sujet : Responsive web design (A Book Apart, n°4). Son travail de design, ses écrits et ses allocutions ont aidé de nombreux designers et organisations à exploiter la flexibilité du Web afin de concevoir à la fois pour les mobiles, les tablettes, les ordinateurs et tous les appareils qui pourraient voir le jour à l’avenir.

Depuis de nombreuses années, Ethan Marcotte intervient lors de nombreuses conférences, notamment An Event Apart, SXSW Interactive et Webstock. Parmi ses clients, il compte le New York Magazine, le festival du film de Sundance, le Boston Globe et People Magazine.

Pour suivre toutes les nouveautés numériques du Groupe Eyrolles, retrouvez-nous sur Twitter et Facebook

@ebookEyrolles

EbooksEyrolles

Et retrouvez toutes les nouveautés papier sur

@Eyrolles

Eyrolles