Rechercher
  • Des usages à la conception et autres
  • digressions autour de l'expérience utilisateur.
Rechercher Menu

Mobile first versus Responsive Web Design

Deux sujets à la mode dans un même titre, si avec ça je ne fais pas péter le compteur de visites, je n’ai plus qu’à me tourner vers le porno !

Alors oui, ce sont deux sujets à la mode mais qui me paraissent mal compris, individuellement d’une part et ensemble d’une autre part.

J’ai déjà évoqué la problématique du Responsive Web Design (RWD en abrégé pour la suite.) dans cet article. Je ne vais donc pas revenir en détail dessus. (Lisez-le pour suivre ce que je vais raconter par la suite.). Ce qu’il faut retenir c’est que cette méthode d’adaptation des sites Web en fonction du support a des limites liées aux usages et aux conditions techniques.

Concernant Mobile First (MF pour la suite), c’est une approche qui a été proposée par Luke Wroblewski en 2011 dans son livre Mobile First aux éditions A Book Apart. Je me permets de citer une partie de sa conclusion :

« Starting with this personal and portable device in mind first allows us to:
– Take advantage of the enormous growth in mobile internet usage and find new ways for people to use our websites and applications.
– Embrace mobile constraints to focus and prioritize the services we’re designing and building.
– Use mobile capabilities to innovate the complete customer experience.
– Take what we know about designing for the Web and start thinking differently about mobile organization, actions, inputs, and layout. »

Je le rejoins bien sur ces points. Ayant fait beaucoup de projet sur téléphone mobile avant l’arrivée de l’iPhone (et depuis), je vais revenir notamment sur le deuxième point qu’il évoque et que je traduirais librement par :

“Prendre en compte les contraintes du mobile pour se concentrer sur l’essentiel du service que nous concevons.”

Il était une fois retour vers le futur

Dans des temps reculés, avant que le prophète Jobs ne vienne éclairer le monde de sa brillante fulgurance, je travaillais pour une entreprise dont le nom évoque sa couleur (Non, ce n’est pas Aubergine) et j’avais pour mission de concevoir des services pour le WAP. À cette époque, nous disposions pour “surfer” de mobiles avec des écrans modestes, 128×128 pixels en niveau de gris étant un luxe, et d’un simple clavier. Le réseau en GPRS permettait généreusement de transmettre au mieux 4 fois 9600bps soit 1000 fois moins que la 3G.

La conception des services répondait à des règles très strictes :
– Le contenu ne doit pas dépasser 500 signes (+ ou – 10 %)
– Les noms donnés aux hyperliens ne doivent pas dépasser 15 caractères
– Le pied de page contient la navigation, toujours dans le même ordre en fonction de la hiérarchie.
– Etc.

Que du bonheur ! Et je voyais les chefs de produits défiler dans mon bureau, ils arrivaient jeunes, innocents, enthousiastes de travailler sur l’avenir du Web, la fleur au fusil et ressortaient dépités une fois que je leur avais expliqué les quelques contraintes. Il fallait donc trancher dans le vif, limiter les images, réduire les textes, penser à une arborescence au cordeau, supprimer tous les gadgets, simplifier, simplifier, et encore épurer.

Quelque temps après, j’ai travaillé à la conception de l’interface de l’OS d’un téléphone mobile bas de gamme donc sur un écran de petite taille sans touchscreen bien sûr. De même il fallait se centrer sur l’essentiel. La règle était alors simple, si quelqu’un dans l’équipe pensait qu’une fonction n’était pas essentielle, on la supprimait.

Mosaïque d'écran pour téléphone mobile

Mosaïque d’écran pour téléphone mobile

Donc concevoir pour mobile nécessite de répondre à de nombreuses contraintes et donc faire des choix pour se centrer sur l’essentiel. L’essentiel qui doit permettre de rendre le service.

De là une approche mobile first…

MF et RWD dans un bateau.

Là où s’installe la confusion c’est quand, on commence à concevoir une interface Web, par la version mobile, en se disant je fais du “MFRWD”.

Par exemple, ce bloc-notes est basé sur un thème RWD dont la feuille de style (CSS) initiale est prévue pour mobile et si on a élargi la fenêtre, des styles complémentaires viennent modifier l’affiche de certains éléments.

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

Le RWD consiste souvent à déplacer des contenus, à les redimensionner et les adapter dans une moindre mesure. On peut donc effectivement commencer par le moins large, sans doute plus contraignant et puis décliner les versions plus larges et donc relativement plus faciles à organiser. Mais, je pense que l’on confond méthodologie de conception et résultat technique. Le RWD est essentiellement une solution techno centrée, guère nouvelle sur le fond. Mobile First est une approche en termes de conception d’interfaces.

Les services sont maintenant, pour une grande majorité, disponibles sur plusieurs supports ou du moins veulent l’être. C’est là qu’on va se retrouver avec la pire approche MFRWD, on va commencer par le mobile parce que c’est sans doute pertinent ou dans l’air du temps, puis on va rajouter des choix technico-budgeto-marketo-hiérarchique pour un service unique qui fonctionne sur tous les supports. Et on se retrouve avec un truc comme Météo France. C’est absolument le même contenu sur tous les supports, et c’est parfaitement inutilisable.

Sur un projet, il est souvent nécessaire de faire des choix pour diverses raisons plus ou moins bonnes et rationnelles. En ergonomie, on va s’appuyer sur des méthodologies scientifiques et la connaissance des utilisateurs pour faire les choix. Ces choix sont souvent mal compris et viennent en contradiction avec des études “clients” faites de manière beaucoup plus légère (pour rester poli). On se retrouve dans des réunions, à expliquer nos choix, et leurs fondements, puis à un moment, il y a quelqu’un qui dit “Mais je crois qu’il faut…” et on se retrouve dans ce genre de situation.

L’approche Mobile First a l’avantage d’être relativement compréhensible, comme pouvaient l’être les contraintes du WAP. Il est alors plus facile de faire entendre la nécessité de se centrer sur les fonctions utiles et utilisables. Ça n’empêchera jamais, les demandes sans fin sur l’ajout de fonctionnalités ! Donc même si ce n’est pas compris, comme c’est à la mode, vous pouvez user de votre mauvaise foi, pour dire “Non, ce n’est pas possible dans une approche mobile first” !

MF ≠ RWD & Interface distribuée et adaptative

Utilisés au même niveau de conception, les principes du RWD et MF sont, pour moi, antinomique, car MF se centre sur une situation d’usage en mobilité, là où RWD fait en sorte qu’un contenu unique soit disponible quel que soit le contexte d’usage.

Si on reprend l’exemple du Louvre, que j’avais utilisé pour l’article sur le RWD, et qu’on applique une approche Mobile First. On va donc se poser la question : “Qu’est-ce j’attends d’un musée, sur mon mobile ?” :

  • Une app sur mobile devrait rendre le service en fonction du moment où l’utilisateur en a besoin. Loin du musée, il faudra sans doute proposer en priorité des informations de type horaires, itinéraire, réservation de billets. Si la personne est dans le musée, il faudra lui proposer d’accéder aux descriptions des œuvres, ou des services en réalités augmentées lui permettant de voir plus qu’un simple tableau. On parlera d’interface adaptative dans ce cas.
  • Ce qui n’empêche pas d’avoir en complément un site Web très complet, qui peut reprendre une partie de ces contenus et en proposer d’autres bien plus riches et adaptés à un grand écran.

On est dans une logique d’interfaces distribuées, sur différents supports avec des contenus communs, mais des fonctionnalités différentes en fonction des usages du support. Cela permet d’avoir un site Web RWD, mais dans ce cas il faut envisager de le concevoir déjà pour PC, voire tablette avant de le décliner pour mobile où l’expérience serait dégradée.

Auteur :

Lead UX designer en Freelance depuis le dernier millénaire ! J'aide à concevoir des services, des applications en étant centré sur l'utilisateur et ses usages.

13 commentaires Ecrire un commentaire

        Ecrire un commentaire

        Les champs obligatoires sont signalés * markiert.


        facilisis suscipit risus. ut ante. ut in