HTeuMeuLeu

Ces dernières semaines ont été particulièrement chargées en révélations dans le monde d’Android. La fin du premier trimestre 2012 a également été l’occasion pour de nombreuses sociétés d’annoncer leurs résultats. Mais surtout, le procès actuellement en cours aux États-Unis opposant Google à Oracle sur l’utilisation de technologies propres à Java. Si vous voulez en savoir plus, CNET a un résumé assez complet.

Voici une sélection personnelle de différents faits et chiffres apparus ces dernières semaines :

• Larry Page a dit : « Je crois qu’Android était important pour Google. Je ne dirais pas que c’était crucial. » (source)
• On a vu a quoi ressemblait le premier prototype de Google Phone en 2006, deux ans avant l’arrivée de l’iPhone.
• Google espérait vendre 10 millions de tablettes et atteindre 33% de parts de marché en 2011 (source)
• La Kindle Fire d’Amazon, une tablette Android dépourvue de tous les services de Google, est la plus populaire des tablettes Android avec plus de 54% de parts de marché (source)
• Six mois après sa sortie, la dernière version d’Android ne représente que 4,9% de tous les téléphones Android. (source)
• C’est la plus lente adoption d’Android, toutes versions confondues. (source)
• L’opérateur Verizon a vendu au cours du premier trimestre 2012 plus d’iPhones que tous les modèles de téléphones Android confondus (source)
• « Apple a capturé 73% des bénéfices de l’industrie téléphonique et Samsung a capturé 26%. HTC a pris 1%. Tous les autres ont perdu de l’argent. » (source)
• En 2010, Google gagnait 2,5x plus d’argent avec iOS qu’avec Android. (source)

« Android vaincra ».

Mais pas cette année. Cette année, c’est Apple.

Ce week-end, j’ai regardé une vidéo de Sequeletis (vue via Twitter) expliquant comment le jeu Mega Man éduque le joueur à travers son design et la conception de ses niveaux, et non par de vulgaires tutoriels. La vidéo dure 20 minutes, mais tout s’enchaîne très vite c’est très rigolo (j’ai ris tout haut à 1min44).

Si ce concept est important dans le jeu vidéo, c’est à mon avis tout aussi valable pour le web. Il y a deux mois je partageais avec vous l’exemple des portes de Norman, en résumant ma pensée :

Si vous devez expliquer à l’internaute comment se servir de votre page, même avec une simple phrase, vous avez raté votre travail.

C’est malheureusement une pratique très courante sur le web, où on va forcer l’internaute à lire une notice. Même un simple « cliquez ici » est une notice. Pourtant, des petits détails parfois anodins peuvent faire la différence.

Par exemple chez Archiduchesse, quand vous ajoutez un produit à votre panier à partir d’une page liste, une petite étoile en pixel art va partir du produit pour de diriger vers le récapitulatif du panier en haut à droite du site.

S’il est assez courant de retrouver un récapitulatif panier sur un site e-commerce à cet endroit, et s’il est déjà ici assez bien mis en avant graphiquement, cette animation fait clairement le lien entre l’action tout juste réalisée et la suite, c’est à dire le passage d’une commande.

Sur la plupart des sites e-commerce, bien qu’ayant des mises en page relativement similaires, l’ajout au panier se suit en général d’une popup indiquant à l’internaute qu’il peut « poursuivre son shopping » ou « finaliser sa commande ».  Si on reprends l’exemple de la vidéo de Mega Man du début, ce genre de popup est complètement l’équivalent des bulles d’aide dans les jeux vidéo vous bloquant dans votre lancée pour vous expliquer des concepts basiques.

Le skeuomorphisme est le principe d’imiter dans un objet un détail de conception qui n’est plus nécessaire, mais qui était indispensable autrefois. On trouve de nombreux exemples dans la vraie vie, comme l’imitation de rainures de bois sur des meubles en plastique, ou l’imitation du son de fermeture de l’obturateur sur un appareil photo numérique compact ou bridge. En informatique, on rencontre chaque jour pleins d’exemples. Le plus classique est l’utilisation d’une disquette comme icône de sauvegarde de documents.

Cet article de aKa chez FramaBlog nous rappelle également de manière amusante pourquoi les touches de nos claviers sont disposées ainsi :

Un beau matin de 1868, alors que les États-Unis résonnent encore des canons de la guerre de sécession, un bricoleur du Wisconsin du nom de Sholes invente la première machine à écrire. Sans se poser trop de question, il place logiquement les touches par ordre alphabétique.

Chaque touche appuyant sur une barre métallique horizontale qui ne peut pas frotter contre ses voisines, Sholes se voit dans l’obligation de décaler les rangées de touches, décalage qui est encore présent, sans aucune raison autre qu’historique, sur votre clavier, voire même sur les claviers virtuels des tablettes et des écrans tactiles !

Les champions du skeuomorphisme ces dernières années, ce sont Apple, qui usent et abusent d’effets skeuomorphiques dans leurs logiciels.

L’année dernière, James Higgs exprimait son mépris pour cette nouvelle tendance :

Il va sans dire que ma préférence va pour le design sans décoration, certainement sans un soupçon de sentimentalisme, et que je déteste ces nouvelles applications. Pourquoi ?

Pour faire simple : parce que ce sont des mensonges. Elles tentent de nous réconforter en essayant de nous montrer comment elles sont liées aux objets physiques du monde réel alors qu’il n’y en a pas besoin. En quoi sommes nous aidés à comprendre ce que fait l’application Localiser mes amis en y ajoutant des décorations en cuir ? Et à quel point ça peut être difficile pour quelqu’un, même un nouveau venu dans le numérique, de comprendre une liste de livres ? Est-ce que c’est si difficile, que la seule façon de le faire comprendre est de les présenter sous forme d’une bibliothèque en bois ?

Sur Snow Leopard, Photo Booth ressemblait à ça :

Puis est arrivé Lion, et son mode plein écran. Et voici venir le train du skeumorphisme :

Boom ! Des rideaux. Des panneaux en bois. Des boutons en métal. Vraiment, Apple ?

Encore une fois, regardons l’utilité de Photo Booth : prendre des photos, enregistrer des vidéos, et leur appliquer des filtres. La première version de Photo Booth rendait tout cela très facile et accessible. Par contre, elle ne communiquait pas le but de Photo Booth : faire l’idiot et s’amuser. Laissez-moi vous présenter un exemple :

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

Photo Booth est un jouet numérique. La première version de Photo Booth, bien que très propre et fonctionnelle, ne ressemblait pas à un jouet. Ce n’était pas amusant, et ça ne vous encourageait pas à jouer avec. Avec le nouveau mode plein écran, Apple utilise le skeuomorphisme pour inviter ses utilisateurs à s’amuser.

Le skeuomorphisme sert à communiquer et à renforcer des sentiments, à aider une application à devenir une expérience mémorable, et pas juste un outil. Ça aide à communiquer sur le but d’une Interface Utilisateur, et pas seulement sur les fonctionnalités qu’elle propose.

En février dernier, les différents fabricants de navigateurs (Mozilla, Opera et Microsoft) ont exprimé leur souhait d’interpréter certaines propriétés CSS3 avec le préfixe -webkit-. Le lendemain, Daniel Glazman (co-président du groupe de travail CSS du W3C) lançait un appel à tous les développeurs web pour éviter que cette situation ne se produise. Le message a été plutôt bien relayé par la communauté du développement web et du design web. Malheureusement hier, le magazine .NET rapportait qu’Opera s’apprêtait de manière imminente à implémenter et interpréter certaines propriétés avec le préfixe -webkit- :

Opera, aux côtés de Microsoft et Mozilla, ont annoncé lors d’une réunion du CSS Working Group qu’ils supporteraient certaines propriétés avec le préfixe WebKit. C’est parce que trop d’auteurs de sites mobile utilisent uniquement les propriétés avec un préfixe -webkit-, et même pas la version standard, sans préfixe, lorsqu’elle est disponible. Cela mène à une expérience utilisateur réduite sur Opera, Firefox Mobile et IE Mobile, qui n’affichent pas les mêmes effets à la mode, comme des transitions, des dégradés, même s’ils supportent ces effets.

Il y a trois mois, je résumais le ridicule de la situation, auquel j’ajoute aujourd’hui cette représentation Tarantino-esque de l’état du web.

Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Je l’ai dit hier et je le redis aujourd’hui : c’est une honte. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs favorisent leurs propres intérêts personnels au détriment du Web Ouvert. C’est particulièrement honteux de la part d’Opera et surtout Mozilla qui se vantent sans cesse de défendre le Web Ouvert.

Qu’on soit bien clair : l’origine de tout ce débat, l’origine du problème, ce n’est pas le W3C, ce ne sont pas les navigateurs. Ce sont nous, petits intégrateurs, qui sommes la cause de ce problème. Ou plutôt, les intégrateurs peu consciencieux ou peu avertis, qui utilisent uniquement des préfixes -webkit- sans se préoccuper des autres navigateurs.

Je me considère comme un intégrateur un minimum averti. Je travaille en agence depuis 6 ans, et je fait de la veille que je partage quotidiennement sur Twitter ou sur ce blog. J’estime être relativement au courant des nouveautés du web et en particulier en intégration. Au fil des années, de ma part mon travail et également via Twitter, j’ai rencontré et discuté avec des dizaines voire une centaine d’intégrateurs. Des intégrateurs freelance, des intégrateurs en agence, des intégrateurs chez l’annonceur pour de plus ou moins grands comptes. En dehors de la sphère Twitter et de la petite famille francophone de développeurs web, j’ai très souvent constaté qu’une bonne partie d’intégrateurs sont souvent mal renseignés sur leur métier. Dans certains cas, c’est parce qu’ils considèrent l’intégration comme un simple métier, et qu’ils n’éprouvent pas l’intérêt de faire une veille quotidienne. Dans d’autres cas, c’est par manque de temps et par épuisement. Par exemple, j’ai rencontré un jour une intégratrice qui travaillait dans une agence où elle devait intégrer chaque jour un site complet (de 10 à 20 pages). Difficile de trouver le temps de faire de la veille dans de telles agences.

L’origine du problème, c’est donc le manque de formation et de connaissances détaillées dans le web pour une grosse partie des intégrateurs, développeurs web ou webdesigners. En choisissant d’interpréter les propriétés avec le préfixe -webkit-, les navigateurs ne vont pas résoudre l’origine du problème. Ils vont l’aggraver. Ces intégrateurs vont continuer à utiliser des propriétés avec le préfixe -webkit- uniquement, en se satisfaisant que ça fonctionne désormais partout. Mais ils ne se remettront pas en question, et ils n’aideront pas à rendre le web meilleur.

Alors quelle est la solution ?

Beaucoup d’intégrateurs souhaiteraient tout simplement l’abandon des préfixes navigateurs. Mais ces préfixes sont utiles et nécessaires. Ils permettent aux navigateurs d’implémenter des fonctionnalités en cours de définition par le W3C, et aux développeurs de les tester. Mais à tout moment, ces propriétés sont susceptibles de changer, pour être améliorées voire supprimer. C’est ce qui est arrivé avec les définitions des dégradés en background. La première syntaxe proposée par le W3C a été revue et adoptée par les autres navigateurs suite à la proposition d’une meilleure syntaxe par Mozilla.

Alors quelle est la solution ?

Je n’ai pas la prétention d’avoir une solution miracle. Mais par expérience, je sais une chose : si à un moment donné, un navigateur affiche un message alarmant à l’internaute sur un site donné, alors toute la hiérarchie d’une boîte va se réveiller pour que ce soit corrigé au plus vite. J’ai souvent rencontré le cas sur IE6. Sur IE6, quand vous êtes sur une page en HTTPS et que vous appelez une ressource en HTTP, le navigateur affichera une alerte à l’internaute lui demandant s’il souhaite afficher ou pas les contenus non sécurisés. A chaque fois que j’ai aidé des clients à résoudre ce problème sur leurs sites, croyez moi, toute la hiérarchie était sur le coup : des remontées du service téléphonique client au département marketing jusqu’à la direction générale. L’origine du problème vient également d’une mauvaise pratique de la part du développeur web, qui n’a pas pris le soin d’appeler des contenus sécurisés partout. Mais en corrigeant ce problème, le développeur web apprends quelque chose. Et s’il tient à sa survie, il y a de grandes chances qu’il retienne la leçon.

On pourrait alors imaginer un message d’alerte similaire, laissant entendre que le site a été mal conçu, et lui proposant d’améliorer le rendu du site. Si l’internaute accepte, le navigateur pourra interpréter les préfixes -webkit-. Sinon, la page s’affichera normalement.

Avec une telle solution, tout le monde est gagnant. L’internaute peut afficher une version optimale du site. Le navigateur peut démontrer ses capacités. Et le développeur web et les concepteurs du sites seront invités à revoir leurs pratiques.

J’espère vraiment que la décision d’Opera et de Mozilla n’est pas figée, et qu’ils essaieront de travailler avec des développeurs web pour trouver la meilleure solution, plutôt que d’imposer au monde entier leurs mauvaises décisions.

Après un premier trimestre 2012 exceptionnel, Apple a annoncé hier ses résultats du deuxième trimestre 2012. Encore une fois, et comme le résume MG Siegler, les chiffres sont exceptionnels :

• 39,2 milliards de dollars de chiffre d’affaires
• 11,6 milliards de dollars de bénéfices
• 47,4% de marge brute
• 35,1 millions d’iPhones vendus
• 11,8 millions d’iPad vendus
• 4 millions de Mac vendus
• 7,7 millions d’iPod vendus

Mais ce qui me marque le plus, c’est qu’Apple fait désormais sa deuxième entrée dans le Top 20 des entreprises ayant réalisé le plus de chiffre d’affaires en un trimestre. Apple occupe désormais la 4ème et la 6ème place de ce classement grâce aux deux derniers trimestres. Les 18 autres places sont occupées par des compagnies pétrolières, dont la plus récente date du 3ème trimestre 2011 à la 18ème place pour ExxonMobil.

Quand j’y réfléchis, je suis époustouflé.

Je suis né et j’ai grandi dans un monde où les rois du pétrole étaient les rois du monde. Nos moyens de locomotions, nos modes de vie, nos Guerres, ont directement été influencées par la possession et le contrôle du pétrole.

Depuis 6 mois, ce n’est plus le cas. Depuis 6 mois, c’est une société informatique qui a pris ce rôle. Depuis 6 mois, c’est Apple qui domine le monde.

Des étudiants de l’Université de Stanford (en Californie) ont présenté la semaine dernière à Lyon les résultats de leur recherche intitulée « Qui a tué ma batterie : analyser la consommation d’énergie des navigateurs mobiles« . Le rapport de l’étude de 10 pages est particulièrement complet et détaillé, et sa lecture s’avère très intéressante. C’est à ma connaissance un des premières lectures du genre aussi complète sur ce sujet. Si la lecture en anglais vous effraie, voici un petit résumé et une traduction des points les plus importants.

Les mesures ont été effectuées sur un téléphone Android ADP2 avec une connexion 3G. Un multimètre relié à la batterie enregistrait les mesures matérielles. Une version modifiée du navigateur par défaut d’Android a été utilisée pour mesurer précisément l’impact énergétique de chaque fichier chargé, et permettre d’automatiser la mesure de consommation pour des pages avec et sans cache.

Les tests ont été effectués sur 25 sites connus représentatifs du paysage du web. Les premiers résultats des mesures sont assez marquants. S’il faut compter au minimum une dizaine de joules pour établir une connexion 3G, la différence de consommation d’un site à l’autre peut aller de quelques joules à plus de 40.

Voici quelques exemples et quelques points qui m’ont particulièrement marqué dans cette étude.

• Certains sites comme Youtube passent près d’un quart de leur énergie de rendu sur des images.
• Le code JavaScript de Yahoo est inclus dans les pages HTML. La quantité de code JavaScript est très petite mais le code est exécuté à chaque chargement de la page. Ainsi l’exécution JavaScript prends seulement 6,79% du total de l’énergie utilisée pour le rendu.
• AOL et Picasa contiennent tous les deux de grandes images, but la consommation d’énergie des CSS d’AOL est beaucoup plus faible que celle de Picasa. La raison est qu’AOL utilise des tableaux HTML pour positionner ses images alors que Picasa utilise CSS pour positionner ses images. Ceci illustre parfaitement comment le positionnement en CSS est moins efficace en énergie que le positionnement utilisant des balises HTML.
•  Réduire JavaScript sur une page web mobile aux seules fonctions utilisées sur une page réduit grandement la consommation d’énergie. Utiliser des librairies JavaScript génériques (comme jQuery) simplifie le développement, mais augmente la consommation d’énergie des pages résultantes.
• Comme JavaScript, un fichier CSS doit être spécifique à la page et contenir seulement les règles requises par les éléments présents.
• JPEG est le format le plus efficace en énergie sur les téléphones Android, quelque soit la taille des images. Pour démontrer ce point, nous avons utilisé Mogrify pour convertir toutes les images des pages d’Amazon et de Facebook en JPEG avec une compression à 92% de qualité. Les deux sites ont alors constaté un gain de consommation d’énergie, à hauteur de 20% pour Amazon et 30% pour Facebook. La raison de ce gain est que le format JPEG compresse mieux les images et est plus rapide à décompresser que du PNG ou du GIF.

Et voici la traduction de leur conclusion apportant des conseils pour concevoir des sites efficaces en énergie.

• Nos expériences démontrent que le format JPG est le meilleur format pour le navigateur d’Android, et ce pour toutes les tailles d’images.
• Gmail, le plus « vert » des sites mobiles que nous ayons trouvé, utilise des liens HTML pour ouvrir les messages sur lesquels l’utilisateur clique. La version bureau de Gmail utilise JavaScript à la place. Nos expériences suggèrent qu’utiliser des liens plutôt que JavaScript réduit grandement la consommation d’énergie pour le rendu d’une page. Ainsi, en concevant la version mobile du site différemment de la version bureau, Gmail a été capable de sauver de l’énergie sur le téléphone.
• Nous avons trouvé un certain nombre de pages qui auraient pu être mises en cache localement et affichées sans aucun accès réseau. Malheureusement, ces sites utilisent Google Analytics, un outil qui aide le suivi de l’utilisation du site. Le JavaScript utilisé par Google Analytics force une requête réseau dynamique qui ne peut pas être mise en cache. Ainsi, bien que le site aurait pu être affiché à partir du cache, le téléphone doit payer le coût important de démarrer une session 3G. Nous espérons que ce document aidera les sites web à comprendre le coût de l’utilisation de ces outils tiers. Alternativement, si les navigateurs exposaient le statut de leur connexion à JavaScript, Google Analytics pourrait choisir de ne pas reporter d’informations si la connexion 3G est faible.
• AOL est capable de gagner de l’énergie lors de son rendu en utilisant de simples tableaux HTML pour positionner des éléments sur la page. D’autres sites qui positionnent des éléments en CSS demandent beaucoup plus d’énergies pour le rendu.
• Sur tous les sites mobiles que nous avons testé, les publicités étaient de petits fichiers JPEG et avaient peu d’impact sur la consommation totale d’énergie.
• Des sites comme apple.com sont particulièrement énergivores. Nous espérons que ce document démontre l’importance de construire un site mobile optimisé pour les appareils mobiles. Les sites qui ne le sont pas finissent par vider la batterie des téléphones des visiteurs. Ceci peut potentiellement réduire le traffic du site.

Il est difficile de mesurer la qualité d’une intégration. Certains outils comme le validateur W3C ou des validateurs WCAG permettent de se faire une petite idée, mais ne sont en rien représentatifs de tous les critères concernés par l’intégration d’une page web (graphisme, référencement, développement, etc…).

En y réfléchissant, je pense que la qualité d’une intégration peut se mesurer sur 3 niveaux avec les questions suivantes :

1. Est-ce que c’est bien pour l’internaute ? 
2. Est-ce que c’est bien pour le projet ?
3. Est-ce que c’est bien pour moi ?

La première question, « Est-ce que c’est bien pour l’internaute ?« , fait directement écho à mon mantra. En se préoccupant d’abord de l’internaute, on va faire attention aux problématiques qui vont directement le toucher :

• La performance : la vitesse de chargement d’une page web est un des critères les plus importants vis-a-vis de l’internaute. Est-ce que mon code est bien optimisé ? Est-ce que mes images sont bien découpées et bien compressées ? Est-ce que le nombre de requêtes HTTP est bien optimisé ?
• La compatibilité : vu la multitude d’appareils, de navigateurs et de logiciels permettant d’accéder au contenu de votre site, il est indispensable de codez pour les autres. Est-ce que la propriété X fonctionne sur le navigateur Y ? Est-ce que ma page s’affichera bien sur de nouveaux appareils avec des résolutions d’écran 2 fois supérieures ?
• L’accessibilité : toute aussi importante, et pourtant souvent sous-évaluée. Est-ce que le code un peu filou que je suis en train d’écrire sera bien interprété par un navigateur vocal ?

La deuxième question, « Est-ce que c’est bien pour le projet ?« , s’attache aux particularités de votre projet.

• Le type de projet : on n’évalue pas la qualité d’une intégration d’un e-mail, d’une application Facebook et d’un site e-commerce de la même manière. Les bonnes pratiques de l’intégration d’e-mails sont à l’opposé des bonnes pratiques d’un site e-commerce. Différentes problématiques demandent donc différents regards d’évaluation.
• Le graphisme : trop souvent vu comme la finalité d’une page web, il n’en reste pas moins un critère important. Est-ce que votre intégration ressemble bien à la maquette ? Est-ce que vous avez du prendre certaines libertés ? (et si oui, est-ce vraiment parce que c’est mieux pour le projet ?)
• Le référencement : selon le type de projet, il est possible que vous ayez des impératifs forts en référencement. Certaines préconisations vous demanderont peut être d’aller à l’encontre de vos bonnes pratiques habituelles.
• La technologie utilisée : même en livrant une intégration HTML statique, vous n’obtiendrez jamais le même résultat selon le langage (PHP, .NET, Ruby, …) ou le CMS (WordPress, Magento, …) utilisés par votre projet.

La dernière question, « Est-ce que c’est bien pour moi ?« , est le moment de penser à vous, cher intégrateur, mais aussi à vos collègues intégrateurs. C’est le moment de vous posez des questions sur vos pratiques personnelles.

• La compréhension de votre code : est-ce que vous arriverez à comprendre ce que vous venez d’intégrer dans 1 an ? est-ce que vos collègues vont comprendre ce que vous venez de faire ?
• La pertinence de vos choix d’intégration : j’ai intégré toute ma page en « position:absolute ».  Est-ce que c’était vraiment la meilleure solution ? Et si jamais on doit changer ça dans 3 mois ?
• Les bonnes pratiques habituelles : si vous travaillez en agence, il est important de respecter les normes d’écriture et les bonnes pratiques habituelles. Si votre agence utilise toujours jQuery, est-ce bien raisonnable d’utiliser Mootools parce que « vous aviez envie d’essayer » ?

Ce ne sont ici que quelques exemples, et les tenants et aboutissants de l’évaluation de la qualité d’une intégration sont évidemment bien plus nombreux. Mais ces quelques critères permettent déjà de prendre un certain recul sur son propre travail, et surtout de relativiser sur son jugement du travail des autres.

Le week-end dernier j’ai regardé cette conférence Post Mortem des scénaristes de Portal 2 (Chet Faliszek et Erik Wolpaw) datant de mars dernier à la GDC. Si vous avez aimé Portal 2, c’est vraiment une chouette conférence à voir (attention par contre, c’est plein de spoilers). Ce qui m’a particulièrement plu, c’est qu’ils ne parlent pas vraiment de leurs secrets de fabrication et de comment ils ont imaginé telle ou telle partie du jeu. Mais plutôt, ils parlent de toutes les idées qu’ils ont eu, qu’ils ont développé et qu’ils ont fini par abandonner. J’ai particulièrement aimé ces exemples de fausses fins (à 35 minutes dans la vidéo) :

A un moment, tôt dans la production, nous avions eu l’idée de disperser à travers le jeu des fausses fins. Ça nous est venu en regardant les sessions de tests de Portal 1. Il y a un moment aux environs des 2/3 du jeu où vous avancez sur une plate-forme qui se dirige vers un incendie. Vous êtes supposé vous en échapper et c’est là que vous rentrez en coulisse. Mais pour un petit pourcentage de testeurs, ça leur convenait parfaitement de rester sur la plate-forme et finir dans les flammes. C’était une bonne fin pour eux. C’était triste, mais ils aimaient ça. Ça finissait juste avec eux qui mourraient.

Alors on s’est dit qu’on pourrait faire plaisir à ces gens, et on avait disséminé à travers le jeu des endroits où Chell mourrait, ce serait la fin et on jouerait une chanson. Et si vous vouliez, vous pouviez vous arrêter là.

On en avait une au bout de quelque chose comme 2 minutes de jeu. Si vous mourriez là, il y avait une chanson (que Jay et moi chantions) qui passait en revue ces 2 premières minutes, et ce qu’il venait de se passer.

Puis plus tard dans le jeu, il y avait un passage où il y avait une fissure au plafond où vous pouviez voir la Lune. Vous pouviez placer un portail sur la Lune, et si vous en placiez un sur le mur, ça vous aspirait directement sur la Lune et vous vous asphyxieriez tout en écoutant une chanson triste sur la Lune. Et celle-ci marchait plutôt bien. Pour les gens qui la trouvaient, ce qui n’était qu’un petit pourcentage de nos testeurs, ils l’aimaient vraiment beaucoup.

Mais finalement on a laissé tomber ces fins alternatives. En partie parce que ça représentait beaucoup de travail pour peu de résultats. Mais aussi en partie parce qu’en dehors de ces deux fins, on avait un peu surestimé combien de fausses fins vraiment bonnes on pourrait arriver à imaginer.

Lors de la conception d’un projet, tout le monde va avoir des petites idées. C’est important de pouvoir expérimenter et tester ces idées et ces nouveaux concepts. Mais s’ils ne fonctionnent pas vraiment, ou pas aussi bien qu’on l’avait imaginé, c’est important de savoir abandonner ses idées. C’est difficile à faire, que ce soit parce que c’était une idée qui nous tenait personnellement à coeur, ou parce qu’on a passé beaucoup de temps à l’implémenter pour la tester. Mais il est toujours préférable d’avoir un produit avec une seule grande direction, plutôt que pleins de bonnes petites idées dispersées.

J’ai l’impression qu’il existe un sentiment assez étrange parmi certains développeurs qui ont passé les 10 dernières années à travailler sous Flash. Pour eux, HTML5 fait pâle figure comparé à tout ce qu’offre Flash. Pour eux, HTML5 est une véritable régression.

Je pense que HTML5 n’a pas besoin d’être meilleur que Flash sur tous les points pour le remplacer.

C’est assez courant dans le milieu high-tech. Une technologie supplante une autre, sans pour autant être meilleure sur tous les points. Pensez par exemple à la qualité audio médiocre d’un MP3 par rapport à celle d’un CD audio. Ça m’a particulièrement marqué il y a quelques années quand j’ai écouté en voiture l’album Illinoise de Sufjan Stevens, que je connaissais par coeur pour l’avoir écouté des centaines de fois sur mon ordinateur ou mon iPod. J’avais l’impression de redécouvrir l’album, et d’entendre clairement des instruments que je n’avais jamais entendu auparavant. Pourtant, à choisir, je préfère largement la flexibilité d’un fichier numérique à un CD audio.

Ce qui compte ce n’est pas forcément la technologie pour la technologie, mais la réponse qu’elle apporte aux besoins des vrais gens. Quand on s’en tient à certains points, HTML5 n’arrive pas à la cheville de Flash. Flash dispose de solides frameworks et environnements de travail (FlashDevelop, Adobe Flash IDE, Flex). Les dernières versions de Flash utilisent ActionScript 3, un langage puissant et orienté objet. Flash permets de faire des démos impressionnantes en 3D. Et jusqu’à il n’y a pas si longtemps, Adobe s’assurait de la gestion de la compatibilité entre appareils et navigateurs via son plugin Flash Player.

Mais ces points sont surtout importants pour les développeurs. Mais Monsieur Tout le monde, lui, s’en fiche pas mal de tout ça, de la même manière qu’il s’en fiche de la qualité absolue de la musique qu’il écoute. Sur Internet, je pense que l’accessibilité d’un site, la compatibilité entre appareils et navigateurs, la visibilité par des moteurs de recherche et la vitesse de chargement sont plus importants pour un utilisateur que des effets technologiques en-veux-tu en-voilà. S’il faut que ça passe par des publicités ou des démos interactives moins tape à l’oeil en HTML5 plutôt qu’en Flash, je pense que l’utilisateur final sera gagnant.

Nous sommes dans une période transitoire où les mêmes développeurs, les mêmes créatifs, les mêmes agences essaient de reproduire en HTML5 ce qu’ils avaient l’habitude de faire en Flash. C’est évidemment une erreur. Mais si ces agences essaient de comprendre ce qu’est le web, ce qu’est HTML5, ils arriveront à faire des sites meilleurs.

Vu via Hacker News sur le site du CERN : « La proposition de Tim Berner’s Lee« .

En Mars 1989, Tim Berners-Lee a soumis une proposition pour un système de gestion de l’information à son chef, Mike Sendall. « Vague, mais excitant » étaient les mots que Sendall a écrit sur la proposition, permettant à Berners-Lee de continuer.

Au fait, saviez-vous que bien qu’élaboré au sein des laboratoires Suisse du CERN, techniquement, le web a été inventé en France ?

Basé sur cette B.D. de Cyanide & Happiness et inspiré par ses parodies.

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.