Qu’est-ce que le Res­pon­sive Design ?

Le Res­pon­sive Web Design consiste à dé­ve­lop­per un site Web qui s’affiche de manière optimale sur tous les appareils. Le terme Res­pon­sive Design est aussi vieux que le Web mobile et a commencé à être connu en 2013.

Avant l’avènement du Web mobile, le paysage des appareils com­pa­tibles avec Internet était très homogène : il y avait les or­di­na­teurs de bureau ou les or­di­na­teurs portables, qui étaient assez si­mi­laires en termes de supports d’entrée et de sortie. Les deux types d’appareils étaient dotés d’un clavier et d’une souris ou d’un trackpad, ainsi que d’un écran de 1 000 à 2 000 pixels de large.

À l’époque, nul besoin de déployer des efforts excessifs pour dé­ve­lop­per un site Web qui s’af­fi­che­rait cor­rec­te­ment sur la majorité des appareils utilisés. La solution la plus simple con­sis­tait à limiter la largeur des pages au plus petit dé­no­mi­na­teur commun. Pour cela, on faisait en sorte d’avoir des pages centrées ou alignées à gauche, avec une largeur de 800 pixels. Sur les écrans plus grands, cela révélait un peu plus d’espace blanc que né­ces­saire, mais les pages étaient fa­ci­le­ment lisibles sur tous les appareils.

Avec l’avènement des appareils mobiles, la situation a changé et on a assisté à une profonde di­ver­si­fi­ca­tion des supports. Les écrans de smart­phones et tablettes diffèrent sur plusieurs points : la taille des pixels joue un rôle important, ainsi que la ré­so­lu­tion (« pixels par pouce » ou ppi) apparue les écrans Retina. De plus, ces appareils ne se com­man­dent pas avec une souris, mais avec le doigt. Aujourd’hui, on retrouve également les grands écrans à haute ré­so­lu­tion, de sorte qu’un site Web moderne doit pouvoir s’adapter à des largeurs d’écran allant de 320 pixels à plus de 4 000 pixels.

Un Res­pon­sive Web Design s’adapte à l’espace dis­po­nible sur l’écran. On parle également de « screen real estate » (« espace dis­po­nible à l’écran » en français). Le site Web doit être agréable à regarder sur tous les appareils et offrir une ex­pé­rience uti­li­sa­teur (UX) optimale.

Le Res­pon­sive Web Design englobe une variété de tech­niques et d’approches qui per­met­tent de dé­ve­lop­per un site Web en­tiè­re­ment réactif. Nous re­trou­vons, par exemple :

• Des éléments HTML5 comme picture et des attributs comme srcset et sizes
• Des requêtes médias CSS
• Des unités CSS
• L’uti­li­sa­tion de plusieurs assets dans une même ressource
• L’approche « mobile-first »

Le dé­ve­lop­pe­ment d’un Res­pon­sive Web Design offre plusieurs avantages. L’ex­pé­rience uti­li­sa­teur est au premier plan. En principe, vous n’avez pas besoin du Res­pon­sive Design pour une bonne ex­pé­rience uti­li­sa­teur. Mais cela nécessite soit un site mobile spé­ci­fique, soit l’uti­li­sa­tion de Ja­vaS­cript. Cette approche est donc beaucoup plus complexe que la solution offerte par le Res­pon­sive Web Design basée sur les CSS et entraîne des efforts sup­plé­men­taires pour la main­te­nance des dif­fé­rentes versions du site.

Le design d’un site Web est un facteur décisif : il influence la façon dont un visiteur perçoit les in­for­ma­tions pré­sen­tées sur un site. Un bon design reflète l’identité de la personne ou organisme qui se cache derrière le site Web et contribue à lier le visiteur à la marque. Il doit se sentir à l’aise sur le site et vivre une ex­pé­rience positive. Voyons comment le Res­pon­sive Web Design contribue à optimiser l’ex­pé­rience uti­li­sa­teur à l’aide de deux exemples :

• Imaginons qu’un titre remplisse tout l’écran sur un smart­phone. En revanche, le titre est à peine visible sur la version de bureau avec la même taille de police. Sur un or­di­na­teur de bureau, le titre doit être plus grand pour attirer l’attention du visiteur.
• Autre exemple : imaginons un blog où une barre latérale est affichée à droite de l’article. La barre latérale contient des liens vers d’autres articles avec de petites vignettes. Dans la version de bureau, la barre latérale permet de limiter la largeur de l’article, con­tri­buant ainsi à la li­si­bi­lité. Toutefois, sur un appareil mobile, la barre latérale cou­vri­rait presque la moitié de l’écran. La mise en page doit être modifiée sur les appareils mobiles afin que le contenu de la barre latérale ap­pa­raisse sous l’article.

En principe, un site Web non res­pon­sive affichera sur le petit écran d’un appareil mobile la même chose que sur un or­di­na­teur de bureau, mais en plus petit. Cela oblige l’uti­li­sa­teur à zoomer sur des sections in­di­vi­duelles de la page. Il est donc pré­fé­rable de proposer une version optimisée. Voici quelques exemples :

• Sur un site Web, un bouton est cliqué avec une souris sur la version de bureau et avec l’index sur la version mobile. Par con­sé­quent, le bouton doit être plus grand et éloigné des autres éléments pour la version mobile.
• Imaginez un for­mu­laire sur une page. Nor­ma­le­ment, une marge in­té­rieure (padding) est créée via CSS afin que le texte qu’il contient soit facile à lire et ne touche pas les bords du for­mu­laire. Un padding de 20 pixels à gauche et à droite est normal et parfait pour les grands écrans. Mais sur un appareil mobile dont la largeur d’écran n’est que de 320 pixels, on perd 40 pixels sur 320, soit un huitième. Si le for­mu­laire comporte également une marge ex­té­rieure (margin), disons de 20 pixels sup­plé­men­taires par page, 25 % de l’espace dis­po­nible est déjà perdu sur le dis­po­si­tif mobile. Pour éviter cela, il est né­ces­saire de réduire les marges sur la version mobile.

Une majorité d’uti­li­sa­teurs accède aujourd’hui à des contenus sur Internet via des appareils mobiles. Le fait de ne pas avoir de Res­pon­sive Web Design présente de sérieux in­con­vé­nients comme :

• De mauvais taux de con­ver­sion et des taux de rebond élevés causés par un design et une ex­pé­rience uti­li­sa­teur inadaptés
• Un mauvais clas­se­ment dans les moteurs de recherche, car Google pri­vi­lé­gie les sites Res­pon­sive Design
• De mauvaises per­for­mances à cause du char­ge­ment de res­sources non op­ti­mi­sées, en par­ti­cu­lier sur les appareils mobiles

Le Res­pon­sive Design comprend dif­fé­rentes approches et tech­no­lo­gies. En général, il existe plusieurs solutions selon les contextes. Les choses ne cessent d’évoluer.

La création de mises en page complexes sur les sites Web est une science en soi depuis les débuts du World Wide Web. Le HTML comprend dif­fé­rents types d’éléments qui se com­por­tent dif­fé­rem­ment en fonction de leur dis­po­si­tion. Il y a notamment les éléments de type block, inline et inline-block. Les éléments de niveau block occupent toute la largeur dis­po­nible et sont empilés les uns sur les autres. Les éléments de niveau inline ne prennent que la largeur requise par leur contenu et se placent côte à côte. Voici un aperçu des types d’éléments les plus im­por­tants pour le Res­pon­sive Design :

Lors de la mise en page, il faut gé­né­ra­le­ment placer les éléments de block les uns à côté des autres. Pour cela, il existe plusieurs méthodes. Avant l’avènement du CSS, les mises en page basées sur des tableaux étaient la norme. Avec le CSS, le po­si­tion­ne­ment flottant s’y est ajouté. Aujourd’hui, CSS Flexbox est utilisé pour les mises en page simples à base de lignes ou de colonnes, et le layout de grille CSS pour les mises en page complexes. Dans tous les cas, des di­men­sions CSS relatives sont utilisées pour faire varier le nombre d’éléments affichés côte à côte.

À titre d’exemple : imaginez une page avec quatre éléments de pré­vi­sua­li­sa­tion pour les articles de blog. Ils con­tien­nent chacun une vignette, un titre, une accroche et un bouton « En savoir plus ». Flexbox facilite la création de la mise en page res­pon­sive :

• Affichage sur grand écran : tous les éléments de pré­vi­sua­li­sa­tion les uns à côté des autres en ligne. Chacun des éléments occupe 25 % de l’espace dis­po­nible.
• Affichage sur écran moyen : deux éléments de pré­vi­sua­li­sa­tion l’un à côté de l’autre sur deux lignes. Chacun des éléments occupe 50 % de l’espace dis­po­nible.
• Affichage sur petit écran : les quatre éléments de pré­vi­sua­li­sa­tion se trouvent les uns en dessous des autres sur une même ligne. Chacun des éléments occupe 100 % de l’espace dis­po­nible.

Voici un exemple d’im­plé­men­ta­tion utilisant des classes du cadre CSS res­pon­sive Tachyons. Nous dé­fi­nis­sons les classes ‘w-100 w-50-m w-25-l’ pour chaque conteneur de pré­vi­sua­li­sa­tion. Les quatre con­te­neurs de pré­vi­sua­li­sa­tion sont placés dans un conteneur marqué ‘flex flex-wrap’ :

Il est parfois judicieux de n’afficher qu’un élément sur une certaine taille d’écran. Voyons un exemple pratique : les données ta­bu­laires sont affichées sous la forme d’un tableau en HTML à l’aide de la balise <table>. Cependant, en fonction de la taille du tableau, il peut être difficile d’adapter l’affichage à des écrans très petits. Il suffit alors de faire preuve d’in­gé­nio­sité en signalant à l’uti­li­sa­teur de basculer son appareil à l’ho­ri­zon­tal afin d’avoir suf­fi­sam­ment de place pour afficher le tableau. Toutefois, ce signal ne doit être affiché que sur un appareil doté d’un petit écran et avec une orien­ta­tion portrait.

Le masquage d’un élément peut être fa­ci­le­ment réalisé avec la propriété CSS display: none;. Avec une requête médias CSS spéciale, nous demandons non seulement la largeur de l’écran, mais aussi l’orien­ta­tion de l’appareil. Le signal ne doit être affiché que si la largeur de l’écran en orien­ta­tion portrait est in­fé­rieure à 640 pixels. Sinon, nous cachons l’élément :

En com­bi­nai­son avec le code HTML suivant, la fonction est complète :

Pour une ex­pé­rience uti­li­sa­teur optimale, la taille de la police des éléments textuels d’un site Web doit être adaptée à l’espace d’écran dis­po­nible. Pour ce faire, on utilise plusieurs ty­po­gra­phies dans le Res­pon­sive Web Design.

Comme mesure de base, on utilise l’unité CSS rem (« root em ») pour lier la taille de la police d’un élément pro­por­tion­nel­le­ment à l’élément HTML ‘root’. Ensuite, il vous suffit d’ajuster la taille de la police de l’élément ‘root’ par le biais des points de rupture du style CSS afin de mettre à l’échelle toutes les polices de manière cohérente.

Prenons un exemple. Ici, suivant l’approche « mobile first », nous avons d’abord défini les tailles de police pour les petits écrans :

Ensuite, nous ajustons la taille de la police de l’élément HTML pour les écrans plus grands. Comme la taille de la police des rubriques H1 est définie par rem, elle s’adapte au­to­ma­ti­que­ment :

Une autre approche courante consiste à utiliser les unités CSS vh et vw pour un ajus­te­ment fluide de la taille de la police à la hauteur ou à la largeur de l’écran. En principe, cette approche fonc­tionne sans points de rupture, mais la police peut alors être affichée en minuscule sur de petits écrans. Dans ce cas, on peut utiliser des points de rupture ponctuels ou la fonction CSS calc() pour définir une taille minimale.

Pour optimiser les titres plein écran sur les appareils à petit écran, on utilise une approche sans CSS. Les titres doivent attirer l’attention du spec­ta­teur. Il est ainsi plus facile pour l’uti­li­sa­teur de saisir ra­pi­de­ment le contenu d’une page. Cependant, les mots peuvent devenir très longs, ce qui peut entraîner des problèmes d’affichage. C’est là que les entités HTML « Espace insécable » (&nbsp;) et "Trait d’union con­di­tion­nel" (&shy;) s’avèrent utiles. Elles per­met­tent de spécifier pré­ci­sé­ment où les mots d’une rubrique peuvent être séparés.

Outre la mise en page et la ty­po­gra­phie, l’op­ti­mi­sa­tion de l’affichage des images est au cœur du Res­pon­sive Design. De toute évidence, il n’est pas très logique de charger une image dont les bords ont une longueur de 1 920 pixels sur un téléphone portable doté d’un écran large de 400 pixels. D’une part, l’image, beaucoup trop grande, doit ensuite être réduite dans le na­vi­ga­teur, ce qui nécessite des calculs intensifs. D’autre part, la taille du fichier d’une image augmente pro­por­tion­nel­le­ment avec la taille du côté le plus long.

Une image de 1 920 x 1 080 pixels nécessite environ quatre fois plus de mémoire qu’une image de 960 x 540 pixels. Le té­lé­char­ge­ment d’une telle image sur un appareil mobile prendra donc plus de temps. L’ensemble de ces facteurs a un effet négatif sur la per­for­mance et la fonc­tion­na­lité d’un site Web si les images ne sont pas op­ti­mi­sées en fonction des besoins.

Avec l’in­tro­duc­tion de HTML5, deux nouveaux attributs ont été in­tro­duits pour la balise . Les attributs srcset et sizes spé­ci­fient plusieurs fichiers gra­phiques pour une image ; ils sont également appelés « assets ». Chaque fichier in­di­vi­duel est lié à une demande de requête média CSS. Cela permet au na­vi­ga­teur de charger, à partir de la liste des assets dis­po­nibles, un asset optimal pour l’appareil en question.

Voici un exemple rapide. Le code HTML suivant définit une image pour laquelle il existe deux attributs définis par srcset : un avec une longueur de 480 pixels et un avec une longueur de 800 pixels. Il précise également, via sizes, que l’image de 480 pixels doit être utilisée jusqu’à une largeur d’écran de 600 pixels. Sinon, le na­vi­ga­teur doit charger l’image avec 800 pixels :

Au­pa­ra­vant, les écrans étaient tous plus larges que hauts et les images en format paysage. De nos jours, les écrans de té­lé­phones portables sont en format portrait. Une image en format paysage sur un appareil qui les affiche en format portrait apparait toute petite. Pour un meilleur résultat, il convient d’utiliser une image carrée ou un portrait recadré sur mesure. Le choix des dif­fé­rents re­ca­drages des images est appelé « direction ar­tis­tique ». Elle peut être mise en œuvre avec l’élément HTML5 <picture>. L’élément <picture> permet la dé­fi­ni­tion complexe de plusieurs images équi­va­lentes pour dif­fé­rents cas d’uti­li­sa­tion.

Prenons un exemple. Le code HTML ci-dessous définit un élément <image> qui spécifie dif­fé­rents assets pour le format paysage et portrait. Dans les deux cas, il existe plusieurs versions op­ti­mi­sées pour dif­fé­rentes tailles d’écran :

Tra­di­tion­nel­le­ment, la na­vi­ga­tion est affichée en haut de la page. Il s’agit souvent d’une liste ho­ri­zon­tale d’éléments de menu, avec des sous-menus qui s’affichent lorsque vous les survolez. Cette mise en page n’est pas possible sur les appareils mobiles : il n’y a pas assez de place pour le menu sur les petits écrans et aucun pointeur de souris.

Il existe dif­fé­rentes approches pour afficher les menus de na­vi­ga­tion sur les appareils mobiles. Ils sont tous peu en­com­brants et ne né­ces­si­tent pas de souris. L’ac­ti­va­tion de la na­vi­ga­tion est souvent ac­com­pag­née d’une animation pour attirer l’attention de l’uti­li­sa­teur. Parmi les approches les plus utilisées dans la na­vi­ga­tion res­pon­sive, on peut citer :

• Le menu « hamburger » ou menu à tiroir (trois lignes ho­ri­zon­tales) : l’icône sert d’élément de contrôle central pour l’ac­ti­va­tion du menu
• Le design « Off Canvas » : le menu apparait à l’écran que lorsque l’uti­li­sa­teur le décide via un volet caché.