Le mythe des périphériques
Selon une légende urbaine, les points de rupture sont égaux à la taille d’écran des périphériques (devices en anglais). Ceux qui ont d’abord écrit et utilisé un tel manifeste l’ont fait à une époque où l’iPad et l’iPhone dominaient de loin leurs marchés respectifs. Facile donc : on adapte à ces périphériques qui représentent 90% de la navigation portable, et c’est terminé ! Oui, mais non. Aujourd’hui, ce n’est plus aussi simple.
Beaucoup d’appareils sont désormais viables pour naviguer sur le Web. Je pense à la tablette Nexus 7, aux smartphones Galaxy S3 et Galaxy Note, aux Nokia Lumia, etc. soit autant de résolutions différentes. Vous pouvez faire le choix de traiter toutes ces dimensions une par une. Vous pouvez aussi faire le choix de penser les points de rupture en fonction de votre contenu, et ainsi offrir une lisibilité optimale quel que soit l’appareil utilisé.
Une histoire de contenu
Je fais volontairement abstraction des marges dans les mesures données car elles sont négligeables et que leur absence n’empêche pas la compréhension. Notez donc que les valeurs spécifiées sont approximatives à quelques dizaines de pixels près.
Le texte
Les arcanes typographiques spécifient qu’un texte possède une lisibilité optimale lorsqu’il est décomposé en lignes de 55 à 75 sigles. C’est une contrainte usuelle à respecter pour garantir un confort de lecture à vos visiteurs. Cependant, sur un mobile en mode portrait, il est impossible de faire tenir autant de caractères avec une taille de police convenable. Ce n’est pas bien grave, puisque on ne peut pas vraiment faire autrement. Le premier point de rupture à définir va donc être celui qui correspond à une colonne simple, qui respecte les 55 à 75 caractères de vos textes. Selon certains tests et analyses, cette valeur peut varier et aller jusqu’à 90/100. Dans notre exemple, un site éditorial de type blog, la lecture peut être longue et donc fastidieuse sur mobile. Je définis donc une taille de texte à 14 pixels – en-dessous, les yeux se fatiguent très vite, et au-dessus, le rythme de lecture est saccadé –, et j’effectue quelques tests pour parvenir à une taille optimale maximale de 600px.
Cette première taille ne correspond évidemment à aucun périphérique, et est plus large que l’écran d’un smartphone. Comme dit plus haut, cette contrainte est incontournable. On obtient alors une configuration semblable à celle-ci :
.wrapper {
box-sizing: border-box; // pour appliquer un padding fixe
width: 100%;
max-width: 600px;
margin: auto; // on centre lorsque l'écran est plus large que
600px
padding: 0 0.75em; // 0.75em = 1/2 du line-height
}
De la même façon, j’obtiens des paliers de 600px maximum pour une colonne de texte dans le pied de page. Pour le passage à deux colonnes, on ne va pas attendre 1200px car on étalera nos lignes sur une trop grande largeur. Il vaut mieux les diminuer un peu, quitte à ne pas atteindre les 55 caractères par ligne, pour scinder le bloc en deux colonnes. Disons 800px – un palier qu’on retrouvera pour les images sur le point suivant – pour respecter l’harmonie et ne pas multiplier sans raison valable les configurations de disposition possibles.
De 600px à 800px, on centrera le bloc de contenu pour éviter d’étirer nos textes. Au delà de 800px, on réorganisera le contenu relatif à l’article pour les positionner à gauche et à droite de ce contenu.
Les images
Mes images font 312px de large. En réalité, elles font le double, mais sont d’une faible qualité pour garantir un affichage correct sur écran Retina en perdant très peu de qualité lorsqu’elles sont affichées en 312px, preuve à l’appui. Cette méthode a un avantage non négligeable : mon canvas d’image peut dépasser les 312px, dans la mesure du raisonnable, sans flouter l’image. Je peux donc définir mon palier avec flexibilité.
En reprenant mon premier palier de texte, qui était 600px, je me rends compte que la qualité de mes images ne sera pas appréciable sur écran Retina. Je vais donc les placer sur deux colonnes. Je peux aisément aller jusqu’à 400px de large en une colonne. Le passage à deux colonnes s’effectue alors à 400px, ce qui nous laisse à peine 200px pour une image. C’est un peu court, mais c’est correct. Si les images jouaient un rôle plus important sur la compréhension, nous aurions revu la taille d’appréciabilité et certainement défini un palier plus haut. Ici, ça convient, nous gardons donc 400px comme palier de dédoublement des colonnes pour les images. Par extrapolation, on affichera 3 images par ligne à partir de 800px.
Pour résumer
Nous avons donc défini 3 paliers : 400, 600 et 800px.
- Jusqu’à 400px : toutes les sections s’affichent sur une unique colonne fluide.
- De 400 à 600px : la largeur reste fluide, le texte reste sur une colonne tant dans l’article que dans le pied de page, et les images s’affichent sur 2 colonnes.
- De 600 à 800px : on fixe la largeur à 600px et on centre le tout, car on ne fera rien de très pertinent de ces 200px supplémentaires ici.
- Au-delà de 800px : on affiche les informations de l’article ainsi que les images sur 3
colonnes, et on scinde en deux le pied de page. On limitera l’affichage à 984px, qui
correspond à la taille de la maquette initiale.
Vous pouvez allez plus loin et penser un affichage pour grand écran, comme par exemple en augmentant la taille globale du texte ou en mettant des blocs côte à côte.
À retenir
- Les points de rupture se définissent pour s’adapter à votre contenu, et non à des périphériques spécifiques.
- 55 à 75, voire 90 caractères par ligne pour garantir un bon confort de lecture sur les paragraphes.
- Pensez l’intégration et la conception des images en amont pour être sûr de respecter l’appréciation de celles-ci. N’oubliez pas les écrans HD.
- Le responsive Web design n’est pas une feature, mais une base d’accessibilité indispensable.
Conclusion
Vous avez désormais les bases pour trouver les points de rupture qui correspondent réellement à votre contenu, et non à un appareil. Le marché est trop fragmenté pour favoriser un appareil plutôt qu’un autre. Gardez en mémoire que le responsive Web design n’est pas une réponse ergonomique complète – à l’instar d’une application native –, mais une solution d’adaptabilité pour garantir un minimum de confort sur tous les appareils.
Vos commentaires
# muchos Le 7 décembre 2012 à 09:06
Super article ! Ça change mon travail sur les images : on peut leur donner un ratio taille/compression optimal puis jouer avec leurs dimensions dans css.
En outre, c’est bien mieux de travailler avec des paliers, même si on peut sans doute trouver des "fourchettes" qui englobent un maximum de devices à peu près similaires.
# noclat Le 7 décembre 2012 à 12:41
Il est bien de garder en tête un minimum les tailles récurrentes de devices pour ne pas afficher d’aberrations. Mais le contenu prime, quitte à avoir de légères marges latérales. À prendre en compte la cible du site également pour, pourquoi pas, faire un pallier spécifique pour iPad par exemple. Mais si le device importe plus que le contenu, c’est qu’il faut peut être songer à une application native :).
Heureux que cet article te sois utile :) !
# Enguerran Le 7 décembre 2012 à 17:12
Très bon article.
Moi j’aime bien me représenter les points de ruptures comme des limites de segments. Et je les fixe en fonction du contenu, comme toi, pour m’assurer que tout soit bien lisible et que rien ne casse.
C’est là également que la grille fluide prend tout son intérêt, pour ceux qui ne jurent que par les points de rupture.
# Stéphanie Le 7 décembre 2012 à 18:07
Très bel article, comme je le disais sur twitter, merci d’avoir créé une jolie référence en Français pour ce que je pense depuis un petit moment : placer les points de rupture en fonction du contenu et non en fonction de la taille des périphériques.
J’avais tendance à essayer d’expliquer qu’il vaut mieux placer les breakpoints "quand le layout casse". C’est en fait dire exactement la même chose que de parler du nombre de caractères par ligne, qui sont au final, une manière de "mesurer" (avec de gros guillemets ici, comme tu le dis, ce n’est pas une mesure exacte) quand le contenu sera illisible, et donc que notre layout actuel n’est plus adapté à la taille et disposition du contenu.
# Raphael Le 8 décembre 2012 à 18:18
Salut Nicolas. Joli article en effet :)
En le relisant tranquillement, j’ai l’impression que tu ne vas pas au bout de la logique et ton raisonnement.
Je suis entièrement d’accord qu’il est nécessaire de raisonner en terme de contenu et de facilité de lecture, comme tu l’expliques très bien en introduction.
Par contre, dans ce cas, pourquoi choisir de se donner des repères en pixel et non dans l’unité parfaitement adaptée pour des tailles de polices... l’unité em ?
C’est ce que HTML5boilerplate a fait et c’est bien expliqué sur cette ressource : http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/
Au final, ton design sera *vraiment* basé sur le contenu.
Attention, pour moi ce n’est pas une solution magique car dans beaucoup de maquettes graphiques, il faut bien se rendre à l’évidence, le seul critère universel compréhensible à la fois par Photoshop et un être humain demeure le pixel. Mais dans l’absolu, oui pourquoi pas.
Pour moi, cet article rejoint celui de Hteumeuleu : http://www.hteumeuleu.fr/le-probleme-du-responsive-design/
Et selon moi l’unité idéale que l’on cherche existe depuis longtemps : elle s’appelle le cm ou le mm (voire l’inch) et devrait correspondre exactement à ce qu’on attend d’elle.
Sauf que les navigateurs n’en ont cure, même quand on les force à afficher 1px = 1px CSS.
Peut-être qu’un jour, quand les unités vh ou dppx seront implémentées, on pourra enfin se tourner vers celle qui est vieille comme le monde : le millimètre.
# Nicolas Torres Le 8 décembre 2012 à 20:59
Merci Raphaël pour ces précisions et ressources. L’unité em est en effet beaucoup plus pertinente à l’égard du texte. Cela dit on perd un peu le contrôle sur les paliers d’appréciation des images. Dans un soucis de vulgarisation, j’ai fait un choix et me suis tourné vers la solution la plus communément usitée.
Je suis également d’accord qu’il y a un réel travail d’amélioration à faire sur les unités de CSS. Il en manque indéniablement, et certaines comme le "px" n’ont plus de sens, comme j’essaie de l’expliquer ici.
# Raphaël Le 10 décembre 2012 à 08:42
Nicolas : l’unité "rpx" (pour real pixel) que tu évoques dans ton blog existe déjà : il s’agit de dppx :)
# Mathieu Avons Le 10 décembre 2012 à 13:33
Je ne suis pas certain que le choix des breakpoints doivent uniquement être déterminé par les contenus (images et textes). Pour les petits sites à faible contenu, peut-être qu’on peut se le permettre dans la mesure ou l’on est capable de déterminer la taille des images, des paragraphes et des titres. Mais quand est il pour un site de news ? pour un site e-commerce ? Dans le cadre de plusieurs refontes de sites en responsive, j’ai rencontré de nombreuses problématiques qui m’ont contraintes à changer plusieurs fois mes breakpoints au cours d’un même projet. J’ai dû prendre en compte les contenus, bien évidemment mais aussi les éléments de navigation (filtres, tris, pagination...) , le header (taille du logo, navigation principale, méga-menu...), du footer et même des formats de publicité pour finalement décider de la position exacte de mes breakpoints... Je pense qu’il est difficile de faire un choix arrêté pour les breaks points au début d’un projet. Je pense qu’on peut les définir grossièrement au départ, mais qu’ils s’affinent au fur et à mesure qu’on avance (lors de la conception, lors du design et lors du code).
# noclat Le 10 décembre 2012 à 19:52
@Raphaël : merci, autant pour moi !
@Mathieu Avons : au final, tu ajustes tes breakpoints en fonction de ton contenu, au sens large du terme — header, navigation, publicités en font partie, même s’ils ne sont pas de l’information principale. Mon exemple paraît simple, mais en réalité, il m’a fallu revenir une ou deux fois sur mes points de rupture. L’article n’a pas été écrit d’une traite ;). Donc oui, c’est un travail qui peut nécessiter plusieurs passes.
# jérémie Le 18 avril 2013 à 14:38
Merci pour cet article. En tant qu’intégrateur web et dans le cadre de responsive web design, j’ai plutôt le réflexe d’appliquer un design flexible en deçà d’un seul et unique point de rupture défini par le chef de projet.
# Dagobert Renouf Le 7 mai 2013 à 00:39
Merci pour cet article ! Pour une fois qu’on a du contenu pertinent sur un blog français :) Je m’en vais creuser dans cette direction pour rendre mon approche du responsive web design plus pertinente...
# Olivier C Le 7 mai 2013 à 19:22
Bonjour. M’intéressant aux media queries depuis seulement un an ou deux, je ne connaissais pas vraiment les habitudes des pros et j’ai naturellement tourné mes points de rupture en fonction de ma grille : une 12 colones 1000px, que j’ai divisée en 3 points de rupture, le point le plus bas convertit les div en pourcentage. Un peu simpliste comme solution, je me pencherai sur la vôtre.
J’aime bien votre solution sur les images. Je testerai.
# ThomasF Le 21 octobre 2013 à 11:44
Du coup, pour pousser plus loin le principe, ne faut-il pas des points de rupture par éléments (ou modules) plutôt que pour l’ensemble de la page ? Je m’explique :
– un point de rupture dédié pour verticaliser la navigation quand la place horizontale n’est plus suffisante
– un point de rupture dédié pour ajouter une colonne de droite quand la place devient disponible à droite.
– ...
Ce qui impliquerait de ne pas prévoir x feuilles de styles pour x largeurs d’écran mais plutôt une feuille de style par module avec ces déclinaisons pour ces points de rupture propres.
Une approche réaliste selon vous ?
# Nicolas Hoizey Le 28 mars 2014 à 11:38
Bonjour,
Je relis cet article suite à un tweet qui le remettait en avant, et je reste toujours autant sur ma faim. L’article permet bien entendu d’avoir une approche un peu plus universelle du Responsive Web Design que celle qui s’appuie sur des tailles de points de rupture fixés par rapport à certaines tailles d’écran populaires il y a quelques années, mais cela ne suffit pas à mon avis.
Je comprends que cet article n’est plus tout jeune, mais il y a un an et demi, je me faisais déjà les mêmes remarques, et puisqu’il est de nouveau mis en avant, je pense nécessaire de signaler mes réserves :
– Il manque à mon avis une présentation au début du type de site et contenu(s) que l’on cherche à mettre en place.
– Pourquoi fixer arbitrairement la taille de texte à 14px ? (oui, celle-là je ne pouvais vraiment pas m’en empêcher… ;-) )
– Et bien sûr, mais c’est lié, dommage de fixer les paliers en px…
– Que signifie le commentaire « pour appliquer un padding fixe » de l’instruction
box-sizing: border-box;?– De quel chapeau sort la taille de 312px des images ?
– S’il est question d’afficher ces images dans des conteneurs de 399px (avant palier à 400px), 288px (2 images dans
max-width: 600pxmoins les gouttières, avant palier à 800px), puis effectivement 312px (3 images dansmax-width: 984pxmoins les gouttières), pourquoi ne pas plutôt avoir des images de 400px (x2 pour le Retina) ?– Enfin, comme suggéré par ThomasH, penser les points de rupture de façon globale à la page ne permet pas d’adapter au cas par cas chaque composant, alors qu’ils n’ont pas forcément les mêmes besoins d’adaptation par rapport à l’espace qui les entoure.
Peut-être serait-il pertinent de faire une mise à jour de l’article, ou d’en publier un autre abordant les pratiques actuelles de RWD.
# Nicolas Torres Le 28 mars 2014 à 12:12
Effectivement, cet article date un peu, mais voici des éléments de réponse :
– La taille est fixée à 14px, pourquoi pas ? Il fallait bien choisir une valeur, je n’incite personne à choisir cette valeur.
– Les paliers en pixels sont un parti-pris au vu de ce que implique des paliers en em : ils sont basés sur la taille de texte par défaut, et donc il aurait fallu faire des mises à l’échelle par rapport à la taille de typo rendue, ce qui aurait compliqué les calculs. L’intérêt ici n’est ni la maquette, ni les valeurs, mais le principe de fond.
–
box-sizing: border-box;permet d’inclure les marges internes dans la valeur du width, ce qui signifie qu’on peut spécifier des width en % tout en appliquant des marges internes fixes (par exemple, également à 1.5em pour s’harmoniser avec la ligne de base).– Pour les images, 312px est simplement le résultat obtenu une fois mes ajustements typographiques effectués et mon nombre de colonnes défini.
– Pour la question sur les images de 400px, je vous invite à relire l’article car c’est expliqué.
– Enfin, mon exemple ne répond pas à tout, mais est juste là pour sensibilisé à la problématique des points de ruptures, qui à l’époque étaient posés trop hasardement. Cela-dit, je reste persuadé qu’une approche "content first" peut répondre aussi à une adaptation des composants les plus réticents. Aux designers de mettre tous leurs composants en équation et trouver la solution optimale.
# Nicolas Hoizey Le 1er avril 2014 à 12:49
Merci Nicolas pour ta réponse !
Pourquoi pas 14px pour la taille de texte ? Parce que l’utilisateur a peut-être besoin d’une autre taille. Cf ma conf Paris Web et mon article 24 jours de Web.
OK, je comprends. De toute façon, comme je le disais, faire des paliers en
emalors que la taille de texte est bloquée enpxn’aurait pas beaucoup de sens… ;-)OK pour l’explication du « padding fixe », même si la formule reste étrange… ;-)
J’ai relu l’article au moins 3 fois avant de poser la question, je ne comprends toujours pas cette valeur de 312px plutôt que 400px. Une image de 624px (prévue pour un conteneur de 312px en Retina) ne sera sans doute pas très agréable à regarder dans un conteneur 30% plus grand, surtout si elle exploite la technique « Compressive Images ».
# Nicolas Hoffmann Le 1er avril 2014 à 15:06
Nicolas H : Un peu de recul voyons ;)
L’article est tout à fait valable et pas du tout "vieux", il explique avant tout comment penser le responsive avec le contenu, comme l’a expliqué l’auteur. Les paliers en pixels peuvent tout à fait s’accommoder de valeurs en em (vivent les préprocesseurs pour les calculs), idem pour les colonnes qui peuvent être transformées en pourcentages, etc. Quoi qu’on en dise, les pixels sont bien pratiques pour se faire comprendre.
ThomasF : ça s’appelle les Elements queries, c’est en "super-early draft" :) pour le moment (en général, c’est fait via JavaScript). Ceci dit, en dehors de ça, bon nombre de sites complexes ont cette approche, le côté responsive est géré directement par module, et non de manière globale.
Cela a ses avantages et ses inconvénients : c’est un peu tricky à penser hors du contexte (des fois impossible), mais par contre, c’est plus simple à maintenir : en somme le module contient son layout, ses mediaqueries, etc.
# Nicolas Torres Le 1er avril 2014 à 19:23
Ah oui, en relisant attentivement je me rends compte que j’ai choisis "bêtement" 312px qui correspondaient à une largeur réelle que j’obtenais sur mes différents palliers. Donc les prévoir plus grandes comme tu le suggères (800px à 30%, ou 1200px à 15%, ou autre) aurait été en effet une meilleure solution.
# philippe Mourier Le 3 août 2014 à 10:39
Même si cet article date un peu, il apporte énormément, j’ai enfin réussi à lire un article qu’il parle du sujet sans me faire couper la page au bout de 5 minutes, la demo m’a aussi énormément aider à trouver des repères, le responsive est pour moi un massacre de l’originalité d’un site design et artistique, tout les sites se ressemble et n’ont plus de personnalité, mais il semble que la fin du site graphique à sonnée et je dois mis plier, bien sur ma première réaction à été de me pencher sur les format media query et très vite je me suis dis mais quesque ont fait !!! "Ont repart en arrière ou quoi", "encore une mode de webmaster qui va prendre fin dans 2 ou 4 ans", mais la ; non cet article me semble tellement logique qu’il va surement être la base même de mon entré en matière dans le responsive.
Merci pour cet article riche et logique Nicolas
# Hic Le 12 octobre 2014 à 19:08
Merci Philippe d’être passé par là. Cette discussion devenait presque un débat phylosophique sur la théorie de la complexité. Triste aussi de constater le déclin de la créativité graphique sur le web.
Vos commentaires
Suivre les commentaires :
|
