Trois résolutions d’intégrateur pour 2013

480×320, 1024×768 et 1280×720. Ah ah, comme je suis drôle. Cette blague est tellement vieille qu’à l’époque on rêvait avec du 640×480 sur des gros CRT 12″.

Bref, c’est à nouveau ce moment de l’année. Plutôt que de vous parler de statistiques de navigateurs et de vous rappeler à quel point c’est une époque extraordinaire pour être développeur web, j’ai envie de partager avec vous mes trois résolutions d’intégrateur pour l’année 2013.

  1. Ne plus utiliser jQuery. jQuery fait typiquement partie de ces bonnes pratiques d’hier devenues des mauvaises pratiques aujourd’hui. jQuery a été créé en 2006 pour faciliter le parcours du DOM, faire des requêtes asynchrones et faire des animations, le tout avec une même syntaxe pour différents navigateurs. Sept ans plus tard, les problématiques sont radicalement différentes. Et à l’heure des sites mobiles et du responsive design, ce n’est vraiment plus acceptable d’inclure une bibliothèque JavaScript de 80 Ko. Si je veux parcourir le DOM ou faire des requêtes asynchrones, j’utiliserais du JavaScript vanilla. Si je veux faire des animations, j’utiliserais CSS.
  2. Utiliser les préfixes correctement. L’année dernière, la mauvaise utilisation et la mauvaise implémentation des préfixes navigateurs avaient fait beaucoup de bruit. Si des efforts ont été faits du côté des navigateurs et du W3C pour accélérer les processus de standardisation et rapidement abandonner les propriétés préfixées en Recommandation Candidate, j’ai le sentiment qu’il y a encore du travail à faire chez nous, les intégrateurs. En particulier, il est important de garder en tête que les propriétés CSS préfixées restent des propriétés expérimentales. En utilisant des propriétés CSS préfixées, vous signez un contrat implicite avec les visiteurs de votre site vous engageant à garantir une bonne utilisation de ces préfixes, et ce au cours du temps. Si la base consiste à utiliser les préfixes de l’ensemble des moteurs de rendu (-o-, -webkit-, -moz-, -ms, etc.), il est aussi indispensable de laisser tomber ces préfixes dès que possible. C’est déjà le cas par exemple pour les propriétés border-radius et box-shadow. Mais c’est aussi le cas de pleins d’autres propriétés (transform, transition, animation, etc.) depuis Firefox 16, Opera 12.5, IE10 et prochainement Chrome. A moins de devoir supporter des vieilleries comme Firefox 3.6 ou Safari 4, vous pouvez commencer à faire un petit ménage dans vos préfixes. En 2013, correctement utiliser les préfixes navigateurs signifie d’également s’occuper de leur suppression dès qu’ils ne sont plus nécessaires.
  3. Écrire et partager. J’ai lancé ce blog en juillet 2010, mais je me suis vraiment mis à écrire régulièrement à partir d’octobre 2011. En 2012, j’ai écrit 164 articles (contre 108 en 2011 et 17 en 2010). Je n’ai vraiment aucune prétention avec ce blog. Mais ceci est mon blog personnel, et c’est vraiment chouette d’avoir un espace personnel où s’exprimer librement. C’est vraiment très formateur, que ce soit dans la simple gestion d’un site personnel, mais aussi dans l’écriture, la formalisation de mes idées, et la prise de recul sur mon métier.
    En 2013, je souhaite continuer à partager mes découvertes, mes anecdotes et mes sautes d’humeur. Mais surtout, j’espère que vous en ferez autant.
    On a la chance d’avoir une communauté web francophone assez grande. Malheureusement, celle-ci n’est pas toujours très active. On a de chouettes sites comme Le Train de 13h37, Openweb, Webdesign Friday, Les Intégristes ou encore des blogs personnels que j’aime beaucoup comme ceux de Nicolas Hoffmann, Raphaël Goetter ou Kaelig (qui malheureusement se met à écrire en anglais). Mais ces lectures francophones restent anecdotiques par rapport à la masse d’articles anglophones intéressants mis en avant chaque jour sur Reddit ou Hacker News. En décembre, j’ai lancé 24 jours de web dans le but de rassembler un peu cette communauté web francophone, et ça a plutôt bien marché. J’espère lire plus d’articles en français cette année.

Comme toutes résolutions, je vais peut-être craquer et il y aura sans doute des exceptions. Mais j’espère que celles-ci pourront vous inspirer à définir vos propres résolutions de concepteurs web, et qui sait, peut-être les partager sur votre propre blog. (Vous voyez ce que je viens de faire ?)

Les redesigns non sollicités

J’ai un peu du mal avec les redesigns non sollicités. Un redesign non sollicité, c’est quand un individu lambda décide de reconcevoir un objet, un outil, une fonctionnalité ou l’identité d’une marque célèbre. Plus ou moins récemment, j’ai à l’esprit l’identité de Microsoft, un concept d’UI pour Windows, l’identité et le redesign de Wikipédiaun redesign du New York Times, d’American Airlines, ou encore le redesign de Craigslist paru chez Wired en 2009. Le site Uninvited Redesigns en rassemble un bon paquet.

De nombreux articles ont déjà été écrits concernant les redesigns non sollicités, mais je crois que c’est Khoi Vinh (du NYTimes) qui résume le mieux mon avis :

Les redesigns non sollicités sont formidables et amusants et utiles, et j’espère que les designers ne s’arrêteront jamais d’en faire. Mais en les faisant, j’espère aussi qu’ils se rappelleront que ça n’aide personne, et encore moins l’auteur du redesign, de présumer le pire de la source originale et des gens qui travaillent dur pour la maintenir et l’améliorer, bien que ces efforts puissent sembler imparfaits vus de l’extérieur.

L’un de mes principaux griefs envers ces redesigns non sollicités est qu’ils sont réalisés en dehors de toute contrainte du monde réel. Pas de contrainte de temps, pas de contrainte de budget, pas de contrainte hiérarchique, pas de contrainte historique. C’est facile d’arriver à présenter quelque chose qui peut sembler mieux sans tenir compte d’aucune de ces contraintes.

Mais surtout, quand il s’agit d’un redesign non sollicité d’un site ou d’une application, j’ai l’impression qu’il existe une certaine complaisance élitiste chez leurs auteurs à ne pas vouloir aller plus loin que des JPG. Et le problème, c’est qu’un JPG, ce n’est qu’un JPG. Tout récemment (vu chez Daring Fireball), un contre-point de vue sur un redesign de l’écran verrouillé de l’iPhone résumait très bien le problème :

Juste parce qu’un design a l’air beau ne signifie pas qu’il a été bien pensé.

Le design d’interface, c’est avant tout du design interactif. Ce n’est pas en vous paluchant sur vos PSD dans Photoshop que vous allez résoudre des problèmes. Et si ce redesign que vous entreprenez vous tient vraiment à coeur, alors allez jusqu’au bout, et réalisez le. Vous ne savez pas coder ? Alors apprenez à coder. Sans quoi, votre idée n’a pas beaucoup plus de valeur, que vous ayez ou pas réalisé des maquettes en JPG.

Derek Sivers, fondateur de CD Baby et auteur de l’e-mail le plus réussi au monde, avait rédigé l’article parfait à ce sujet en 2005 : « Les idées sont juste un multiplicateur de la réalisation« .

Ça me fait toujours rire quand j’entends des gens vouloir protéger leurs idées. (Des gens qui veulent que je signe une clause de confidentialité pour me parler même de leur plus simple idée.)

Selon moi, les idées ne valent rien à moins d’être réalisées. Elles sont juste un multiplicateur. La réalisation vaut des millions.

Explication :

IDÉE HORRIBLE = -1
IDÉE FAIBLE = 1
IDÉE COUCI-COUÇA = 5
BONNE IDÉE = 10
EXCELLENTE IDÉE = 15
IDÉE GÉNIALE = 20

PAS DE RÉALISATION = 1$
RÉALISATION FAIBLARDE = 1000$
RÉALISATION COUCI-COUÇA = 10 000$
BONNE RÉALISATION = 100 000$
EXCELLENTE RÉALISATION = 1 000  000$
RÉALISATION GÉNIALE = 10 000 000$

Pour faire des affaires, vous devez multiplier les deux.

La plus géniale des idées, sans réalisation, vaut 20$.
La plus géniale des idées avec une excellente réalisation peut valoir 20 000 000$.

Voilà pourquoi je ne veux pas entendre les idées des gens.
Je ne suis pas intéressé jusqu’à ce que je voie leur réalisation.

Le mois dernier, j’ai découvert en regardant la retransmission du HTML Meetup le projet Responsive Museum Week, initié par Geoffrey Dorne. Partant du constat que les sites de musée sont en général mal conçus et pas du tout adaptés à une consultation mobile, il a lancé un appel pour créer en une semaine des versions responsives de ces sites. Ce qui m’a particulièrement plu dans ce projet, c’est son côté très concret. Ici, pas de JPG, pas de Photoshop. Vous remontez vos manches, vous installez Stylish et vous créez votre CSS. Et le résultat est directement utilisable par tout le monde.

La complexité est parfois nécessaire

Ce matin je suis tombé sur ce bien chouette article intitulé « Le pouvoir de la complexité dans la communication visuelle » :

Un des axiomes de la communication technique est de garder les choses simples. Mais parfois, une communication complexe est la meilleure alternative.

De nombreux types d’informations ont leur propre vocabulaire accompagné de conventions pour la communication visuelle. Prenez l’exemple suivant :

La plupart d’entre vous reconnaîtront certainement ici de la musique, mais êtes-vous capable de lire la partition et d’identifier le morceau ? (en voici un enregistrement)

Si vous savez lire des partitions, vous pouvez tirer une énorme quantité d’information de cet extrait : les notes et les rythmes, les phrasés, les nuances (très fort ou très faible), quel instrument utiliser (cet extrait n’indique pas explicitement un piano, mais c’est suggéré par la façon dont la musique est organisée), les placements de doigts, etc. Dans cet exemple, la connaissance de la musique Italienne est utile pour comprendre « sempre pianissimo e senza sordini » (toujours très calme et sans sourdine) et d’autres phrases.

Voici un autre exemple différent d’un langage visuel spécialisé :

Voici le résultat du modèle complet :

Les modèles de tricots, comme la musique, utilisent un ensemble standard de symboles. Mais malheureusement pour la communauté mondiale du tricot, il existe de nombreuses variantes régionales. (Le problème est encore pire en crochet, où des termes comme « double crochet » [bride, en français] ou « treble/triple crochet » [double bride, en français, merci Madame pour la traduction] ont une signification différente dans les modèles en anglais Britannique et les modèles en anglais Américain). Ceci dit, il est faisable pour un tricoteur qui parle seulement anglais d’utiliser un modèle de tricot russe ou japonais.

Ces exemples m’ont immédiatement rappelé cette interview de Richard Feynman, prix nobel de physique. Je vous avais déjà montré cet extrait en février dernier en m’intéressant à la première partie de l’interview. Interrogé par un journaliste agacé qui cherche à comprendre pourquoi des aimants se repoussent quand on les colle. Dans cette deuxième partie, Richard Feynman lui explique pourquoi il ne peut pas lui répondre (à partir de 6:09).

Je ne peux pas vous expliquer cela dans des termes qui vous seraient familiers. Par exemple, si je vous expliquais que les aimants s’attirent comme s’ils étaient reliés par un élastique, je tricherais avec vous. Parce que rapidement vous me poseriez des questions concernant la nature des élastiques. Et si vous êtes suffisamment curieux, vous me demanderiez pourquoi des élastiques tendent à revenir à leur forme initiale, et je devrais alors vous expliquer cela en terme de forces électriques, ce qui était exactement ce que je voulais éviter de vous expliquer à la base. Donc j’aurais triché vraiment pauvrement.

Donc je ne vais pas pouvoir vous donner une réponse à votre question « Pourquoi est-ce que les aimants s’attirent ? », à part vous dire que c’est effectivement le cas. Et aussi vous dire que ça fait parti des éléments de ce monde, avec les forces électriques, les forces magnétiques et les forces gravitationnelles parmi tant d’autres. Si vous étiez étudiant je pourrais aller encore plus loin et vous expliquer que les forces magnétiques sont liées aux forces électriques, de manière très intime. Que la relation entre les forces de la gravité et les forces électriques reste inconnue. Et ainsi de suite.

Mais je ne peux vraiment pas faire un bon travail, voire même le moindre travail, pour expliquer les forces magnétiques dans des termes qui vous seraient plus familiers, parce que je ne le comprends pas moi même dans des termes qui vous sont plus familiers.

Tout cela m’a rappelé un travail qui m’a occupé en partie cette semaine. Il y a quelques années, nous avions développé un outil de génération de code HTML remplaçant certains codes de templates par des valeurs saisies dans un formulaire. A l’époque, on avait opté pour une écriture des codes de templates la plus simple possible, du genre [[field_type:field_name]]. Deux ans plus tard, en remettant le nez dans ce projet, cette écriture me semble des plus farfelues. A vouloir créer un système de templates lisible par n’importe qui, on a omis de rendre ça lisible pour un développeur. Notre outil étant destiné uniquement pour nous en interne, entre développeurs, il n’y avait aucune raison à vouloir chercher à simplifier cette écriture pour un néophyte.

Ça m’a rappelé la différence d’écriture qu’on peut trouver entre un template Smarty en PHP et un template WordPress. Smarty est un très bon système de template si vous souhaitez à tout prix masquer à votre audience (créateurs de thèmes, développeurs, intégrateurs) quelque chose qui pourrait ressembler à du code. Mais en tant qu’intégrateur, je trouve que c’est particulièrement horrible à lire et très rigide à manipuler. A l’inverse, WordPress propose simplement un ensemble de fonctions. Ça ressemble à du PHP, ça sent le PHP : c’est du PHP, et rien n’est fait pour essayer de le cacher. C’est probablement un peu plus décourageant pour un néophyte qui voudrait se lancer dans la création d’un thème WordPress.

Mais ça a le mérite d’imposer un minimum de rigueur. Si vous voulez jouer de la musique, il va falloir apprendre à lire des partitions ou des tablatures. Si vous voulez tricoter, il va falloir apprendre à lire des modèles de tricot. Si vous voulez comprendre comment fonctionnent des aimants, il va falloir comprendre la physique. Si vous voulez coder, il va falloir comprendre comment coder.

Arrête de faire ton Homer !

La semaine dernière j’ai lu Subcompact Publishing, une très longue et très complète analyse par Craig Mod des applications de magazines numériques.  Il part de l’exemple de la version iPad du magazine Vanity Fair qui nécessite plusieurs écrans d’explications pour comprendre comment s’en servir. Et il répond alors magnifiquement à la question : « Comment en sommes-nous arrivés à des interfaces si complexes ? »

Peut-être que nous avons fait nos Homer.

Quand il a été demandé à Homer Simpson de créer sa voiture idéale, il a créé The Homer. Sans retenue, le processus d’Homer était additif. Il ajouta trois klaxons et une bulle spéciale insonorisée pour les enfants. Il ajouta plus à tout ce que les voitures étaient déjà. Plus de klaxons, plus de porte-gobelets.

La voiture d'Homer Simpson

Dans le design de produit, l’exercice le plus facile est de faire des ajouts. C’est le moyen le plus facile pour faire d’un vieux truc un nouveau truc. L’exercice le plus difficile est de reconsidérer le produit dans le cadre du présent. Un cadre qui peut être très différent de ce moment où le produit avait été initialement conçu.

C’est une parfaite illustration. La prochaine fois que je me surprendrais ou surprendrais l’un de mes collaborateurs à vouloir ajouter des fonctionnalités sans queue ni tête à un site, je n’aurais qu’une chose à dire : « Arrête de faire ton Homer ! ».

24 jours de web

Je n’ai pas beaucoup écrit ces deux dernières semaines, et ce pour deux raisons. La première, c’est que j’ai beaucoup travaillé la refonte d’un gabarit d’e-mail responsive pour un client. C’était un travail très intéressant et enrichissant. Mais c’est aussi le genre de travail qui donne envie de passer sa soirée prostré dans sa douche en pleurant. J’y reviendrais prochainement. Mais surtout, si je n’étais pas très actif sur ce blog, c’est parce que j’étais occupé sur le lancement d’un autre projet : 24 jours de web.

Inspiré par 24ways.org, 24 jours de web est un « calendrier de l’avent pour les gens qui font le web d’après ». Chaque jour jusqu’au 24 décembre, vous aurez droit à un nouvel article sur le design, l’intégration, le développement, l’accessibilité, etc. Et jusqu’au 24 décembre, le site vous invite à faire un don à une association caritative.

J’ai lancé ce projet principalement pour le fun. Mais j’en tire déjà beaucoup de leçons sur l’organisation d’un projet collaboratif dans des délais relativement courts. Les premiers retours que j’ai pu lire sur Twitter me semblent plutôt enjoués. Et vous aurez même droit à une surprise inutile totalement débile si vous faites un don.

Je vous invite donc cordialement à découvrir le site et à le suivre tout au long du mois de décembre. Et si vous avez des remarques ou des suggestions, n’hésitez pas à me les soumettre.

Le troisième âge du web

Le problème du responsive design

J’ai donné un lightning talk à Paris Web

Adobe et le web

Un bon concepteur web est un bon utilisateur

Un placeholder ne remplace pas un label

Les animations de menus déroulants sur le web

L’intégration, c’est faire des choix

Les résultats d’Apple pour le quatrième trimestre 2012

Véronique Marino – Compréhension de l’autisme

Jake Archibald – Application cache is a douchebag

Mike Monteiro – How Designers Destroyed the World

Littéralement

Les smart banners sous iOS 6

Les filtres CSS