HTeuMeuLeu

Le week-end dernier, le Wall Street Journal annonçait que Digg allait être racheté par le groupe betaworks pour 500 000$. À peine 2 ou 3 ans plus tôt, le site était estimé à plus de 160 millions de dollars.

Avant cette annonce, j’avais complètement oublié Digg. Pourtant, entre 2006 et 2010, j’étais un gros visiteur de Digg. Je ne postais pas, mais j’adorais venir sur le site tous les jours et découvrir du nouveau contenu. C’était probablement le premier réseau social pour lequel j’avais un réel engouement. Avec cette annonce, des tas de souvenirs me sont remontés d’un seul coup.

Son fondateur, Kevin Rose, et ses shows à l’Américaine. MrBabyMan, le membre du site le plus actif dont le moindre post atteignait la page d’accueil. L’histoire de 09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0. Et puis en 2010, il y a eu la V4, ses plantages fréquents, son algorithme modifié pour pousser davantage de contenus promotionnels, la DiggBar, et la fuite d’une très grande partie de ses utilisateurs vers Reddit.

Et puis des souvenirs encore plus anciens me sont remontés. En 2003, j’avais regardé la première « émission » de Kevin Rose sur le hacking et le social engineering : The Broken. Et je me souvenais particulièrement de la séquence Hacking with Ramzi :

http://www.youtube.com/watch?v=fDFXaqDf8kk

Le rachat de Digg aurait pu me laisser totalement indifférent. Sauf qu’hier, la nouvelle équipe du site chez betaworks a présenté son projet : Rethink Digg.

Comme l’ont annoncé betaworks et Digg sur leurs blogs, nous allons prendre le contrôle de Digg et en refaire à nouveau une startup. Ce qu’ils n’ont pas mentionné, c’est que nous allons le reconstruire de zéro. En six semaines.

Le 1er août, après six semaines pleines de caféine et d’adrénaline, nous allons sortir une nouvelle v1.

Je suis sceptique, mais j’ai hâte de voir ce que ça va donner.

Vous connaissez cette sensation lorsque vous répétez un mot tellement de fois à la suite qu’il finit par perdre tout son sens et devenir incompréhensible ? C’est une sentation qu’on appelle la satiété sémantique :

La satiété sémantique arrive brusquement, quand votre langue trébuche sur chaque syllabe, le mot n’étant plus qu’un assemblage hétéroclite de lettres dénué de toute signification. Il faut alors quelques secondes – parfois même quelques minutes – pour désinhiber notre cerveau et lui faire admettre à nouveau que « placard » n’est pas un néologisme ! À lui seul, le terme de satiété sémantique explique parfaitement le concept : on n’a littéralement « plus faim du sens », notre cerveau est rassasié du contenu.

Récemment, j’ai eu le même sentiment en travaillant sur l’intégration d’un champs de recherche, et en regardant l’icône de loupe utilisée. La maquette ne présente pas de problèmes en elle-même. Mais au bout d’un certain temps, mon cerveau a complètement perdu le sens de la loupe.

« C’est bizarre », me suis-je dit. « Je n’ai jamais utilisé de loupe de ma vie pour chercher quelque chose. Une loupe, ça permets de voir des détails. C’est l’icône idéale pour un bouton de zoom. Mais pas pour une recherche. C’est quand même bizarre d’utiliser exactement le même symbole, la même icône, la même métaphore, pour deux fonctions totalement différentes. »

Totalement écervelé, je suis allé bêtement poser la question sur StackExchange, en cherchant à retrouver l’origine de l’utilisation d’une icône de loupe comme symbole de recherche. Il se trouve que ça tient principalement à deux clichés.

Le détective cherche des indices avec sa loupe. Le scientifique cherche des détails microscopiques avec sa loupe. Et c’est tout. C’est une sacrément bonne métaphore quand vous n’avez jamais fait ça de votre vie, mais que c’est pourtant bien ancré dans votre inconscient via des lectures, films et séries de votre jeunesse.

D’après les réponses sur StackExchange, un des premiers logiciels à utiliser la loupe comme icône de recherche fut le système d’exploitation NeXT (la boîte lancée par Steve Jobs après son éviction d’Apple), à la fin des années 80.

L’icône fut ensuite reprise dans des produits plus grands publics, comme le Newton d’Apple , les premiers Palm Pilot, puis démocratisée dans Windows 95. Alternativement, la recherche était de temps en temps représentée par des jumelles (comme dans Word), une lampe torche (comme dans Netscape), ou illustrée par un chien (comme dans Windows XP, ou chez Lycos).

Mon cerveau est désormais rassasié, et je peux continuer à travailler tranquillement.

J’ai le sentiment qu’il existe chez certains webdesigners la conviction d’être des artistes, et que les designs de sites web se doivent d’être des chefs d’oeuvres représentatifs de leur art. C’est complètement faux.

Le webdesign n’est pas un art.

Et c’est même tout sauf ça. En mars dernier, Christopher Butler expliquait ça très bien dans son article « Your ego is a bad designer » :

La différence fondamentale entre le design et l’art réside dans ceux pour qui chacun est au service. L’art est au service de l’artiste; c’est un véhicule d’expression de soi. A partir de là, il est au service des autres simplement en existant, en donnant de l’inspiration, en montrant ce qui est possible. Le design, à l’opposé, ne devrait jamais servir le graphiste en premier. Le graphiste rend toujours un service à quelqu’un d’autre. Le design est au service du client, et le processus de servir le client sert au graphiste. Contrairement à l’art, le design n’est pas un véhicule d’expression de soi. (Les designers peuvent s’exprimer à travers leur travail; le bon design n’en a pas besoin.) En d’autres mots, le design ce n’est pas totalement à propos de vous.

Vous pouvez détester autant que voulez les peintures de Picasso, les films de Tarantino ou la musique de Sufjan Stevens, ça n’enlève rien au fait que ce sont des artistes. Leurs oeuvres sont imprégnées de leur personnalité. Vous aimez ou vous n’aimez pas. Vous comprenez ou vous ne comprenez pas. Ça marche bien commercialement ou ça ne marche pas. Peu importe.

Par contre, si vos internautes ne comprennent pas comment fonctionne votre site, s’impatientent devant un formulaire super long à charger parce que vous avez cru bon d’utiliser des listes déroulantes personnalisées, ou bloquent devant des ombres physiquement improbables, ils sont tout à fait en droit de vous haïr personnellement.

Il y a déjà presque 5 ans, Jeffrey Zeldman (le papa de « A List Apart » et des livres « A Book Apart ») expliquait comment « Comprendre le webdesign » :

Le webdesign ce n’est pas le design de livres, ce n’est pas le design de poster, ce n’est pas l’illustration, et les plus grands accomplissements de ces disciplines ne sont pas le but recherché par le webdesign. Bien que certains sites web peuvent être des moyens pour diffuser des jeux et des vidéos, et bien que ces moyens de diffusions peuvent être agréables à regarder, de tels sites sont des exemples du design de jeux et du storytelling vidéo, pas du webdesign. Alors qu’est-ce que le webdesign ?

Le webdesign est la création d’environnements numériques qui facilitent et encouragent l’activité humaine; qui reflètent ou s’adaptent à des voix et des contenus individuels; et changent gracieusement au cours du temps tout en maintenant leur identité.

Répétez ça, en mettant l’accent :

Le webdesign est la création d’environnements numériques qui facilitent et encouragent l’activité humaine; qui reflètent ou s’adaptent à des voix et des contenus individuels; et changent gracieusement au cours du temps tout en maintenant leur identité. 

En juin dernier, l’excellent Benoït Meunier détaillait sur son blog le travail d’un (web) designer :

Votre travail n’est pas toujours aussi cool et amusant que vous pouvez le croire. Il est très souvent clérical. C’est aussi un travail scientifique de recherche, d’analyse. Vous êtes aussi un psychologue qui cherche l’écoute et non le prochain pitch. Vous connaissez aussi tous les recoins du projet par coeur. Vous en connaissez aussi les implications fiscales et l’évolution d’affaires ne vous est pas étrangère.

Votre travail demande aussi de regarder les statistiques, d’évaluer le comportement, de synthétiser des montagnes de données pour permettre une meilleure décision et par la suite, proposer d’enlever un lien, de modifier un titre, de faire des tests sur le meilleur adverbe d’un appel à l’action.

Votre travail c’est aussi ça.

Vous n’êtes pas Don Draper. Vous devez travailler fort, sur quelques pixels parfois pas très sexy mais cruciaux à une bonne expérience.

Vous êtes payé pour cela. Faites-le bien.

J’ai le sentiment qu’en France, la vue du webdesign comme un art est particulièrement accentuée  à cause du titre de « Directeur artistique ». Dans certaines agences web, vous pourrez rencontrer toute une bande de directeur et directrice artistique. Certains sont effectivement des directeurs artistiques, et suivent et dirigent des shoots photos, des conceptions vidéos, etc… Mais certains sont en réalité des webdesigners. Cette simple mention sémantique joue dans l’inconscient des clients et des webdesigners eux-mêmes que le webdesign a un rôle artistique.

Si vous êtes dans ce cas-là, arrêtez de vous appelez directeur artistique. Vous êtes peut être un designer d’Interface Utilisateur, ou alors un Architecte de l’Information. Mais sur le web, vous n’êtes pas un directeur artistique.

Le webdesign n’est pas un art.

De temps en temps, je reçois une maquette avec un formulaire à intégrer qui contient quelque chose comme ça :

Ceci est une liste déroulante personnalisée. C’est vachement pratique pour repérer les webdesigners débutants, les graphistes print qui font du web, ou encore les webdesigners qui pensent que le design est la finalité d’une page web (indice : ce n’est pas le cas).

Si vous êtes intégrateur, vous savez déjà que vous allez devoir faire quelque chose de très sale pour arriver à ce résultat graphique. Les contrôles de formulaires sont par défauts très limités à modifier en CSS. Ceci est dû au fait que ce sont en fait des éléments remplacés par le navigateur par des contrôles propres au système d’exploitation. L’avantage, c’est que le formulaire pourra s’adapter au fonctionnement du système d’exploitation. Par exemple sur iOS, vous aurez droit à la roue du juste prix. L’inconvénient, c’est que vous êtes assez limité au niveau de la présentation.

CSS3 apporte quelques solutions (notamment avec la propriété appearance), mais on est loin d’une solution universelle. La moins pire des solutions à l’heure actuelle consiste à utiliser du JavaScript pour remplacer les contrôles de formulaire par de faux contrôles. La bibliothèque Uniform (en jQuery) fait ça plutôt bien.

Mais ça implique d’énormes compromis. Il y a quelques semaines, Aviv Ben-Yosef rappelait sur son blog pourquoi il faut éviter les faux contrôles de formulaires en HTML.

Voici une liste des pour et contre de l’utilisation de tels contrôles graphiques.

Pour : 

• C’est joli.

Contre :

• Ça alourdit le temps de téléchargement de la page, et donc aussi le nombre de requêtes.
• Ça ralentit le chargement de la page côté client. Vous devrez attendre que tous vos scripts soient chargés avant de pouvoir utiliser votre formulaire.
• Ça diminue l’ergonomie de votre site. Les contrôles de formulaires système ont l’avantage d’être familiers pour les internautes. Même si vous avez fait une charte de liste déroulante super jolie et ergonomique, ça demandera du temps de compréhension supplémentaire à vos visiteurs.
• Ç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. Mais rien ne vous garantit que ça ne fonctionnera encore sur les machines de demain.
• Ça détruit l’accessibilité de votre page. Les faux contrôles générés en HTML deviennent totalement inutilisables.
• Ça a un impact sur le temps d’intégration, et donc le coût de votre projet.

Par pitié, n’imposez pas ça à vos visiteurs.

Médiamétrie a publié aujourd’hui une étude sur la fréquentation des sites internet selon les systèmes d’exploitation mobiles :

Android, l’OS de Google, a dépassé le système d’exploitation mobile d’Apple – iOS – depuis le mois de mars 2012 et représente désormais plus d’un accès mobile sur deux en juin 2012. En nombre de visites, Android a progressé de 29 % entre les mois de janvier et juin.

En parallèle, iOS, passe de 52,5 % à 36 % entre les mois de janvier et juin, soit une baisse de 38 %.

J’ai un peu de mal à croire cette étude. En novembre dernier, je constatais que les vrais gens n’utilisent pas Android pour surfer. Depuis, le nombre d’appareils vendus sous Android a encore doublé, annoncé à 400 millions lors de la Google I/O la semaine dernière. Pourtant les statistiques n’ont pas l’air d’avoir beaucoup bougé.

D’après NetMarketShare, en novembre 2011, 16,70% des internautes mobiles mondiaux étaient sur Android, contre 54,05% sur iOS. En juin 2012, on est à 19,73% sur Android contre 65,27% sur iOS. D’après StatCounter, en novembre 2011, 29,33% des internautes mobiles français étaient sur Android, contre 58,31% sur iOS. En juin 2012, on est à 36,12% sur Android contre 53,8% sur iOS.

Et même sur mon petit blog, que je considère dédié à une cible particulièrement high-tech, je ne constate pas le changement annoncé par Médiamétrie. En novembre dernier, j’avais 2,8% de visiteurs sous Android contre 8% sur iOS. Le mois dernier, j’avais 3,8% de visiteurs sous Android contre 9,5% sur iOS.

Et c’est valable pour tous les sites clients que j’ai pu réalisé. Je constate bien une hausse des visites sur Android, tout comme sur iOS. Mais dans tous les cas iOS reste le système majoritaire devant Android.

Mais ne faisons pas de ces statistiques une généralité. Et il y a peut être bel et bien une exception culturelle française sur les plus gros sites. Le principal changement dans le paysage mobile français ces 6 derniers mois, c’est l’arrivée de Free Mobile. En mai dernier, Free annonçait avoir déjà plus de 2,6 millions d’abonnés mobile. On peut supposer qu’une partie des nouveaux clients chez Free ont opté pour un nouveau mobile lors de leur inscription. Au même moment, Free annonçait avoir vendu pour 11,5 millions d’euros de terminaux. Avec des téléphones vendus au prix fort entre 40€ et 785€, ça fait entre 15 000 et 288 000 téléphones vendus (iOS, Android et Blackberry confondus). Je ne pense pas que 300 000 téléphones suffisent à faire basculer le paysage mobile français sur Android.

Je suis intimement persuadé que les résultats de médiamétrie sont totalement faux. Et j’ai deux hypothèses pour expliquer les erreurs de leurs mesures.

La première, suggérée par TOMHTML, est que les mesures de l’étude concerneraient uniquement les réseaux cellulaires, et non les réseaux Wi-Fi. Les chiffres d’Akamai confirmeraient alors ceux de Médiamétrie. Mais l’étude ne fait absolument pas mention du type de réseau, et ça me semblerait assez saugrenu de faire une étude uniquement sur des réseaux cellulaires sans le mentionner.

Ma deuxième hypothèse est que les mesures de Médiamétrie sont tout simplement erronées. Cette étude se base sur les visites des plus gros sites des principaux groupes français, soit près de 250 sites au total : pagesjaunes.fr, skyrock.com, jeuxvideo.com, doctissimo.fr, clubic.com, premiere.fr, etc… Pour obtenir des statistiques, les sites doivent inclure le script eStat de Médiamétrie. A ma grande surprise, je suis tombé sur une grosse erreur dès mon premier essai.

Si vous visitez pagesjaunes.fr sur ordinateur (le site n°1 en juin d’après médiamétrie avec plus de 77 millions de visites), vous accédez au site classique, qui inclut correctement le tag eStat. Par contre, si vous visitez pagesjaunes.fr sur mobile, vous êtes redirigés automatiquement sur mobile.pagesjaunes.fr, qui lui n’inclut plus du tout le tag eStat, mais utilise à la place le concurrent de Médiamétrie, Xiti.

Même constat sur le site mobile de Doctissimo (n°4 avec 40 millions de visites), France 3 (n°7 avec 9,7 millions de visites), France 2 (n°8 avec 9,6 millions de visites), Elle.fr (n°14 avec 4,6 millions de visites), etc…

L’explication la plus rationnelle pour moi est que ces 6 derniers mois, de nombreuses marques ont lancé un site mobile dédié. Ces sites mobiles n’intègrent pas tous correctement le tag eStat de Médiamétrie. Les internautes mobiles sont quand même redirigés automatiquement vers ces sites, notamment « grâce » à du sniffing d’agent utilisateur. Si ce sniffing n’est pas fait correctement (laissant potentiellement de côté des vieilles versions d’Android, ou privilégiant systématiquement les iPhones), les utilisateurs d’Android peuvent alors se retrouver sur le site classique, et ainsi faire gonfler les chiffres de Médiamétrie.

CQFD.

Mise à jour du 05 juillet : contactés par mes soins sur Twitter, PagesJaunes confirme « que le résultat est surprenant. Il ne correspond pas à ce que l’on constate pour notre appli »

Cette semaine, Benjamin De Cock écrivait sur son blog un article contre les applications web, en faveur des applications natives.

J’ai pris mon actuel écran d’accueil [sur mon iPhone] comme exemple. Combien d’apps serais-je capable de recréer aujourd’hui en ciblant uniquement la dernière version de Safari Mobile et sans sacrifier aucune fonctionnalité ? Indice : aucune.

• Alarme: Oubliez la fonctionnalité la plus utile : l’alarme.
• Calendrier: Les alertes d’événements ne peuvent pas être implémentées.
• Photos: Vous ne pouvez pas stocker 1000 photos et vidéos en cache.
• Appareil photo: Forcément, non.
• Réglages: Vous ne pouvez pas modifier les réglages, évidemment.
• Rappels: Vous ne pouvez pas créer de vrais rappels.
• Reeder: Vous ne pouvez pas partager un article par SMS.

Je ne savais même pas qu’on pouvait partager un article par SMS dans Reeder. Et je ne pense pas qu’utiliser Safari Mobile comme référence de fonctionnalités HTML5 soit très pertinent (au contraire). En théorie, il existe des API HTML5 (en cours d’écriture ou déjà implémentées) pour quasiment toutes les fonctionnalités décrites.

Mais il marque un point : les applications web, on n’y est pas encore tout à fait.

La semaine dernière, Facebook a annoncé la sortie prochaine d’une nouvelle version beaucoup plus rapide de son application iOS, abandonnant HTML5 au profit d’Objective-C.

Mais d’un autre côté, on voit naître actuellement une tripotée de systèmes d’exploitation poussant les applications web : Google et Chrome OS, Mozilla et Firefox OS, Microsoft et l’interface Metro de Windows 8. Alors est-ce cela signifie qu’on va avoir des OS au rabais avec des applications web amputées ? C’est très certainement le cas aujourd’hui (cf. les tests des derniers Chromebooks sur Chrome OS), mais je pense qu’il faut ajouter d’autres arguments dans la balance.

Pour moi, les applications web résolvent deux problèmes de longue date dans l’informatique :

• L’universalité d’une application : En codant en HTML5, en respectant les standards, vous êtes à peu près certains de pouvoir faire tourner votre application sur n’importe quel navigateur et plate-forme compatible. Bien sûr, il y aura toujours des cas particuliers à gérer. Mais comparez ça avec le casse-tête actuel du développement mobile (iOS, Android, Windows Mobile), et ce n’est pas dur de voir l’avantage du web en tant que plate-forme. L’adage de Java se prête plutôt bien (« Write once, run everywhere »), même si sa parodie aussi (« Write once, debug everywhere »).
• La pérennité d’une application : En codant en HTML5 aujourd’hui, il y a de grandes chances que votre application fonctionne encore dans 10 ans sur des appareils et des navigateurs totalement différents. A l’inverse, il y a de grandes chances qu’en choisissant une application native aujourd’hui, la plate-forme sur laquelle elle tourne soit totalement désuète d’ici 10 ans. J’expliquais déjà tout ça il y a quelques semaines en parlant de la rétro-compatibilité.

Alors forcément, en tant qu’intégrateur, mon point de vue est certainement un peu biaisé. Mais je pense que nous sommes dans une période un peu bancale. HTML5 n’est pas encore assez mûr pour permettre de réaliser n’importe quel type d’application de manière aussi performante qu’une application native. Mais développer aujourd’hui une multitude d’applications sur tout autant de plate-formes me semble un choix farfelu.

La semaine dernière, je suis tombé sur une vidéo de Shaun Inman (le Shaun Inman de sIFR, également développeur du sympathique Last Rocket) présentant son analyse du comportement de la caméra de Super Mario World.

Voici quelques détails sur le comportement de la caméra :

• Elle suit le joueur de gauche à droite.
• Si on change de direction, la caméra reste fixe tant qu’on ne bouge pas plus de 16px à gauche ou à droite.
• Elle est collée au bas de l’écran, sauf quand Mario sort ses petits bras pour s’envoler et qu’il décolle, où la caméra le suit en hauteur.
• Dans les niveaux sous-terrains, la caméra va se coller en haut de l’écran quand on est sur des plate-formes en hauteur.
• Dans les niveaux qui s’étendent en hauteur, la caméra suit Mario en hauteur dès qu’il atterrit sur une nouvelle plate-forme (mais pas pendant son saut).
• Sous l’eau, la caméra se détache et suit Mario.

J’ai probablement joué des dizaines et des dizaines d’heures à Super Mario World sur Super NES et sur GameBoy Advance. Je ne m’étais jamais rendu compte à quel point la caméra du jeu était élaborée, tellement elle semblait naturelle dans le jeu.

En août 2011, Twitter lançait Bootstrap, une boîte à outils HTML, CSS et JavaScript destinés à simplifier la création d’applications web. Bootstrap inclut un système de grille, des styles par défaut pour les principaux types de contenus, mais aussi le code nécessaire pour faire fonctionner les composants les plus courants qu’on retrouve sur des sites web (popups modales, messages d’alertes, carrousel, etc…).

Depuis février dernier, Bootstrap est le projet le plus populaire sur GitHub. La NASA utilise Bootstrap. La chaîne MSNBC utilise Bootstrap. Même la maison blanche utilise Bootstrap.

Je ne suis pas tout à fait certain que l’utilisation de Bootstrap était très pertinente dans ces 2 derniers cas. Et je ne suis en général pas trop friand de toute surcouche CSS. Pourtant, je pense que Bootstrap marque un pas important sur le web.

En mars dernier, j’étais tombé sur cet article de Dave Winer qui partageait ce point de vue :

J’étais développeur logiciel avant qu’il n’y ait un Mac, et je me souviens de quelque chose dont peu de développeurs se souviennent. Je me souviens comment l’industrie high-tech avait réagi. Et pour une grande partie, c’était avec pas mal de scepticisme. Et le truc intéressant c’est que les points négatifs que les gens trouvent à Bootstrap aujourd’hui sont exactement les mêmes que les points négatifs que les gens trouvaient au Mac en 1984. Et dans les deux cas, les choses que les gens n’aimaient pas étaient ce qui les ont rendu important.

Ce dont le Mac s’est rendu compte, c’est qu’il y avait un ensemble de choses que tous les logiciels devaient faire, alors pourquoi ne pas les faire toujours de la même façon ? En le faisant, les logiciels seraient plus faciles à développer et à débugger, mais surtout, plus faciles à utiliser. S’il y avait une seule façon de faire des menus, alors une fois que l’utilisateur aurait appris à se servir d’un menu dans une application, il saurait déjà s’en servir dans toutes les autres. La même chose est valable pour les scrollbars, les fenêtres, le clavier, la souris, l’imprimante, le son.

La raison pour laquelle les développeurs n’aimaient pas ça, et j’en faisais parti, est qu’ils ont pris ce que l’on faisait, et l’ont banalisé. De plus, il y avait des limites avec cette approche à taille unique. Il y avait des applications qui ne correspondaient pas très bien aux standards de l’interface. Que faire pour elles ? Et bien, vous adaptiez, voilà ce que vous faisiez.

De mon point de vue, Bootstrap est important parce qu’il permets en un minimum de temps et un minimum de connaissances d’avoir une application web ou une interface d’administration propre et fonctionnelle.

A l’instar des développeurs Flash, des développeurs applicatifs découvrent le web grâce aux nouveautés HTML5. Sauf que ça ne les intéresse probablement pas de passer des heures à faire de la mise en page en CSS. Grâce à Bootstrap, ces développeurs peuvent se concentrer sur le fonctionnement de leur application.

Aussi, je me souviens, au lancement de Bootstrap, avoir lu un tweet anglophone qui disait quelque chose comme ça :

Si vos interfaces d’administration ne sont pas aussi propres que Bootstrap, vous devriez vous poser des questions, ou alors rembourser vos clients.

Je pense que Bootstrap est aujourd’hui aussi important pour le monde de l’intégration que l’a été WordPress pour le monde du développement. Il y a 10 ans, les clients payaient beaucoup d’argent pour avoir un simple module d’actualités administrable avec un système de commentaires. Aujourd’hui, simplement en installant WordPress, vous avez ça de base, et bien plus. Il faut bien entendu faire attention à ne pas tomber dans une utilisation systématique de ces outils. Il m’arrive encore de travailler sur des petits sites institutionnels où WordPress n’a pas sa place. Mais c’est de plus en plus rare.

Si vous choisissez aujourd’hui d’intégrer une administration de site sans Bootstrap, vous avez intérêt à avoir de sérieux arguments.

Cette semaine, Google a sorti une version de Chrome sur iOS. Cependant, le moteur de cette version n’est pas celui de Chrome. Le moteur de rendu n’est pas le WebKit de Chrome, et le moteur JavaScript n’est pas le V8 de Chrome.

Ceci est dû à l’article 3.3.2 de la license du programme de développement sur iOS :

3.3.2 — Une application ne doit pas elle-même installer ou lancer d’autre code exécutable sous aucune façon, incluant sans limite à travers l’utilisation d’une architecture de plug-in, l’appel à d’autres frameworks, d’autres APIs ou encore différemment. Aucun code interprété ne peut être téléchargé ou utilisé dans une application sauf pour du code qui est interprété et exécuté par les APIs documentées par Apple et interpréteurs intégrés.

Cette règle bloque ainsi tout émulateur de jeux (sauf s’ils ont été réécris en Objective-C, comme Commodore 64), mais elle empêche aussi presque tout navigateur.

Les deux solutions pour créer un navigateur sur iOS sont alors :

• Exécuter tout le rendu et tout JavaScript côté serveur. C’est ce que fait Opera Mini. Ça leur permets d’optimiser le rendu de la page, et de compresser un peu plus la page téléchargée. Mais ça implique que toute action faite en JavaScript sera exécutée côté serveur, ce qui peut rendre la navigation beaucoup plus longue.
• Utiliser les API d’iOS pour afficher une page web. Cela signifie que vous utiliserez le moteur de rendu et le moteur d’exécution JavaScript de Safari. C’est ce que font la plupart des navigateurs sur iOS, comme Dolphin, Atomic ou désormais Chrome.

Le problème en utilisant cette deuxième solution, c’est qu’Apple bride son moteur JavaScript lorsqu’une page web est appelée dans une application (ou en raccourci plein écran sur l’écran d’accueil). Le résultat (vu hier sur Hacker News), c’est que Chrome sur iOS est jusqu’à 3 fois plus lent que Safari.

Ce comportement propriétaire d’Apple est clairement un frein à l’évolution du web sur mobile et à un marché compétitif sain. Alors qu’attendent Google, Firefox et les autres pour se plaindre ? Dans les années 2000, Microsoft avait été accusé d’abus de position dominante, profitant de son monopole sur le marché des systèmes d’exploitation pour développer un monopole sur le marché des navigateurs. Et bien la différence c’est qu’Apple n’a pas une position dominante sur le marché mobile. Cette place est occupée par Android. Apple est donc dans la position particulièrement confortable de pouvoir faire tout et n’importe quoi, le meilleur comme le pire, sans avoir à se soucier de réglementations du marché.

Et le plus drôle dans tout ça, c’est qu’en imposant désormais Chrome comme navigateur par défaut dans Android 4 et plus, c’est Google qui pourrait être accusé d’abus de position dominante.

Le petite casse-tête de cette semaine m’a fait réaliser quelque chose que j’avais en tête depuis quelques mois. Un bon effet CSS c’est comme une bonne blague. Pour que ça marche, ça doit être court, bien écrit et explicite. Voici un exemple :

Avez vous déjà remarqué que les femmes qui sont contre l’avortement sont des femmes que vous n’auriez pas voulu baiser en premier lieu ?

Ça, mesdames et messieurs, c’est George Carlin au Carnegie Hall en 1984. Ce n’est pas une blague qu’il sort en plein milieu du spectacle, après un long moment de préparation du public. Non. Il arrive sur scène, il salue le public et le remercie. Et il sort cette blague. Sérieusement, si vous ne connaissez pas George Carlin, regardez-le.

Ce genre de blague, c’est ce qu’on appelle en anglais une « one-liner« . Une blague courte, parfaitement racontée, et qui demande une petite seconde de réflexion avant de bien comprendre toute sa subtilité (un peu comme une doublette). Dans ce domaine, Demetri Martin est mon dieu vivant :

Dire « Je suis désolé » c’est la même chose que « Je m’excuse ». Sauf à un enterrement.

C’est vraiment la même chose en CSS. Un bon effet CSS, ça doit être :

• court : s’il vous faut 36 balises et autant de règles CSS, vous allez passer pour le lourdingue de service. Je pense que la séparation de la forme et du contenu devient enfin possible. Profitez-en.
• bien raconté : si vous écrivez du CSS, alors écrivez du CSS. Par pitié ne venez pas utiliser d’autres pseudo-langages et des tonnes de JavaScript.
• explicite : votre code doit être suffisamment ingénieux et explicite à lui tout seul. En reprenant l’exemple de mon casse-tête, la solution trouvée n’est pas la plus intuitive ni la première qui vient à l’esprit. Mais une fois qu’on la connaît, elle paraît évidente. Vous devez dans tous les cas éviter la surréflexion.

Mes effets préférés en CSS, comme mes blagues préférées, sont des one-liners.

Ce mois-ci, le magazine Entrepreneur a publié un article expliquant comment Marissa Mayer, la Vice Présidente des services locaux de Google, tenait le coup avec ses équipes en travaillant 130 heures par semaine :

Quand Mayer soupçonne un employé de s’épuiser, elle leur demande de trouver leur rythme. Et ils reviennent avec une demande, « Je dois être à la maison pour les dîners tous les mardi », ou « Je dois être à l’heure pour être aux matches de football de ma fille ». Elle concède à ses demandes, sans exception.

« Vous ne pouvez pas avoir tout ce que vous voulez », avertit Marissa. « Mais vous pouvez avoir les choses qui comptent vraiment pour vous. Ça vous permets de travailler vraiment dur pendant une longue période sur quelque chose qui vous passionne. »

Initialement, j’avais réagi sur Twitter en faisant une bonne blague bien grasse. Mais cet article est complètement dingue, et ce n’est pas très drôle.

130 heures par semaine, ça fait plus de 18 heures par jour, 7 jours sur 7. 18 heures par jour, ça vous laisse 6 heures pour dormir, manger, vous laver, vous divertir, voir votre famille, voir vos amis, vous évader. 6 heures par jour pour vivre.

En travaillant 130 heures par semaine, même à un salaire de 7000€ par mois, vous gagnez moins qu’en travaillant 35 heures par semaine pour 2000€ par mois.

Je travaille en tant qu’intégrateur depuis 6 ans. Je suis entrepreneur depuis 4 ans. J’aime mon travail. J’aime ma boîte. Mais s’il y a bien quelque chose que j’ai appris, c’est qu’il y a un équilibre à trouver. Il faut travailler pour vivre. Pas l’inverse. Peu importe le projet sur lequel vous travaillez, peu importe la mission dont vous vous sentez investi.

J’ai déjà travaillé plus de 100 heures par semaine. J’ai déjà travaillé plus de 35 heures en 2 jours. Je n’en garde aucun bon souvenir ni aucun enrichissement personnel. Il m’arrive encore de travailler un peu plus le soir, voire le week-end, quand j’ai des projets qui me plaisent particulièrement. Mais quand ça arrive, je considère que c’est un échec. Je trouve ça choquant de se vanter ainsi, et qu’une revue vante ces pratiques de travail sans aucun commentaire.

Ce genre d’histoires n’est pas spécifique à Google ni à Apple. C’est une parfaite illustration de la théorie espagnole, dont je vous parlais il y a quelques mois. Ça m’attriste de voir que des journalistes s’acharnent à dénoncer les conditions de travail d’ouvriers chinois, alors les « ouvriers » occidentaux ne sont pas mieux lotis.

This week, I encountered a nice brain teaser in front end development. After 2 hours of brainstorming, I finally found a solution that pleased me. I posted the problem on Twitter, then on my blog. To my surprise, I had a lot of answers, and some of them were actually pretty ingenious. So I decided to translate it in english so you english folks can enjoy it too.

So here it is :

It’s a pretty common visual effect, especially in print magazines. However, I found out that it was not that intuitive to reproduce this effect simply in CSS.

Here are the rules :

1. The text must not be divided by any tags (so no span for each lines, no br)
2. You can use as many tags as you want around the text
3. No JavaScript, only HTML and CSS
4. The white background must follow around the text
5. There is a margin inside the white background around the text of 20px on the left and right, and about 10px on top and bottom
6. The text is dynamic, so we must be able to easily change it and still have the visual effect
7. The solution must work on modern browsers (IE9, Firefox 13, Chrome 19, …)

To help you get started, I created a sample code on jsFiddle. You’re free to edit the HTML and CSS, as long as you respect the rules above.

I invite you to share your realisations on the comments below. I’ll publish the solution I came up with later this week. Have fun, and good luck to all !

Cet après-midi, j’ai rencontré un joli casse-tête en intégration. Après 2 heures de remue-méninges, j’ai fini par trouver une solution qui me convenait. J’ai posté le problème sur Twitter, et à ma grande surprise j’ai eu beaucoup de réponses, dont certaines assez astucieuses, mais ne collant pas tout à fait à ce que je souhaitais faire. Alors avant de donner la solution que j’ai trouvé, j’ai décidé de faire durer le suspens un peu plus longtemps et de poster le problème ici.

Voici le casse-tête en question :

C’est un effet graphique assez classique, en particulier dans la presse papier. Pourtant, il se trouve que ça reste relativement complexe à reproduire de manière simple en CSS.

Voici les règles à respecter :

1. Le texte ne doit contenir aucune balises (donc pas de span pour chaque ligne, pas de br)
2. Vous pouvez utiliser autant de balises que vous voulez autour du texte
3. Pas de JavaScript, que du HTML et CSS
4. Le fond blanc doit suivre le contour du texte
5. Il y a une marge à l’intérieur du fond blanc autour du texte de 20px à gauche et à droite de chaque ligne, et d’environ 10px en haut et en bas
6. Le texte est dynamique, et on doit donc pouvoir le modifier en conservant l’effet
7. La solution doit fonctionner sur les navigateurs modernes (IE9, Firefox 13, Chrome 19, …)

Pour vous aider à démarrer, j’ai mis à votre disposition sur jsFiddle un exemple de code HTML et CSS. Vous êtes libres de modifier le code HTML et CSS, tant que vous respectez les règles ci-dessus.

Je vous invite à partager vos réalisations dans les commentaires. Mercredi soir, je publierais la solution que j’ai trouvé, et je sélectionnerais mes solutions préférées parmi les commentaires. Amusez-vous bien, et bonne chance à tous !

Hier soir, le journal de 20H de France 2 a diffusé un reportage sur Woody Allen avec en fond, une citation qui lui était attribuée sur sa vision de la mort et « la vie à l’envers ». Je connaissais cette citation et je l’adorais, mais j’étais convaincu qu’elle était de l’excellent George Carlin. Après une recherche sur Google, il s’avère que cette citation vient en fait du comédien Sean Morey lors d’un passage au Tonight Show dans les années 1980.

Voici la citation en question :

La chose la plus injuste avec la vie, c’est la façon dont elle se termine. La vie est dure. Elle prends beaucoup de temps. Et qu’est-ce que vous avez à la fin ? La mort ! Qu’est-ce que c’est que ça, une récompense ? Je pense que le cycle de la vie est à l’envers.

Vous devriez mourir en premier, comme ça, c’est fait. Ensuite vous vivez dans une maison de retraite. Vous vous faites expluser quand vous êtes trop jeune. Vous récupérez une montre en or. Vous allez au travail. Vous travaillez quarante ans jusqu’à ce que vous soyez suffisamment jeune pour apprécier votre retraite. Vous vous droguez, vous buvez de l’alcool, vous faites la fête, et vous vous préparez pour aller au lycée. Vous allez au collège. Vous devenez un enfant, vous jouez, vous n’avez aucune responsabilités. Vous devenez un petit bébé, vous retournez dans l’utérus. Vous passez neuf mois à flotter dedans.

Et vous finissez en un orgasme !

J’ai toujours eu le sentiment que c’était un peu la même chose pour les sites web. Chaque mise en ligne, c’est un peu comme la mort du projet. Tout le monde a passé des mois et des mois à travailler d’arrache-pieds sur le projet. Six mois se sont écoulés. Et puis une fois en ligne, c’est terminé. On croise les doigts pour que tout ce qu’on a conçu fonctionne comme on l’espérait. On regarde un peu les statistiques les premiers jours. Et puis plus rien.

« Qu’est-ce que c’est que ça, une récompense ? » Je pense que le cycle de vie d’un projet web est à l’envers.

D’abord vous devriez commencer par mettre votre site en ligne, comme ça, c’est fait. Débrouillez vous pour installer un WordPress ou un Magento avec un thème par défaut, et insérez quelques contenus que vous aviez déjà rédigé sur un coin de table. Voilà. Nous sommes au premier jour de votre projet, et vous pouvez déjà commencer à gagner de l’argent avec votre site en ligne.

Maintenant que votre site est en ligne, vous allez pouvoir commencer à le concevoir. Mais pas en  regardant votre boule de cristal ou en déballant vos 5 ans d’études et tous les bouquins que vous avez lu sur la conception web (ça revient au même). Non, vous allez pouvoir concevoir votre site à partir de vraies données, celles de vos visiteurs. Est-ce que les visiteurs trouvent facilement mes coordonnées ? Est-ce que les visiteurs arrivent facilement à ajouter un produit au panier ? Non ? Et bien commençons par travailler sur ces points.

Petit à petit, vous allez pouvoir améliorer la structure et le contenu de votre site. Vous pouvez en profiter pour améliorer le référencement naturel de votre site en affinant vos résultats jour après jour. Vous allez pouvoir retravailler l’intégration de votre site et sa charte graphique, toujours en vous basant sur les statistiques des premières visites et les axes à améliorer. Vous allez même découvrir des besoins de nouveaux modules à développer que vous n’auriez jamais imaginé au départ. Et tout cela en continuant à gagner de l’argent.

Six mois se sont écoulés. Votre site est en ligne depuis le premier jour. Vous avez déjà des clients, des visiteurs fidèles, et vous savez que votre site réponds à leurs besoins. Vous avez déjà gagné pas mal d’argent, et vous avez presque déjà rentabilisé votre investissement initial. Vous pouvez désormais sereinement envisager la suite et sabrer le champagne !

Alors, bien sûr, tout ceci est un peu tiré par les cheveux. Peu de projets sont adaptés pour travailler ainsi, et peu de clients seraient prêts à prendre le risque d’avoir un site en ligne au premier jour qui ne colle pas à leur idéal. Mais pourtant, je suis persuadé que cette méthodologie serait parfaitement adaptée au web.

La semaine dernière, Alex Limi et Trond Werner Lansen, de la toute nouvelle équipe Design et Stratégie Produit chez Mozilla, ont présenté dans une conférence interne un prototype de Firefox sur iPad.

Surnommée Junior, cette version se veut plus ergonomique et totalement adaptée au support. Le constat de départ d’Alex Limi est que la version de Safari sur iPad est une simple copie de la version bureau, et qu’elle est souvent pénible à utiliser et peu adaptée au support.

L’interface de Junior est minimaliste : les sites sont affichés en plein écran, avec uniquement deux boutons en surimpression vers le bas de l’écran. A gauche, un bouton précédent. A droite, un bouton « Plus » pour accéder à une page d’option (avec les onglets ouverts, les favoris, la saisie d’une URL). En restant le doigt appuyé quelques secondes sur ces boutons, d’autres icône apparaissent (page suivante, bouton rafraîchir).

La page d’option est découpée en trois parties : l’historique et les onglets ouverts, les favoris, et un champs de saisie d’une URL. Voici quelques remarques intéressantes concernant ces 3 fonctionnalités :

• L’historique et les onglets ouverts sont fusionnés. En fait, il n’y a pas vraiment de notion d’onglets ouverts, et on trouve simplement un aperçu de tous les onglets de navigation préalablement ouverts. Dans le prototype actuel, on ne trouve pas par contre d’historique de navigation au sein d’un même onglet.
• Les favoris sont affichés sous forme d’icônes rectangulaires. Alex Limi préférait éviter d’avoir une simple liste de texte, ou les icônes carrées déjà présentées pour les sites adaptés à iOS. Il faudra donc créer un nouveau format d’icône (avec très certainement une balise meta correspondante).
• Le champs texte en bas de l’écran sert à la fois pour la saisie d’une URL ou la recherche. Curieusement, le prototype actuel utilise Bing pour l’auto-complétion.

Junior permets également de gérer facilement une utilisation multi-utilisateurs, avec un écran dédié au choix d’un profil (avec un mode invité qui fonctionne comme un mode « navigation privée »).

La nouvelle est particulièrement importante, puisqu’elle marque un changement stratégique chez Mozilla. Pour rappel, Apple interdit l’exécution de code non-natif au sein d’une application iOS. Il est donc interdit pour un navigateur d’utiliser son propre moteur de rendu. Les fabricants peuvent alors soit utiliser une vue WebKit d’iOS, ou générer le rendu d’un site à distance (comme le fait Opera Mini). Contre toute attente, Mozilla a choisi d’opter pour WebKit. Il y a à peine 18 mois, Matt Brubeck de Mozilla était plus catégorique sur l’intérêt de Mozilla pour iOS :

A moins qu’Apple ne supprime ces restrictions, Mozilla ne dépensera pas de temps et d’argent sur ce projet.

Hier, mes collègues et moi avons eu un débat virulent sur les magiciens et nos tours de magie préférés (oui, ce sont des choses qui arrivent dans un bureau rempli de développeurs). Ce qui a démarré tout ça, c’est ce tour où le magicien Cyril Takayama fait sortir des burgers d’une affiche :

Je déteste ce genre de tours. Ce n’est pas de la magie. C’est prendre vos spectateurs pour des idiots et des imbéciles. Ce tour ne demande aucune intelligence ni aucune dextérité. Tout ce qu’il demande, c’est une fausse affiche avec un faux fond et avec un vrai ami chinois derrière qui vous glisse des burgers (démonstration).

Ainsi, je me rends compte de ce qui me plaît vraiment dans la magie : le storytelling, et l’absence de préparatifs.

Ce que j’appelle le storytelling, c’est la narration, la mise en scène, la façon dont le tour est amené. J’aime beaucoup Éric Antoine pour ça. Je déteste cet autre tour de Cyril Takayma où il passe 2 minutes à faire joujou avec sa cigarette. Maintenant pour être honnête, le tour du burger était plutôt pas mal dans se sens là.

Par contre, il était mauvais pour le deuxième point : l’absence de préparatifs. Son tour ne fonctionne qu’avec son matériel, son assistant, et sous un certain angle de vue. C’est la même chose pour les magiciens qui découpent leur assistante dans une boîte à double fond. Ce qui me plaît dans la magie, c’est la spontanéité, et la capacité de réaliser un tour à partir d’un jeu de cartes classique ou d’objets du quotidien non truqués.

Vous voulez des exemples ? Je vous avais déjà parlé de Penn Jillette, et son tour « cups and balls » reste pour moi absolument fabuleux. Et puis ce tour de James Galea (à 2min30) est vraiment parfaitement exécuté :

Si je vous parle de tout ça, c’est parce que je pense que les bons intégrateurs sont des magiciens. En fait, Harry Roberts de CSS Wizardry tenait le même propos l’année dernière :

Un bon moyen d’être efficace est à travers l’illusion. Un bon exemple de ça sont les fausses colonnes en CSS; surmontant un problème complexe avec un code minimal et une illusion intelligente. Les fausses colonnes sont, encore aujourd’hui, un des meilleurs petits bouts d’illusion du développement web qui résolvent rapidement un problème qui autrement demanderait beaucoup de temps et de code.

Ça m’arrive souvent de tomber sur quelque chose de surprenant sur le web, de regarder comment ça a été fait, et d’être déçu parce que les développeurs ont simplement triché en utilisant du code supplémentaire, parfois très sale.

Pour reprendre l’exemple des colonnes de hauteurs égales en CSS, certaines solutions consistent à utiliser du JavaScript pour générer dynamiquement la bonne hauteur. Mais cette solution ne demande aucune intelligence ni aucune dextérité. Tout ce que ça demande, c’est de rajouter une plâtrée de code qui sera téléchargé en plus et exécuté après le chargement de la page.

Je suis bien plus impressionné par un code CSS simple, qui peut s’appliquer partout, avec le strict minimum de code HTML, que par des démonstrations poussives de code qui demandent une structure HTML bien spécifique.

Si votre code ne provoque pas chez vos collègues un « attends, la vache, comment t’as fait ça là », c’est que vous n’êtes probablement pas un très bon magicien.

Il y a quelques mois, un tweet anglophone avait fait le tour du web déclarant quelque chose comme ça :

Google est le nouveau Microsoft. Microsoft est le nouveau Apple. Apple est le nouveau messie.

La semaine dernière, dans le podcast The Talk Show, John Gruber et MG Siegler discutaient de cette idée :

John Gruber : Dans une vue d’ensemble, à la table de poker de la Silicon Valley, l’état d’esprit « l’ennemi de mon ennemi est mon ami » fait de Google le nouveau Microsoft. Ce sont les seuls à mettre leurs doigts dans les tartes de tout le monde, à ne se faire aucun ami, et à détruire les amitiés qu’ils avaient.

C’est toujours difficile de s’imaginer jusqu’où cette industrie peut aller en à peine 5 ans. Mais quand l’iPhone a été présenté en 2007, il y avait Eric Schmidt, invité sur scène, à faire des accolades avec Steve Jobs, et à expliquer à quel point Google et Apple sont de supers entreprises, presque frère et soeur. Apple font leur truc, Google fait son truc, c’est complètement dissocié, on s’aime, et on est très heureux d’avoir quelques uns de nos services sur iPhone. Et maintenant regardez où ils en sont.

Google se fait des ennemis de tout le monde.

MG Siegler : Exactement. Et quand vous leur en parlez, ils n’ont pas l’air d’en être conscients. Ce n’est même pas vraiment un secret, et tout le monde le voit. Et si vous n’êtes pas l’ennemi de Google maintenant, vous avez peur que Google vienne sur votre terrain parce que c’est ce que Google fait tout le temps. Je dirais que la meilleure relation qu’ils ont, c’est avec Samsung, parce que Samsung est la seule société à bien s’en sortir avec Android, mais… on verra bien ce qui va se passer avec le rachat de Motorola.

John Gruber : En effet, ils ont vraiment l’air de ne pas être conscients de ça. Et pour moi c’est la différence avec l’époque où Microsoft était l’ennemi de tout le monde. Microsoft avait bien conscience de leur rôle, et qu’ils se faisaient des ennemis de tout le monde. Qui que ce soit qui faisait des bénéfices, Microsoft voulait leur voler leur marché.  Google n’a pas conscience de ça. Google pense qu’ils sont encore les amis de tout le monde, alors que tout le monde les déteste.

C’était vraiment marquant hier, lors de la keynote de lancement du WWDC2012 d’Apple, qu’Apple faisait un bon gros doigt d’honneur à Google du début à la fin. Des petites piques de potaches (« Ice Cream Sandwich. Jelly Bean. Hey, qui c’est qui trouve ces noms ? Ben & Jerry ?« ), aux choix réellement stratégiques (abandon de Google Maps, mise en avant de résultats sportifs dans Siri, intégration profonde dans iOS de Facebook et Twitter, …), Apple semble bien déterminé à laisser Google de côté.

Le malaise envers Google se fait aussi sentir sur le web, où la relation entre Mozilla et Google me semble toujours aussi étrange. Si les deux sociétés sont officiellement « partenaires » (notamment via un contrat d’1 milliard de dollars pour les 3 années à venir), j’ai vraiment l’impression que Mozilla aurait préféré que Google reste en dehors du marché des navigateurs. Et si de mon point de vue, l’arrivée de Chrome a été une bonne chose et a donné un coup de fouet au marché des navigateurs, je ne suis pas sur que le glissement vers le statut de N°3 était dans les ambitions de Mozilla.

Dans les années 1980, une légende urbaine racontait que le groupe Van Halen exigeait avant chaque concert d’avoir dans leur loge un bol rempli de M&M’s, mais ne devant contenir aucun M&M’s marron. Il se trouve que cette légende (racontée notamment dans Wayne’s World 2) est belle et bien réelle. Mais il ne s’agit pas du tout d’une excentricité du groupe, et il y a une raison bien rationnelle derrière tout cela. Il y a quelques années, Jim Cofer expliquait sur son blog :

Van Halen était un des premiers groupes de rock à faire des concerts vraiment énormes dans des villes moyennes comme Macon, en Géorgie. Les équipes des scènes dans ces petites villes étaient habituées à ce que des groupes viennent en ville avec, au plus, trois semi-remorques pleins d’équipement. L’équipement de Van Halen demandait jusqu’à 9 semi-remorques. Il y avait beaucoup de matériel, et les équipes dans ces lieux étaient souvent submergées. Et quand les gens sont sous l’eau, ils font des erreurs. A un concert de rock, « faire une erreur » pendant l’installation a un grand nombre de conséquences possibles. Certaines erreurs n’auront aucun effet. D’autres erreurs rendent le son du groupe horrible, ce qui n’affecte que l’image du groupe. Mais certaines erreurs sérieuses peuvent tuer des gens… et c’est exactement ça dont le groupe avait peur.

Au coeur de n’importe quel concert majeur, il y a un contrat. Une grande partie des textes de ces contrats sont des mentions légales standards passe-partout, mais chaque groupe peut y ajouter des demandes spécifiques via quelque chose appelé un « avenant ». La plupart des contrats impliquant des concerts dans des lieux importants sont bourrés d’avenants, dont la plupart évoquent des détails techniques spécifiques à la mise en scène du groupe. Par exemple, un avenant pourra dire « Article 148 : Il y aura 15 prises de courant séparées de 6 mètres, espacées de manière identique, fournissant 19 ampères au total, sur des poutres suspendues au plafond, qui doivent pouvoir supporter un poids total de 2500 Kg chacune, en étant suspendues à au moins 9,5 mètres de hauteur, mais pas plus de 11,5 mètres, au dessus de la scène« . Les contrats des concerts de Van Halen avaient plusieurs centaines de demandes similaires, et leurs contrats finissaient par ressembler, comme le disait le chanteur David Lee Roth, à des « Pages Jaunes chinoises ».

Les équipes des lieux importants dans les grandes villes étaient habituées à des spectacles techniquement complexes comme ceux de Van Halen. Le groupe jouait dans des lieux comme le Madison Square Garden de New York ou l’Omni à Atlanta sans le moindre incident. Mais le groupe remarquait souvent des erreurs, parfois des erreurs significatives, dans l’installation de la scène dans les plus petites villes. Le groupe avait besoin d’un moyen pour savoir que leur contrat avait bien été lu en entier. Et voilà comment est arrivé le « bol sans M&M’s marron ». Le groupe avait ajouté une clause au beau milieu du jargon technique d’autres avenants : « Article 126 : Il n’y aura aucun M&M’s marron dans la zone backstage, sous peine d’abandon du spectacle, avec réparation intégrale. » Ainsi, le groupe pouvait simplement entrer dans un stade, et chercher un bol de M&M’s dans leur loges. Pas de M&M’s marron ? Quelqu’un a lu le contract en entier, donc il n’y a probablement pas d’erreur majeure avec les équipements. Un bol de M&M’s avec des bonbons marrons ? Pas de bol de M&M’s du tout ? Arrêtez tout le monde et vérifiez le moindre petit truc, parce que quelqu’un n’a pas pris la peine de lire le contrat.

Si vous déléguez une tâche et que vous voulez vous assurer qu’elle est bien exécutée, vous devriez toujours demander un « bol de M&M’s sans marrons » dans votre cahier des charges. J’ai trop souvent eu écho de chefs de projets ou référenceurs insatisfaits parce que telle demande ou telle préconisation n’avait pas été prise en compte, bien qu’écrite noire sur blanc dans le cahier des charges.

Dans le cas d’un référenceur, on pourrait imaginer la demande d’ajout d’une balise <meta name= »mms » content= »nobrown » /> sur une page spécifique, noyée au milieu de toutes les autres préconisations. Ainsi, pour vérifier si le travail a été fait, il suffira de commencer par vérifier la présence de cette balise.

Début mai, des ingénieurs de Facebook sont venus chez Google faire une présentation intitulée « Timeline timeline« , où comment l’outil de profilage en Timeline de Chrome leur a permis d’optimiser les pages Timeline sur Facebook, et vice-versa. Paul Irish, de chez Google, résumait sur son compte Google+ ses principales notes :

• Quand vous essayez d’améliorer la vitesse de rendu CSS d’un site, vous devez identifier le pourcentage du temps passé à exécuter les sélecteurs (« selector matching« ), au calcul des styles (« style recalculation« ), au reflow et au repaint.
• Vous êtes préoccupés par le paint ? Désactiver le rendu d’un élément avec « visibility:hidden » et voyez ce que ça donne.
• Vous êtes préoccupés par le reflow ? Sortez un élément de l’arbre du rendu avec « display:none ».
• Utilisez requestAnimationFrame pour mesurer le nombre d’images par secondes.
• Des images en background fixes sont très coûteuses en framerate.
• Chrome est assez paresseux pour décoder des images en JPG. Redimensionner une image côté client est très coûteux car Chrome garde à la fois l’image originale décodée et la nouvelle image redimensionnée en mémoire. Cela peut causer l’expulsion d’autres images de la mémoire ce qui demandera un nouveau décodage par la suite. Chrome Task Manager permets de suivre les chiffres de vos images en cache : si la consommation de mémoire est plus ou moins la même alors que vous voyez de nouvelles images, vous expulsez très certainement des anciennes images.
• performance.webkitNow() a été implémenté dans Chrome et permets de faire des mesures très précises (à la nanoseconde et même au delà).

L’année dernière, j’ai découvert (grâce à une conférence TED) Dan Meyer. Dan Meyer est un professeur de mathématiques en collèges et lycées, actuellement doctorant à l’Université de Stanford. Le crédo de Mr Meyer, c’est que les mathématiques sont partout autour de nous, et qu’il faut partir de ça pour les enseigner et les rendre intéressantes.

Il lutte contre les manuels scolaires, avec leurs problèmes tout fait totalement déconnectés de la réalité et qui utilisent de faux prétextes pour rendre intéressant les problèmes. Par exemple :

Personne, dans la vraie vie, ne s’est posé ce genre de problèmes. Et encore moins sous cette forme.

Il a donc imaginé une méthodologie en 3 actes :

1. Introduisez le problème central de votre histoire/tâche clairement, visuellement, viscéralement, en utilisant aussi peu de mots que possible.
2. Les protagonistes/étudiants surmontent les obstacles, cherchent des ressources, et développent de nouveaux outils.
3. Résolvez le problème et mettez en place une suite/extension.

Un des premiers problèmes sur lesquels j’étais tombé, et qui m’avais particulièrement plu, est celui du réservoir d’eau. Regardez la vidéo ci-dessous, et voyez si ça provoque en vous le besoin soudain de résoudre ce problème.