Responsive Web Design, du point de vue du chef de projet
Publié le
Mis à jour le
Le site anglophone Dev.Opera (géré par Opera Software, oui, le navigateur) publie des articles de fond sur des sujets web de pointe, présentés par des experts du monde entier.
Ce qui, dès le début, surprend beaucoup de gens à propos du Responsive Web Design (communément désigné par l’acronyme RWD), c’est bien sûr la simplicité de la syntaxe. Comme Rich Quick le disait lors de sa conférence récente à Front Row destinée à présenter les concepts de base :
« Tout tourne autour d’une simple ligne de CSS ! »
Évidemment, il serait impensable pour tout geek qui se respecte d’entendre une telle assertion, et de ne pas avoir envie de manipuler à l’extrême cette fameuse ligne magique ! Ce que la plupart d’entre nous découvre alors, au-delà de l’introduction technique, c’est qu’il y a un océan de bonnes pratiques à appréhender. Elles sont couvertes très efficacement dans le désormais classique livre « Responsive Web Design » d’Ethan Marcotte, et beaucoup d’autres ressources en ligne, incluant le très bon « Love your devices: adaptive web design with media queries, viewport and more » (en anglais) par Chris Mills, également consultable sur le blog Dev.Opera.
C’est ici que beaucoup s’arrêtent. Après tout, une grande partie des challenges techniques du RWD sont plus ou moins similaires, quels que soient la taille et le budget du projet. Il y a cependant des problématiques additionnelles à considérer sur les projets plus larges, qui ne sont que trop rarement discutées ; et cet article a pour ambition de les présenter !
Ces challenges trouvent avant tout leurs origines dans la manière dont les rôles et les profils habituels d’un projet web se mélangent sur les projets RWD plus lourds, avec des designers graphiques devant comprendre le flux HTML et les intégrateurs HTML devant faire des choix de design graphique. Ces problèmes vont trouver leurs solutions en reconsidérant les rôles que l’on attribue à chaque membre de l’équipe projet, et en adaptant les modes de communications dans l’équipe. Mais avant de détailler tout ça, commençons par nous poser quelques questions sur notre projet !
Tout d’abord, est-ce qu’il est pertinent que mon projet soit RWD ?
Après vos premières expériences sur les media-queries, au terme desquelles vous vous trouverez convaincus par leur simplicité, il se peut que vous vous commenciez à imaginer certains de vos sites web favoris en version RWD. Il se peut aussi que vous vous surpreniez à penser que tout devrait être RWD ; vous penseriez peut-être même à rendre vos amis et votre famille RWD si vous le pouviez !
Malheureusement il va vous falloir prendre un peu de recul : selon le contexte et l’objectif d’un projet, il peut être préférable de ne pas considérer du tout l’option RWD. Il n’y a pas de règle simple et universelle capable de vous donner une réponse évidente. Plusieurs points sont à prendre en considération. Voici donc quelques questions que vous devez vous poser avant d’acter une décision avec votre client.
Chacune de mes versions aura-t-elle les mêmes contenus et les mêmes fonctionnalités ?
Pour des raisons d’accessibilité, essayez de limiter le masquage des fonctionnalités entre les différentes versions. Partez du principe que chacune de vos fonctionnalités doit être disponible, et que même si certaines d’entre elles sont mises en avant dans l’une ou l’autre de vos versions, aucune de doit être dissimulée.
En RWD, les utilisateurs ne choisissent pas la version mobile d’un site, c’est vous qui la lui imposez. Mais que se passe-t-il lorsqu’ils souhaitent utiliser une fonctionnalité de la version « Desktop » ? Vous pouvez jouer avec la hiérarchie visuelle de vos composants sur la page, mais n’essayez pas de les cacher. Si l’on vous demande d’intégrer une fonctionnalité uniquement pour les mobiles, alors il est peut être temps de considérer la création d’une version mobile de votre site web.
Si vous choisissez malgré tout de cacher certaines fonctionnalités, alors pensez à mettre un switch « Version desktop » / « Version smartphone », qui puisse désactiver / réactiver les media-queries, à l’aide de javascript.
Certaines pages sur une version vont-elles devoir se décomposer en plusieurs pages sur une autre ?
Il y a certains besoins pour lesquels le RWD ne peut pas grand chose pour vous ; par exemple dans les cas où vous avez une page sur une version, qui serait plus abordable si découpée en plusieurs pages sur une version plus petite. Prenez la page d’accueil de Facebook par exemple, qui contient entre autres une navigation détaillée, deux flux de données live, et une messagerie instantanée. Êtes-vous sûr de vouloir voir apparaître ces éléments sur votre home mobile ? Hm, ce serait plus clair de séparer ces fonctionnalités sur plusieurs pages, vous ne pensez pas ? Pour les sites lourds en contenu, faire du RWD simple peut rendre votre page surchargée, et totalement inutilisable ! Si la règle « 1 page = 1 page » ne marche pas (et que vous ne pouvez pas la simuler en JavaScript), alors le RWD ne vous aide pas beaucoup, et il est peut être plus pertinent de créer un site séparé.
La publicité fait-elle partie de votre business model ?
Aussi longtemps qu’il n’existera pas de solution de publicité en ligne compatible avec le RWD, utiliser celles qui existent dans un contexte RWD vous apportera quelques migraines techniques. Fort heureusement, c’est un problème connu, et des solutions sont en cours d’élaboration. L’article de Mark Boulton « Responsive Advertising » est un très bon point de départ pour étudier le sujet plus en profondeur.
De l’effet papillon !
Plusieurs de vos problèmes majeurs avec les projets RWD viendront des rôles à redéfinir parmi l’équipe projet. Globalement, vous aviez habituellement un designer fonctionnel concentré sur des wireframes et qui n’avait pas trop à se soucier d’importantes contraintes techniques, et de l’autre, un intégrateur HTML/CSS/JS, qui pouvait transformer les designs de vos rêves en pages statiques accessibles, avec une interaction aux petits oignons ! Ces deux personnes n’avaient pas véritablement besoin des talents de l’autre pour avancer sur leur part du travail.
Grossièrement, vous aviez la célèbre séquence : spécifications – conception – design – intégration – développement back-end, et tous les petits morceaux avant, après, et au milieu. Chacune de ces étapes pouvait se réaliser indépendamment des autres. Par exemple, l’intégrateur pouvait très bien travailler sur des maquettes plusieurs semaines après la conception.
Le RWD impose des contraintes techniques plus lourdes que les contraintes habituelles sur la conception, ce qui secoue fortement ce bon vieux modèle. Vous ne pouvez plus produire un unique wireframe fixe comme avant et vous attendre à ce que le reste de l’interaction puisse être construit à partir de ça. Et vous ne pouvez pas attendre d’un designer fonctionnel habitué au web « fixe » qu’il produise un résultat techniquement pertinent, s’il n’a pas les connaissances techniques solides lui permettant de respecter le flux HTML entre les différentes versions RWD.
Du coup, allez-vous devoir demander à votre intégrateur de faire des wireframes ? Ou alors attendez, vous pouvez peut-être demander à votre designer graphique de faire du HTML/CSS directement ? Aaaah, migraine !
Une chose est sûre : la séparation des rôles et des expertises dans une équipe projet n’est plus aussi claire qu’elle ne l’était, et un bon vieux couperet « ok go, on va le faire en RWD ! » ne suffira pas. Il faut redéfinir jusqu’à l’ordre dans lequel les différentes étapes d’un projet se réalisent.
La tête avant les jambes : un peu de planification
Avant de vous lancer dans vos wireframes, posez-vous quelques questions conceptuelles qui définiront comment le reste des opérations se déroulera, et comment il sera séparé entre les diverses équipes. Une fois que vous aurez mis tout ça à plat (et, surtout, que vous l’aurez fait confirmer par le client), vous aurez une base solide sur laquelle itérer.
Où seront les points de rupture du design ?
En première étape, réfléchissez aux points de rupture de votre site : ceux où le design et la mise en page doivent changer. Le décider dès maintenant rendra toutes les tâches suivantes largement plus simples (conception, design graphique, et évidemment, intégration HTML).
Il y a plusieurs approches pragmatiques pour prendre la décision, mais généralement, le choix se fait entre :
choix par le contenu : vous regardez votre design avec votre véritable contenu final, et vous définissez empiriquement l’endroit où la mise en page nécessite d’être esthétiquement modifiée avant que votre header ne déborde, votre colonne n’explose, ou que votre contenu ne jaillisse de son contentant ! Ce choix des points de rupture est donc indépendant du support cible. Si le site web n’a pas beaucoup de gabarits, et que pour chaque gabarit, le contenu n’est pas si différent d’une page à l’autre, il est très pertinent d’utiliser cette méthode. C’est une approche simple à bien des égards – il n’y a pas pas besoin de media queries pour les types d’écrans à supporter, puisque les points de rupture fonctionnent quelle que soit la taille de votre écran. Cependant, cette approche n’est pas très efficace pour les sites qui ont beaucoup de gabarits, et sur lesquels, pour chaque gabarit, le contenu n’est pas du tout similaire d’une page à l’autre (ce qui représente une large quantité de projets, vous reconnaîtrez !)
choix par les terminaux : le choix peut être plus simple en regardant la liste des périphériques que vous souhaitez supporter, et en appliquant les points de rupture sur leurs dimensions. Vous suivez donc les résolutions des terminaux les plus courants (ou mieux encore : pourquoi ne pas étudier quelles résolutions votre cible utilise, si vous le pouvez ?), et les appliquez à vos designs. C’est un chemin beaucoup plus simple pour les sites complexes avec un contenu non-connu à l’avance, mais il est aussi plus limitant quant à l’objectif de supporter de manière homogène une grande variété de tailles d’écran, etc.
Il se peut que vous vous trouviez déçu qu’il n’y ait pas d’approche plus logique pour prendre cette décision, mais tout compte fait, il s’agit avant tout ici de la prendre « au mieux » afin que chacun puisse se lancer dans sa tâche ! Une fois la décision prise, l’équipe peut avancer…
Sera-t-il fluide sur toute la largeur?
Un design RWD parfait est censé être fluide quelle que soit la largeur d’écran ! Cela dit, en vrai projet, un site web est réalisé pour des cibles, comme « tous les smartphones, les écrans de 1024 px ou plus, et l’iPad » (qui est une cible plutôt typique, en 2012). Pour ces cas, un compromis possible est de partir sur un version fixe pour les grands écrans, une version fixe pour l’iPad, et une version fluide pour les smartphones. Tout ceci colle parfaitement à la cible, et coûtera beaucoup moins cher que de partir sur de la fluidité quelle que soit la taille d’écran, y compris les écrans extra-larges que l’on peut trouver aujourd’hui ! Et en étant pragmatique, sur les autres écrans de tablettes et d’ordinateurs, le résultat ne sera peut-être pas 100% parfait, mais il sera convenablement adapté, et très utilisable (même s’il est toujours bon de tester pour s’en assurer)
Mobile first ou non ?
Une manière idéale de mal faire un design RWD est de produire un layout dense pour une version desktop, puis de tenter de tout compresser et « faire rentrer » pour des écrans moins larges ! Cela ne signifie pas que commencer par le desktop est une mauvaise idée, et cela ne signifie sûrement pas qu’il faut nécessairement commencer par prototyper votre version mobile ; mais vous devriez vous posez cette question en contexte pour chaque projet.
Adapter une version desktop en mobile peut vous donner un excellent coup de pouce pour innover et trouver des nouvelles manières de réorganiser votre contenu. Et à l’opposé, commencer par le mobile peut vous aider à vous concentrer sur les fonctionnalités de base, et vous débarrasser de ce qui n’est pas essentiel pour votre utilisateur. Les deux méthodes ont chacune des avantages décisifs !
Il existe aussi une troisième voie tout aussi acceptable et qui peut correspondre à votre projet selon votre budget : celle de construire toutes les versions simultanément. Dans tous les cas, il est toujours bon de définir à l’avance l’approche que vous allez choisir pour votre projet, en commençant par l’étude de votre cible et de votre stratégie.
Aujourd’hui, une excellente manière de dépister que vous vous y prenez mal, est de comparer un wireframe pour site desktop avec celui du site ou de l’application mobile, exactement comme Luke Wroblewski l’a fait avec Southwest Airlines dans son livre Mobile First. Avec un site d’une telle densité, il peut être très constructif de vous inquiéter avant tout de votre utilisateur mobile, afin d’obtenir l’interface la plus simple et épurée possible.
Par contre, si votre client cible plutôt les utilisateurs sur desktop pour son site web, et ne s’intéresse au RWD que pour délivrer une version accessible à ses utilisateurs sur mobile, alors il est sans doute plus pertinent de vous inquiéter avant tout de vos utilisateurs sur desktop.
Quel outil de wireframing devrions-nous utiliser ?
Les outils permettant un wireframing RWD sans demander une certaine quantité de code HTML/CSS (et donc de connaissances techniques suffisamment avancées) n’existent simplement pas à ce jour ! L’excellent Gridpack App d’Erskine Design est un début, car il permet de créer une grille RWD très rapidement pour tester votre contenu, mais il n’est pas pertinent pour les phases d’ergonomie car il nécessite d’avoir dès maintenant les mains dans le code. Idéalement, il nous faudrait quelque chose comme Axure, ou Balsamiq, mais en version fluide.
En attendant, vous pouvez toujours utiliser votre outil favori dédié aux largeurs fixes, et l’utiliser intelligemment pour chaque version RWD.
On passe à l’action! Quelques conseils…
Vous êtes maintenant fin prêts, et avez toutes les armes en main pour vous lancer ! Mais si vous êtes habitués aux wireframes fixes, la tâche ne sera pas facile pour autant ! Il se peut que vous aboutissiez à un nombre très élevé de wireframes pour un site complet ; mais vous pouvez tout-à-fait choisir de faire l’impasse sur certains d’entre eux, et de laisser intelligemment l’interprétation de ce qui manque à l’intégrateur.
Gardez aussi quelques bonnes pratiques en tête (comme celle de limiter le masquage de fonctionnalités), et n’oubliez pas les nombreuses contraintes techniques, notamment liées au flux HTML.
À ce jour, il n’existe pas de solution universelle pour le processus de design RWD, donc quoi que vous décidiez, vous aurez besoin de beaucoup de pragmatisme en regard de votre contexte spécifique. Cela dit, il existe quelques points de départs communs qui peuvent influencer la définition de votre propre méthodologie.
Une grande quantité d’itérations courtes
Celle qu’Ethan Marcotte recommande consiste en une suite d’itérations courtes (par exemple, une semaine) durant lesquelles chacun travaille, puis partage ses trouvailles avec le reste de l’équipe. De cette manière, les designers peuvent aider les développeurs à améliorer leurs travaux faibles en design, et inversement. Bien que cette technique semble logique, et devrait vous donner un résultat très équilibré entre technique et design, elle nécessite aussi des deadlines peu contraignantes, et un budget potentiellement élevé !
Toutes les versions first !
Quelque soit la version que vous réalisez en premier (mobile, desktop, …), vous rencontrerez toujours vos difficultés RWD lorsque vous tenterez de l’adapter sur les résolutions restantes. Une manière d’avoir une vision continue des trois versions consiste à… les composer simultanément ! Bien que cette approche soit plus rapide et nécessite moins d’intervenants au projet, elle vous obligera à disposer d’un « designer RWD« , c’est-à-dire quelqu’un qui a l’expertise de la réalisation d’un storyboard fonctionnel, mais qui comprend aussi le RWD et les contraintes techniques liées au flux HTML. Et bien sûr, un tel profil n’est pas facilement disponible…
Comment fabriquer votre propre « designer RWD » !
Une manière simple de résoudre ce problème consiste à faire travailler ensemble un webdesigner « classique » et un intégrateur pour chaque étape, qu’elle soit de conception ou de développement. Évidemment, cette approche est tout d’abord coûteuse ; mais après quelques projets RWD, votre designer sera sensibilisé aux règles du flux HTML, et n’aura progressivement plus besoin de l’aide de l’intégrateur. C’est un investissement constructif, vous venez juste de créer votre « designer RWD » !
La validation « au cas où »…
Pour des designs et des gabarits complexes, une manière efficace de s’assurer que toute la conception est techniquement acceptable est de valider toutes les itérations de wireframe avec une phase de vérification technique, où l’intégrateur réalise le wireframe sous forme de page HTML/CSS. Bien sûr, cette étape coûte également une charge supplémentaire sur les phases de design, mais elle permet de s’assurer de manière certaine que toute cette phase est valide. En outre, s’il est bien réalisé, une majorité de ce code sera réutilisable pour les intégrations finales, à réaliser après le design graphique ; donc, tout n’est pas perdu !
Conclusion
En lisant les blogs çà et là, vous vous apercevrez rapidement que les tentatives récentes de figer un processus de design RWD sont toujours très expérimentales : il y a quasiment autant de propositions que de blogs ! Évidemment, des avancées sont réalisées, et des propositions très intéressantes sont avancées, mais rien n’est encore gravé dans le marbre.
Sachant cela, l’essentiel pour le moment est de s’assurer de se poser les bonnes questions au démarrage de chaque projet, de faire des choix en fonction du contexte, et de se lancer dans sa propre expérimentation avec un maximum de pragmatisme.
Et surtout : si dans vos expérimentations, vous trouvez de nouvelles idées pour rendre tous ces défis RWD plus simples à gérer, écrivez sur le sujet ! Partagez vos découvertes avec le monde, et découvrons ensemble des moyens d’améliorer nos process de travail !
Merci au grand sage Julien Femia, pour sa relecture de traduction avisée !
