HTeuMeuLeu

En ce moment, je lis « A Theory of fun for game design » de Raph Koster. Dans les premiers chapitres du livre, l’auteur détaille le fonctionnement de notre cerveau. J’ai particulièrement aimé l’explication suivante :

Il ne faut pas sous-estimer le désir d’apprendre de notre cerveau. Si vous mettez quelqu’un dans une chambre de privation sensorielle, il deviendra malheureux très rapidement. Le cerveau raffole d’être stimulé. À tout moment, le cerveau cherche à essayer d’apprendre quelque chose, à essayer d’intégrer des informations sur sa vision du monde. Il est insatiable de cette façon.

Ça m’a tout de suite rappelé un excellent article lu l’année dernière sur « l’endroit le plus silencieux au monde« .

Le plus long que quelqu’un ait survécu dans la chambre anéchoïque des laboratoires Orfield au sud de Minneapolis est 45 minutes.

Elle absorbe les sons à 99,99 % et détient le record mondial Guinness de la pièce la plus silencieuse au monde. Mais si vous y restez trop longtemps vous pourriez commencer à halluciner. […]

Quand c’est calme, vos oreilles s’adaptent. Plus la pièce est silencieuse, plus vous entendrez des choses. Vous entendrez votre coeur battre, parfois vous pourrez entendre vos poumons, ou les gargouillis de votre estomac bruyamment.

Dans une chambre anéchoïque, vous devenez le son.

Et c’est une expérience vraiment déroutante. M. Orfield explique que c’est si déconcertant que s’asseoir devient une obligation.

Il dit : « La façon dont vous vous orientez est grâce aux sons que vous entendez en marchant. Dans une chambre anéchoïque, vous n’avez aucun indice. Vous retirez les indices perceptifs qui vous permettent d’être en équilibre et de bouger. Si vous restez là pendant une demi-heure, vous devez vous asseoir. »

En décembre dernier, j’ai lancé le site 24 jours de web, « le calendrier de l’avent des gens qui font le web d’après ». Voici quelques remarques personnelles sur ce projet.

C’est peut-être le phénomène de Baader-Meinhof, mais le moins qu’on puisse dire, c’est qu’il y a eu un paquet de calendriers de l’avent autour du web cette année. Entre 24 ways, Performance Calendar, UXmas, ou The Christmas Experiments, il y avait de quoi lire.

Je pensais que ce serait facile comme projet. Un appel à auteurs et association en novembre, un thème WordPress à créer, et hop début décembre tout est prêt et on n’en parle plus. Oh, comme j’étais naïf.

Le dimanche 28 octobre, j’ai contacté quatorze personnes que j’apprécie, que je connais dans la vraie vie ou pas, afin de les solliciter pour écrire un article. Cela m’a permis d’avoir déjà un premier aperçu du ressenti du projet. Quand j’ai reçu la réponse de Benoît Meunier dans l’après-midi, je savais que j’étais sur la bonne voie.

Certaines propositions doivent être longuement réfléchies. D’autres, comme la tienne, pas du tout.

Rémi, ce sera avec joie.

Sur ces quatorze premiers contacts, seuls deux n’ont pas donné suite, faute de disponibilité ou d’inspiration sur le moment.

Le 29 octobre, j’ai publié un appel pour chercher des volontaires pour écrire un article pour le site, et aussi pour trouver une association. Le message a été très bien relayé sur Twitter. Au total, j’ai reçu 34 propositions d’articles. Ça faisait super plaisir ! Mais ça m’embêtait de rejeter dix articles. J’ai écarté trois sujets que j’estimais pas assez aboutis, ou alors en décalage avec l’orientation « conception web » du site. Et j’ai donc retenu 31 articles. Ça tombe bien, ça me permettais de tenir tous les jours jusque fin décembre. Sauf qu’en fait il n’y a eu que 29 articles. Malgré de nombreuses relances de ma part, je n’ai eu absolument aucune nouvelle d’un des auteurs dont j’avais accepté l’article. Et concernant l’autre, j’ai eu la surprise de découvrir un article/tutoriel proposant un résultat copié/collé d’un autre article francophone. J’ai essayé de discuter avec l’auteur et de proposer un autre sujet, mais les échanges étaient houleux. J’ai préféré ne pas insister.

Avant le lancement, j’ai eu la chance d’avoir une proposition d’Agnès et de l’association les zCorrecteurs pour relire et corriger l’intégralité des articles. Je ne sais pas comment j’aurais fait sans eux. Non seulement ils ont pris le temps de corriger les fautes d’orthographe et d’adapter certaines tournures de phrases, mais aussi de commenter chaque article avec des règles simples pour éviter de refaire les mêmes fautes. Exemple :

« lâcher du leste »
leste = agile (adj.)
lest = truc lourd qui sert à alourdir les montgolfières et ce genre de choses.

Le premier décembre, le site a été lancé dès minuit. Et les visites ont commencé à affluer. 662 le premier jour, 759 le deuxième, 2249 le troisième (merci aux trolls dans les commentaires), 1432 le quatrième, etc. Le lancement du site s’est très bien passé. Mais c’est après que ça s’est gâté.

Je m’étais fixé un planning d’ordre de passage, sans critère particulier. Mais au premier décembre, je n’avais pas encore relu tous les articles. J’étais donc particulièrement en retard. Et je devais désormais coordonner les relectures orthographiques, les mises en pages des articles dans WordPress, les réponses diverses aux mails que je recevais, etc. Durant tout le mois de décembre, j’ai passé mes midis et mes soirées à assurer le bon déroulement du site, alors que je m’attendais à avoir tout fini début décembre.

Et comme si ça ne suffisait pas, il n’y avait quasiment aucun don sur le site. J’avais souhaité ajouter au site un aspect caritatif en incitant sur chaque page à faire un don pour une association ayant répondu à mon appel. Je me disais que quitte à avoir un site avec potentiellement un peu d’audience, autant en faire profiter quelqu’un. Sauf que ce n’est pas aussi facile que ça. Le 22 décembre, l’association avait récolté tout juste 300€. C’est bien. Et je me dis que c’est toujours mieux que rien. Mais avec 11 000 visiteurs uniques, 23 000 visites et 55 000 pages vues à cette date, ça faisait quand même vraiment peu.

J’étais un peu démoralisé. Mais j’ai continué. J’ai insisté. J’ai relancé lourdement les appels aux dons sur Twitter, même si je n’aime pas ça. Et j’ai créé une version epub de tous les articles, disponible au téléchargement pour tout don effectué. Et ça a pas trop mal marché.

Au total, le site a permis à l’association de réinsertion professionnelle L’Abri de récolter plus de 650€ (après la commission de Paypal). Et ça, c’est chouette.

Au total, depuis le premier décembre jusqu’à aujourd’hui, le site a accueilli 14 883 visiteurs uniques pour 31 959 visites et 73 643 pages vues. Et ça aussi, c’est vraiment chouette.

Alors je ne sais pas encore si je relancerais le site cette année. Mais au cas où, en guise de note personnelle à moi-même, voici trois points que j’aimerais améliorer :

• Gérer tout tout seul, c’est un peu difficile. Dieu merci j’ai eu l’aide des zCorrecteurs pour la relecture. Mais je pense qu’une aide supplémentaire pour la mise en place des articles sous WordPress ne serait pas de refus. 
• Je pense qu’avec 14 000 visiteurs, on aurait du pouvoir récolter plus de 1000€ pour une association. L’incitation aux dons doit donc être améliorée. Peut-être qu’il faudrait mettre en place un système où l’article du jour ne serait publié qu’à partir de x euros donnés. Peut-être qu’il faudrait créer une boutique avec des produits dérivés sur le thème du web. Peut-être qu’il faudrait trouver un partenaire prêt à faire un don en échange de publicité.
• Les articles publiés la dernière semaine ont été deux fois moins vus que les autres. C’est la faute des congés et des jours fériés de cette semaine, ou peut-être d’une fatigue du calendrier qui s’éternise au delà de 24 jours. Mais du coup, ce n’est pas cool pour les auteurs des très bons articles publiés cette semaine là. Je pense qu’il faut limiter le nombre d’articles à vingt-quatre.

Si vous avez des remarques ou des suggestions, n’hésitez vraiment pas à m’en faire part dans les commentaires ou par mail.

J’en profite pour remercier encore tous les auteurs, tous les donateurs, les zCorrecteurs et tous les lecteurs qui ont permis de rendre ce projet vivant.

Je suis intégrateur.

Je suis aussi entrepreneur, co-gérant, patron, concepteur, ergonome, développeur, blogueur, twitteur, concubin, collègue, ami, frère, fils, tonton, parrain, …

Par contre, je ne suis pas directeur technique, développeur côté client, ingénieur côté client, junior, senior, expert, gourou, ninja, star, …

Le terme qui me correspond le mieux, et avec lequel je me présente auprès de mes clients, c’est intégrateur. Ce n’est pas forcément le titre le plus explicite pour des personnes ne travaillant pas dans le web. Ce n’est pas non plus le titre le plus précis. Ce n’est certainement pas le titre le plus élogieux ou le plus fanfaronnant. Mais c’est le titre qui représente aujourd’hui le mieux mon métier. C’est un mot simple, court, humble.

Je suis intégrateur. Ce n’est pas un hasard si j’apporte un certain attachement à cette sémantique.

Hier, j’ai publié une blague sur Twitter :

Alicia Keys est Directrice de Création chez Blackberry. Will.i.am est DC chez Intel. Et Lady Gaga est DC chez Polaroid. (l’article chez The Verge)

Et après on se demande pourquoi je pouffe de rire quand on me présente un DC ou un DA dans une agence web.

C’est le genre de chose qui me fait rire. Ça me fait rire que mes collègues DA aient le même titre que Lady Gaga chez Polaroid. Je n’ai pas fait une blague atroce sur le physique de quelqu’un. J’ai fait un commentaire sarcastique sur le fait que le graphiste qui a réalisé les maquettes sur lesquelles je travaille en ce moment a le même titre que Will.i.am chez Intel.

Mais apparemment, ça a suffit pour lancer un débat sur Twitter toute la matinée sur le bien-fondé du titre de directeur artistique. Les habituels vieux de la vieille se sont insurgés, préférant croire à une méconnaissance de ma part (laissant alors place au tout aussi habituel « tu n’es qu’un intégrateur, tu n’as pas le droit de parler de ça »). Les plus compréhensifs se sont adaptés, reconnaissant que les termes de Directeur Artistique n’avaient plus beaucoup de sens.

C’est le problème avec les noms de métiers. Les instituteurs(trices) deviennent des professeurs des écoles. Les hommes/femmes de ménage deviennent des technicien(ne)s de surface. Les caissier(e)s deviennent des hôte(sse)s de caisse. Les noms changent, mais les métiers demeurent.

Il y a quinze ans, j’aurais volontiers adopté le titre de webmaster. Puis le nom a été utilisé à tort et à travers, usurpé, et vidé de sons sens. Ça n’enlève rien au métier qui se cache derrière. Mais soyons sérieux, travailler dans le web aujourd’hui et se faire appeler webmaster laisse place à un léger rictus.

Je ne serais peut-être pas intégrateur toute ma vie. Non pas que je n’aime pas ce métier. Je l’adore. Mais peut-être qu’un jour, Justin Bieber sera nommé intégrateur chez Apple. Et Carly Rae Jepsen sera intégratrice chez Facebook. Ce jour là, comptez sur moi pour faire des commentaires caustiques sur ces ambassadeurs improbables. Ce jour là, ce sera aussi surement l’occasion pour moi de prendre du recul sur mon métier, son intitulé et son sens.

Ces derniers mois, j’ai eu la chance de travailler à plusieurs reprises sur l’intégration d’e-mails responsive. C’est un sujet particulièrement intéressant qui rapproche des technologies préhistoriques (mise en page en tableaux, support CSS archaïque) avec des concepts modernes (du responsive design). C’est un peu comme si un scientifique fou décidait de resusciter des dinosaures.

Comment savoir quoi que ce soit sur un écosystème disparu ? et par conséquent, comment affirmer qu’on peut le contrôler ? Je veux dire, vous avez des plantes dans ce bâtiment qui sont vénéneuses et vous les avez choisies parce qu’elles étaient jolies. Mais ce sont des organismes vivants et agressifs qui n’ont aucune idée du siècle où ils sont et qui vont se défendre avec violence si nécessaire.
Dr. Ellie Sattler, Jurassic Park

Les logiciels mails sont un peu comme les dinosaures de Jurassic Park. Ils n’ont pas la moindre idée du siècle où ils sont. Par exemple, savez-vous quel moteur de rendu utilise Outlook 2003 ? Allez, faites une supposition. IE5 ? IE6 ? IE7 ? IE8 ? IE9 ? Félicitations, quoi que vous ayez répondu, vous avez gagné. Outlook 2003 utilise le moteur de rendu de la version d’Internet Explorer présente lors de son installation. Cela signifie que si vous installez Outlook 2003 avec IE6, que vous mettez à jour IE6 vers IE8, Outlook 2003 sera toujours sous IE6. Outlook 2003 est condamné à rester tout seul dans sa propre bulle pour le restant de son existence. (Merci au passage aux gens d’Email On Acid de se casser la tête pour essayer de comprendre ce genre d’horreurs).

Pas étonnant donc, que des logiciels comme Outlook puissent se comporter violemment si on essaye de leur donner du code un peu élaboré. Comme j’aime bien raconter des histoires de bugs, en voici un bien particulier sur lequel je suis tombé.

J’ai travaillé sur l’intégration d’un gabarit d’e-mail responsive pour la newsletter mensuelle d’un client. La newsletter est particulièrement longue, avec la présentation de plusieurs articles récents (avec une photo et un court extrait), des actualités et enfin la présentation de deux produits comme ci-dessous.

Dans la version mobile, les deux produits doivent simplement se retrouver les uns sous les autres. Facile, non ? Si c’est le b.a.-ba de l’intégration responsive pour un site, il faut déjà ruser un peu en utilisant des tableaux flottants (<table align="left">) pour le produit de gauche, le séparateur entre les deux produits et le produit de droite. Mais ce n’est pas la partie qui m’a posé le plus de problème. Et je suis rapidement arrivé à faire une intégration qui fonctionne sur l’ensemble des navigateurs, et sur les principaux logiciels mails mobiles.

Et puis, grâce à Email On Acid (ceci n’est pas un article sponsorisé), j’ai testé le rendu sur Outlook. Et là, c’est le drame. Sur Outlook 2007 et 2010 (qui utilisent le moteur de rendu de Word, normal), mes deux produits sont l’un en dessous de l’autre. J’ai beau réduire les tailles de mes tableaux, essayer d’ajuster le tout en laissant plus de marge, ça ne passe pas. Chaque test, chaque modification de dimension dans le code HTML nécessite que j’édite mon code, que je fasse une archive, que je l’uploade sur Email On Acid, que j’attende le résultat de la capture générée sur Outlook. Autrement dit, la démarche est longue et pénible. Et puis en lisant tous les précieux conseils glanés sur le web, j’ai trouvé ce qui pourrait être la solution. C’est particulièrement sale, mais à ce stade je n’avais plus rien à perdre. Et ça a marché. A priori, il s’agit d’un comportement « normal » du moteur de rendu de Word.

Voici la marche à suivre en quatre étapes, toutes nécessaires :

1. Ajoutez un bgcolor avec une couleur de fond sur tous les <td> des tableaux flottants
2. Ajoutez une bordure d’un pixel de la même couleur sur les tableaux en question
3. Diminuez la taille des tableaux de 2px pour s’ajuster suite à l’ajout de la bordure. Jusque là, vous me direz, il n’y a rien de trop sale. Mais attention accrochez-vous bien, car c’est maintenant qu’on va vraiment faire de la magie.
4. Entourez le contenu du premier <td> de chaque tableau flottant avec une balise de paragraphe. Stylez ce paragraphe avec les propriétés mso-table-lspace:0;mso-table-rspace:0;

Et moi qui trouvais ça crade d’ajouter un display:inline pour corriger les problèmes de marge sur des flottants sur IE6.

Mais youpi ! Désormais tout fonctionnait. L’intégration était terminée et la newsletter a pu être envoyée dans les temps. L’humanité était hors de danger !

Mais ça, c’était sans compter la newsletter suivante. Le mois suivant, tout fier de moi et de mon gabarit responsive, je m’apprêtais à intégrer cette nouvelle édition sur ce gabarit en deux temps trois mouvements. Tout se passait bien, jusqu’à ce que je teste sur Outlook 2007 et 2010. Une nouvelle fois, les deux produits se retrouvaient l’un après l’autre. « Attendez c’est pas possible, j’ai déjà passé des plombes à blinder ce gabarit », me suis-je dit. C’est parti pour un nouveau retroussage de manches et des tests à gogo. A l’ancienne, j’essaie d’épurer mon code au maximum pour n’avoir que les produits et essayer d’identifier le problème. Avec seulement les produits, tout passe bien. Je rajoute alors le footer de l’e-mail et une actualité au-dessus. Ça passe. Je rajoute encore d’autres extraits d’articles. Ça passe. Je rajoute le header du mail. Ça passe. Je rajoute le texte d’introduction. Ça ne passe plus.

« Petite futée. »

« Ce n’est quand même pas ce petit texte d’intro en haut qui fait tout péter dans le bas de mon mail. » J’essaie de comprendre, je cherche un logique à tout ça, je teste, je reteste, je déteste (la terre entière). Au fil de mes lectures, je finis par tomber sur cet article qui décrit une fonctionnalité bien étrange d’Outlook 2007 et 2010.

Dans Outlook 2007 et 2010, le moteur de rendu de Word insère une balise <br /> à chaque fois qu’il détecte « une limite de texte » (ce qui correspond a peu près à un saut de page). D’après Email On Acid, ces limites de textes apparaissent environ tous les 23,7 pouces (soit environ 1790 px). Et bah le voilà, mon problème. J’en arrive cependant à la 6ème étape du débogage : « Mais comment est-ce que ça a pu marcher dans la première newsletter ? ». Et bien ma deuxième newsletter est un chouilla plus longue que la précédente. Du coup, Outlook insère un <br />, mais cette fois-ci en plein milieu de mes blocs produits. La solution adoptée est simple : éviter d’avoir un tableau qui englobe tout l’e-mail, et diviser son code en plusieurs tableaux les uns en dessous des autres. Youpi, cette fois-ci tout fonctionne !

Je peux désormais fièrement prendre un peu de recul sur mon code. Et tel le professeur Ian Malcolm, je ne peux que faire le constat suivant :

C’est vraiment un gros tas de merde.

Ce matin, j’ai lu avec stupeur cet article de Jeremy Kahn, « Je suis pour la mono-culture WebKit » :

Imaginez si Firefox passait à WebKit : ça libérerait des tonnes de temps passé à corriger des bugs de Firefox. Ne vous méprenez pas, un monde sans bugs spécifiques à certains navigateurs est une chimère. Mais standardiser sur un seul moteur de rendu ferait avancer d’un grand pas l’unification du web.

Vous ne serez pas surpris si je vous dis que Jeremy Kahn travaille chez Google. Mais je suis toujours aussi surpris de voir que l’argument en faveur d’un seul moteur de rendu trouve une audience.

Le débat n’est pas nouveau, et j’y avais longuement contribué il y a deux ans avec mon article sur le pixel perfect. Plus récemment, sur Branch, j’expliquais mon point de vue.

S’accorder sur un moteur de rendu unique, c’est comme souhaiter une dictature. Ça peut être bien si le dictateur en question est sympa et oeuvre pour le bien de tous. Mais l’Histoire nous prouve que ce n’est jamais le cas.

S’accorder sur un moteur de rendu unique, c’est choisir un bénéfice à court terme (ne plus avoir à se casser la tête avec plusieurs moteurs de rendu), au détriment de bénéfices au long terme (avoir des navigateurs toujours plus performants et plus complets).

J’aime beaucoup la conclusion de l’article de ce cher Kahn :

La compétition est bonne et nécessaire, mais pas pour tout. J’adorerais voir les fabricants de navigateurs se concentrer sur la compétition pour des fonctionnalités qui bénéficient à l’utilisateur, plutôt que sur leur propre interprétation des standards du W3C.

J’aurais tendance à dire que les navigateurs sont finis. Et même si les quelques nouveautés d’interface bien pensées apparues ces dernières années sont les bienvenues, la vraie différenciation se fait justement sur le moteur de rendu et le moteur d’exécution JavaScript. C’est là le nerf de la guerre. Je ne pense pas qu’un traducteur ou un lecteur PDF intégré soit un argument suffisant pour des vrais gens pour s’imposer la difficile tâche de changer de navigateur. Par contre, un navigateur deux fois plus rapide à afficher une page web, ça peut valoir le coup.

Opera a récemment présenté un projet de navigateur mobile sous WebKit. Mozilla en a fait de même l’année dernière en présentant Firefox Junior. Même Microsoft utilise WebKit pour Outlook 2011 sous Mac. Dans le web mobile, WebKit bénéficie déjà d’un monopole important entre Safari sous iOS et Chrome sur Android.

La perspective d’une mono-culture WebKit semble de plus en plus réaliste. Mais ce n’est vraiment pas quelque chose dont on peut se réjouir. Et encore moins quelque chose que l’on devrait souhaiter.

Vendredi, Aaron Swartz, 26 ans, s’est donné la mort. Je ne vais pas mentir : je n’avais jamais entendu son nom avant d’apprendre la nouvelle. Mais il se trouve que je connaissais malgré moi son travail. A 14 ans, il co-écrit la spécification RSS 1.0. A 19 ans, il créé la société Infogami qui sera rapidement fusionnée avec Reddit, dont il deviendra alors un des co-gérants.

Depuis juillet 2011, Aaron Swartz était poursuivi par la Court Fédérale des États-Unis pour avoir téléchargé 4 millions d’écrits académiques du JSTOR via de simples curl sur une connexion publique du MIT. Bien que les plaintes du JSTOR furent abandonnées, il fut persécuté par le procureur du Massachusetts. Il risquait 35 ans d’emprisonnement.

En lisant tous les articles qui fleurissent à son sujet, j’ai particulièrement aimé l’anecdote suivante où il explique comment il a réussi à rejoindre le groupe de travail RDF du W3C à l’âge de 14 ans.

D’abord j’ai demandé aux membres du groupe si je pouvais les rejoindre. Ils ont dit non. Mais je voulais vraiment être dans ce groupe de travail, donc j’ai essayé de trouver un autre moyen. J’ai lu les règles du W3C, qui était l’organisme de standardisation qui dirigeait ce groupe de travail. Les règles stipulaient que s’ils pouvaient rejeter n’importe quelle demande provenant d’un individu, si un organisme qui était membre officiel du W3C demandait d’ajouter quelqu’un dans un groupe de travail, ils ne pouvaient pas refuser. Alors j’ai parcouru la liste des organismes membres du W3C, j’ai trouvé celui qui me semblait le plus amical, et je leur ai demandé s’ils pouvaient me faire rejoindre le groupe de travail. Ils l’ont fait.

 

Quand j’étais petit, j’aimais bien lire les bandes dessinées Gaston Lagaffe. En particulier, j’aimais beaucoup un gag récurrent dans lequel Gaston cherche un déguisement pour le bal costumé.

Dans son emballement créatif, Gaston oublie à chaque fois le but initial de son déguisement, à savoir d’aller au bal, et s’interroge : « Oui… mais si on danse ? ».

C’est exactement ce qui m’est venu à l’esprit hier en découvrant la tablette IdeaCentre Horizon 27″ de Lenovo. En particulier, regardez à 0:49 dans la vidéo de présentation la gentille maman de famille qui transporte la tablette.

Du haut de ses vingt-sept pouces, la tablette de Lenovo pèse plus de 7,7 Kg. (En comparaison, un iPad mini pèse 308 g, un iPad 652 g, un Macbook pro 15″ 2,02 Kg, et un iMac 27″ 9,54 Kg.) Je peux imaginer l’intérêt d’un écran tactile d’ordinateur de bureau de cette taille. Je peux aussi imaginer l’intérêt d’une table tactile fixe de cette taille. Mais une tablette transportable, sérieusement ? Il semblerait que personne ne se soit dit « C’est bien… mais si on la transporte ? ».

Cette phrase de Gaston, j’y pense aussi souvent quand je reçois des maquettes pas tout à fait finies de graphistes débutants. « Il est joli ton formulaire qui rentre pile poile dans la zone de ton visuel… mais si on fait une erreur ? » Dans son emballement créatif, le graphiste avait oublié le but initial de son formulaire, à savoir valider des données saisies par l’utilisateur pour ensuite les enregistrer.

Le travail d’un graphiste web, mais aussi de tout concepteur web en général, c’est de penser. Et plus précisément de penser à tout. Il est joli ce _______, mais si _______ ?

Le mois dernier, j’ai regardé l’excellente conférence de Marcin Wichary à Fronteers 2012 intitulée « The biggest devils in the smallest details » (45 minutes, plus des questions/réponses). Marcin est développeur chez Google et travaille principalement dans l’équipe des doodles. Au cours de cette conférence, il revient sur plein de doodles réalisés ces dernières années avec des détails vraiment intéressants (et une bonne blague sur IE à la treizième minute).

Mais surtout, il présente un outil maison pour générer les animations des doodles (dont il avait déjà parlé chez Smashing Magazine) : le crushinator.

Voici le doodle qu’on avait pour la fête nationale. Il y a quelques années, on voulait faire un doodle pour Rude Goldberg, mais son anniversaire était le jour de la fête nationale.  Alors on s’est dit « Et si on faisait un doodle tandem », une machine très patriotique à la Rube Goldberg ? Voilà ce que ça a donné !

C’est une jolie petite animation qui marche vraiment bien. Mais réfléchissez-y. Comment feriez-vous pour mettre ça sur la homepage de Google de façon à ce que tout le monde en profite ? Vous avez quelques options :

• Vous pouvez mettre un GIF animé. Mais les GIFs animés sont plutôt bizarres. Ils ne sont pas très jolis et vous ne savez pas vraiment ce qu’il se passe avec eux. Vous ne pouvez pas les arrêter, vous ne savez pas quand ils se chargent exactement, à chaque image, et parfois ils sont longs à charger.
• Une vidéo en HTML5, Flash ou sur Youtube. Flash et Youtube sont plutôt cools mais assez lourds et ne marcheraient pas sur iOS.
• Une vidéo en HTML5, à l’inverse, ne marcherait pas sur tous les navigateurs.
• Des images individuelles : beaucoup de latence, beaucoup de bande-passante.
• Des animations CSS3 : on pourrait imaginer recréer tout ça en CSS avec des transformations et ce genre de choses. Mais ça ne marcherait pas sur les vieux navigateurs non plus.

Donc on a inventé notre propre truc, qu’on a appelé « crushinator ». (C’est une référence à Futurama.) La façon dont ça fonctionne est essentiellement que ça regarde chaque image et la compare à la suivante. Et ça créé un sprite à partir de la différence entre ces images.

J’avais adoré le doodle en hommage à Martha Graham, et j’étais bluffé par le sprite utilisé. C’est vraiment très intéressant de désormais savoir comment ça a été fait.

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

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édia, un 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.

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.