Le problème du responsive design

Je ne suis pas un gros fan de responsive design. Ce qui me dérange, ce n’est pas vraiment le fait d’adapter des mises en page à la taille de son navigateur. Ce n’est pas vraiment nouveau, et on a même retrouvé un exemple datant de 1999. La vraie nouveauté, c’est la possibilité d’utiliser des fonctionnalités natives de CSS pour parvenir à ce résultat. Mais ce qui me dérange, c’est que la technologie actuelle ne nous permet pas de proprement résoudre ce problème.

Au début du mois, Apple a sorti l’iPad mini. C’est une belle machine, aux caractéristiques très proches de l’iPad 2. Et ça c’est embêtant pour nous, pauvres intégrateurs, car l’iPad mini et l’iPad 2 ont la même résolution d’écran, mais pour une taille d’écran bien différente (respectivement 7,9″ et 9,7″). Avec si peu de différence, Apple a fait en sorte que toutes les applications sur iPad mini fonctionnent comme sur iPad 2. Et c’est donc valable pour Safari, où il est presque mission impossible de détecter l’iPad mini, même via user agent ou device-pixel-ratio.

Et c’est là l’un des premiers problèmes des media queries. Vous pouvez cibler un écran sur sa résolution, sur sa densité de pixels (pixels CSS, et non des pixels physiques), mais pas sur sa taille physique. Est-ce que vous devriez présenter votre contenu de la même manière sur des écrans de 4″, 7″ ou 10″ avec une résolution identique ? Je ne suis pas sûr. Andy Ihnatko avait trouvé un exemple plutôt parlant :

Flipboard sur iPad mini et Nexus 7

Il n’y a pas beaucoup d’applications Android optimisées pour tablettes. Vous pouvez avoir Flipboard sur les deux appareils, mais la version Nexus 7 est juste une version agrandie de la version téléphone. Sur quelle version préféreriez-vous passer 20 minutes à lire ?

Et la taille physique de l’écran n’est pas le seul manque des media queries. Que faire sur votre site si un internaute utilise le magnifique écran haute définition d’un iPad 4, mais avec une connexion Edge lamentable ? Ce genre de chose arrive. Vous ne pouvez pas vous permettre de lui balancer des images haute résolution parce que vous trouvez ça plus joli. Vous allez alors devoir recourir à la détection de la vitesse de connexion, par exemple en JavaScript avec la propriété navigator.connection. Mais je pense que les media queries devraient permettre de détecter la vitesse de connexion.

Les nouvelles technologies et les nouveaux usages font apparaître de nouvelles problématiques. Si l’on est en bonne voie de résoudre le support des écrans haute définition avec la balise <picture> ou la valeur image-set en CSS, on est à mon avis encore loin d’avoir une solution native pour les tailles physiques d’écran ou les vitesses de connexions. Et le problème, c’est qu’en l’absence de solution native, on va avoir tendance à chercher des solutions externes, souvent sales, et dont on aura du mal à se débarrasser.

Le mois dernier à Paris Web, Vitaly Friedman (de Smashing Magazine) était venu présenter ses trucs et astuces pour le responsive design. La foule était en délire, jusqu’à ce qu’il présente sa solution pour détecter la taille de l’écran en JavaScript et charger de nouveaux styles, basée sur un gros hack utilisant :after sur la balise <body>. Je me souviens alors de réponses assez vives sur Twitter, rappelant l’existence d’une solution propre et native pour faire ça avec la fonction window.matchMedia. Et je me souviens d’un tweet (qui je crois était de Daniel Glazman) qui disait quelque chose comme ça :

Ça prend des années pour standardiser de nouvelles fonctionnalités. Mais ça prend une éternité pour se débarrasser des mauvaises pratiques qui ont voulu combler l’absence de ces fonctionnalités.

L’intégration c’est faire en sorte que son site marche bien aujourd’hui, mais aussi s’assurer qu’il fonctionnera demain.

  1. kloh, le

    Tu expliques très bien la pensée au fond de ma tête !
    J’ai déjà eu l’occasion de bidouiller des petites choses en responsive, mais la problématique de la résolution vs. taille réelle de l’écran est juste une horreur. Et ce n’est (malheureusement ?) qu’un début je crains :o)

  2. Ombre, le

    Pour ce qui est de l’iPad mini, j’espère que Apple va corriger la résolution dans une prochaine version de Safari. ;-)

    Pour les images hidpi/retina, j’aime beaucoup cette idée (en attendant une solution du w3c): http://blog.netvlies.nl/design-interactie/retina-revolution/

  3. Fabien, le

    Hâtons-nous de casser cette mode « responsive design », afin que l’on cesse de faire croire aux clients qu’avec un coup de baguette CSS on est capable de leur fournir un site web qui s’adapte à tout.

    Il faut être parlant, fournir une version responsive, aujourd’hui c’est grosso modo le temps d’intégration x2

    J’ai vu la conf de Vitaly et hormis les probs que tu cites, moi ce qui me gêne le plus dans le responsive c’est l’ergonomie qui part en sucette à chaque point de rupture …

  4. Bartdude, le

    En même temps, si tu surfes en mobile et avec une connexion pourrie qui plus est, je pense que

    1) Tu cherches à avoir une mauvaise expérience
    2) Tu es habitué à ca, et tu ne jettes à priori pas la pierre au concepteur du site

    Je pense quoi qu’il en soit qu’il est impossible de s’assurer qu’un site marchera encore demain, on peut juste essayer de coller aux standards et croiser les doigts pour que tout le monde les respecte aussi longtemps qu’ils sont valables.

  5. Remi Grumeau, le

    > En même temps, si tu surfes en mobile et avec une connexion pourrie
    > qui plus est, je pense que
    >
    > 1) Tu cherches à avoir une mauvaise expérience
    > 2) Tu es habitué à ca, et tu ne jettes à priori pas la pierre au concepteur du site

    Un mobile + connection pourrie, ce n’est pas nécessairement ta faute. Un iPhone + 40min de metro parisien = iPhone5 + Edge. Ok , tu sais que c’est lent vu que tu le fais tt les matins. Il n’empêche, si tu es à la recherche d’un numéro de téléphone ou d’une adresse sur le site d’une boutique pour le copier coller dans Plans ou dans un email, tu apprécieras que ce site ne te fasse pas attendre 3 plombes juste pour une image en HD simplement parce que tu as un iPhone Retina. Des solutions existent… compresser ses images par ex :)
    http://blog.netvlies.nl/design-interactie/retina-revolution/

    Remi

  6. dom, le

    Qui dit Responsive dit controle cross Browsers/devices
    Quand je pense que je me plaignait du cross browser avec IE6
    C’etait plus simple

  7. JC Bousignac, le

    C’est vrai que le responsive webdesign cela donne une impression de déjà vu, surtout pour ceux qui ont connu un temps que les moins de 20 ans ne peuvent pas connaître… Le responsive webdesign est sur toutes les lèvres, et est mis à toutes les sauces commerciales possibles et imaginables, le filon du moment avec les gogos qui vont avec… Merci pour cet article.

  8. Pierre Ristic, le

    En même temps investir intelligemment dans une version « responsive » de l’intégration vaut mieux qu’engloutir un gros budget « Payes-ton-appstore » sans aucun bénéfice ergonomique. Pour le budget d’une bonne intégration responsive on a souvent une mauvaise application mobile.

  9. Raphaël, le

    Hello,

    Le sujet est très intéressant et mérite une attention particulière.

    Il y a plusieurs façons d’aborder le problème de la multiplication des devices. Quel que soit la solution choisie, elle ne sera pas parfaite puisque tout est une question de curseur :
    – si on veut une interface idéale pour chaque device (autant ergonomique que performante), il faut bien traiter un par un tous les devices. Si on en a le temps et les moyens, pourquoi pas. Et ensuite s’amuser à les maintenir. Et aussi ne pas oublier d’ajouter tous les nouveaux venus tels que l’iPad mini.
    – dans tous les autres cas, le Responsive Web Design est une solution qui cumule de nombreux avantages (le premier étant « au moins c’est lisible »), sans atteindre la perfection en effet.

    Le problème au final du RWD n’est pas vraiment la performance (on peut l’atteindre en pensant « mobile first), ni l’ergonomie (on peut faire exactement ce qu’on veut en RWD et s’approcher à la perfection d’une app native, ou presque).
    Comme tu le dis, le problème principal est de ne pas s’adapter correctement à la taille physique des terminaux, et uniquement à leurs pixels.

    Selon moi c’est un peu comme il y a quelques années quand CSS nous proposait monts et merveilles et qu’on se cassait la tête contre les murs parce qu’au final c’était foireux, ça s’affichait différemment selon les navigateurs, ou plein de navigateurs buguaient.

    Au final on en est au même point. Tout simplement parce que l’unité que l’on cherche existe depuis longtemps : elle s’appelle le cm ou le mm (voire l’inch) et devrait correspondre exactement à ce qu’on attend d’elle.
    Sauf que les navigateurs n’en ont cure, même quand on les force à afficher 1px = 1px CSS.

    Peut-être qu’un jour, quand les unités vh ou dppx seront implémentées, on pourra enfin se tourner vers celle qui est vieille comme le monde : le millimètre.

  10. Integrateur, le

    Le Responsive Design consiste surtout à passer son temps à bidouiller l’affichage d’un CMS pour afficher le contenu le plus important sur les plus petites surfaces. Pour moi, cela revient à virer pub, affiliations et widgets gadgets. Je me recentre donc sur le contenu plutôt que sur le panel de possibilités/fonctionnalités offert par le système de publication.

  11. Grégoire Hoin, le

    Je trouve ces remarques intéressantes, mais détachées de la réalité.

    Le terme « responsive design » est employé à toutes les sauces, c’est sûr, mais je ne crois pas que ce soit une raison pour décrier l’ensemble des techniques, et surtout des principes que ça représente.

    On ne met pas assez l’accent dessus, mais le premier principe du responsive devrait être celui du « progressive enhancement » avant tout. Les hacks n’ont pas vraiment leur place si l’on s’y prend comme cela.

    Oui, pour l’instant, toutes les technologies ne sont pas encore là. Comme le dit Raphaël, on ne peut pas atteindre la perfection, mais il vaut mieux implémenter ce qui est déjà possible, que de continuer à faire des bons vieux sites desktop en 960px. Nous attendons tous avec impatience le srcset, et le support des media queries plus avancées. Mais ce n’est pas en restant les bras croisés à attendre que les technologies soient prêtes que l’on développe les meilleures pratiques que nous sommes tous en train de chercher.

    Pour développer pour un futur qui ne sera que plus complexe en termes de multiplicité des devices, combiner progressive enhancement, mobile first et responsive est aujourd’hui la meilleure façon d’y arriver (à ce sujet: http://ignorethecode.net/blog/2012/11/18/touch_on_desktop/ )

  12. mantis, le

    Je ne suis pas de votre avis car vous parlez de mauvais responsive design.

    Si on s’attarde à tester le résultat comme on le fait habituellement pour avoir un site cross-browser alors le résultat est très bon.

    Responsive design signifie que l’on adapte le site au device quelqu’uil soit. Donc il est nécessaire de passer du temps à vérifier le résultat obtennu sur un smartphone de différentes tailles de différentes gamme et de même pour les tablette.
    De plus on adapte son contenu donc images etc…
    Le but étant d’alléger pour mobile

  13. thierry, le

    Pour moi, le problème du responsive design n’est pas tellement la possibilité ou l’impossibilité technique d’en faire que ce qui en résultera en termes de design.

    Voici trois blogs au design responsive sur lesquels je suis tombé (attention, hein, j’ai pas de smartphone ni de tablette, alors, je peux pas passer en revue toute une série de sites pour voir ce qu’ils donnent sur ces divers devices, mon propos est juste une réaction à ces sites au design responsive sur lesquels je suis tombé) :

    http://www.vinch.be/blog/2012/04/19/ce-blog-est-responsive/
    http://blog.barbayellow.com/2012/05/24/barba-v4/
    http://www.romaindavid.fr/2010/08/31/le-design-ne-sert-a-rien/

    – plus de menu « catégories » ;
    – plus de menu chronologique ;
    – plus de nuage de tags ;
    – pour certains, plus de tags associés aux articles ;
    – pour certains, plus de moteur de recherche interne.

    J’ajouterai que :
    – s’agissant des tags associés aux articles, ceux-ci donnent accès à un bien moindre nombre d’articles qu’un item de menu « catégories » ;
    – un moteur de recherche interne est de peu d’utilité si le visiteur n’est pas en mesure de déterminer des mots-clés de recherche pertinents faute de pouvoir connaître les thématiques du site via un menu « catégories » ou un nuage de tags.

    Pour moi, en tant qu’utilisateur, à l’exception de ceux que j’ai bookmarkés ou enregistrés avant que ces sites aient un design responsive, les contenus de ceux-ci sont pratiquement inaccessibles.

    Dans le cas de ces exemples, le responsive design se traduit par une régression considérable, encore jamais vue depuis les débuts du web, dans les moyens d’accès aux contenus des sites.

    Si le responsive design doit déboucher sur cela, c’est tout simplement une monstrueuse erreur.