HTeuMeuLeu

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.

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.

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 ! ».

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.

Cette semaine, j’ai lu avec attention la longue tirade de Gaétan Weltzer intitulée « Qu’est-il arrivé au webdesign ? »

Il y a quelques années, [le webdesign] et moi étions jeunes et fous, nous courions ensemble nus dans un pré rempli de coquelicots et de tiques. Déjà intégrateur accompli et avec des notions d’ergonomie basiques, je comprenais suffisamment comment il fonctionnait pour que lui et moi laissions libre court à notre créativité. C’était des fois moche, des fois pas super lisible ou au contraire agressif, mais c’était du design ! Du design original et unique.

La communauté du webdesign était dans une lancée splendide où ce métier était en essor fulgurant et a vu naître de nombreux talents. Les blogs de designs se multipliaient (c’était à l’époque l’apparition du phénomène des blogs, ils allaient modifier toute l’économie de la planète et ériger un nouvel ordre) et chacun partageait ses coups de cœurs, ses ressources, des tutoriels, ses brushs Photoshop… et je ne me lassais pas de contempler les sélections de webdesign ou de portfolios, tous plus créatifs les uns que les autres.

A cette époque lointaine, le poids des images était une contrainte encore plus forte qu’aujourd’hui. Mais malgré ça, on s’en foutait ! La passion qui nous animait nous poussait à créer des webdesigns avec toujours plus d’images, d’animations Flash, de petite textures sur une barre de titre, de splendides illustrations. Au diable le poids ! On repoussait notre imagination, on créait les nouvelles tendances. Webdesigns texturés de partout, d’autres imitant des scènes de la vie courante (comme un bureau vu du dessus, oui, c’était il n’y a pas si longtemps !). Et cette mode des designs 2.0 qui avait tant marqué les tendances ! en bien comme en mal…

Ce n’est pas la première fois que je lis ce genre d’article de graphiste déplorant le manque d’originalité des refontes de sites actuels. Mais je pense que ça tient en une phrase simple (excusez mon langage) : sur le web, c’est fini les conneries.

Il y a quelques semaines, j’avais lu un tweet de Francisco Inchauste concernant le design d’applications mobiles qui est resté profondément ancré dans mon esprit :

On est encore à un stade similaire à lorsqu’on a inventé la télévision et qu’on s’asseyait devant une caméra pour lire le scénario d’une émission parce que les gens étaient encore habitués à la radio.

Je pense que cette métaphore est particulièrement valable pour le web. On a passé les 20 dernières années à essayer de reproduire sur le web ce qu’on faisait dans la presse papier, puis ce qu’on faisait dans des CD-Roms interactifs, puis ce qu’on faisait à la télévision, parce qu’on voulait se rapprocher de ce que les gens connaissaient. Je me souviens encore de jeuxvideo.com qui ne publiait des actualités qu’une fois par jour, à 19 heures. Ce n’est pas ça le web. Et le résultat n’était qu’une médiocre imitation d’autres supports de communication.

Je pense que nous arrivons dans le troisième âge du web, que je décrirais comme suit :

1. On est sur le web.
2. On fait du business sur le web.
3. On fait notre business sur le web.

Le premier âge, caricaturalement dans les années 1990, consistait à être sur le web. « Youpi, on a un site Internet ! Alors l’adresse c’est h t t p deux points slash slash trois double v… point com. On n’a pas encore de site marchand, mais vous pouvez télécharger notre catalogue en BMP. »

Le deuxième âge, dans les années 2000, consistait à faire du business sur le web. « Nouveau ! Passez votre commande dans notre catalogue ou sur notre site Internet ! »

Le troisième âge, dans lequel on entre tout doucement, consiste à faire la majorité de son business sur le web. Fini la presse papier. Fini les magasins (ou presque). Dans un contexte où le web représente alors une majorité de votre activité, un site internet n’est plus un support de communication pour votre activité. C’est votre activité.

Il y a quelques mois, je discutais avec un responsable technique d’un grand site de vente à distance français. Il m’expliquait que la moindre modification sur une fiche produit pouvait entraîner des centaines de milliers d’euros de perte de chiffre d’affaires par jour. Un simple changement de couleur de bouton, un simple changement d’icône, le moindre texte, le moindre kilo-octet en plus. La moindre modification passe alors par des mois d’A/B Testing, d’étude analytiques des statistiques du site, pour ensuite adapter, retester, et peut-être en fin de compte adopter une modification.

Dans un tel contexte, il est évident qu’il est hors de question de dire « qu’on s’en fout des contraintes » ou « au diable le poids de la page ». Il en va de la vie de l’entreprise. Le métier de webdesigner est donc en train de se professionnaliser. Le métier de webdesigner n’est pas de faire de l’art. Dans certains cas, il ne s’agit même pas d’être créatif. Si ça ne vous plaît pas, alors changez de métier.

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 :

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.

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.

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.

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. 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).

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.

Ce week-end, j’ai regardé la vidéo du test du Nexus 4 de The Verge. Les tests vidéo de The Verge sont particulièrement bien réalisés, et le Nexus 4 semble être un bon rapport qualité/prix pour un téléphone Android. Mais à un moment, je suis un resté bloqué devant un petit détail de l’interface d’Android. De 4:15 à 4:30 dans la vidéo, Joshua Topolski joue avec le menu de notifications et le nouveau panneau de préférences.

Ma réaction a été de me dire : « Whao, cette animation est vraiment naze ». Alors que je regardais ce passage en boucle pour comprendre pourquoi, mon cerveau n’arrêtait pas de me dire « Ce n’est pas possible. On n’y croit pas une seule seconde. Pitié arrête moi ça ».

A ce stade de votre lecture, il y a quelque chose que vous devez savoir sur moi : j’adore les animations. Et pas juste des courts-métrages animés, comme celui-ci, celui-ci ou celui-là. Mais plus particulièrement, les animations d’interface. Bien réalisé, c’est le genre de détails qui peut totalement transformer et donner vie à une interface. Et dans ce domaine, Apple maîtrise plutôt bien le sujet.

Alors j’ai me suis tourné vers Youtube pour voir des vidéos du centre de notifications d’iOS, et essayer de comprendre en quoi l’animation d’Apple était si différente. Voici une comparaison côte à côte.

iOS et Android utilisent deux métaphores différentes pour cet effet d’apparition, que j’appelerais le tiroir et le parchemin. Quand vous ouvrez un tiroir, le contenu qui se révèle à vous suit le mouvement du tiroir. Pour voir le contenu qui apparaît, il suffit de laisser votre regard fixe vers le haut du tiroir. Quand vous déroulez un parchemin, le contenu qui se révèle à vous reste fixe. Pour voir le contenu qui apparaît, vous devez suivre du regard le déroulement en cours.

Retranscrits dans notre monde informatique, vous comprendrez déjà que l’effet du parchemin est naturellement plus fatigant pour notre cerveau et nos yeux. Mais surtout, sans notion physique et sans indication visuelle du contenu restant à dérouler, je pense que cette métaphore ne fonctionne pas.

Et le problème, c’est que sur le web, on en voit partout, des menus déroulants en parchemin. Voici quelques exemples glânés sur le web et via Twitter (merci @synapse_studio) : Ville d’Agen, Beats by Dr Dre, World Trade Center de Lyon, Highcharts JS, La cinémathèque française.

Alors cela ne signifie pas qu’il faut bannir les animations en parchemin. Mais ça signifie que si vous tenez vraiment à faire une animation en parchemin, vous allez devoir faire quelques kilomètres en plus pour que ça fonctionne vraiment. Récemment, Justin Windle a publié Makisu, une impressionnante démonstration de menu déroulant en CSS 3D. Je pense que cette animation rend particulièrement bien car elle est très détaillée. Mais le rendu est du coup visuellement un peu trop lourd et beaucoup trop caractérisé pour une utilisation réelle sur un site institutionnel.

Je pense que la propagation de cette animation est dûe en partie à jQuery. En jQuery, pour faire une animation en parchemin, il suffit d’appeler la fonction slideDown() sur n’importe quel élément. Et c’est tout. A l’opposé, pour faire une animation en tiroir, il faudra surcharger son code HTML pour avoir un conteneur avec une hauteur souple et un overflow:hidden, pour ensuite jouer sur un margin-top négatif sur un élément global à l’intérieur. Ce n’est pas forcément plus compliqué, mais ça demande plus de travail, et plus de réflexion. Certains sites, comme Converse, font ça pas trop mal.

Après jQuery, il devient désormais plus facile que jamais de faire des animations dans une page web. Mais comme j’aime à le répéter : juste parce que vous pouvez le faire ne signifie pas que vous devez le faire. Voici quelques conseils pour animer vos sous-menus :

1. Une animation sert à attirer l’attention et à renforcer la compréhension d’une action. Si vous n’êtes pas sûr de ce que vous faites, ou si vous n’avez pas beaucoup de temps pour travailler sur ces animations, alors ne faites rien. Une mauvaise animation va rendre votre site pire que sans animation.
2. A moins que vous n’ayez de solides arguments, privilégiez une animation en tiroir (plus reposante visuellement), et pas en parchemin (plus difficile à suivre pour notre cerveau, et beaucoup plus complexe à mettre en place pour être réellement efficace).
3. Ne répétez pas votre animation à l’apparition de chaque sous-menu quand on passe d’un onglet à un autre. Votre animation doit se jouer à la première ouverture d’un sous-menu, et puis c’est tout. Cela signifie que même si vous utilisez des animations CSS, vous aurez besoin d’un peu de JavaScript pour détecter ce comportement. Si cela vous semble trop contraignant à mettre en place, alors ne faites pas d’animation.

S’il y a une chose particulièrement importante que vous devez savoir à propos de l’intégration, c’est qu’il s’agit avant tout de faire des choix. Tout le temps. Choisir la bonne balise, le bon nom de classe, la bonne méthode de positionnement, le bon framework, etc… En mai dernier, j’abordais déjà (maladroitement) ce sujet dans mon article sur les contraintes de l’intégration. Mais l’importance de nos choix en intégration m’est revenu à l’esprit à travers deux exemples.

A Paris Web, j’ai pu assister au très bon atelier de Jean-Pierre Vincent sur la performance sur les sites mobiles. Ce qui m’a marqué, c’est la dualité entre certaines bonnes pratiques. Par exemple, afin d’améliorer le temps de chargement de votre site, il est conseillé de diminuer le nombre de requêtes. Une bonne pratique consiste alors à privilégier l’emploi de propriétés CSS pour éviter d’utiliser des images pour des effets graphiques (bords arrondis, ombres, fond en dégradés). Sauf que l’utilisation de ces propriétés a un coût important sur le temps de rendu de la page une fois téléchargée côté client. En optimisant d’un côté, vous alourdissez de l’autre. Quel choix allez vous faire ?

Et puis la semaine dernière, il y a eu ce tweet de Raphaël Goetter : « WebPerf says : « id is the best CSS selector »; OOCSS says : « don’t use id ». Well.« . Si l’impact bénéfique sur la performance d’un id n’est plus vraiment d’actualité, son utilisation reste toujours sujet à débat. En utilisant des ids dans votre HTML, vous aurez potentiellement une page plus légère. Mais vous serez contraint d’alourdir vos sélecteurs CSS, en compliquant au passage la maintenabilité de votre code. Quel choix allez vous faire ?

Si certains choix vont être faits en réponse à des objectifs clairs de votre site, d’autres vont plutôt relever de votre personnalité d’intégrateur. En mai dernier, je résumais  :

S’il est assez naturel de voir la personnalité d’un graphiste transparaître à travers ses créations, il en va de même pour un intégrateur. Mais contrairement à un graphiste, le travail de l’intégrateur est souvent invisible, et beaucoup plus difficile à juger.

L’intégration, c’est faire des choix. Mais souvent, il ne s’agit pas forcément de faire le meilleur choix, mais plutôt de faire le moins pire.

Après 3 trimestres exceptionnels, Apple a présenté hier ses résultats pour le quatrième trimestre 2012, clôturant ainsi son année fiscale.

La société a publié un chiffre d’affaire pour le trimestre de 36 milliards de dollars et un bénéfice net de 8,2 milliards de dollars, ou 8,67$ par action diluée. […]

La société a vendu 26,9 millions d’iPhones au cours de ce trimestre, soit une hausse de 58% en comparaison au même trimestre il y a un an. Apple a vendu 14 millions d’iPads au cours de ce trimestre, soit une hausse de 26% en comparaison au même trimestre il y a un an. La société a vendu 4,9 millions de Macs au cours de ce trimestre, une hausse de 1% en comparaison au même trimestre il y a un an. Apple a vendu 5,3 millions d’iPods, une baisse de 19% en comparaison au même trimestre il y a un an.

Si on additionne les chiffres de l’année 2012, ça donne :

• 125,04 millions d’iPhones vendus (37,04 + 35,1 + 26 + 26,9)
• 58,23 millions d’iPads vendus (15,43 + 11,8 + 17 + 14)
• 18,1 millions de Macs vendus (5,2 + 4 + 4 + 4,9)
• 35,2 millions d’iPods vendus (15,4 + 7,7 + 6,8 + 5,3)

Avec 41,73 milliards de dollars de bénéfices, Apple enregistre ainsi le plus gros record de bénéfices depuis 2008 (détenu alors par ExxonMobile). De manière assez amusante, la seule société d’électronique qui s’en sort aussi bien en ce moment, c’est Samsung.

Je le dis et je le répète : nous vivons dans le monde d’Apple. Je suis curieux de voir combien de temps cela va durer, et ce que cela va donner en 2013.

La conférence de Véronique Marino à Paris Web la semaine dernière, Comprendre l’autisme pour améliorer les projets transmédias, était pour moi une très bonne surprise. Certes, ce n’était pas une grande conférence ni du grand spectacle, comme ont pu l’être les conférences de Mike Monteiro ou Jake Archibald. Mais c’était une conférence avec un sujet important, le genre de sujet qu’on garde bien dans un petit coin de sa tête et qui mûrit en nous tout doucement.

La conférence tournait beaucoup autour de la description de l’autisme et les effets du handicap, mais aussi sur les solutions pour accompagner les autistes. Les exemples n’étaient pas nombreux, mais pourtant bien marquants.

Par exemple, les autistes comprennent difficilement le langage imagé. Donc si vous dîtes à un autiste que vous allez « manger un buffet froid », il comprendra plutôt que vous allez manger le meuble de votre grand-mère sans le réchauffer. Et ça, ça pose évidemment des problèmes dans la vie quotidienne, notamment face à des pictos.

Alors qu’ils sont d’usage courant, un autiste ne comprendra pas les pictogrammes de toilettes avec un homme ou une femme. Pour lui, c’est juste un homme ou une femme. Rien n’indique qu’il s’agit de toilettes dans le pictogramme en lui-même. Ça laisse à réfléchir sur les pictogrammes qu’on utilise sur nos sites (et ça rejoint l’autre excellente conférence de Sébastien Desbenoit sur l’utilisation des pictos).

L’autisme est un sujet que je connais peu, mais qui m’attire beaucoup. En début d’année, j’étais tombé sur cet article intitulé « Attention to Detail » qui m’avait particulièrement marqué (et il se base sur des exemples de Toy Story et Plants vs Zombies, donc allez le lire, vraiment).

Il y a une société appelée Specialist People Foundation qui traite abondamment des problèmes dans ce domaine. Elle emploie des personnes atteintes d’autismes et autres troubles similaires, et s’appuie sur la différente nature de perception de ses employés pour s’attaquer à une variété de problèmes. J’aime beaucoup de chose à propos de cette organisation, mais je pense que le plus impressionnant est comment ils ont efficacement créé une force de quelque chose qui est perçue comme une faiblesse.

« Nos consultants ont une passion pour le détail sans égal, et apportent des compétences uniques à des tâches pour lesquelles les employés de la plupart des sociétés ont moins de motivation à réaliser, laissant ainsi plus de places à des erreurs. Les caractéristiques uniques de l’autisme font que nos consultants apprécient vraiment des tâches que la plupart des employés trouvent ennuyeuses, répétitives ou difficiles dues au niveau de détail et de concentration requis.« 

En attendant la vidéo de Paris Web, vous pouvez consulter ses slides, ou regarder la vidéo de sa conférence donnée l’année dernière à Web-In à Montréal.

Suite à Paris Web la semaine dernière, j’avais très envie de vous parler de la conférence de Jake Archibald : Application cache is a douchebag. J’avais vu passer les slides de sa conférence en début d’année et j’avais trouvé ça plutôt rigolo. J’avais tort. C’est carrément excellent.

Jake Archibald prend un sujet en apparence assez simple, le cache d’application en HTML5, et explique en détails à quel point en pratique c’est complexe. Et le tout en enchaînant des blagues à un rythme soutenu tout au long de sa conférence. A tel point que Jake Archibald ferait passer Le comte de Bouderbala pour Anne Roumanoff.

Voici comment sa conférence débute.

A l’époque des modems 56k, on utilisait seulement Internet pour des courtes durées. Vous vous connectiez, vous vérifiez vos e-mails, et puis vous partiez. Mais maintenant on est presque toujours connecté. Et ça transforme le fait de ne pas avoir de connexion en un gros problème. Ceux qui comme moi doivent utiliser une connexion à l’étranger savent de quoi je parle. Quand je me connecte depuis l’étranger, je me sens comme un accro au jeu. A chaque fois que je me connecte, je sais que je dépense de l’argent. Mais je ne peux pas m’en empêcher. Je dois savoir ce qu’Internet dit sur mon dos ou ce qu’il se passe. Mon téléphone émets un petit son quand j’utilise des données en 3G depuis l’étranger. Mais je n’en ai pas vraiment besoin car j’arrive presque à entendre les bouchons de Champagne sauter à chaque fois que j’utilise un méga-octet.

Et ma propre dépendance me dégoûte vraiment. Il y a un moment, là où je travaillais, je devais aller faire la grosse commission aux toilettes. Il y avait cinq cabinets à l’intérieur. Malheureusement, les quatre premiers étaient occupés. En général ce n’est pas grave, je n’ai besoin que d’un cabinet. Mais je savais par mes expériences passées que le Wi-fi du bureau n’allait que jusqu’au quatrième.

J’y ai réfléchi un instant et je me suis dit : « Non. Je trouve cela totalement inacceptable. » Et j’ai fait demi-tour et je suis retourné à mon bureau et j’ai attendu.

Je suis devenu quelqu’un qui a besoin d’une connexion Internet pour aller faire caca.

Et c’est ainsi que Jake Archibald nous emmène dans les méandres du fonctionnement du cache d’application, en personnifiant cette spécification, et en la présentant comme un trou-du-cul (ou plus précisémment un « douchebag« ). Le genre de personne qui dirait « I’m going to turn your offline user experience from sucks-ass… to success !« .

J’étais mort de rire quand Jake expliquait qu’il ne faut surtout jamais changer le nom de fichier de manifeste. En faisant ça, vous rentrez dans une boucle infinie ou vos anciens utilisateurs ne recevront plus jamais aucune mise à jour.

J’ai fait ça sur Sprite Cow de façon totalement idiote. Et j’ai mis 30 minutes à me rendre compte de ce que j’avais fait et de pouvoir le corriger. D’après Google Analytics, 20 personnes ont visité le site pendant cette période. Ces 20 utilisateurs ne recevront plus jamais la moindre mise à jour du site. Jamais, jamais.

Ils vivent maintenant la vie de développeurs Drupal. Tous les autres s’amusent à faire des trucs nouveaux super cools, et eux sont coincés avec la vieille même merde.

Vous l’aurez compris, je vous recommande vraiment de voir cette conférence. Si la vidéo de Paris Web n’est pas encore en ligne, vous pourrez en trouver quelques unes dans d’autres événements, comme celle-ci à Mobilism 2012. Les slides de sa conférence sont eux déjà disponible sur le site de Paris Web. Et vous pouvez également lire son article du même nom chez A List Apart publié en mai dernier.

La semaine dernière, j’ai eu la chance d’assister aux conférences de Paris Web. Je vais essayer de revenir cette semaine sur les conférences qui m’ont le plus marqué. L’une des principales têtes d’affiche était Mike Monteiro, avec sa conférence intitulée How Designers Destroyed the World.

J’avais découvert Mike Monteiro via sa conférence « Fuck you, pay me« , puis via ses podcasts sur Mule Radio Syndicate, ou encore son travail via sa société Mule Design Studio sur AllThingsD ou Evening Edition, et en avril dernier son livre « Design Is a Job » (horriblement traduit en français en « Métier web designer« ).

Comme le nom de sa conférence l’indique, Mike Monteiro nous raconte comment les designers ont détruit le monde. Comment les designers ont détruit le monde en se préoccupant de projets futiles plutôt que de s’attarder sur des choses qui comptent vraiment. A-t-on vraiment besoin de plus de 60 projets de pochettes pour iPad sur Kickstarter ? A-t-on vraiment besoin de cette veste imaginée par des étudiants du MIT qui se gonfle quand on reçoit un J’aime sur Facebook ?

Mike tourne ensuite toute sa conférence autour d’un exemple concret de mauvais design qui a ruiné la vie d’un être humain. A cause des préférences incompréhensibles sur la vie privée de Facebook, Bobbi Taylor a révélé malgré elle son homosexualité, jusqu’alors tenue secrète, à son père. Problème : son père est un trou du cul et l’a menacée de la renier et s’est mis à insulter les gens de sa chorale gaie sur Facebook. Comme le dit Mike, « Je suis père d’un garçon, et ceci n’est pas une façon de traiter vos enfants ». Vous pouvez lire l’article original du Wall Street Journal ou en français sur les blogs du Monde.

Mike enchaîne alors les conseils pour éviter de se retrouver dans une telle situation. « Décide d’être le connard qui va faire bouger les choses. Personne ne te donnera la permission. » (piqué chez Les Intégristes). Et surtout : si vous n’êtes pas d’accord avec ce qu’on vous demande de faire, dites non. Quittez votre boulot. Mais arrêtez de faire du mauvais travail.

« You are responsible for the work you put into the world » est à mon avis la phrase qui résume le mieux sa conférence (thème qu’on retrouve largement dans son livre).

Ce que j’ai particulièrement aimé, c’est que cela ne concerne vraiment pas que les designers au sens graphique du terme. Cela concerne tous les créateurs. Les développeurs, les intégrateurs, les entrepreneurs, les chefs de projet. Si vous créez quelque chose, que ce soit une affiche, un site web, un article sur votre blog, une vidéo sur Youtube, vous êtes responsable de l’impact que cela aura sur les gens.

Reste que certains conseils de Mike sont vraiment propres à la culture américaine, et ça s’est senti pendant les questions-réponses. Aux États-Unis, vous pouvez quitter votre boulot un lundi soir et trouver un autre travail le mardi matin, comme si de rien n’était. En France, on préfère vous garder deux mois en préavis au cas où, même si vous avez manifestement montré votre désintérêt dans votre boîte en démissionnant.

Ça n’en reste pas moins une très bonne conférence, et un très bon moment. L’ambiance dans la salle était électrique, presque religieuse. Alors oui Mike Monteiro lisait son texte sur son écran. Oui, il utilise l’effet de fumée de Keynote dans ses slides. Ça n’en reste pas moins un très bon spectacle avec quelques bonnes idées à retenir et à mettre en pratique.

En attendant que la vidéo de la conférence ne soit en ligne (si on en croit les années précédentes, ce ne sera pas avant avril prochain), je vous recommande vraiment le livre « Design is a job« . Je vous invite également à voir sa conférence « What Clients Don’t Know (… And Why It’s Your Fault) » donnée au TYPO Talks en mai dernier, où Mike raconte comment il s’est acheté un vélo, et comment éduquer les clients en leur expliquant notre travail.

J’adore les petites erreurs du quotidien, celles qui résultent d’une petite incompréhension ou d’un manque d’interrogation. Je suis retombé sur ma petite collection d’exemples d’erreurs glanées sur le web, issues de demandes prises un peu trop… littéralement.

Comme par exemple, quand vous demandez à un votre collègue d’écrire sur votre camion citerne « Diesel fuel » et « No smoking » en arabe.

Ou quand vous demandez à votre boulanger un gateau avec écrit dessus « Meilleurs voeux Suzanne » et en-dessous de ça « Tu vas nous manquer ».

Ou quand votre collègue devait traduire un panneau anglais en gallois, et qu’il a traduit votre première réponse à son mail de demande du texte à traduire (qui manque de bol était « Je ne suis pas au bureau pour le moment. Envoyez tout message à traduire. »).

Ou quand vos ouvriers ont creusé un trou dans votre plafond de la forme des nuages de révision d’AutoCAD.

Ou quand vos ouvriers ont pris la flèche vers l’info-bulle de votre plan pour une découpe dans vos escaliers.

Ou quand l’acteur principal de votre série hurle à voix haute la didascalie censée lui indiquer son intonation (en l’occurrence, « disappointed« ).

Des erreurs, ça arrive à tout le monde. Mais celles-là, je prie pour les éviter.

Dans iOS6, Safari intègre une nouvelle fonctionnalité assez discrète : les smart banners. Une smart banner (ou « bannière intelligente », en opposition à toutes ces bannières stupides), c’est une bannière qui vient s’ajouter en haut de votre site dans Safari pour mettre en avant votre application iOS.

Pour ce faire, il vous suffit d’ajouter la balise meta suivante avec l’identifiant de votre application, n’importe où dans votre code HTML. Pour obtenir l’identifiant de votre application, vous pouvez utiliser l’iTunes Link Maker d’Apple.
<meta name="apple-itunes-app" content="app-id=562772514" />

La bannière affiche alors l’icône, le nom, le développeur, la note et le prix de l’application, ainsi qu’un lien pour y accéder depuis l’App Store et une croix pour faire disparaître définitivement la bannière. Voici le rendu final sur une page web (avec ici l’excellentissime Devil’s Attorney).

Si vous faites parti du programme d’affiliation d’Apple, vous pouvez également ajouter votre identifiant d’affilié comme suit :

<meta name="apple-itunes-app" content="app-id=562772514, affiliate-data=partnerId=42&siteID=darkmaul" />

Sur son blog, David Smith détaille également l’existence d’un paramètre supplémentaire permettant de passer une URL à votre application dès son premier lancement, pour afficher par exemple un contenu spécifique.

Je ne suis en général pas friand de ce genre de gadget purement marketing, mais c’est clairement beaucoup moins intrusif que des alertes JavaScript ou des lightbox maison. Et ça vous évite un peu de tomber dans les pratiques mobiles du Mal.

S’il y a bien une spécification qui m’excite plus que tout parmi les nouveautés de HTML5 et CSS,  c’est bien celle des filtres CSS. Cette spécification regroupe deux notions importantes : les filtres par défaut, et les filtres personnalisés. En voici un rapide aperçu.

La propriété filter permet d’appliquer des effets à n’importe quel élément d’une page web. Par défaut, la spécification prévoit plusieurs fonctions de filtres qui vont jouer sur le rendu de l’élément. On retrouve des filtres de couleurs (grayscale, sepia, saturate, invert, brightness, contrast, opacity) ou des filtres de transformation (blur, drop-shadow). Prenons l’exemple simple du filtre de niveau de gris (grayscale). Ce qui nécessitait un rendu côté serveur ou via un plugin il y a 5-6 ans, puis quelques lignes de JavaScript en Canvas il y a 2-3 ans, est désormais devenu un one-liner.

filter:grayscale(1);

La cerise sur le gateau, c’est que comme il s’agit de propriétés CSS à valeur numérique, vous pouvez les animer grâce à la propriété transition ou aux déclarations d’animation CSS.

Parmi ces filtres natifs, la fonction drop-shadow est particulièrement intéressante. Contrairement à la propriété box-shadow (qui se contente de faire une ombre rectangulaire autour d’un élément), le filtre CSS drop-shadow s’adapte aux formes. Cette démo issue de cet article chez Bricss illustre très bien la différence entre les deux propriétés.

Mais là où ça devient vraiment intéressant, c’est avec les filtres personnalisés, connus aussi sous le nom de shaders CSS. Un shader, dixit Wikipédia, est « une suite d’instructions donnée à un ordinateur, utilisé en image de synthèse, pour paramétrer une partie du processus de rendu réalisé par une carte graphique ou un moteur de rendu logiciel ». Présentés pour la première fois par Adobe en octobre 2011 et décrits comme « des effets cinématiques pour le web« , les shaders CSS ont rejoint la spécification des filtres en août dernier.

Pour créer un shader CSS, pas de JavaScript, mais du GLSL (langage proche du C déjà utilisé en 3D avec OpenGL, WebGL ou DirectX). AlteredQualia a récemment écrit un article très complet pour débuter avec les shaders CSS. Concrètement, il existe deux types de shaders :

• Les vertex shaders, qui permettent de déplacer et déformer les sommets d’un polygone
• Les fragment shaders, qui permettent de modifier le rendu des pixels d’un objet

J’ai récemment commencé à lire Switch : how to change things when change is hard de Chip et Dan Heath. Comme son titre l’indique, le livre explique comment parvenir à changer des choses quand le changement semble impossible. Et pour ça, tout le livre tourne autour d’une analogie sur notre cerveau : l’éléphant et son cavalier. Voici un extrait du premier chapitre.

Le savoir conventionnel en psychologie est que le cerveau a deux parties indépendantes qui travaillent en permanence. Premièrement, il y a ce qu’on appelle le côté émotionnel. C’est la part de vous qui est instinctive, qui ressent de la douleur et du plaisir. Deuxièmement, il y a le côté rationnel, aussi connu comme le système réflectif ou la conscience. C’est la part de vous qui délibère et analyse et se penche vers l’avenir.

Ces dernières décennies, les psychologues ont beaucoup appris sur ces deux systèmes, mais bien sûr l’Homme a toujours été conscient de la tension. Platon disait que dans nos têtes nous avons un cocher rationnel qui doit maîtriser un cheval indiscipliné qui « répond à peine à la cravache et l’aiguillon combinés ». Freud écrivait à propos de l’identifiant égoïste et du superégo consciencieux (et aussi l’égo, qui sert d’intermédiaire entre les deux). Plus récemment, des économistes comportementaux ont surnommé les deux systèmes le Planificateur et le Faiseur.

Mais, pour nous, la tension du duo est mieux capturée par une analogie utilisée par le psychologue de l’Université de Virginie Jonathan Haidt dans son fantastique livre The Happiness Hypothesis. Haidt dit que notre côté émotionnel est un Éléphant et notre côté rationnel son Cavalier. Perché en haut de l’éléphant, le cavalier tient les rênes et semble être le chef. Mais le contrôle du cavalier est précaire car le cavalier est tout petit à côté de l’éléphant. A chaque fois que l’éléphant de six tonnes et le cavalier sont en désaccord sur la direction à prendre, le cavalier va perdre. Il est totalement soumis.

La plupart d’entre nous sont bien trop familiers avec des situations dans lesquelles notre éléphant domine notre cavalier. Vous avez déjà vécu cela si vous vous êtes déjà reveillé en retard malgré votre réveil, si vous avez déjà trop mangé, rappelé votre ex à minuit, procrastiné, essayé d’arrêter de fumer et échoué, laissé tomber le sport, si vous vous êtes déjà mis en colère et avez dit quelque chose que vous regrettiez, abandonné vos cours d’espagnol ou vos leçons de piano, refusé de parler lors d’une réunion parce que vous aviez peur, et ainsi de suite. La bonne nouvelle c’est que personne ne compte les points.

La faiblesse de l’éléphant, notre côté émotionnel et instinctif, est claire : il est fainéant et capricieux, recherchant souvent la récompense à court terme (un cornet de glace) plutôt qu’à long terme (perdre du poids). Quand les efforts pour changer échouent, c’est habituellement la faute de l’éléphant, puisque les types de changements que nous voulons impliquent généralement des sacrifices à court terme pour une récompense à long terme. (On réduit les dépenses aujourd’hui pour obtenir un meilleur bilan l’année prochaine. On évite le cornet de glace aujourd’hui pour une meilleure silhouette l’année prochaine.) Les changements échouent souvent car le cavalier ne peut simplement pas tenir l’éléphant sur la route suffisamment longtemps pour atteindre la destination.

La faim de l’éléphant pour une gratification instantanée est l’opposée de la force du cavalier, qui a habilité de penser à long terme, de planifier, de penser au delà du moment (toutes ces choses que votre animal de compagnie ne peut pas faire).

Mais ce qui peut vous surprendre est que l’éléphant a aussi d’énormes forces et que le cavalier a des faiblesses handicapantes. L’éléphant n’est pas toujours le mauvais garçon. L’émotion est le truc de l’éléphant : l’amour et la compassion et la sympathie et la loyauté. Cet instinct féroce que vous avez pour protéger vos enfants du mal, ça c’est l’éléphant. Ce raidissement de la colonne vertébrale que vous ressentez quand vous devez vous défendre, ça c’est l’éléphant.

Et encore plus important si vous regardez un changement en cours : c’est l’éléphant qui fait avancer les choses. Progresser vers un but, qu’il soit noble ou grossier, demande l’énergie et la conduite de l’éléphant. Et cette force est le miroir de la plus grande faiblesse du cavalier : faire du surplace. Le cavalier a tendance à suranalyser les choses et à surréfléchir. Il y a des chances pour que vous connaissiez des gens qui ont le problème du cavalier : votre ami qui peut agoniser pendant 20 minutes avant de choisir ce qu’il va manger pour dîner; votre collègue qui peut se remuer les méninges pour trouver de nouvelles idées pendant des heures mais ne semble jamais pouvoir prendre la moindre décision.

Si vous voulez changer les choses, vous devez attirer les deux. Le cavalier fournit le planning et la direction, et l’éléphant fournit l’énergie. Donc si vous atteignez les cavaliers de votre équipe mais pas les éléphants, les membres de votre équipe auront la compréhension sans la motivation. Si vous atteignez leurs éléphants mais pas leurs cavaliers, ils auront la passion mais sans direction. Dans les deux cas, les défauts peuvent être paralysants. Un éléphant réticent et un cavalier qui fait du surplace peuvent tous deux faire en sorte que rien ne change. Mais quand les éléphants et les cavaliers bougent ensemble, le changement peut arriver facilement.

C’est ma nouvelle analogie préférée.

Cette semaine chez Le Train de 13h37, Anthony Ricaud (développeur web chez Mozilla) parle des dangers d’une culture mono-navigateur dans le monde mobile. Je suis globalement d’accord avec son propos et l’importance des standards sur le web. Par contre, je ne suis pas d’accord avec une partie de son article sous-titrée « Sans Firefox, pas d’iPhone ».

Nous sommes en 2004, Internet Explorer domine le marché des navigateurs, Netscape n’est plus. Après une compétition acharnée, la fameuse Browser Wars, le navigateur avec les fonctionnalités les plus intéressantes a gagné. Oui, c’était bien Internet Explorer le meilleur navigateur à ce moment-là.

Les développeurs web sont vraiment ravis de pouvoir utiliser tous les raffinements d’Internet Explorer 6 : font-face, AJAX, innerHTML. Malheureusement, la plupart de ces fonctionnalités sont inopérantes dans les navigateurs alternatifs de l’époque (Mozilla Suite, Opera, etc.), ce qui limite forcément leurs parts de marché : les utilisateurs pensent qu’ils sont défaillants et retournent donc dans le confort du navigateur dominant.

Imaginons maintenant que l’iPhone sorte dans ce contexte de 2004. Un téléphone mobile révolutionnaire, un iPod à écran panoramique doté de commandes tactiles et un appareil de communication sur Internet innovant.  » Appareil de communication sur Internet innovant  » ?
Avec si peu de sites compatibles ? Je ne crois pas : la plupart des sites incluent du code spécifique à Internet Explorer, rendant Safari iPhone bien inintéressant. Et franchement, un iPod qui passe des coups de fil sans un vrai navigateur, ça n’aurait pas valu ce prix-là. Et toute la révolution de l’internet mobile qui a suivi aurait été bien retardée.

Heureusement, entre la domination d’Internet Explorer et la sortie de l’iPhone, il y a eu un nouvel arrivant qui a changé la donne : Firefox.

La thèse d’Anthony, c’est qu’Apple n’aurait jamais sorti l’iPhone dans un contexte où des millions de sites n’auraient pas fonctionné dessus. Mais c’est pourtant exactement ce qu’ils ont fait. Et ce, délibérément.

Quand Apple a présenté l’iPhone en 2007, le monde s’insurgeait de l’absence de Flash. Et à raison : en 2007, le paysage des navigateurs était représenté principalement par IE6, IE7, et Firefox 2, un peu d’Opera et de Safari (mais pas encore de Chrome). On était alors très loin de l’omniprésence de HTML5 actuelle. Et Flash était alors un standard de facto. Non seulement Flash était utilisé pour lire des vidéos ou jouer à des jeux, mais aussi pour quasiment n’importe quel type d’animation et de contenu : carrousels, menus, sites full-flash. L’horreur. En refusant à Adobe de porter son plugin sur iPhone OS, Apple a délibérément choisi de rendre incompatible (en partie ou totalement) des millions de sites web. C’était une véritable plaie pour les utilisateurs et les auteurs des sites en question, mais l’histoire prouvera que c’était la bonne décision.

Et l’iPhone n’était pas un cas isolé. En 2010, avec l’iPhone 4, Apple a introduit pour la première fois ses écrans Retina, avec des écrans d’une résolution 2x supérieure. Cette année, pour la première fois, Apple a sorti un Macbook Pro avec un écran Retina 13″ d’une résolution de 2880x1800px. Problème : avec une telle résolution, tous les contenus non adaptés apparaissent atrocement flous. Avec ses écrans Retina, Apple a rendu des millions de sites web moches. Mais la bonne nouvelle, c’est que ça pousse les développeurs consciencieux à revoir leurs pratiques. Ce qui était il y a encore quelques années une pratique courante d’avoir du texte dans des images est devenue une pratique à éviter à tout prix. Et même si on est encore au balbutiement de l’adaptation de sites pour écrans Retina, la disparition de textes en image est plutôt une bonne chose pour le web.

Il y a quelques années, je me souviens d’avoir lu un tweet (dont j’ai oublié l’auteur) qui disait quelque chose comme ça :

Avec l’iPhone, Apple a fait plus pour les standards du web que Mozilla en 5 ans.

C’est assez catégorique, mais je pense que c’est vrai. En supprimant Flash de ses appareils, Apple n’a pas laissé le choix aux développeurs web que de se conformer à des standards pour laisser leur contenu visible. Je suis convaincu que si Flash avait été présent sur iPhone dès le départ, les standards du web n’aurait jamais autant d’écho qu’aujourd’hui.

Mozilla pousse les standards et les bonnes pratiques du web par l’évangélisme. Apple pousse les standards et les bonnes pratiques du web par la dictature.

Les deux méthodes portent leurs fruits, mais clairement pas aussi rapidement. Et si on devait attendre comme Mozilla que plus aucun site n’utilise Flash pour bloquer le plugin, il y a de fortes chances pour que ce jour n’arrive jamais.