Le theming responsive dans Drupal - Part I - Approche générale

Première partie de notre étude, de nos recommandations concernant l'intégration et le theming responsive avec Drupal. Nous vous partageons ici les secrets de nos transactions qui ont justifié l'adoption de certaines priorités et autres instructions.

Retrouvez l'ensemble des considérations traitant du responsive dans Drupal :
Le theming responsive dans Drupal - Part I - Approche générale
Le theming responsive dans Drupal - Part II - Les maquettes et wireframes responsives
Le theming responsive dans Drupal - Part III - Le mode opératoire de bluedrop.fr

Il y a plusieurs approches à adopter, suivant que :
1. Le client fournit déjà un design :
2. 100% Responsive;
3. Partiellement ou pas du tout responsive (ex: un design pour les PC mais pas pour les tablettes ou les smartphones).
4. Le client ne fournit qu'une charte graphique;
5. Le client ne fournit rien.

Le premier cas est le plus simple si les maquettes fournies sont responsives, car le client a déjà entièrement réfléchit à sa stratégie et il n'y a plus qu'à adapter cette dernière pour Drupal. Il conviendra cependant de s'assurer que les choix graphiques et ergonomiques du client sont compatibles avec notre technologie.

Dans le cas où son implémentation est incomplète, il faudra obligatoirement compléter les maquettes – toujours en partant de la dimension d'écran la plus petite vers la plus grande — et s'assurer du bon affichage des élements d'un point de vue visuel et ergonomique.
Les 2 derniers cas doivent d'abord passer par une étape pédagogique vis à vis du client, pour bien lui expliquer les avantages et contraintes d'un design responsive.

Penser "mobile first"

Le trafic web mobile dépasse aujourd'hui celui du web classique tel que nous l'entendions il y a seulement 2 ans. Inévitablement, tous les sites que nous allons créer seront désormais principalement consultés à partir d'un smartphone ou d'une tablette avant de l'être sur un PC classique.

Le fait qu'un site puisse être consulté à partir d'un smartphone n'est donc plus une option mais la norme ! C'est quelque chose que nous devions intégrer techniquement et commercialement.Il faut donc réfléchir à partir d'une consultation mobile et élargir petit à petit vers le format classique desktop.

Ce qui peut se traduire par :
- Elaborer les maquettes ergonomiques (wireframes) en partant d'un terminal mobile vers le PC : * Quel contenu est primordial et doit apparaître quel que soit la résolution du terminal. * Quel contenu est secondaire (ou techniquement impossible à afficher sur un petit écran) et ne doit pouvoir être visible que sur tablette ou sur PC ?
- Travailler la charte graphique en sens inverse en partant de la résolution la plus grande pour aller vers le mobile : ** Enlever au fur et à mesure les éléments qui ne sont pas essentiels.

Techniquement cela doit se traduire par l'utilisation en premier lieu d'une feuille de style (CSS) et d'un theming généralement sur une seule colonne, qui peu à peu se transforme en 2 ou 3 colonnes au fur et à mesure que la résolution augmente. Le mobile est la norme, cela doit donc être l'affichage par défaut (par exemple même si javascript n'est pas disponible ou désactivé, ou si on ne connait pas le navigateur). C'est seulement à partir de là, que l'on commence à tester la résolution du terminal et les différentes options disponibles du terminal (javascript, css3, etc.).

La question des breakpoints et des media queries

L'univers du mobile est très fragmenté :
- De nombreux systèmes d'exploitation (dans l'ordre actuel) : * Android * iOS * Windows * Blackberry
- De nombreuses marques et résolution d'écran (surtout valable pour hors iOS).

Il n'est donc pas recommandé de construire sa stratégie (sauf si cela est explicitement demandé par le client, en connaissance de cause) sur un système d'exploitation ou une marque donnée. Il faut réfléchir en termes de de contenu.

Techniquement :
- Utiliser une feuille de style par breakpoint, en commençant toujours par la feuille mobile qui sera chargée par défaut.
- Combiner ce système avec les media-queries pour fournir à l'utilisateur une expérience fluide et agréable entre chaque changement majeur de breakpoint.
- Utiliser des valeurs relatives (% ou em) et non fixes (pixels) pour le styling des éléments, afin de ne pas casser la mise en pages.

Exemple :
On peut définir 3 breakpoints :
1. De 0 à 600px
2. de 601 à 980px
3. Au delà de 981px

Pour le premier breakpoint, on part sur un affichage fluide (largeur des éléments à 100%) sur une seule colonne. Mais grâce aux média queries, on peut par exemple augmenter la taille des polices à partir de 320px et plus pour rendre la lecture agréable.

De 601 à 980px, on passe à 2 colonnes qui sont toujours à 100% de la largeur au total.

Au delà, on passe à 3 colonnes, mais on peut toujours grâce aux media-queries limiter la taille de l'ensemble à 1200px (avec des marges automatiques à droite et à gauche) dès que la résolution de l'écran est au dessus de 1200px de largeur. On adapte également la taille des polices en conséquence pour éviter d'avoir des lignes de textes trop longues et illisibles.

Notes sur la lisibilité

Il est très important de toujours garder à l'esprit qu'au delà de 80 caractères par ligne, la lisibilité d'un texte décroit fortement. L'oeil n'est pas habitué à balayer horizontalement sur une grande distance.

Il faut absolument éviter d'avoir un site avec du texte qui prenne toute la largeur de l'écran dans les grandes résolutions.
Il ne faut plus avoir peur d'utiliser des tailles minimums de polices au-dessus de 14 voir 16px (je parle en pixels, je ne devrais pas mais c'est pour vous donner un ordre d'idée).

Il faut également se débarrasser des contraintes liées au sacro-saint fold. Il y a des molettes sur les souris, il est facile de faire défiler son écran d'un simple balayage vertical du bout des doigts...

Interfaces tactiles

Ceci est la seconde révolution liée à l'adoption massive de terminaux mobiles par les utilisateurs :
- La souris n'est plus le seul et unique système de pointage. On pourra même bientôt le considérer comme secondaire.
- Les écrans tactiles ne sont plus réservés aux terminaux mobiles, on commence à les trouver sur les PC portables ou de bureau.
- Malheureusement, toujours en raison de la fragmentation de l'univers mobile, il n'existe (pas encore) de solutions universelles pour traiter tous les cas de figure.

Que faire ?
- Toujours garder à l'esprit que la souris ne sera pas le seul système de pointage utilisé sur le site. * Les actions _au survol_ (hover) doivent donc être proscrites (ex : survol d'un menu pour déplier le second niveau), préférer le clic. * Aérer les formulaires et les interfaces — particulièrement sur les petites résolutions — penser aux doigts.
- Utiliser les nouveaux "états" (hover, etc.) disponibles pour les terminaux tactiles lorsque cela est possible et prévoir des solutions de rechange dans le cas contraire.
- En bonus on peut également prévoir des gestures supplémentaires pour qu'un slideshow puisse avancer / reculer au balayage horizontal de ce dernier par l'utilisateur.

Points à valider avec les développeurs front-end

Voici une petite liste, pas du tout exhaustive, désordonnée et ouverte à discussion.
- Adopter un design Mostly Fluid (fluide en dessous d'une certaine valeur et fixe pour les trop grandes largeurs d'écran).
- Ne pas définir les éléments avec des valeurs fixes (px) mais préférer les % ou les em.
- Définir les polices en em.
- Pour le theming des élements de bases (colonnes, navigation, etc.) se reposer au maximum sur le framework disponible (Omega4 ou autre) sans ré-inventer la route. De cette façon, on peut éventuellement profiter des mises à jours du système sans casser la mise en pages.
- Se constituer une bibliothèque Js / Css d'éléments de base qui soit compatibles avec les terminaux mobiles et tactiles, la proposer par défaut pour les clients indécis.
- Ne pas contraindre les médias (images, sons, vidéos) dans une largeur fixe, mais fluide (100%). * Utiliser des icônes au format SVG ? * Utiliser des fonctionnalités CSS3 pour les gradients et les bordures afin de les faire évoluer aisément sans problèmes pour les différents résolutions. ** Penser à fournir des images en haute résolution pour les terminaux mobiles dont la densité de pixels est élevée (ex : écrans retina sur iOS).
- Penser mobile first (c'est le cas d'Omega4 et du Twitter Bootstrap désormais).

A suivre...

Le theming responsive dans Drupal - Part I - Approche générale
Le theming responsive dans Drupal - Part II - Les maquettes et wireframes responsives
Le theming responsive dans Drupal - Part III - Le mode opératoire de bluedrop.fr

Ludovic Coullet
Twitter : @lcoullet