Une pincée de Boostrap ne rend pas une interface responsive

Il faut comprendre que le responsive design n’est pas une solution technique.

Le HTML est par nature responsive. Il définit un jeu de contraintes entre le conteneur et son contenu. Il est possible de jouer sur ces contraintes. En premier lieu il faut savoir comment s’articulent ces contraintes, afin de définir la structure de son code-source HTML. Ensuite il est possible de modifier ces contraintes en utilisant les technologies conçues pour cela, à savoir le CSS et le Javascript.

Ceci est le soubassement technique qui permet de concevoir des interfaces responsives. Bootstrap, lui, est une formalisation particulière de techniques qu’une équipe peut installer et utiliser selon des règles — ce qu’on appelle un framework.

Voilà pour l’aperçu technique. Mais c’est loin d’être la seule partie.

Le design et l’expérience utilisateur font tout aussi bien partie du responsive design. Et ignorer cela, c’est s’exposer à de nombreux désagréments.

Le premier élément à considérer pour faire du responsive design, c’est pourquoi faire du responsive design ?

La réponse la plus évidente est “pour que ça marche sur tous les navigateurs et tous les terminaux : mobiles, tablettes, portables, ordinateurs fixes — quelle que soit leur marque”.

Ce qui fait un sacré paquet de tailles d’écrans, certains tactiles, d’autres pas ; et presque autant de claviers.

Pourquoi ne pas faire autant de sites qu’il y a, par exemple, de terminaux ? En les classant par familles, ça ferait, disons, 4 ou 5 sites différents. Sans compter qu’on peut aussi concevoir des applications mobiles. Pas besoin de faire du responsive.

Aussitôt les donneurs d’ordre font leurs comptes : ça coûterait beaucoup, beaucoup, beaucoup plus cher. Le responsive design est une solution économique.

C’est un élément à garder en tête : on fait du responsive design pour économiser du temps et de l’argent. Oui, le temps et l’argent, c’est la même chose, mais ça ne se range pas au même endroit, et ça ne se gagne pas de la même façon. Donc, ce n’est pas la même chose, mais il y a une dynamique entre les deux.

Une idée reçues à écarter est donc celle-ci : le responsive design est une technique qui permet d’économiser, certes par rapport à l’hypothèse où l’on réalise plusieurs sites, mais qui coûte plus cher que de réaliser un site pour un seul terminal. Et plus vous ajouterez de terminaux dans votre cible, plus ça coûtera cher.

Le responsive design est un effort particulier. Un effort est réalisé par des personnes, et ces personnes sont payées pour réaliser cet effort. Ergo, le responsive design a un coût.

C’est important, et c’est surtout important de le comprendre dès la conception, c’est à dire dès la mise en place de la réflexion sur l’interface utilisateur, sur les cinématiques, et pour la production des exemples graphiques qui servent le plus souvent de spécifications.

Bien souvent, on introduit cet effort au moment de l’intégration technique. Et concrètement, ça se traduit par : “On n’a qu’à utiliser Bootstrap”.

Il est impossible de concevoir une cinématique d’écrans dans une résolution maximale et de penser que l’interface sera efficace sur tous les terminaux parce qu’on utilise Bootstrap.

In a nutshell : ce que permet Bootsrap (ainsi les autres frameworks du même type), c’est gérer les proportions des éléments et de les répartir sur une grille.

Par exemple, on va décider qu’un article sera présenté sur trois colonnes en mode desktop, sur deux colonnes en mode tablette, et sur une seule colonne en mode mobile.

Notez bien qu’il n’existe pas de “mode desktop” ou de “mode mobile”, c’est un abus de langage de ma part. Je le fais volontairement car je l’entends fréquemment. Le code n’a pas conscience d’être exécuté sur tel ou tel terminal : le HTML est un standard, il sera interprété de la même façon dans tous les navigateurs. Le contexte matériel n’a pas d’importance de ce point de vue.

(NB pour les développeurs qui viennent d’ouvrir des yeux ronds partagés entre incrédulité et colère : je mets ici de côté les différences d’interprétations du HTML selon les versions de navigateurs — idéalement le code devrait s’exécuter partout pareil. Ce n’est exactement pas le cas, mais c’est globalement le cas).

Ce que fait Bootstrap, c’est de proposer d’appliquer des règles d’affichage différentes selon la largeur du viewport du navigateur. C’est tout. Il se trouve que le viewport maximum du navigateur sur mobile est plus étroit que le viewport maximum du navigateur sur desktop. C’est donc une règle généralement correcte que de dire “mode mobile”. Cependant, rien ne vous empêche, sur desktop, de réduire la largeur de votre navigateur jusqu’à atteindre celle d’un mobile. Bootstrap appliquera dès lors les règles du “mode mobile”, bien que vous soyez sur un desktop. Vous voyez qu’il n’a rien de magique.

Ce que fait le développeur qui utilise Bootstrap, c’est appliquer ces règles qui précisent le comportement d’un élément de l’interface d’après le design qui lui a été fourni.

Vous voyez où je veux en venir ?

Si on ne lui a pas précisé le design d’un mode particulier, le développeur ne peut pas appliquer les règles sur ce mode particulier.

Ce que l’on va demander au développeur, c’est d’interpréter le design pour le transposer dans une autre résolution — ce qu’il va faire en appliquant des règles Bootstrap que le navigateur va interpréter à son tour.

Cette double interprétation fonctionne tant bien que mal mais souffre de nombreux défauts et n’est pas optimale.

Elle réclame un effort supplémentaire de la part du développeur — un effort bien supérieur à celui d’une simple application de règles déduites d’un design existant. Il passe par un certain nombre d’essais et d’erreurs, de réglages et de modifications qui multiplie, à mon estime, par quelque chose comme deux à trois fois la charge de travail estimée initialement (c’est une dérivée de la complexité du layout initial).

Le développeur n’étant pas un designer, ses choix ne sont pas guidés par la qualité de l’expérience utilisateur, domaine dans lequel il n’est pas expert.

Ses choix sont perturbés par la complexité technique, il faut à la fois concevoir à l’objectif et la façon de l’atteindre. C’est un exercice difficile et fatiguant, et s’il s’y ajoute la tension d’une deadline à respecter, la tentation de céder à des raccourcis et des facilités est inéluctable.

Cette situation démontre également qu’il n’y a pas eu de réflexion attentive sur l’expérience utilisateur en fonction de l’appareil à utiliser, et ce n’est pas un manque auquel le développeur peut pallier.

Par exemple, il existe une différence majeure entre les appareils mobiles et les terminaux desktop, au-delà de l’espace disponible pour afficher l’interface, qui est l’interface de saisie : les desktops utilisent une souris (le plus souvent) et les appareils mobiles ont une interface tactile. Scroller, cliquer ne se fait pas de la même façon. L’évènement “rollover” qui se déclenche au survol de la souris n’existe pas sur un mobile (et c’est un élément d’interface très fréquent sur les designs que j’ai eu l’occasion d’implémenter).

Le meilleur choix possible est de laisser le temps au designer de concevoir l’interface selon de multiples résolutions.

En outre, le designer doit également avoir une bonne connaissance de l’outil qui sera utilisé, dans cet exemple Bootstrap, afin de savoir quels règles et quels outils sont fournis par le framework dans le but de faciliter son implémentation et de garantir une expérience utilisateur uniforme.

Pour cela, un travail en commun entre le designer et le développeur reste la meilleure solution (clin d’oeil appuyé vers les méthodes agiles).

En conclusion, je dirais qu’il faut avoir conscience que la finalité d’un framework comme Bootstrap n’est pas de rendre une interface responsive.

C’est plus précisement de fournir un ensemble de règles et d’outils qui agissent comme des contraintes — des guides — pour faciliter le développement d’une interface utilisable au mieux et au moindre coût sur la plupart des terminaux.

La bonne méthode est de concevoir son interface mobile-first : concevoir d’abord le format minimal, qui est le plus contraignant et qui se trouve être le format le plus utilisé maintenant que le trafic est majoritairement en provenance de mobile, puis de l’éteindre progressivement vers les écrans plus larges.

Selon les contenus, il peut être approprié de définir de nouveaux breakpoints (des largeurs qui vont déclencher de nouvelles règles de comportements) afin de contenir au mieux les formats intermédaires des tablettes et phablets, mais aussi les écrans très larges.

Il faut utiliser avec parcimonie certains types d’éléments, comme les onglets, les navigations avec trop d’éléments qui ont tendance à se “casser” sur plusieurs lignes.

Les événements spécifiques comme les “rollovers” sont à circonscrire selon des règles bien établis, pour ne pas perdre en usabilité.

Et le Javascript doit être utilisé en dernier recours, car son utilisation abusive peut ralentir le chargement de l’interface (je parle ici d’une interface rendue côté serveur, bien entendu).

Bootstrap est un outil très bien conçu, modulable et modifiable si on utilise sa version “code-source” qui sera compilée localement, mais dont la prise en compte ne doit pas se faire à un niveau uniquement technique, mais doit être partagé entre tous les acteurs participants à la création d’une interface.

Rien n’interdit d’ajouter de la complexité à son comportement, de prendre en compte des règles plus complètes et complexes que son fonctionnement natif, de créer de nouveaux composants, de multiples breakpoints, des mixins particuliers et inventifs, mais cela ne peut se faire qu’au sein d’une équipe qui maîtrise déjà son fonctionnement ordinaire.

A titre personnel, je conclus en disant que j’encourage toutes les équipes à embrasser le modèle responsive-design option mobile-first, gratifiant et efficace, en ayant conscience de ces prérequis que son utilisation optimale impose — pour toutes les situations où la réalisation d’un site avec une interface unique pour tous les terminaux est considérée comme la meilleure option.