HTeuMeuLeu

Il y a deux mois, je partageais mon emballement pour une conférence de Bret Victor présentant le futur des interfaces de développement. En deux mois, la vidéo de sa conférence a été vue plus de 335 000 fois sur Vimeo, et l’extrait que j’avais mis sur Youtube a été vu plus de 100 000 fois. Autrement dit, je crois ne pas avoir été seul à être emballé.

Pourtant, pour une raison qui m’échappait et m’agaçait un peu, Bret Victor n’a pas publié en ligne ses démos. Bien sûr, certains de ses articles comme « Up and Down the Ladder of Abstraction » présentaient déjà des applications réelles de ces prototypes. Et puis il y a aussi Tangle, sa librairie JavaScript pour créer des documents interactifs. Mais pas de véritable outil de développement.

Pour expliquer son choix, Bret Victor a sobrement retweeté le commentaire suivant vu sur Hacker News :

Parfois il est plus important de bien poser la graine d’une idée plutôt que le produit fini.

Pour lui, « c’est l’idée et non le produit qui doit se propager et se répandre ».

Le moins qu’on puisse dire, c’est que son idée a bien germé et a inspiré de nombreux développeurs. En moins de deux mois, on a vu apparaître les clônes suivants de son interface :

• RECanvas, une version basique de l’éditeur Canvas avec quelques exemples prédéfinis
• Water, un autre prototype utilisant la librairie D3.js
• TnLogy, une autre version avec un exemple de moteur physique
• LiveClJS, une version de l’éditeur de jeu en ClojureScript
• Frogatto Editor, l’éditeur de niveau du jeu éponyme
• CodeBook, un éditeur Canvas quasiment aussi complet que le prototype de Bret Victor

Certains sont clairement des prototypes, mais d’autres sont parfaitement utilisables pour de vrais projets. Ce qui me fascine particulièrement avec cet exemple, c’est la liberté et la rapidité avec laquelle une idée se propage et se concrétise.

Ça me rappelle une demande de Paul Irish (développeur évangéliste pour Google Chrome) lancée sur Twitter il y a deux mois : « Créez une interface web pour générer des GIFs animés en drag’n’drop ». En 24 heures, MotherEffingAnimatedGIF était né et finalisé. En vingt-quatre petites heures.

Je ne sais pas s’il y a beaucoup d’autres plate-formes de développement qui connaissent une telle effervescence et une telle profusion. Mais ça correspond parfaitement à ma vision du web et de HTML5 décrite ici il y a quelques mois :

Avec HTML5, un tout nouveau public découvre les joies et les possibilités de l’animation pour le web. HTML5 est un standard ouvert et gratuit. Avec HTML5, vous facturez à vos clients votre création plutôt que la technologie. Avec HTML5, votre code est constamment visible et accessible aux yeux de tous.

La philosophie de HTML5 est inclusive; elle pousse à la créativité en équilibre avec la technique, à l’ouverture et au libre échange.

 

Hier soir, j’ai vu chez 37signals une conférence de Aaron Draplin présentant en 50 minutes « 50 points pour détruire votre carrière« . Ça parle de design, d’astronomie, et de conseils pour bien vivre sa vie en général. Mais surtout Aaron est un monsieur très rigolo, et avec un langage cru et un franc-parler.

J’ai particulièrement ris quand il a présenté son point N°17 : Méfiez-vous de certaines catégories professionnelles.

Méfiez-vous de certaines catégories professionnelles. Voici le pire de la société. On va commencer par le bas.

7. Les télémarketeurs, faites attention
6. Les Agents de Sécurité des Transports (« TSA agents »)
5. Les pickpockets
4. Les employés du Département des Véhicules Motorisés, si vous ne l’avez jamais vécu c’est vraiment mauvais
3. Les voleurs de chevaux
2. Les collecteurs d’impôts
1. Et tout en haut… Les développeurs web. Ces salauds vont vous mentir, vous gruger et vous voler en vous regardant droit dans les yeux, inventer des conditions à la volée dont j’ai pas la moindre idée de ce qu’ils racontent, et puis vous envoyer un long e-mail en vous expliquant pourquoi c’est important… Écoutez : faites bien attention aux développeurs web. Saletés de charlatans.

C’est triste, mais ironiquement je suis assez d’accord avec lui. Le monde du développement web est bourré de charlatans. C’est difficile pour un graphiste d’être un charlatan . Si vous êtes un mauvais graphiste, ça se verra tout de suite dans votre travail. Par contre, pour un développeur web, ça me semble facile d’entourlouper un client en lui vendant un travail baclé et de mauvaise qualité, mais qui s’affichera pourtant correctement et correspondra à ses attentes graphiques.

C’est bien pour ça que je me tue à répéter que le design n’est pas la finalité d’une page web. Si vous voulez vraiment savoir ce que vaut un intégrateur, ne regardez pas ses pages intégrées. Regardez son code.

Vu ce matin sur Reddit, un extrait d’une interview de Penn Jillette, magicien professionnel, publiée initialement par Game Informer en 2009 :

Vous savez, quand j’avais 15, 16, 17 ans, je passais 5 heures par jour à jongler, et je passais peut-être 6 heures à sérieusement écouter de la musique. Si j’avais 16 ans aujourd’hui, je passerais surement ce temps à jouer à des jeux vidéo.

Le truc que les personnes âgées ne comprennent pas, c’est que – si vous n’avez jamais écouté Bob Dylan, et que quelqu’un vous le fait découvrir pendant 15 minutes, vous n’allez pas rentrer dedans. Vous n’allez simplement pas comprendre. Vous devez passer des heures et des heures pour comprendre la forme, et la même chose est vraie pour le jeu vidéo.

Vous n’allez pas simplement regarder un FPS où vous tuez des zombies et comprendre les nuances. Il y a une quantité énorme d’arrogance et d’orgueil quand quelqu’un peut regarder quelque chose 5 minutes et le rejeter. Que vous parliez de jeu vidéo ou de musique classique, vous ne pouvez pas le faire en 5 minutes. Vous ne pouvez pas écouter Le Sacre du Printemps une fois et comprendre tout ce que faisait Stravinsky.

Il me semble que vous devriez au moins avoir la politesse de dire que vous n’y connaissez rien, plutôt que de dire que ce que font les autres est mal. Le cliché de l’enfant passionné qui ne va pas dehors et joue juste à des jeux vidéo est totalement faux. Et ça vaut aussi pour l’enfant passionné qui lit des bandes dessinées et qui devient un génie, et ça vaut aussi pour l’enfant passionné qui écoute chacune des chansons que Led Zeppelin a sorti.

Ce genre d’obsession chez un adolescent de 16 ans n’est pas moche. C’est magnifique. Ce genre d’obsession va conduire à un adulte de 30 ans sophistiqué qui a des connaissances sur cette forme d’art.

Comme beaucoup d’informaticiens, je pense « être tombé dedans quand j’étais petit » en grande partie grâce aux jeux vidéo. Dans mon cas, c’était au début des années 90s à l’âge de 8-9 ans.

Au départ, je ne faisais que jouer (notamment à Doom et Alone in The Dark, ce qui en retrospective n’était quand même pas très malin de la part de mes parents). Mais rapidement, ça a éveillé ma curiosité, et ça m’a poussé à apprendre plus de choses. J’ai appris à me servir de lignes de commande pour parcourir des dossiers et lancer des jeux. Puis j’ai appris à copier des disquettes et graver des CD. Et puis j’ai appris les différentes protections possibles sur un CD-Rom, et comment les contourner. Et puis j’ai appris à faire des maps sur Half-Life. Et puis j’ai appris comment les uploader sur Internet pour les partager avec le monde entier. Et puis j’ai appris comment créer des pages web pour partager ma passion du jeu vidéo.

Et puis je suis devenu intégrateur.

C’est ce genre d’obsession qui m’a conduit aujourd’hui à faire un métier que j’aime. Et bien que ce métier n’existait pas quand j’étais petit et que j’ai commencé à développer cette « obsession », c’est exactement ça que je voulais faire.

Bonus : Si vous aimez la magie, et puisque cet article part d’une citation de Penn Jillette, je vous invite très chaudement à regarder ce tour de Penn et Teller.

La question « Pourquoi tu demandes ? » devrait être la première réponse à pas mal de questions qui semblent hors contexte. Imaginons par exemple la conversation suivante entre deux intégrateurs :

Intégrateur N°1 : Dis, tu sais comment appliquer un style uniquement sur IE6 ?

Intégrateur N°2 : Tu peux utiliser un hack ou des commentaires conditionnels.

Intégrateur N°1 : Ok, merci.

Vous croyez avoir aidé à résoudre le problème ? Revoyons la scène en insérant la question magique.

Intégrateur N°1 : Dis, tu sais comment appliquer un style uniquement sur IE6 ?

Intégrateur N°2 : Pourquoi tu demandes ?

Intégrateur N°1 : Et ben ça m’énerve, j’ai une div en float:left avec une marge à gauche, et sur IE6 elle est carrément plus grande.

Intégrateur N°2 : Oh, ça c’est le bug des marges doubles. Il suffit d’ajouter un display:inline sur la balise en question et ça marchera.

Intégrateur N°1 : Oh, tu viens de m’apprendre un truc, merci.

Cette question, pourtant si simple, permets d’identifier réellement le problème, et du coup de le résoudre, plutôt que de le contourner.

Ça marche très bien entre développeurs, mais c’est également vrai pour les échanges avec tous les autres corps de métiers du web, et en particulier avec les clients. Bien répondre à un client, c’est d’abord bien comprendre son problème.

Récemment, je suis tombé sur ce très rigolo court métrage de Michael Davies, « Ça veut dire quoi vierge ?« , qui illustre parfaitement mon propos.

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

Je vous encourage vraiment à regarder cette vidéo, mais si l’anglais vous bloque, voici une traduction par mes soins (attention, spoiler).

La fille : Maman, ça veut dire quoi, « vierge » ?

La mère : Et bien… Les filles et les garçons… les adultes, ont des corps différents… mais qui sont fait pour s’emboîter de manière très ingénieuse… comme un puzzle !

La fille : Comme les puzzles que fait Papy ?

La mère : Oui ! Enfin, non… Non ! Quand une maman et un papa s’aiment, s’aiment beaucoup… Parfois, ils aiment bien se montrer à quels points ils s’aiment.

La fille : Est-ce que le papa fait un cadeau à la maman ?

La mère : En quelque sorte.

La fille : Quel genre de cadeau ?

La mère : Papa a un truc spécial, et Maman aussi. Et quand Papa et Maman veulent faire quelque chose de spécial, pour faire un bébé, Papa prends son truc spécial et le mets dans l’endroit spécial de Maman.

La fille : Winchester ?

La mère : Non !

La fille : Le magasin de chaussures ?

La mère : Non chérie. Un endroit spécial dans le corps de Maman. Et ça rends Maman très heureuse. Et Papa est heureux aussi. Et finalement, parfois après un long moment, parfois très rapidement, Papa devient tellement heureux que ça créé une sorte d’explosion et que toutes les graines de Papa se précipitent vers l’oeuf de Maman. Et c’est ce qu’on appelle faire l’amour.
Enfin bref, jusqu’à ce que tu le fasses pour la première fois, on dit que tu es vierge. Ça doit répondre à ta question.

La fille : Mais alors… ça veut dire quoi, « extra vierge » ?

Google a présenté Project Glass, son projet de lunette de réalité augmentée, à travers une simple page Google+, une vidéo et une courte présentation (l’accentuation est de moi).

Nous partageons cette information maintenant parce que nous voulons entamer une discussion et apprendre de vos retours inestimables. Donc nous avons pris quelques photos pour montrer ce à quoi cette technologie pourrait ressembler et avons créé une vidéo pour démontrer ce que ça pourrait vous permettre de faire.

Je crois que je ne déteste rien de plus au monde que ce genre de vidéos. Ce genre de vidéos, comme le Seabird de Mozilla, la vision du futur de Microsoft, ou le futur de BlackBerry. C’est de la pure foutaise. Ces vidéos n’ont pas plus de valeur que les interfaces présentes dans des films comme Minority Report ou Prometheus. Il y a 6 mois, John Gruber résumait très bien le problème de ces vidéos :

Les designs de ces vidéos de concepts sont libres de toutes contraintes du monde réel — qu’elles soient techniques, logiques, ou financières. Travailler avec des contraintes est tout ce dont il s’agit pour du vrai design.

Je suis fasciné par les avancées technologiques dans tous les domaines. Mais ici il s’agit simplement présenté une vidéo d’un prototype. Même s’ils parvenaient à concrétiser ce prototype, il y a de grandes chances pour qu’on en soit très loin dans la réalité.

Dans la réalité, un tel projet réalisé par Google ressemblerait plutôt à ça.

Aujourd’hui sort sur nos écrans Titanic, en 3D. Je me passerais de commentaires sur cette mode. Mais ça m’a rappelé une interview rigolote vue récemment de Neil deGrasse Tyson, mon mème/astrophysicien/directeur du planétarium du Musée d’Histoire Naturelles de New York préféré (dont je vous avais déjà parlé). Il évoque la véracité scientifique des films de science fiction en général, et s’arrête sur un détail particulier du Titanic de James Cameron.

Je dois avoir été l’une des dernières personnes au monde à avoir payé pour voir le film Titanic au cinéma. On n’était plus que cinq dans la salle à ce moment là. Tout le monde avait vu le film trois fois, je devais le voir au moins une fois.

Donc je regarde le film, et tout se passe bien. Ce film, pour rappel, avait été largement vendu comme reproduisant précisément les détails du bateau. James Cameron, le réalisateur, a loué un submersible pour aller jusqu’à l’épave du bateau et observer le design des murs, les motifs chinois et les salles de commande. Il a retranscrit tout ça dans son film. Voilà quelqu’un qui se soucie des détails. Donc je regarde le film. Le bateau coule. (Désolé, j’ai raconté la fin, au cas où certains ne savaient pas.)

On connaît le jour, l’heure, la longitude, la latitude, l’année. On sait tout sur quand et comment ce bateau a coulé. Et là il y a Kate Winslet, sur sa planche, qui chante en plein délire, pendant que son petit copain coule jusqu’au fond de l’océan… (Pourquoi est-ce qu’il n’a pas essayé de s’accrocher avec elle ? Vous croyez qu’ils n’auraient pas pu arrivé à trouver un moyen à deux ? Vraiment ?) … elle est là, elle regarde le ciel. Il n’y a qu’un seul ciel qu’elle aurait du regardé, et c’était le mauvais ciel. Pire encore, ce n’était pas seulement le mauvais ciel, mais la partie gauche du ciel était le miroir de la partie droite du ciel. Non seulement c’était faux mais en plus ça a été fait par un paresseux. Et là je me dis… c’est mal !

On connait tous le ciel. C’est notre jardin à tous (et si ça ne l’est pas, ça devrait l’être). Et pour quelques dollars vous pouvez acheter un programme de planétarium sur votre ordinateur, regarder le ciel à la date du naufrage du Titanic et vous rendre compte que ce n’est pas le ciel du Titanic de James Cameron.

Donc j’ai pris ma plus belle plume, et j’ai écrit une lettre à James Cameron, lui disant poliment : « Comment est-ce que tu as pu foiré le ciel ? ». Je n’ai eu aucune réponse.

Cinq ans plus tard, je fais parti d’une commission dont il fait également parti (d’ailleurs il a été conseiller pour la NASA pendant un moment – pas pour le ciel, mais pour d’autres trucs, comme de l’exploration). Et donc, je me trouve dans la même pièce que lui. Je me dis : « voilà une belle occasion ! ». Donc je lui dis : « Monsieur Cameron, je vous ai écris une lettre il y a quelques années », qu’il n’a jamais reçue, « saviez-vous que votre ciel est complètement faux ? On connait ce ciel, et tout le reste de votre film était si précis… ». Et il me réponds : « Je ne le savais pas. » En fait ça s’est passé en post-production. Et c’est tout ce qu’il m’a dit. J’étais totalement immature, et je voulais qu’il s’agenouille à mes pieds et qu’il implore mon pardon. Mais il ne l’a pas fait. Et donc je suis resté profondément insatisfait à cause de ça.

Trois ans plus tard, il reçoit une récompense du magazine Wired. Et ils ont loué MON planétarium pour lui remettre. Donc dans mon immaturité irrationnelle, je lui en parle à nouveau. Il se trouve que j’étais invité à dîner avec lui après l’événement. On n’était que huit, on buvait bien, l’ambiance était décontractée. Je lui dit « Jim » (parce que maintenant je peux l’appeler Jim), « je t’avais écris une lettre concernant ton ciel, le fait qu’il était erroné, comment tu avais pu faire ça… » Et il m’a répondu : « La dernière fois que j’ai vérifié, Titanic a généré 1,3 milliards de dollars de recette à travers le monde. Imagine combien il aurait pu générer si j’avais eu le bon ciel ! ». Ça me l’a bouclée, je ne pouvais rien répondre à ça. Je suis rentré chez moi, la queue entre les jambes.

Deux mois plus tard, je reçois un appel d’un type : « Bonjour, je travaille en post-production dans les studios  de James Cameron. On va sortir une version spéciale du film pour son dixième anniversaire, et il m’a dit que vous aviez un ciel qu’on pouvait utiliser. »

« YEEEEES ! »

Ce sont les petits détails qui font la différence.

La semaine dernière, le Huffington Post a publié un compte-rendu sympathique d’un entretien avec Marissa Meyer sur le design de Google, et « Pourquoi la page d’accueil de Google.com est aussi simple« .

Mayer raconte que Sergey Brin lui expliqua pourquoi la page d’accueil était si vide. Quand il a commencé à créer Google, « Nous n’avions pas de webmaster et je ne faisais pas de HTML », lui a-t-il dit.

« Il a mis en place la plus simple page web qu’il pouvait pour tester le moteur de recherche quand il était étudiant en doctorat », dit Mayer pendant son entretien avec le journaliste du Bloomberg Businessweek Josh Tyrangiel. « La première version n’avait même pas de bouton de recherche parce que la touche entrée marchait aussi bien. C’était un peu par accident.  »

Mayer nota que les utilisateurs étaient initialement embrouillés par la pleine page blanche qu’ils trouvèrent sur Google.com. C’était à l’opposé de la plupart des sites de la fin des années 1990s qui « clignotaient, tournaient dans tous les sens et se rendaient eux-même compliqués. » Les gens n’arrivaient pas à comprendre comment utiliser le moteur de recherche car Google.com était trop simple.

Dans les premières études d’utilisateurs de Google, les étudiants de l’Université de Stanford devant faire une recherche sur Google restaient assis pendant 45 secondes en fixant leur écran, pas sûrs de ce sur quoi ils devaient cliquer ou comment faire une recherche », se rappelle Mayer.

« Je leur demandais, ‘Qu’est-ce que vous attendez ?’ « , dit Mayer. « Ils me disaient, ‘J’attends le reste de la page.’ La page d’accueil vide était tellement hors contexte en 1999 qu’ils attendaient que le reste de la page se charge. »

Google avait besoin d’un moyen de signaler à ses utilisateurs que la page était totalement chargée et prête à utiliser, expliqua Mayer. La solution ? Mettre en bas de la page une petite mention légale de copyright – une qui n’avait aucune valeur légale, mais dont le seul but était de suggérer que c’était OK de commencer à faire une recherche sur le web.

C’est un peu triste de voir l’état actuel de la page d’accueil de Google, régulièrement polluée par de l’auto-promotion (en particulier quand on la compare avec DuckDuckGo).

Il y a quelques années, j’avais regardé une conférence de Jason Fried (le fondateur de 37signals) où il présentait sa vision et ses méthodes de travail. J’avais particulièrement aimé sa comparaison entre le travail et le sommeil (à partir de 8’40 dans la vidéo).

Vous pouvez comparez ça à du sommeil paradoxal (« en état MOR »). Quand vous dormez, votre sommeil n’est pas productif jusqu’à ce que vous soyez en sommeil paradoxal. C’est là où la magie du sommeil se passe vraiment. Et ça prends du temps pour arriver en sommeil paradoxal. Vous ne pouvez pas allez vous coucher et arriver au sommeil paradoxal immédiatement. Il vous faut au moins une demi heure ou plus pour y arriver. Et là, si quelqu’un vous réveille, ou s’il y a du bruit, ou quoi que ce soit, vous sortez du sommeil paradoxal. Et pour y revenir, vous ne pouvez pas reprendre là où vous étiez. Vous devez refaire tout le processus pour retourner en sommeil paradoxal à nouveau. Donc même si vous passez une nuit de 8 heures, vous n’avez pas vraiment dormi pendant 8 heures. Vous avez seulement eu quelques heures de sommeil paradoxal. Nous trouvons que le sommeil paradoxal est une bonne comparaison au travail.

On aime bien l’idée que le travail est comme le sommeil dans la mesure où ça prends du temps pour se mettre dans le flot de quoi que ce soit que vous soyez en train de faire. Vous ne pouvez pas vous pointer pas au travail et être productif immédiatement. Et personne ici ne travaille réellement 8 heures par jour. On va être présent au travail 8 heures par jour, on va être assis à notre bureau 8 heures par jour, mais on n’est pas réellement productif 8 heures par jour. Si vous avez quelques heures de bon travail dans une journée, alors c’est une bonne journée. Et ça prends du temps pour arriver à cet état, pour être en effet productif et faire du bon boulot. Et c’est ce qu’on appelle du  « travail paradoxal ».

A chaque fois que quelqu’un vous touche l’épaule, il vous sort du travail paradoxal et il vous faut du temps pour revenir à cet état.

Je pense que c’est l’une des raisons qui poussent de nombreux développeurs, souvent malgré eux, à préférer travailler le soir ou le week-end. Au travail, la plupart des chefs de projets ou des clients n’hésitent pas à vous appeler ou à venir vous voir dès qu’ils ont la moindre interrogation. C’est chouette de pouvoir apporter une réponse dans l’immédiat. Mais il est rare qu’une question nécessite réellement une réponse immédiate. Très souvent, un mail répondu dans la demi-journée aurait largement pu suffire. Une interruption, même de quelques minutes, coûte en réalité bien plus en productivité.

Hier j’ai lu un article formidable chez Aentan qui parle de surréflexion :

Avez vous vu le film de Bollywood « 3 Idiots » ? C’est le film le plus rentable de tous les temps en Inde qui raconte les aventures de 3 ingénieurs étudiants à la fac. Une des scènes m’a particulièrement marqué.

– Dans l’espace, les stylos à encre ne peuvent pas être utilisés. Donc après des millions de dollars de dépenses, les scientifiques ont inventé ce stylo ! Grâce à lui vous pouvez écrire sous n’importe quelle angle, sous n’importe quelles températures, sans gravité. 

– Monsieur, pourquoi les astronautes n’ont pas essayé un crayon dans l’espace ? 

Le reste de l’article est tout aussi génial avec un exemple de puzzle qu’on trouve sur Facebook, ou comment couper une pizza en 11 parts égales.

La surréflexion est une vraie plaie en intégration. Si vous passez trop de temps à réfléchir à un problème, à la façon d’intégrer une maquette, vous finirez bien souvent par apporter une solution démesurée.

Pour une page donnée, vous pourrez trouver des milliers de façons différentes de l’intégrer. Bien sûr dans le tas il y aura des milliers de mauvaises façons de l’intégrer. Mais il n’y aura jamais une seule bonne façon d’intégrer une page. Chaque choix réalisé lors d’une intégration, que ce soit dans l’utilisation de vos balises sémantiques, dans les styles choisis pour réaliser une mise en page, ou dans la façon de coder des interactions en JavaScript, aura un impact sur le résultat final dans des directions différentes. Vous pouvez créer une page dont le poids est parfaitement optimisé, mais plus difficile à maintenir. Vous pouvez créer une page en urgence dans un temps très court, mais elle ne sera peut être pas très optimisée. Ces deux versions peuvent être toute aussi bonne, selon les critères requis pour cette page en particulier.

Si vous passez trop de temps à surréflechir le moindre de ces choix, vous ferez du sur place.

Il y a 6 mois, je partageais ma vision d’Adobe et de Flash en la résumant en une phrase :

La philosophie de Flash est exclusive; elle pousse à la créativité aux dépends de la technique, à la fermeture et à la lucrativité.

Depuis, Adobe a annoncé l’arrêt de Flash sur mobiles et son repositionnement de Flash pour de la vidéo et du jeu premium. Et on a vu arriver pour la première fois des démos de jeux impressionantes, comme Epic Citadel ou Tail Drift. Mais hier, Adobe a provoqué la colère de toute sa communauté en annonçant une taxe dédiée aux développeurs de jeux en Flash.

Les fonctionnalités premium sont disponibles sans redevance et sans restriction jusqu’au 31 juillet 2012. A partir du 1er août, les fonctionnalités premium nécessiteront une license d’Adobe. Les applications qui gagnent moins de 50 000$ de chiffre d’affaires resteront libre de toute redevance, tout comme l’utilisation des fonctionnalités premium livrées avec Adobe AIR, y compris pour les applications mobiles pour iOS et Android.

Il n’y a aucun frais pour utiliser les fonctionnalités premium des applications qui génère moins de 50 000$ de chiffre d’affaires. Pour chaque application qui génère plus de 50 000$, les frais pour utiliser les fonctionnalités premium seront de 9% du chiffre d’affaires net de l’application au dessus de 50 000$. Le chiffre d’affaires net est calculé après déduction des taxes, des coûts de traitement des frais, et des frais des plate-formes sociales.

Il est courant pour les développeurs de laisser une part de leurs revenus à la plate-forme qui les diffuse. Apple prends 30% des ventes sur l’App Store. Google prends 5% des ventes sur le Chrome Web Store. Mais c’est en échange d’un service d’hébergement, de diffusion et à moindre échelle de promotion des applications que vous soumettez. Avec la nouvelle taxe d’Adobe, vous n’avez rien de plus en échange. Autrement dit : bien que vous ayez payé Adobe des milliers d’euros en license pour utiliser leurs outils de développement Flash, vous devrez vous acquitter de 9% de vos revenus au delà de 37 000€ pour continuer à utiliser Flash.

Néanmoins, ce cap financier n’est clairement pas atteint par la plupart des jeux Flash. Et surtout, les fonctionnalités premium en question concernent uniquement l’utilisation conjointe de deux API (ApplicationDomain.domainMemory et Stage3D.request3DContext), dédiées à l’optimisation de la mémoire et à l’accélération graphique matérielle. Pourtant, cette annonce sonne vraiment comme un geste audacieux de la part d’Adobe, qui a construit son patrimoine dans le domaine du jeu grâce à des petits développeurs indépendants.

J’ai toujours du mal à voir où va Adobe en souhaitant se concentrer sur du jeu vidéo « premium », digne de consoles de salon. L’immense succès des jeux Flash s’est construit grâce à des milliers de développeurs indépendant qui ont créé des jeux simples, et attractifs pour le grand public. En visant du jeu haut de gamme, Adobe cible un public de joueurs avertis. Et dans ce domaine, ils ne sont pas en concurrence avec des organismes de standards du web, mais avec des sociétés spécialisées dans le jeu vidéo comme Nintendo, Sony et Microsoft. Adobe s’est par exemple associé à Epic et Unity pour porter leurs moteurs 3D respectifs sous Flash Player. Mais ces moteurs fonctionnent déjà sur les autres plates-formes (iOS, Android, PC, Mac, ou même via un plugin web pour Unity). J’ai un tout petit peu de mal à voir pourquoi un développeur choisirait de passer par Adobe pour porter un jeu sur le web aujour’hui.

Hier, Mozilla a lancé BrowserQuest, une démo technique sous forme de mini-jeu massivement multijoueurs tout en HTML5. C’est une petite aventure toute simple (comptez une vingtaine de minutes pour tout explorer), mais ça fourmille de détails et de références cachées. Mais c’est surtout très bien réalisé.

Le jeu a été développé par les français de Little Workshop, et a déjà accueilli plus de 150 000 joueurs en moins de 24 heures (vous pouvez suivre le nombre de connectés en temps réel ici). Il utilise pleins de joyeusetés (Canvas, WebWorkers, localStorage, Media Queries, HTML5 Audio). Et c’est censé tourner sur n’importe quel navigateur moderne sur n’importe quelle plate-forme. Oh, et vous pouvez récupérer tout le code source du jeu librement.

En jouant à BrowserQuest, je n’ai pas pu arrêter de m’empêcher de penser que ce que j’avais là, sous mes yeux, était important. En y réfléchissant, je pense que c’est important à deux niveaux.

C’est important pour Mozilla, parce que de mémoire, c’est leur première démo HTML5 qui s’adresse au grand public. Google a compris ça il y a déjà un an en proposant des clips interactifs comme 3 Dreams Of Black, ou plus récemment avec Angry Birds. Microsoft a compris ça également en portant Cut The Rope en HTML5. Mozilla a sorti le grand jeu avec BrowserQuest (sans mauvais jeu de mot), et c’est une très belle démonstration pour prêcher par l’exemple.

Mais c’est aussi important pour le web. BrowserQuest n’est pas une démonstration des capacités de Firefox. C’est une démonstration des capacités du web, en tant que plate-forme, avec ses langages. Peu importe votre ordinateur, votre tablette, votre téléphone, votre écran, votre système d’exploitation, votre navigateur, vous pouvez en profiter dès maintenant.

Et ça, ça change tout.

J’aime bien les histoires de bugs. TheDailyWTF est une mine d’or pour ça, mais j’aime beaucoup entendre de vive voix des développeurs raconter leurs propres expériences. Voici l’histoire d’un bug que j’ai rencontré il y a quelques mois. C’est le genre de bug qui une fois résolu, donne l’impression d’être David Caruso dans Les Experts : Miami, et donne envie d’enfiler une paire de lunettes de soleils en criant YEEAAAAHH à travers tout le bureau.

Quelques jours après le lancement d’un nouveau site e-commerce, le client me transfère le mail d’un de ses collègues qui rencontre un problème sur Internet Explorer. Sur la fiche produit, lorsqu’on ajoute un produit à son panier, la « div » qui s’affiche via une lightbox est coupée sur la droite.

Bizarre. Tout a bien été testé avant le lancement du site. Et même sur IE6, qui n’est pas censé être supporté, tout s’affiche correctement. Au risque de faire un peu cliché, je rassure le client en lui disant que « chez moi ça marche ». Je lui demande un peu plus de précisions sur la version d’Internet Explorer et le système d’exploitation utilisés, car sa capture d’écran envoyée ne laissait entrevoir que le contenu de la page qui posait problème.

D’après le client, le problème se produit bien sur IE8. Ça ne le fait pas sur son poste, mais il l’a bien vu sur le poste de son collègue. Et pire, sur le poste d’un autre collègue, sous IE7, l’overlay de la div s’affiche au-dessus de tout le contenu du site et de la div elle-même. Et le service de la relation client téléphonique confirme également avoir reçu des appels de clientes perdues devant leur ordinateur à cause de ce problème.

Mince alors ! On a pourtant bien testé le site dans tous les sens, sur les différents postes de la boîte sous différentes configurations. De mon côté, j’utilisais une machine Virtuelle sous Windows 7 avec IE9 d’installé. J’utilisais le « Mode de compatibilité » d’IE pour tester le rendu du site sous les différentes versions d’IE. Je sais que ce mode n’est pas 100% fidèle aux vraies versions du navigateur, mais pour ce genre de problème qui touche surtout à des styles, ça fonctionne d’habitude très bien.

Les jours ont passé et je ne vois pas trop comment trouver une solution. Je propose au client d’y jeter un oeil la prochaine fois que je leur rendrais visite dans leurs locaux. Mais c’est embêtant… Plusieurs personnes rencontrent ce bug, de manière systématique, et pas moi.

Tracassé, je décide le week-end qui suit de ressortir un vieux PC chez moi sur lequel je sais que j’ai un IE7 d’origine installé sous Windows XP. Je commence par tester sur le serveur de test du site. Rien. Je teste en ligne. Et là, miracle ! J’arrive à reproduire le problème ! C’est drôle comme la reproduction d’un bug peut être une grande satisfaction pour un développeur.

C’est l’heure de sortir ma loupe de détective et enfin de pouvoir commencer mon enquête. Sur le site en ligne, je remarque que j’ai des règles de styles supplémentaires qui apparaissent. Ces règles proviennent… de la page d’erreur 404 du site.

Après inspection des ressources appelées par la page sur IE, je me rends compte que le site fait appel à un fichier « ie.css ». C’est surement une petite délicatesse mise à ma disposition par le développeur du site. Sauf que, ne m’ayant rien dit, et n’ayant pas l’utilité d’un tel fichier, je n’avais pas créé le dit fichier sur le serveur. Du coup, la page du site faisait appel à une CSS qui renvoyait en fait la page 404 du site. Or, sur les anciennes versions d’IE, les styles présents dans une page 404 étaient interprétés dans la page courante. Les styles de la page 404 rentraient donc en conflit avec ceux de la fiche produit. Ce bug, présent sur IE7 sous Windows XP SP1, avait été corrigé dans les versions suivantes sous Windows XP SP2. Il n’apparaissait pas dans le mode de compatibilité d’IE7 sous IE9 car il s’agit d’un problème lié au chargement des ressources d’IE, et non à son moteur de rendu. Et le bug n’était pas présent sur le serveur de test, car sur ce serveur la page 404 appelée était celle par défaut du serveur et ne contenait aucun style.

Il ne me restais alors plus qu’à créer ce fichier, et passer le tout en ligne. L’affaire était résolue, et je pouvais désormais crier de joie à travers tout le bureau.

Lu chez plasmasturm, repris lui même d’ailleurs : Les 6 étapes du débogage.

1. Ça ne peut pas arriver.
2. Chez moi ça marche.
3. Ça ne devrait pas arriver.
4. Pourquoi est-ce que ça arrive ?
5. Oh, je vois.
6. Comment est-ce que ça a pu marcher ?

S’il y a un livre qui a profondément changé ma compréhension du monde et la façon dont je conçois des sites Internet, c’est très certainement « The Design of Everyday Things » de Donald Norman. Le livre traite de la conception des objets de la vie de tous les jours, d’ergonomie et de facilité d’utilisation, avec pleins d’anecdotes et d’exemples comme je les aime. Dans les premiers chapitres du livre, l’auteur prends l’exemple des portes. Cet exemple est devenu tellement célèbre qu’il est désormais courant de désigner une porte mal conçue comme une « porte de Norman ».

Quand nous approchons une porte, nous devons trouver le côté qui s’ouvre et l’endroit à manipuler. En d’autres termes, nous devons arriver à comprendre ce que l’on doit faire et où le faire. Nous nous attendons à trouver un signal visible pour réaliser la bonne manipulation : une plaque, une prolongation, un creux, un renfoncement – quelque chose qui permette à la main de toucher, saisir, tourner ou s’insérer. Ceci nous dit où agir. L’étape suivante est de comprendre comment : nous devons déterminer quelles opérations sont permises, en partie en se basant sur l’affordance, en partie guidés par les contraintes.

Il y a une variété incroyable de portes. Certaines ne s’ouvrent que si un bouton est appuyé, et certaines ne semblent pas s’ouvrir du tout, n’ayant aucun bouton, aucun matériel, ni aucun autre signe de leur fonctionnement. La porte s’ouvre peut être à l’aide d’une pédale. Ou peut être qu’elle est activée par une commande vocale, et que nous devons prononcer la phrase magique (« Sésame ouvre toi !« ). En outre, certaines portes ont des étiquettes sur elles : tirez, poussez, glissez, portez, sonnez, insérez votre carte, entrez votre mot de passe, souriez, tournez, saluez, dansez, ou peut-être juste, demandez. D’une manière ou d’une autre, quand un appareil aussi simple qu’une porte doit être utilisé avec un manuel d’utilisation – même s’il s’agit d’un manuel d’un seul mot – alors c’est un échec, mal conçu.

Je pense que c’est tout aussi valable pour le web. Si vous devez expliquer à l’internaute comment se servir de votre page, même avec une simple phrase, vous avez raté votre travail.

Que vous soyez graphiste, développeur ou chef de projets, je vous recommande vraiment très chaudement la lecture de « The Design of Everyday Things« . Le livre, bien que datant de 1988, n’a jamais été traduit en français. Mais même en étant très précis et très détaillé, il se lit relativement facilement et se divise en pleins de sections assez courtes et souvent illustrées. Et il ne coûte que 10€ chez Amazon (et si vous utilisez ce lien, vous contribuerez à mon bien être personnel).

Dans la même veine, cette galerie de photos de panneaux sur des panneaux créée par Jason Fried me fait toujours autant sourire.

Le piratage n’existe pas parce qu’il y a des mauvaises personnes ici et là qui sont des voleurs et/ou qui détestent le capitalisme et/ou se sentent dans leur droit. Bien sur, il y a des mauvaises pousses, mais ce sont les exceptions, pas la règle. Le piratage existe parce que c’est souvent un moyen plus facile d’obtenir du contenu que les moyens légaux. Et parfois, c’est le seul moyen.

MG Siegler, dans son très bon article « Winter And The Wall » (repartant du même exemple de l’offre légale inexistante pour la série Game Of Thrones, déjà brillamment illustré il y a quelques semaines chez l’excellent The Oatmeal).

Depuis un petit moment, je n’arrête pas d’entendre parler de pré-processeurs CSS, comme Sass, LESS, ou Stylus. Ces outils ajoutent de nouvelles fonctionnalités à vos CSS (comme des variables, des fonctions ou des snippets) en générant votre code côté serveur. Parfois ça donne un peu envie, mais la plupart du temps vraiment pas (voire pire encore).

Lea Verou résume parfaitement mes appréhensions sur ce genre d’outils :

• Les pré-processeurs faussent notre perception de la taille finale d’une feuille de style, et ça peut être difficile d’optimiser correctement le tout
• Les pré-processeurs rendent plus difficile la routine classique de débuggage, où les numéros de lignes visibles dans Firebug (ou équivalent) ne correspondent pas à votre CSS
• L’utilisation de pré-processeurs en équipe nécessite que toute l’équipe maîtrise l’outil
• Les fonctionnalités apportées par les pré-processeurs finiront par arriver dans les spécifications officielles de CSS (c’est déjà le cas pour les variables). Comme le dit Lea, « coder pour un pré-processeur CSS aujourd’hui c’est un peu comme construire un chateau de sable ».

Ceci dit, je n’ai jamais utilisé de pré-processeur CSS. Il est donc possible qu’avec certains d’entre eux, mes craintes ne soient pas justifiées. Pour autant, j’ai énormément de mal à me pencher sur ce sujet et m’y intéresser réellement. Peut-être parce que je suis un vieil intégrateur. Mais peut être aussi parce que j’ai tendance à préférer les choses simples.

Il y a quelques mois, j’étais tombé sur « The MicroPHP Manifesto« , un excellent article dans lequel un développeur PHP revendique son amour pour coder en PHP, sans frameworks. La comparaison donnée dans son introduction est pile poil comme je les aime :

La ligne standard de l’histoire du Punk est qu’il s’agissait d’une réaction aux excès du rock moderne, en particulier le rock progressif de l’époque. La réalité est indéniablement plus compliquée, mais je suspecte qu’il y a en ça une part de vérité. Le rock’n’roll semblait être dans son âge d’or à la fin des années 60s et 70s, inaccessible pour le grand public. Le contraste entre des groupes comme Rush et Black Flag, tous les deux supposés jouer du « rock », était extrême.

Pour rigoler, regardons la batterie du batteur de Rush Neil Peart :

Et maintenant, voici les Black Flag en train de jouer à Los Angeles en 1979 :

Vous pouvez faire tenir la totalité de Black Flag dans l’espace de la batterie de Neil Peart. Et ils joueraient quand même de manière impressionante et déchireraient tout.

Cet exemple colle parfaitement à l’utilisation de pré-processeurs en CSS. Dans l’absolu, CSS est un langage simple à utiliser. Vous n’avez pas besoin d’un compilateur. Vous n’avez pas besoin d’un éditeur particulier. Vous pouvez aller sur n’importe quel ordinateur, coder dans le bloc-notes, et faire des sites « qui déchirent ». Pour moi, une CSS doit être agnostique de tout éditeur et de tout autre langage.

Le manifeste du micro PHP cité ci-dessus s’applique alors parfaitement ici. Et si je devais résumer ma pensée en une phrase, je détournerais le fameux dicton pour donner le manifeste du CSS pur et dur suivant :

Ce qui se passe en CSS, reste en CSS.

Je déteste l’expression « surfer sur Internet ». Je ne surfe pas. Je suis assis comme un gros porc au fond de ma chaise en train de fixer un écran d’ordinateur. Je n’ai jamais fait de surf, mais je pense que ça n’a pas grand chose à voir. J’ai toujours imaginé que le terme venait d’un fournisseur d’accès ou d’une grosse boîte de com’ des années 90 qui a voulu rendre le web super cool. Mais sur le web français, les réponses sont plutôt évasives quand on cherche d’où vient l’expression. Voici par exemple l’explication de Wikipedia :

L’expression surfer sur le Web signifie « consulter le Web ». Elle a été inventée pour mettre l’accent sur le fait que consulter le Web consiste à suivre de nombreux hyperliens de page en page.

Okay. Il va falloir m’expliquer le rapport entre suivre des liens de pages en pages et des grands blonds musclés qui glissent sur des grandes vagues en Californie.

Heureusement, une petite recherche en anglais nous amène droit à la réponse. La première personne associée à l’utilisation de cette expression est Jean Armour Polly, une bibliothécaire et auteur américaine. En juin 1992, elle publie dans le bulletin de la bibliothèque de l’Université du Minnesota un article intitulé « Surfing the internet« . Sur son site personnel, elle raconte comment lui est venue l’idée de cette expression.

J’étais sous contrat avec le Wilson Library Bulletin pour écrire un article adressé aux débutants à propos d’Internet, à soumettre au journal en mars 1992. L’article a été imprimé dans l’édition de juin 1992.

En écrivant cet article, je savais que ce serait un des premiers du genre. « Zen and the Art of the Internet » était publié sur le net par Brendan Kehoe en janvier 1992, et c’était devenu un phénomène du net à petite échelle. Jusque-là il n’y avait que des RFCs (Requests for Comments) et d’autres écrits techniques à propos d’Internet. L’article de Kehoe innova pour les nouveaux utilisateurs universitaires, et j’étais décidée à faire la même chose pour les bibliothécaires.

En cherchant un titre pour l’article, j’évaluais plein de métaphores possibles. Je voulais quelque chose qui exprimait le plaisir que j’avais à aller sur Internet, tout en évoquant la compétence et l’endurance nécessaire pour bien l’utiliser. J’avais aussi besoin de quelque chose qui évoque un sens de l’aléatoire, du chaos et même du danger. Je voulais quelque chose qui fasse mouche, qui fasse mordre à l’hameçon, quelque chose de nautique.

A cette époque j’utilisais un tapis de souris de la bibliothèque d’Apple à Cupertino, en Californie, célèbre pour inventer et s’approprier des expressions savoureuses et les faire imprimer sur des survêtements et des tapis de souris (par exemple, « Un mois au laboratoire peut vous éviter une heure à la bibliothèque »). Celui que j’avais présentais un surfeur sur une grande vague. « Surfeur de l’information », ça disait. « Eureka », me suis-je dis. Et j’avais ma métaphore.

Quand je pense à l’état actuel du web, j’ai le sentiment qu’on est entré dans la 3ème génération d’intégrateurs. Chaque génération a été marquée par sa guerre entre navigateurs, ses outils de développement, et ses bonnes et mauvaises pratiques.

La première génération était la génération Netscape/Internet Explorer, du milieu des années 1990 jusque l’an 2000. Netscape était le navigateur dominant, mais s’est rapidement fait rattraper par Internet Explorer. La connexion à Internet se faisait en général en 56k. Les sites étaient principalement codés à l’aide d’éditeurs WYSIWYG, comme Microsoft Frontpage ou Macromedia Dreamweaver. Les mises en page de sites se faisaient à l’aide de tableaux, de frames, et les pages étaient remplies d’images « spacer.gif » ou de gifs animés. C’étaient les débuts d’Internet, et la première préoccupation d’un intégrateur était de mettre une page web en ligne.

La seconde génération était la génération Firefox, de 2001 jusque la fin de la décennie. Internet Explorer était le navigateur dominant, mais s’est rapidement fait grignoter par Firefox. La connexion à Internet se faisait en général par ADSL. Les sites étaient principalement codés à l’aide de gros IDE spécifiques à un langage de développement, comme Visual Studio. Les mises en page de sites se faisaient à l’aide de CSS, de float, et les pages étaient remplies de div et de Flash. La première préoccupation d’un intégrateur était de respecter le design réalisé par un graphiste.

La troisième génération est la génération WebKit, qui a débuté un peu avant 2010. Il n’y a plus vraiment de navigateur dominant, mais le moteur de rendu WebKit (utilisé dans Chrome, Safari) est largement majoritaire. La connexion à Internet se fait désormais principalement sur mobile, en Edge ou 3G. Les sites sont codés à l’aide d’éditeurs de code aux interfaces plus minimalistes, comme Textmate, SublimeText ou Notepad++. Les mises en page de sites se font à l’aide de CSS3, de media queries, et les feuilles de styles sont remplies de préfixes navigateurs. La première préoccupation d’un intégrateur est de rendre son site visible partout, peu importe le navigateur, la taille de l’écran et le type d’appareil utilisé.

Cela m’amène à faire le constat suivant. Chaque génération dure entre 5 et 10 ans. Et chaque génération a vu apparaître des méthodes de travail radicalement différentes avec des problématiques totalement différentes. J’ai toujours un léger rictus quand je vois des agences web ou des intégrateurs se vanter d’avoir « 15 ou 20 ans d’expérience », car en réalité, vous avez seulement l’expérience depuis le début de la génération en cours. Et pire, si vous avez de l’expérience mais que vous ne vous remettez pas en question, vous risquez de traîner d’anciennes pratiques désormais devenues obsolètes voire néfastes.

Si je pense qu’il n’est plus possible aujourd’hui de maîtriser toutes les facettes de l’intégration, je pense aussi qu’il est très important pour un intégrateur de continuellement se remettre en question. Les bonnes pratiques d’aujourd’hui seront les mauvaises pratiques de demain.

Et quand des clients me demandent si je crains la concurrence d’autres agences ou d’agences low-cost, je réponds par la négative. Ma plus grosse crainte, c’est moi même. La peur que je n’arrive pas à me renouveler. Et pire : la peur que je ne me rende même pas compte qu’il faille que je me renouvelle.

La semaine dernière s’est déroulée à Austin au Texas la SXSW (South by Southwest), un des plus grands festivals de musique, films et médias interactifs. C’est un des rendez-vous les plus importants pour le web, où les plus grands acteurs donnent des conférences sur tous les sujets du moment. Google était donc présent, et a donné pendant près de 3 heures une série de mini-conférences sur Android, Google+ et le web. Paul Irish, développeur dans l’équipe de Chrome, a présenté pendant 20 minutes les « trucs vraiment nouveaux nouveaux tout chaud » en HTML5. Si vous avez un peu de temps et que vous voulez rester à la page, cette vidéo est faite pour vous ! (la présentation de Paul Irish débute à 1h51)

Voici l’ensemble des sujets abordés, avec les liens vers les démos présentées :

• Les régions et exclusions CSS (article, démo), pour créer des mises en pages avancées comme dans des magazines
• Les filtres CSS (démo), pour appliquer des effets (flou, luminosité, contraste, …) sur n’importe quel élément d’une page
• La propriété navigator.connection, pour connaître le type de connexion de l’internaute
• L’API FullScreen (démo), pour afficher n’importe quel contenu d’une page en plein écran
• L’API Pointer Lock (démo), pour contraindre le curseur de la souris à rester dans une zone précise (idéal pour les jeux)
• L’API GamePad (démo), pour utiliser une manette de jeu
• L’API Page Visibility (démo), pour savoir si une page web est affichée ou en arrière-plan
• La fonction requestAnimationFrame (article, démo), pour créer des animations en utilisant efficacement le processeur de la machine
• La fonction getUserMedia (démo Photobooth, démo Webcam Toy, démo explosion), pour utiliser la webcam et le micro de l’internaute
• WebRTC, pour créer du chat audio/vidéo en temps réel

 

Le nouvel iPad est sorti, et les premiers tests de journalistes professionnels apparaissent.

Toujours pas de support d’Adobe Flash.
— Edward C. Baig, USA Today

Dommage… […] l’iPad nouvelle formule ne sait toujours pas lire les vidéos en Flash.
— Didier Sanz, Le Figaro

Au-delà des défauts habituels des produits mobiles Apple comme le manque d’ouverture ou l’absence de compatibilité avec flash, les défauts du nouvel iPad reste pour la plupart déjà connu.
— Florent Deligia, Lyon Capitale

Dans la liste des autres technologies mortes que le nouvel iPad ne supporte toujours pas : les disquettes 3,5″, les cassettes audio, les CD audio, les DVD, …

Quelle déception.