Les articles de l'année 2012

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.

J’ai donné un lightning talk à Paris Web

Le mois dernier, j’ai eu la chance d’assister pour la première fois aux conférences de Paris Web. Mais surtout, j’ai eu le privilège de donner pour la toute première fois un lightning talk. J’ai pris beaucoup de plaisir à lire les retours d’autres participants ou orateurs, comme Sophie, Xibe, ou Marie. Alors j’avais envie de partager ma propre expérience.

Un lightning talk, c’est une « conférence éclair » de 4 minutes. Au delà de 4 minutes, le micro est coupé et c’est fini pour vous. A Paris Web, ce sont Daniel Glazman et Robin Berjon (du W3C) qui s’occupent d’organiser la session, où 10 orateurs se succèdent dans un amphithéâtre plein à craquer et une ambiance survoltée. Si vous voulez un aperçu, je vous invite vraiment à regarder les lightning talks de Paris Web 2011.

En juin dernier, j’ai donc répondu à l’appel à orateurs de Paris Web en proposant un sujet de conférence de 15 minutes, et un lightning talk de 4 minutes. Mon sujet de conférence, complètement hors-sujet, a été judicieusement écarté (mais donnera lieu à cet article). Le nombre de propositions de lightning talk étant peu élevés, un nouvel appel à orateurs dédié a été lancé en août. J’ai donc renvoyé ma proposition. Et à ma grande surprise, j’ai été retenu.

Voici mon sujet et l’introduction de mon lightning talk :

Le thème de Paris Web cette année, c’est la fin d’un monde, inspiré par le calendrier Maya. Je ne crois pas en ça ni en aucune religion. Mais si c’est vraiment c’est la fin du monde, je ne suis pas fou, je préfère quand même me confesser au cas où. Je vais en faire profiter tout le monde en confessant 20 pêchés du web.

Je me suis dit que 4 minutes c’était beaucoup trop court pour aborder un sujet sérieux. Alors je me suis dit que j’allais plutôt essayer de faire rire, voire juste sourire (ou même un petit rictus, quoi, vas-y décoince toi). J’avais déjà plutôt une bonne idée des 20 points que j’allais aborder (si vous êtes curieux, vous pouvez voir mes slides). J’ai passé un peu de temps à réfléchir aux commentaires humoristiques ou sarcastiques que je pourrais faire pour chaque point. Mais ce que je ne savais pas, c’est que ça demande un temps démesuré de préparer une conférence de 4 minutes. Stéphane Deschamps, qui donnait lui aussi un lightning talk, résumait très bien la chose une semaine avant :

Plus jamais je ne propose un lightning talk pour @parisweb : plus de boulot qu’une bête conf de 45 minutes, je trouve. Faut être sot.

Et dieu sait qu’il a raison. Le plus long, ce n’était pas tant de réfléchir sur mon sujet, de trouver des remarques rigolotes, ou de préparer mes slides. Non, le plus long, c’était de s’entraîner, encore et encore, tous les jours, pour tenir 4 minutes, et pas une seconde de plus. J’avais préparé des notes, dictant mot pour mot ce que je voulais dire. En répétant tout seul et en lisant mes notes, je finissais à l’aise en 3’50 (« That’s what she says« ). Par contre, la semaine venue, en répétant devant ma copine ou devant mes collègues, je dépassais de justesse les 4 minutes. J’ai donc continuer à m’entraîner, à revoir un peu mon texte, à supprimer quelques passages, à prévoir quelques raccourcis au cas où. Le matin même, en m’entraînant tout seul, à 3’55, je me sentais prêt.

Mais ça c’était sans compter sur le stress. Et je l’ai senti monter, dès le jeudi matin, en arrivant pour la première fois dans l’auditorium d’IBM pour assister à la conférence de Daniel Glazman. « Ok donc là, demain soir, c’est moi qui serait sur scène. » Aïe. « Bon bah, quitte à parler devant tout le monde, autant s’entraîner dès maintenant. » Et j’en ai donc profiter pour poser une question à la fin de sa conférence. J’avais la voix un peu tremblante, je ne trouvais pas tout à fait mes mots, mais ça s’est pas trop mal passé. Mais ça n’a pas empêché le stress de monter petit à petit. Le vendredi a été horrible. J’avais envie d’uriner toutes les 10 minutes. Les conférences de la matinée s’enchaînaient, puis vint la pause déjeuner, et les quelques conférences de l’après-midi. Et là je remettais tout en doute. Est-ce que je vais vraiment réussir à parler devant plus de 400 personnes, dont pleins de grands noms de la profession ? Est-ce que je vais vraiment réussir à faire rire de blagues qui d’habitude ne font rire que moi ? Et est-ce que je vais vraiment faire un sujet d’une liste de 20 mauvaises pratiques ? J’ai horreur des articles de listes. Pourquoi est-ce que j’ai proposé ça ! Argh !

Et puis ça y est, il était bientôt 17h, l’heure pour tous les spectateurs de se rassembler dans l’auditorium principal. Daniel Glazman et Thomas Berjon avaient préparé eux aussi un lightning talk en remplacement d’un désistement de dernière minute. Ils ont ouverts le bal, et puis c’était au tour de Sébastien Delorme et ses « 4 minutes accessibles » (à moins que ce ne soit l’inverse ? mon cerveau était en mode panique à ce moment là, alors je ne me souviens plus trop). Et puis ça a été mon tour. Je suis monté sur scène, j’ai cherché avec Daniel Glazman mes slides.

Et là il s’est passé un truc incroyable et totalement inattendu. Alors que mon premier slide est apparu devant toute la salle (avec dessus inscrit uniquement « Rémi, Intégrateur, @HTeuMeuLeu »), j’ai entendu un « bravo » et quelques applaudissements dans la salle. Alors je me suis peut-être trompé, et peut-être que ça ne m’était pas du tout destiné et qu’il s’est passé un truc dans la salle au même moment. Mais dans mon élan de narcissisme d’orateur éphémère, j’ai pris ça pour moi. Et ça m’a fait un bien fou. (Qui que vous soyez, si vraiment c’était pour moi, alors merci.)

Et c’est ainsi que je suis parti pour 4 minutes. J’ai bafouillé un petit peu dans mon introduction, omettant de dire que j’avais 20 points à présenter. « Merde, t’as oublié de dire qu’il y avait 20 points. C’est important de dire qu’il y en a 20. Vite vas-y dis le tu viens de perdre 3 secondes à réfléchir là. » Et puis tout s’est enchaîné, presque parfaitement. Les développeurs Flash étaient en colère quand j’ai dit « Pardonnez-nous d’avoir utilisé Flash au détriment de l’accessibilité, l’intéropérabilité, la maintenabilité et du référencement ». Les gens ont rit quand j’ai dit que « Comic Sans Ms, c’est une police de Connare ». Daniel Glazman s’est arraché les cheveux quand j’ai dit « Pardonnez-nous pour les préfixes navigateurs ». Et les graphistes étaient en colère quand j’ai dit « Pardonnez-nous d’avoir utiliser Photoshop pour faire du web ». Excellent.

Au final, c’était vraiment une chouette expérience. Je suis conscient que ça n’a pas plus à tout le monde (sérieusement, décoincez-vous), mais les quelques retours que j’ai pu avoir le lendemain aux ateliers ou sur Twitter étaient plutôt positifs. Et du coup, ça me motive beaucoup pour la suite. Pour continuer à tweeter, pour continuer à écrire sur ce blog, pour lancer des projets comme 24 jours de web, ou pour peut-être donner des conférences dans d’autres évènements web en 2013.

Adobe et le web

Hier soir, je suis tombé avec effroi devant cette bannière publicitaire :

Il y a tellement de choses de travers dans cette publicité. Adobe corrobore l’idée qu’écrire du code, c’est un inconvénient. Adobe véhicule l’idée que le code HTML est une conséquence de la conception web, et non la conception web en elle-même.

Je ne vais pas vous le cacher, je n’aime pas Adobe. Je n’aime pas leur modèle économique désuet qui consiste à vendre des logiciels près de 1000€. Je n’aime pas les interfaces honteuses de leurs logiciels. Je n’aime pas leurs formats propriétaires horriblement conçus. Je n’aime pas leur hypocrisie.

Mais surtout, je pense qu’Adobe n’a jamais rien compris au web.

La récente suractivité d’Adobe au sein du W3C est très intéressante, comme avec les filtres ou les régions CSS, même si ça ressemble aussi à une énième tentative désespérée de reproduire du print sur le web. C’est déjà un comportement moins pathétique que ça.

L’échec de Flash sur mobiles en est un bon exemple de l’incompréhension du web d’Adobe. L’horrible prototype Wallaby en est un autre. Et Muse n’en est qu’un supplémentaire.

Adobe Muse est un des derniers nés du Creative Cloud d’Adobe, disponible en abonnement pour 20$ par mois. La promesse d’Adobe est de pouvoir créer des sites « de qualité professionnelle, conformes aux derniers standards web » « sans savoir écrire de code ». En bon concepteur web, j’ai donc testé rapidement Adobe Muse en créant deux simples pages, avec un simple titre en Helvetica Neue et un paragraphe de Lorem Ipsum. Vous pouvez voir le résultat sur jsFiddle. Voici quelques remarques :

  • jQuery est inclus par défaut sur toutes les pages, même si vous n’en avez absolument pas l’utilité, ainsi qu’une plâtrée de JavaScript en dur dans chaque page.
  • Mon texte en Helvetica Neue a été transformé automatiquement en image. Ça pourrait être pertinent pour une page unique, mais comme j’utilise cette police ailleurs sur mon site, il aurait été plus pertinent d’opter pour l’inclusion une police en CSS.
  • Le code HTML est peu sémantique, et truffé de balises inutiles.
  • Le code CSS n’utilise pas tous les préfixes navigateurs (comme les horribles déclinaisons de device-pixel-ratio)
  • Quand vous créez un nouveau site dans Adobe Muse, la première chose qu’on vous demande, c’est la largeur et la hauteur de votre site web. Et moi qui croyais que j’allais faire du web.

Je ne vais pas y passer des heures, mais vous avez compris l’idée : on est loin, mais alors très loin du travail qu’un intégrateur professionnel doit réaliser. Alors bien sûr, il y a déjà eu pas mal d’améliorations dans Muse depuis son lancement en 2011. Mais je doute que le logiciel ne parvienne un jour à atteindre la qualité du travail d’un professionnel.

Et c’est là pour moi le problème. Adobe essaie de vendre Muse comme un logiciel professionnel. Muse n’est pas un logiciel professionnel. C’est un logiciel amateur, pour des amateurs, destiné à faire des sites de qualité amateur.

Un bon concepteur web est un bon utilisateur

Il y a 6 ou 7 ans, dans la première agence web dans laquelle j’ai travaillé, l’équipe de graphistes a failli me rendre fou. J’avais l’impression que la plupart d’entre eux avaient une culture web proche du néant. Digg ? « Jamais entendu parler, c’est quoi ? » LaFraise ? « Un site de bonbons ? » 37signals ? « Combien de quoi ? » Et encore aujourd’hui, il n’est pas rare que je lise des commentaires de personnes travaillant dans le web se vantant fièrement de ne jamais avoir eu de compte Facebook, ou de ne pas avoir de smartphone. Je trouve ça fou.

Selon moi, pour être un bon concepteur web, vous devez être un bon utilisateur. Et ce, que vous soyez chef de projet, graphiste, développeur, intégrateur, etc.

Être un bon utilisateur, c’est avant tout être curieux. C’est ne pas rechigner à s’inscrire sur un site, ou à installer une nouvelle application pour remplacer votre IDE ou votre logiciel de retouche photo habituel. En tant qu’utilisateur, vous allez peut-être faire de très bonnes découvertes, ou au contraire tomber sur des expériences exécrables. Vous allez peut être tomber sur un e-mail extrêmement bien rédigé. Ou vous allez peut être vous rendre compte que votre grille-pain veut vous tuer. Mais ce qui est bien, c’est que dans les deux cas, ce sera enrichissant pour vous.

Récemment, Jason Fried avait écrit ce tweet :

You know that thing you don’t like? What’s one good thing about it?

Être un bon utilisateur, c’est aussi faire attention au moindre détail. En utilisant un produit que vous n’aimez pas, essayez d’identifier ce que vous n’aimez pas. En utilisant un produit que vous aimez, essayez d’identifier ce que vous aimez. Dans les deux cas, est-ce que vos critiques sont universelles, ou alors purement subjectives et personnelles ? Soyons réalistes : aucun produit n’est universellement parfait. En répondant à ces questions, vous devriez commencer à prendre conscience de la cible des produits que vous concevez.

L’excellent Dustin Curtis a écrit un article plus ou moins sur ce sujet la semaine dernière :

 « Le meilleur » n’est pas nécessairement un produit ou un objet. C’est la récompense d’avoir gagné le combat entre la patience, l’obsession et le désir. Cela prend une quantité de temps déraisonnable pour trouver le meilleur de quelque chose. Cela vous demande de connaître tout à propos du marché du produit, de sa fabrication, de son design, et d’arriver à naviguer parmi les prix trompeurs et le marketing. Cela vous demande de trouver le meilleur objet pour vous-même, ce qui demande de savoir ce qui compte réellement pour vous.

Des gens raisonnables ne passeraient probablement pas leur temps à lire un livre sur l’histoire des couverts, à en acheter vingt ensembles, et à tester le ressenti de chaque ustensile en métal contre leurs dents. Cela paraît fou. Mais qui se soucie des gens raisonnables ?

Si vous êtes une personne déraisonnable, croyez moi : le temps passé à trouver le meilleur de quoi que ce soit vaut totalement la peine. Il vaut mieux avoir quelques objets fantastiques conçus pour vous plutôt que d’avoir de nombreux objets peu fiables conçus pour plaire à tout le monde. Le résultat, être capable de faire confiance aveuglément aux objets que vous possédez, est intensément libérateur.

Être un bon utilisateur, c’est aussi savoir faire la différence entre le suffisant, le bon, et le meilleur.

Un placeholder ne remplace pas un label

Un placeholder ne remplace pas un label. Voilà. C’est tout. Je n’ai rien d’autre à ajouter. C’est une déclaration évidente. Et pourtant, j’ai l’impression de visiter de plus en plus de sites qui ont la manie d’utiliser un placeholder en guise de label. Voici quelques exemples aperçus récemment (et ce sont pourtant des gens biens qui ont fait ces sites).

Des exemples de formulaires en placeholder

En avril dernier, Roger Johansson résumait très bien le problème d’ergonomie lié à une telle présentation de formulaire :

La description de l’attribut placeholder dans la spécification HTML5 est très claire :

« L’attribut placeholder ne doit pas être utilisé en tant qu’alternative à un label. »

Pourquoi pas ? C’est assez évident. Puisque chaque texte dans l’attribut placeholder est visible uniquement lorsque le champ est vide, une fois que vous avez commencé à écrire quelque chose (ou si une valeur est pré-remplie par le serveur), votre indication a disparu. Vous voulez revenir en arrière et changer quelque chose ? Vous avez intérêt à vous souvenir de ce que le faux label en placeholder disait avant que vous ne commenciez à écrire, sous peine de devoir vider le champ pour voir le label apparaître à nouveau. Et, comme je le disais avant, dans certains navigateurs, le simple fait de placer le focus sur le champ suffit à faire disparaître le placeholder. Ne pas savoir ce que vous êtes censé indiquer dans un champ, ce n’est… pas très bien.

Au delà de ce problème d’utilisabilité, il y a aussi un problème clair d’accessibilité lorsque le champ texte ne propose pas d’alternative autre que le placeholder. Chris Coyier abordait brièvement le sujet dans l’un de ses articles :

C’est tentant d’utiliser un texte en placeholder en remplacement d’un label (en particulier maintenant que certains navigateurs laissent afficher le texte jusqu’à ce qu’on commence à écrire), mais n’utilisez pas de « display:none » et ne supprimez pas les labels. J’ai récemment entendu l’histoire navrante d’une aveugle qui essayait de s’inscrire à l’université, dont le formulaire d’inscription n’avait pas de label. Elle n’avait alors aucune idée de ce qu’il fallait mettre dans les champs. Donc si vous utilisez un texte en placeholder en remplacement d’un label, utilisez une technique accessible pour masquer les labels.

Voici une liste des pour et des contre l’utilisation d’un placeholder en guise de label.

Pour : 

  • C’est joli, et on gagne de la place.

Contre :

  • Ça diminue l’ergonomie de votre site. Même avec quelques champs, vos formulaires sont plus difficiles à utiliser. Et c’est encore pire sur mobile, où la suppression du texte d’un champs pour faire réapparaître son faux label est une tâche complexe.
  • Ça réduit l’interopérabilité de votre site. Oui, ça fonctionne bien sur les machines à l’heure à laquelle vous avez développé votre site. Et oui, vous avez mis un polyfill de placeholder pour les vieux navigateurs. Mais rien ne vous garantit que ça ne fonctionnera encore sur les machines de demain, puisque ce n’est pas fait pour ça à la base.
  • Ça détruit l’accessibilité de votre page. Sauf si vous prenez le temps de mettre en place une solution fiable et accessible (note : masquer les labels pour les utilisateurs qui ont JavaScript activés n’est pas une solution fiable et accessible). J’ai une astuce pour vous : une solution existe en HTML, et ça s’appelle un label.
  • Ça a un impact sur le temps d’intégration, et donc le coût de votre projet.

Ça ne vous rappelle rien ?

A moins que vous ne détestiez votre métier et que vous ne détestiez les gens qui utilisent votre site web, n’utilisez pas de placeholder en remplacement d’un label.