Bienvenue dans l’enfer du responsive

Voici une partie du footer de Sarenza.com vue dans une résolution de 540px de large, actuellement en production.

Sarenza

Voici le header de 3suisses.be dans n’importe quelle résolution supérieure à 980px de large, actuellement en production.

3suisses

Voici le header du site Time.com dans une résolution entre 500px et 700px de large, actuellement en production. C’est comme ça en production depuis au moins les six derniers mois où j’ai visité le site.

time

Et voici le header du site de la marque Tape à l’Oeil dans une résolution inférieure à 768px de large sur desktop. C’est comme ça en production depuis la refonte du site en septembre dernier.

tape-a-loeil

Je n’essaie pas de jouer au petit malin en vous montrant ces exemples. Ces exemples sont des exemples de site responsive de marques renommées qui à un moment rencontrent un problème d’affichage plus ou moins grave. Je ne dis pas que ces sites sont mal conçus (je trouve le menu de 3suisses.be particulièrement bien intégré). Mais ces sites se heurtent à un problème que j’ai également rencontré l’an passé en travaillant sur des adaptations responsive de gros sites.

On assume depuis longtemps qu’il est indispensable de tester son site sur différents navigateurs, sur différentes versions de ces navigateurs, sous différents systèmes d’exploitation, sous différentes versions de ces systèmes d’exploitation. Avec un site responsive, il faut toujours faire ça, mais en plus tester toutes les largeurs et hauteurs de fenêtres possibles.

Bienvenue dans l’enfer du responsive.

Et c’est encore plus un enfer dans une équipe de grande taille, ou avec différents prestataires externes, ou sur un site faisant appel à des contenus extérieurs (ou réalisés en externe). Et ça l’est encore plus dans le contexte d’un site dont le contenu évolue constamment.

Je n’ai malheureusement pas encore trouvé de solution miraculeuse pour identifier ce genre de soucis, à part une vigilance manuelle accrue. J’ai bien essayé de faire des captures d’écran de sites dans différentes résolutions avec des navigateurs sans-tête comme PhantomJS, ou alors avec des services comme BrowserStack. Mais cela nécessite toujours une vérification manuelle des captures. Alors qu’on s’empresse de plus en plus à faire des sites responsive, il me semble important de commencer à instaurer des processus de monitoring des designs de sites. (Je crois avoir vu passé quelque chose dans ce sens l’année dernière du côté de la BBC ou du Guardian, mais je n’ai rien retrouvé. C’est la BBC qui a un outil pour ça, basé sur PhantomJS, merci Kenny.)

En attendant, en tant qu’intégrateur, je ne peux que de redoubler de prudence lors de la conception de mon code (le design atomique, ça aide), et m’assurer que tout le monde comprenne bien pourquoi ça prend un peu plus de temps pour changer un « s ». Et aussi inviter mes collaborateurs à mettre en pratique la maxime du métro New-Yorkais : « If you see something, say something ».

  1. Aurelien, le

    Hello,

    Je pense qu’il faut un nouveau prestataire externe ou responsable interne dédié à cette tâche dite « ingrate » tellement les enjeux sont importants.

    Cela signifie un budget dédié qui permettra un contrôle toutes les semaines…

  2. Maurice, le

    Le problème est de penser que le responsive design est uniquement un problème technique. Le responsive design dépasse largement les responsabilités des intégrateurs, c’est une problématique qui concerne toute l’organisation : designers, développeurs, rédacteurs de contenus, publicité, product manager, chef de projet, etc. L’impact pour l’entreprise est souvent sous-estimé.

  3. Mickaël, le

    La phase de recette interne va devenir de plus en plus importante, je pense qu’un système comme GhostLab http://vanamco.com/ghostlab/ va devenir la norme pour les acteurs du web pour garantir un qualitatif client.

  4. David Leuliette, le

    Je rencontre quotidiennement exactement les mêmes problèmes. Les phases de test sont extrêmement longues à mettre en place et à recetter.

    Ce n’est pas testé sur tous les navigateurs ?
    Et tous les appareils ?

    – Aucun problème mais c’est quoi le budget ?

    C’est vrai que c’est plus sexy de vendre à un clients du contenu graphique que des phases de test…

    J’espère pouvoir trouver une solution du coté de https://github.com/stefanjudis/grunt-photobox
    mais c’est pas gagné

  5. Anthony, le

    En effet il y a bien eu un travail dans ce sens par la BBC qui permet de faire différentes captures d’écran des différences un peut comme à l’air de le faire grunt-photobox que je connaissait pas (donc merci).
    https://github.com/BBC-News/wraith

  6. PhilippeVay, le

    Merci David pour cet outil, je ne crois pas en avoir entendu parler auparavant.

    Pour ma part j’ai testé avec succès PhantomCSS qui ajoute la comparaison d’images à CasperJS (comme photobox le fait avec node.js apparemment) ; CasperJS étant issu de PhantomJS. Il y a aussi PhantomFlow qui reprend les résultats de PhantomCSS, assez bluffant mais j’ai préféré développer un petit outil pour gérer moins manuellement l’avalanche de captures d’écran que prennent ces outils !

    Reste à intégrer ça à ma manière de travailler et voir combien de temps supplémentaire cela représente. C’est en tout cas un excellent outil « anti-régression » dans un gros projet de dizaines et dizaines de gabarits avec 4 ou 5 points de rupture…
    Si je peux passer un peu moins d’heures à jouer du Shift-Ctrl-M dans Firefox, je prend ! :)

  7. Claire, le

    Je peux vous apporter un complément d’information sur le site http://www.t-a-o.com en tant que chef de projet de l’équipe d’intégration.
    Nous avons développé 2 versions : desktop et mobile, et nous avons utilisé un standard Hybris qui permet de détecter le device (RESS) sur base du user-agent, pour switcher sur la bonne version. L’inconvénient est qu’on ne gère pas les tailles intermédiaires de fenêtre sur un desktop. L’avantage est qu’on reste sur le natif Hybris, et qu’on optimise les performances.
    On a fait ce choix en assumant qu’un client lambda gardera une fenêtre navigateur suffisamment grande pour un affichage correct, et jusque là nous n’avons pas de retours des clients à ce sujet, hormis de la part des pro du responsive design qui check l’affichage inférieur à 768 px et qui détectent la supercherie ;)
    En revanche, j’approuve les remarques sur la difficulté de mener des tests sur l’ensemble des devices et navigateurs, les simulateurs ne sont pas fiables à 100%, on reste sur du test sur device réel pour avoir un bon résultat, ce qui est effectivement très consommateur de temps.

  8. Rémi, le

    Merci Claire pour ces précisions. Je connais bien les contraintes de ce genre de plate-forme. Ceci dit, je ne peux pas m’empêcher que la détection d’appareil basée sur l’user-agent est un jeu risqué. Et ici, un simple test sur BrowserStack permet d’identifier le même problème de rendu sur Kindle Fire 2. Ce n’est peut être pas l’appareil le plus populaire, mais j’ai tendance à penser que si j’arrive à produire un bug, peu importe la manière alambiquée qui m’a amené à produire ce bug, alors il y a au moins un utilisateur qui arrivera à la même chose.

    Sinon, j’ai testé Wraith avec l’exemple configuré pour la BBC. Et ça marche bien, mais ça ne correspond pas tout à fait à ce que j’ai en tête. Premièrement parce qu’on doit choisir son moteur de rendu (soit WebKit, soit Gecko, mais pas les deux en même temps). Et parce que la comparaison de screenshot ne se fait qu’entre les dits screenshots. Dans l’exemple du problème du logo du Time, aucune erreur n’aurait été identifiée, puisque le rendu est le même quelque soit le navigateur.

    Comme le dit Maurice, « L’impact [du responsive] pour l’entreprise est souvent sous-estimé ». Et le problème, c’est que pour l’instant ça retombe surtout sur l’intégrateur. (Les graphistes n’ont pas pensé leur maquette pour du responsive ? Tant pis, l’intégrateur s’en occupera.)

  9. Arnaud, le

    Si on ajoute à ça les problèmes de longueur de texte variant (parfois beaucoup) avec la traduction, on passe a un stade supérieur à l’enfer.
    Et je ne parle pas de l’inversion de l’affichage de la langue arabe

  10. mantis, le

    Je n’ai qu’un mot « Foundation » !

    Le responsive est facile il suffit de l’appréhender de la bonne manière c’est à dire mobile first !

    Ensuite le problème des langues arabes enfin la lecture de droite a gauche.
    Foundation propose ce paramètre.

    Honnêtement, le responsive design n’est pas un problème il est une solution. Le problème étant l’adative design qui lui englobe toutes les problématique.

    Heureusement, les choses avancent, pour ma part je regarde l’évolution de Foundation et il y a là un ensemble de brique vraiment parfaite pour répondre à cette problématique que cela vous pose.
    Aussi je propose à chacun de visiter le blog de Zurb (créateur de foundation) qui propose de nombreuses idées sur le design mobile.

  11. mantis, le

    Mais voilà comme dit plus haut c’est que seul l’intégrateur à la vision du responsive. il est grand temps de former aussi les autres membres des équipes à comprendre la problématique du mobile.