L’approche mobile-first est-elle obsolète ?
L’approche mobile-first a beaucoup fait parler d’elle ces dernières années. Si l’on s’en réfère aux chiffres, plus de la moitié du trafic vers un site web provient d’un mobile (d’après l’étude annuelle de Mediametrie réalisée en 2018). Les professionnels du web l’ont bien compris et vantent les mérites d’une approche qui viserait à placer le smartphone au centre de la conception d’une interface.
Table of Contents
Rappel sur le mobile-first vs responsive.
La démarche mobile-first vise à concevoir une interface en partant du postulat que notre utilisateur cible utilise majoritairement son smartphone pour interagir avec notre produit. il s’agit alors de tenir compte des contraintes liées à l’utilisation de ces dispositifs : zones d’écran difficilement atteignables, temps de chargement, utilisation du pouce, etc. Pour en savoir plus, n’hésitez pas à consulter un de mes précédents articles.
La démarche responsive quant à elle ne s’attarde généralement pas sur les contraintes spécifiquement liées au mobile. Penser responsive signifie tout simplement que l’on vise à fournir la meilleure expérience utilisateur possible et ce, peu importe si l’utilisateur utilise un smartphone, une tablette, un ordinateur portable, ordinateur de bureau, etc.
Les limites de la démarche.
S’il est tout à fait pertinent de s’assurer qu’une interface sera parfaitement adaptée au format d’écran du dernier smartphone, ce raisonnement peut amener à négliger l’expérience de tous les autres utilisateurs. La démarche mobile-first risque par exemple de négliger le cas d’un utilisateur sur son écran ultrawide.
Penser mobile avant tout, c’est ainsi prendre le risque de délaisser la qualité de l’expérience de tous les utilisateurs qui n’utilisent PAS un smartphone. Par ailleurs, une mauvaise interprétation de la démarche mobile-first pourrait laisser entrevoir le smartphone comme un remplaçant de l’ordinateur. Or, de mon point de vue, il devrait plutôt être envisagé comme un complément.
La multiplication des formats.
Généralités.
Comme le mentionne Dan Rose, les utilisateurs consomment aujourd’hui du contenu depuis une telle variété de dispositifs, de navigateurs, de lieux, qu’il devient presque impossible de prévoir de façon précise l’ensemble des variations possibles et imaginables. Il n’est pas non plus envisageable de prévoir le contexte dans lequel sera un utilisateur lorsqu’il consultera votre site : sur son smartphone dans les transports en commun ou avec sa tablette sur son canapé ?
Deux solutions s’offrent à nous : tenter de prévoir l’intégralité des scénarios d’usages et proposer à l’utilisateur une version spécifique du site pour chacun d’eux, ou plus simplement concevoir un site web qui sera capable de tenir compte et de s’adapter à la situation afin de toujours fournir une expérience de qualité.
Cas spécifiques.
Lorsqu’elles conçoivent une interface, les équipes se limitent souvent à une version desktop (PC) et une version mobile (smartphone) du futur produit. S’il s’agit évidemment d’un gain de temps, cette démarche ne peut pas tenir compte des contraintes de tous les autres formats.
Les tablettes.
Les tablettes sont généralement délaissées lors de la conception d’une interface responsive et ce pour plusieurs raisons. La première raison concerne leur faible représentation dans les statistiques. En effet, elles ne représentent souvent qu’un très faible pourcentage du trafic. La seconde est qu’il est parfois difficile de déterminer à partir de quel seuil nous passons d’un grand smartphone à une petite tablette.
Pourtant, il y a de très grandes chances que parmi votre audience se trouve des utilisateurs de tablette. Et même s’ils ne représentent que 2% de votre trafic, il s’agit là de 2% d’utilisateurs que vous n’avez pas réussi à capter.
Mode paysage ou portrait.
Lorsqu’on conçoit une interface pour mobile, nous partons du postulat que le smartphone sera utilisé en mode portrait. C’est tout bonnement oublier qu’il existe un mode paysage qui est certes, utilisé de façon minoritaire, mais qui reste existant.
Les écrans larges.
Je remarque beaucoup de sites web réalisés par des professionnels dans des conditions budgétaires certainement très avantageuses et qui pourtant ne s’affichent pas correctement sur les écran ultra-larges. C’est notamment le cas des sections de sites en plein écran qui s’étirent à l’infini en largeur au détriment de leur contenu.
Des formats inhabituels.
La réalité est que nous ne pouvons prévoir de manière précise l’émergence future de formats très spécifiques et dont nous avions pas anticipé les cas d’usage. Les constructeurs ne cessent de proposer de nouveaux concepts dans une logique d’innovation et afin de se démarquer de la concurrence.
Le navigateur n’est pas toujours en mode plein écran.
Il est aussi important de faire la distinction entre le format d’un écran, et la place occupée par la fenêtre du navigateur.
Comme le précise Engage, Il est généralement facile d’obtenir des statistiques concernant les habitudes de vos utilisateurs. Ces statistiques incluent généralement l’OS (système d’exploitation), le navigateur utilisé (Firefox, Chrome, Safari, etc.), et les résolutions d’écrans. Il sera par contre très rare d’obtenir des informations détaillées concernant par exemple la hauteur et/ou largeur moyenne de la fenêtre du navigateur. La majorité des solutions analytics n’enregistrent pas la taille de la fenêtre (viewport).
L’utilisateur ne met pas toujours son navigateur en plein écran. Il peut par exemple décider de mettre deux applications côte à côte ou simplement préférer un autre format. Comme l’affirme Engage, cela signifie qu’il nous est impossible d’obtenir une représentation précise des habitudes de navigations de nos utilisateurs en terme de taille de la fenêtre de navigation. Nous ne pouvons qu’estimer et déduire que des utilisateurs sur écrans larges auront des fenêtres de navigation plus larges.
Que faire ?
Cette article n’a pas vocation à lister de A à Z l’ensemble des éléments à prendre en compte compte-tenu des points abordés précédemment. Il s’agit essentiellement de mon point de vue d’amener une réflexion plus large autour de nos méthodes de travail et ce, même si cela implique une remise en question de certains fondamentaux. Cela dit, voici quelques pistes qui me viennent à l’esprit.
Adapter sa démarche de conception au projet.
Selon Intercom, Lorsqu’il s’agit de penser à la conception d’une interface, il est encore aujourd’hui judicieux de concentrer son attention sur le “grand” écran. La réalité est qu’une majorité d’utilisateurs passe une grande partie de sa journée assise devant de grands écrans; qu’il s’agisse d’un ordinateur portable ou d’un écran de bureau. Cela est d’autant plus vrai si le produit concerne par exemple les entreprises ou leurs employés qui passent pour la plupart la majeure partie de leur temps au bureau. Dans ces conditions, l’approche mobile-first n’a pas de sens puisque l’utilisation du smartphone restera minoritaire tandis que l’expérience utilisateur sur grand écran devrait être la priorité.
Déterminer des points de rupture (breakpoints).
Pour faire simple, les breakpoints sont les tailles pour lesquelles l’affichage de certains éléments du site changent. Il s’agit ainsi de déterminer les conditions d’affichages de vos éléments en fonction de la largeur et de la hauteur du viewport (la fenêtre du navigateur) afin d’offrir à votre utilisateur la meilleure expérience possible. N’hésitez pas à lire cet article du Journaldunet pour en savoir plus.
Il s’agira également de déterminer le comportement que doit adopter votre site web lors d’un affichage sur des écrans très larges. Vos éléments doivent-ils systématiquement occuper 100% du viewport (plein écran), ou préférez-vous au contraire que vos composants restent “fixes” à partir d’une certaine largeur ?
L’utilisation d’unités absolues ou relatives.
Par unités absolues vs. relatives, j’entends parler d’unités qui dépendent ou non du viewport. Cela concerne typiquement l’aspect CSS de votre produit. En effet, tandis que les valeurs en pourcentages (%) ou en viewport (vh ou vw) sont dépendantes du viewport (la fenêtre du navigateur), les valeurs en pixels (px) ne tiennent pas compte de la largeur ou de la hauteur de la fenêtre.
Si nous aurions tendance à penser qu’il faudrait idéalement privilégier une unité relative, ce ne sera pas toujours le cas. Imaginez un texte dans un bloc rectangulaire. Vous décidez d’assignez à ce bloc une largeur maximale absolue de 1080px tandis que vous ajoutez à votre texte des marges horizontales relatives équivalentes à 10% de largeur de votre viewport. Si le résultat tel qu’il s’affiche sur votre ordinateur vous convient, vous risquez cependant d’être surpris lorsque vous mettrez la fenêtre en plein écran sur un ultrawide.
Tester sur un maximum de dispositifs.
Il va sans dire que le meilleur moyen pour se représenter le rendu d’une interface sur un type de dispositif consiste à faire des tests. Rassurez-vous, vous n’êtes pas obligés d’investir dans une gamme complète de dispositifs. La plupart des navigateurs possèdent dans leurs outils développeurs une option permettant d’émuler le format d’un device spécifique.