La théorie espagnole

La semaine dernière, je suis tombé sur un article intitulé : « Tous les projets logiciels sur lesquels j’ai travaillé ont utilisé la théorie espagnole de gestion de projets, et il y a des chances pour que les votre aussi« .

Et effectivement, ce fut le cas. Pour expliquer la théorie en question, l’auteur cite le livre « Peopleware: Productive Projects and Teams » de Tom DeMarco et Thimoty Lister.

Les historiens ont établi il y a longtemps une abstraction de différentes théories de valeur : la théorie espagnole, pour sa part, disait qu’il n’existait qu’une quantité fixe de valeur sur Terre. Ainsi, le chemin vers l’accumulation de richesse consistait à apprendre comment l’extraire plus efficacement du sol ou des gens.

Et puis il y a eu la théorie anglaise qui stipulait que la valeur pouvait être créée par de l’ingéniosité et la technologie. Ainsi les Anglais ont eu une révolution industrielle, pendant que les espagnols perdaient leur temps à exploiter le terrain et les indiens dans le Nouveau Monde. Ils ont déplacé d’énormes quantités d’or à travers l’océan, et tout ce qu’ils ont gagné de leurs efforts a été une énorme inflation (beaucoup trop d’or chassaient trop peu de biens).

La théorie espagnole est bien vivante parmi les managers un peu partout. Vous le voyez quand ils parlent de productivité. La productivité signifie réaliser plus en une heure de travail, mais bien trop souvent elle signifie soutirer plus pour une heure de paye. Il y a une grosse différence. Les managers de la théorie espagnole rêvent d’atteindre de nouveaux niveaux de productivité grâce au simple mécanisme du travail supplémentaire impayé. Ils divisent le travail réalisé en une semaine par 40 heures, et non pas par les 80 ou 90 heures que le travailleur a réellement passé.

Ce n’est pas vraiment de la productivité — c’est plus de la fraude — mais c’est le dernier cri pour de nombreux managers américains. Ils intimident et gratifient leurs équipes de très longues heures de travail. Ils leur font comprendre à quel point la date de livraison est importante (même si c’est peut être totalement arbitraire; le monde ne va pas s’arrêter juste parce qu’un projet se finit un mois plus tard). Ils les piègent en leur faisant accepter des plannings désespérément serrés, les poussent à sacrifier tout pour tenir la date butoir, et feront n’importe quoi pour les faire travailler de plus en plus fort.

Vous n’avez pas idée à quel point tout ceci résonne de mes précédentes expériences professionnelles.

Bonus : ça me fait aussi penser aux 20% de temps libre chez Google vus par Dilbert.

La vitesse

La semaine dernière, Steve Lohr publiait dans le New York Times un article intitulé « Pour les internautes impatients, un clin d’oeil est trop long » :

Attendez une seconde.

Non, c’est trop long.

Vous vous souvenez quand vous étiez prêts à attendre quelques secondes qu’un ordinateur réponde à un clic sur un site web ou à une frappe au clavier ? Ces temps-ci, même 400 millisecondes — littéralement un clin d’oeil — est trop long, comme l’ont découvert les ingénieurs de Google. Ce délai à peine perceptible provoque moins de recherches chez les gens.

« Inconsciemment, vous n’aimez pas attendre », déclare Arvind Jain, un ingénieur de Google qui est le maestro de la vitesse au sein de la société. « Chaque milliseconde compte. »

La vitesse est pour moi un critère essentiel de qualité d’un site web. Ça tombe bien, puisqu’une grande partie de la rapidité de chargement d’un site va de la responsabilité de son intégrateur. Et ça suit très bien mon mantra. Ainsi, la moindre décision prise par un intégrateur aura un impact sur la rapidité d’un site :

  • Le choix de vos balises HTML
  • Le nommage de vos classes et ids dans le HTML
  • La découpe de vos images
  • Le format de compression des images
  • L’utilisation d’une librairie JavaScript
  • Etc…

D’après moi, une page web ne devrait jamais peser plus de 500Ko. Le très bon Chris Coyier avait fait un sondage sur son blog, et à 64%, ses lecteurs étaient d’accords sur le fait qu’une page ne doive jamais dépasser 500Ko. Mais ça signifie que 36% de ses lecteurs ne voient pas de problèmes à avoir une page de plus de 500Ko. 500Ko, c’est déjà au minimum 10 secondes de chargement avec un débit maximal en EDGE sur mobile. Si vous surfez sur mobile, vous n’avez probablement pas 10 secondes à perdre ainsi.

Même si cette contrainte est en général bien comprise par les clients, elle reste difficile à appliquer. Il y a deux semaines, David Heinemeiser Hansson de 37signals expliquait pourquoi ils se sont concentrés sur la vitesse lors de leur de refonte de Basecamp.

La vitesse est l’un de ces principaux avantages compétitifs qui ont le pouvoir de durer sur le long terme. Comme le dirait Jeff Bezos [PDG d’Amazon], personne ne va se réveiller dans 10 ans en souhaitant que leur application soit plus lente. Les investissements dans la vitesse vont payer des dividendes pour l’éternité.

Avec un petit budget donné pour améliorer son site, un client va très certainement privilégier des changements esthétiques, ou l’ajout de nouvelles fonctionnalités. Ça me paraît surtout être un choix de facilité. Et surtout ça n’a pour moi rien de rationnel. Peut être qu’une refonte graphique va améliorer son site et son chiffre d’affaires.

Mais peut être pas.

La technologie et l’ordre naturel des choses

Je viens de lire le commentaire de Dall0o sur mon précédent article, « Les vrais gens et leurs ordinateurs » :

Mon petit frère de 11 ans a installé chrome + des plugins, se sert de ses favoris et des raccourcis clavier. Il sait installer/utiliser une iso sans soucis. Ma mère a peur de lancer un navigateur.

Ça m’a rappelé une excellente citation de Douglas Adams (auteur du Guide du Voyageur Galactique) :

Tout ce qui existe au monde quand vous naissez est normal et ordinaire, et fait juste partie intégrante de la façon dont le monde marche. Tout ce qui est inventé entre vos 15 ans et vos 35 ans est nouveau et excitant et révolutionnaire, et vous ferez probablement carrière dedans. Tout ce qui est inventé après vos 35 ans est contre l’ordre naturel des choses.

 

« Laisse moi cinq minutes »

Jason Fried, patron de 37signals, « Laisse moi cinq minutes » :

Il y a quelques années j’étais une tête brulée. Dès que quelqu’un disait quelque chose, je trouvais un moyen d’être en désaccord. Je repoussais durement une idée si elle ne rentrait pas dans ma vision du monde.

C’est comme si je devais être le premier avec une opinion, comme si ça signifiait quelque chose. Mais ce que ça signifiait vraiment c’est que je ne réfléchissais pas assez au problème. Plus vite vous réagissez, moins vous réfléchissez. Pas toujours, mais souvent.

C’est facile de parler de réactions spontanées comme si c’était quelque chose que seuls les autres avaient. Si votre voisin n’est pas immunisé, vous non plus.

Ça m’est venu à l’esprit en 2007. Je donnais une conférence au Business Innovation Factory à Providence (dans le Rhode Island). Tout comme Richard Saul Wurman [fondateur de TED]. Après ma conférence, Richard est venu se présenter et complimenter ma présentation. C’est très généreux de sa part. Il n’avait assurément pas à faire ça.

Et qu’est-ce que j’ai fait ? Je l’ai repoussé en lui parlant de sa conférence. Pendant qu’il présentait ses idées sur la scène, je faisais un inventaire des choses avec lesquelles je n’étais pas d’accord. Et quand j’ai eu l’opportunité de parler avec lui, j’ai rapidement repoussé certaines de ses idées. J’ai dû passer pour un tel trou du cul.

Sa réponse a changé ma vie. C’était quelque chose de simple. Il a dit « Mec, laisse moi cinq minutes. » Je lui ai demandé ce qu’il voulait dire par ça ? Il m’a dit que c’était bien d’être en désaccord, c’est bien de repousser des idées, c’est super d’avoir de fortes opinions et croyances, mais laisse un peu de temps à mes idées pour s’installer avant que tu ne sois sur de vouloir débattre contre elles. « Cinq minutes » voulait dire « réfléchir », et non pas réagir. Il avait absolument raison. J’arrivais dans cette discussion pour chercher à prouver quelque chose, et non pas pour apprendre quelque chose.

J’hésite à rendre cette lecture obligatoire avant de laisser des graphistes, des fans de Flash, ou des fans d’Android commenter sur mon blog.

Codez pour les autres

J’utilise de plus en plus des applications (mobile ou web) pour accéder à du contenu diffusé sur des sites. Par exemple, voici le rendu d’un de mes derniers articles sur Google Reader.

Google Reader

Lire la suite de « Codez pour les autres »

Les vrais gens et leurs ordinateurs

Il y a quelques semaines, le magazine Fortune publiait un comparatif des ventes d’ordinateurs par fabricants, avec et sans l’iPad. Résultat : en comptant l’iPad, Apple est devenu le premier vendeur d’ordinateurs, devant HP.

Et puis j’ai vu ce tweet passer pleins de fois sur Twitter :

« Apple n°1 des vente d’ordinateur si on compte l’iPad » < « Lego, n°1 des ventes de voiture si on compte les jouets » (via @Enkimy)

J’aurais trouvé ça rigolo si la comparaison n’était pas aussi incensée. Les gens n’achètent pas des Lego pour la même raison qu’ils achètent une voiture. Les gens achètent désormais un iPad pour la même raison qu’ils achetaient auparavant un ordinateur.

Quand je parle des « gens », je veux bien entendu parler de vraies personnes, de monsieur et madame tout le monde. il y a quelques années, j’avais lu un article sur un blog anglais qui expliquait la relation avec l’informatique pour le commun des mortels. J’ai été incapable de retrouver l’article en question, mais ça disait quelque chose comme ça :

La plupart des gens détestent utiliser un ordinateur. La plupart des gens préférent s’atteler à des tâches ménagères, comme passer l’aspirateur ou sortir les poubelles, plutôt que d’avoir à utiliser un ordinateur. Mais si par malheur ils doivent en utiliser un, par exemple pour rechercher une information sur Internet ou pour rédiger un courrier administratif, l’expérience est bien souvent pénible. La plupart du temps, l’ordinateur est relégué dans une pièce recluse et froide de la maison. Pour l’utiliser, il faudra s’asseoir sur une vieille chaise inconfortable utilisée là à défaut. Et puis il faudra s’armer de patience devant le moindre chargement de l’ordinateur, et faire avec la peur constante d’avoir fait une mauvaise manipulation.

J’ai toujours utilisé mon iPad comme un gadget secondaire, mais je suis vraiment convaincu que pour le marché de masse, pour monsieur et madame tout le monde, c’est tout sauf un gadget. Et ça, ça va profondément changer toute l’industrie informatique ces prochaines années, et en particulier la façon dont on conçoit des sites web.

Une maîtrise complète de l’intégration n’est plus possible

Lu chez James Hague, « Une compréhension complète n’est plus possible » :

Supposons que vous venez juste d’acheter un MacBook Air, et que votre objectif est de devenir maître de la machine, de comprendre comment elle fonctionne à tous les niveaux.

Le livre « Mac OS X Internals: A Systems Approach » d’Amit Singh est un bon début. Ça ne parle pas tant de programmation que de discours approfondis sur la façon dont toutes les parties du système d’exploitation fonctionnent entre elles : ce que fait le firmware, les séquences d’événements durant le démarrage, ce que les drivers font, et ainsi de suite. A 1680 pages, ce n’est pas une petite lecture.

Pour vraiment comprendre le matériel, Intel a gentiment mis à disposition une documentation gratuite en 7 volumes. Je vais rester simple en recommandant la lecture de Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 1: Basic Architecture (550 pages) et les deux volumes décrivant les jeux d’instructions (respectivement 684 pages et 704 pages).

[…]

Le total de tout ça, c’est plus de 11 000 pages de lecture. J’ai omis d’inclure les pages man pour des centaines d’utilitaires système et la documentation d’Xcode. Et je n’ai même pas encore abordé les connaissances graphiques nécessaires pour faire quoi que ce soit d’intéressant avec OpenGL, ou comment écrire du bon C ou Objective-C ou quoi que ce soit concernant la conception orientée objet, et…

Son article touche un très bon point, et ça m’a rappelé cette vidéo de l’excellent Richard Feynman  (prix nobel de physique et joueur de bongo) qui remets un journaliste à sa place quand il lui demande comment fonctionnent des aimants. Si vous ne connaissez pas Richard Feynman, rendez-vous service et regardez cette vidéo.

Feynman: Magnets  FUN TO IMAGINE  4  But see NEW UPDATED file at https://tinyurl.com/ycphc432

Le journaliste : Quand vous tenez deux aimants, et que vous les poussez l’un contre l’autre, vous sentez cette pression entre les deux. Et quand vous les retournez, et ils se collent l’un avec l’autre. Qu’est-ce que c’est cette sensation entre deux aimants ?

Richard Feynman : Qu’entendez-vous par « qu’est-ce que c’est cette sensation ? »

Le journaliste : Et bien, il se passe quelque chose. Cette sensation, il y a quelque chose…  quand vous collez deux aimants l’un contre l’autre.

Richard Feynman : Ecoutez ma question : qu’entendez-vous par « quelle est cette sensation » ? Bien sûr qu’il y a quelque chose. Mais que voulez-vous savoir ?

Le journaliste : Ce que je veux savoir, c’est ce qui se passe, entre ces deux morceaux de métal.

Richard Feynman : Les aimants se repoussent l’un l’autre.

Le journaliste : Oui mais qu’est-ce que ça signifie ? Ou pourquoi est-ce qu’ils font ça ? Ou comment est-ce qu’ils font ça ? … J’estime que c’est une question parfaitement raisonnable.

Richard Feynman : Bien sûr ! C’est même une excellente question ! Mais le problème, c’est quand vous demandez « Pourquoi quelque chose se passe ». Comment quelqu’un réponds à une question comme ça ?

Par exemple, Tante Minny est à l’hôpital. Pourquoi ? Parce qu’elle a glissé sur la glace et qu’elle s’est cassée la hanche. Cette réponse satisfait les gens. Mais ça ne satisferait pas quelqu’un qui vient d’une autre planète et qui ne connaît rien de nous. Par exemple pourquoi quand on se casse la hanche on va à l’hôpital ? Comment vous rendez-vous à l’hôpital quand votre hanche est cassé ? Et bien son mari a vu qu’elle s’était cassé la hanche, il a appelé l’hôpital pour que quelqu’un vienne la chercher. Tout ceci est compris implicitement par les gens.

Quand vous expliquez « Pourquoi », vous devez être dans un cadre de travail qui permets à quelque chose d’être vrai. Sinon vous continuerez éternellement de demander pourquoi.

Pourquoi est-ce que le mari a appelé l’hôpital ? Parce que le mari est intéressé par le bien être de sa femme. Mais tous les maris ne sont pas toujours intéressés dans le bien être de leur femme, quand ils sont soûls et en colère. Et donc vous commencez à avoir une compréhension très intéressante du monde et toutes ses complications. Si vous essayez de poursuivre la moindre branche, vous irez de plus en plus loin dans différentes directions.

Je pense que c’est vrai également pour le métier d’intégrateur. Avec toutes les nouveautés techniques apparues rapidement ces dernières années (HTML5, CSS3, Canvas, WebGL, …), et la mise en avant massive des technologies côté client en dehors du web (applications mobile, Windows 8, …), il n’est plus possible pour un intégrateur de maîtriser l’ensemble des technologies mises à sa disposition. Le métier d’intégrateur et plus largement de développeur front-end va alors se diviser en de nouvelles branches, tout comme il y a 10 ans le métier d’intégrateur s’était détaché du métier de webdesigner.

On en arrive alors à ce que vous aimez faire. Qu’est-ce que vous préférez ? Est-ce l’organisation de contenus basés sur la sémantique HTML ? Ou la mise en page en CSS ? Ou le développement d’interactions en JavaScript ? Est-ce que vous souhaitez continuer à faire des sites web ? Ou est-ce que vous voulez vous spécialiser dans le développement d’applications web (pour mobiles ou pour les OS dédiés) ?

Peu importe la réponse, trouvez ce que vous aimez, et creusez le sujet à fond. Car peu importe votre spécialité, ça deviendra votre plus grand atout.

Devenez un meilleur intégrateur avec Excel

J’ai souvent eu à intégrer des pages statiques avec des longues listes de liens. La plupart du temps, les chefs de projets utilisent Excel (ou OpenOffice, LibreOffice ou Google Docs) pour rassembler et partager tous ces liens. Typiquement, on va y trouver une colonne avec l’intitulé du lien, et un autre avec l’URL du lien.

Un exemple de tableau de liens sous Google Docs

A partir de ces liens, je vais devoir générer le code HTML suivant :

<ul>
<li><a href="http://www.hteumeuleu.fr/chrome-sous-android-ne-supporte-pas-flash/">Chrome sous Android ne supporte pas Flash</a></li>
<li><a href="http://www.hteumeuleu.fr/cout-grandissant-developpement-interactif/">Le coût grandissant du développement interactif</a></li>
<li><a href="http://www.hteumeuleu.fr/produire-c-est-decourager-la-creativite/">« Produire, c’est décourager la créativité. »</a></li>
<li><a href="http://www.hteumeuleu.fr/statistiques-google-janvier-2012/">Les statistiques de Google+ en janvier 2012</a></li>
</ul>

Une façon basique d’arriver à ce résultat serait d’intégrer chaque lien un par un, en copiant l’intitulé du lien, en le collant dans son éditeur de code, puis en copiant l’URL du lien, et en la collant dans son éditeur de code. Mais clairement, c’est long, fastidieux et très pénible. Et ce n’est clairement pas adapté pour des documents de plusieurs centaines de liens.

Voici une façon beaucoup plus simple d’arriver au même résultat en utilisant de simples formules dans un tableur. Ces formules fonctionnent en principe dans n’importe quel tableur (Excel, OpenOffice, LibreOffice, Google Docs), mais selon la langue du logiciel il est possible que vous deviez traduire le nom des fonctions utilisées.

Dans un tableur, pour concaténer deux valeurs de cellules ou deux chaînes de caractères, on va utiliser l’opérateur & (ex : A1 & A2). Une chaîne de caractère doit être délimitée par deux double guillemets anglais (ex : A1 & « toto »). Pour échapper des double guillemets dans une chaîne de caractère, il faut écrire deux double guillemets. Voici alors la formule qu’on utiliserait dans une colonne C pour générer la balise d’un lien dont le contenu se trouve dans la colonne A, et l’URL dans la colonne B.

="<li><a href=""" & B1 & """>" & A1 &"</a></li>"

Si vous avez un document bien formaté, vous pouvez dores et déjà étendre cette formule à tout votre colonne, et vous n’aurez plus qu’à copier/coller le tout dans votre page HTML ! Mais souvent, les documents de ce genre sont remplis d’annotations, avec des lignes vides ou commentées pour structurer un peu le document. On va alors peaufiner un peu notre formule en ajoutant un traitement conditionnel avec la fonction IF (ou SI en français). Cette fonction prends 3 paramètres : IF(test; valeur si vrai; valeur si faux). Afin de s’assurer qu’on doit bien générer du HTML pour la ligne en cours, on va vérifier si la cellule de la colonne URL n’est pas vide. Si c’est le cas, on génère bien le HTML, sinon on n’affiche rien. On obtient alors la formule suivante :

=IF(B1<>""; "<li><a href=""" & B1 & """>" & A1 & "</a></li>" ;"")

Pour finaliser tout ça, je peux également insérer une nouvelle formule dans une cellule vide qui va concaténer toutes mes balises <li>, et les englober dans une balise <ul>. Pour concaténer rapidement toute une plage de cellule, on va utiliser la fonction CONCATENATE(). Ça donne quelque chose comme ça :

=CONCATENATE("<ul>"; C3:C56; "</ul>")

Et voilà ! Vous n’avez plus qu’à copier le contenu de cette cellule dans votre page HTML. J’ai créé sur Google Docs un document d’exemple pour que vous puissiez voir le résultat directement.

2 ans

Il y a 2 ans, le 24 février 2010 à 15h52, je publiais mon premier tweet. A la base, j’ai créé un compte Twitter surtout pour moi. Chaque jour, je lis beaucoup d’articles, de tutoriels et d’actualités sur le développement web. Je conservais les articles qui m’intéressaient vraiment dans mes favoris, mais c’est très vite devenu ingérable. Je me suis dit qu’en les publiant sur Twitter, je pourrais facilement en garder une trace, et qu’au passage, ça intéresserait peut-être d’autres gens.

Il s’avère que ça ne s’est pas trop mal passé.

Il se trouve que j’aime beaucoup Twitter. J’essaie de garder le nombre de comptes que je suis à un nombre raisonnable, en suivant principalement des comptes orientés web. Mais en réalité, je me rends compte que ces 2 dernières années, Twitter a été ma première source d’informations, même bien au-delà de l’actualité du web.

Quelques mois plus tard, j’ai lancé ce blog. L’objectif de ce blog est d’être la continuité du compte Twitter, en partageant mon point de vue sur des sujets qui me tiennent à coeur. Certains appellent ça du troll, mais sincèrement, ce n’est que mon point de vue. Et ceci n’est qu’un blog personnel.

Je lis beaucoup d’articles sur beaucoup de blogs, et je suis toujours aussi surpris de la neutralité et de la consensualité que certains rédacteurs adoptent sur leurs blogs personnels. Je préfère largement lire un article passionné, avec un point de vue (quitte à ne pas être d’accord), plutôt qu’un article sans saveur digne d’un communiqué de presse.

Il y a une citation que j’aime bien (bizarrement attribuée à Mark Twain) qui dit « Danse comme si personne ne te regardait ». J’essaie d’adopter cette philosophie sur mon blog, en écrivant comme si personne ne me lisait. Et si ça peut rassurer mes détracteurs, c’est souvent le cas.

Voici quelques statistiques sur mon blog depuis son lancement en juillet 2010. J’ai eu 98 509 visites, 67 496 visiteurs uniques, et 213 808 pages vues. 58% de mes lecteurs sont sur Windows, 22% sur Mac OS, 9% sur Linux et 6,5% sur iOS (oh, et Android : 2,55%). 43% sont sur Firefox, 33% sur Chrome, 9% sur Safari et 4% sur Internet Explorer (et parmi ces 4%, 54% sont sur IE8, 25% sur IE9, 14% sur IE7, 5% sur IE6). La nuit je rêve d’avoir des statistiques de navigateurs similaires sur les sites de mes clients. 38% de mon trafic est direct, 20% vient de Twitter, 18% vient de Google, 8% vient de Facebook (et 0,5% vient de Google+).

Voici une petite liste des articles les plus vus sur mon blog :

  1. Des maquettes difficilement intégrables… wait, what ? (octobre 2011)
  2. Estimer un temps de développement, c’est difficile (février 2012)
  3. Le Pixel Perfect (mai 2011)
  4. Des démos WebGL (février 2011)
  5. Les développeurs, graphistes et chefs de projets (juin 2011)

Laissez moi revenir en détails sur ce numéro 1. La réception de cet « article » a été phénoménale. Pourtant, j’ai vraiment fait cette image à l’arrache, un mardi soir devant la télé, quelques semaines après avoir vu une image du même genre sur Reddit. Le mercredi matin, je l’ai publiée, et puis je l’ai twittée. Et là, ça a été l’avalanche. Depuis sa publication, l’article a été vu plus de 33 000 fois sur mon blog, et le fichier JPG seul a été vu plus de 76 000 fois depuis mon serveur, générant plus de 7 Go de trafic. Mais l’image a aussi été reprise un nombre impressionnant de fois sur d’autres blogs. Elle a même été traduite en anglais quelques semaines plus tard, et retweetée par George Broussard himself. Grâce ou à cause de cet article, voilà à quoi ressemblent les statistiques du blog ces 2 dernières années.

Statistiques de HTeuMeuLeu

Je pense que cet anniversaire est la bonne occasion pour remercier tous mes lecteurs et tous mes followers. Alors : merci.

 

La feuille de route d’Adobe pour Flash

Adobe a publié cette semaine sa feuille de route pour Flash ces prochaines années, et je ne pouvais pas être plus satisfait :

Avec la croissance de la compétition sur le marché des navigateurs, les fabricants de navigateurs ont de plus en plus innové et ont fourni des fonctionnalités qui ont permis de déployer des animations riches directement grâce aux technologies du navigateur, une rôle autrefois joué principalement par Flash Player. De plus en plus, les animations riches seront déployées directement dans le navigateur en utilisant HTML5, CSS3, JavaScript et les autres technologies modernes du web. Alors que le rôle premier de Flash en tant que moteur d’innovation sur le web reste le même, ce pour quoi il sera utiliser va changer.

Adobe croit que les moteurs d’exécution de Flash se prêtent particulièrement bien à deux utilisations principales : créer et déployer des jeux riches, expressifs avec des graphismes de la qualité d’une console, et déployer des vidéos premium.

Ce changement de cible pour Flash ne signifie pas que les contenus existants ne fonctionneront plus, ou que Flash ne pourra pas être utilisé pour des contenus autres que du jeu et de la vidéo. Par contre, ça signifie que lorsque nous devrons prioriser les développements futurs et les corrections de bugs, le jeu et la vidéo seront nos priorités.

Soyons clairs : aujourd’hui, si vous souhaitez diffuser de la vidéo et que vous êtes un minimum sérieux, vous êtes obligés de proposer une alternative à Flash. D’après NetMarketShare, les utilisateurs mobiles représentent 9% des internautes, et ce chiffre ne va faire qu’augmenter ces prochaines années. Aujourd’hui, plus de 60% du marché des navigateurs supporte nativement les vidéos en HTML5, et ce chiffre ne va faire qu’augmenter ces prochaines années. Les vidéos en HTML5 ont des lacunes, comme l’absence de gestion de contenus protégés (DRM). Mais Adobe le dit clairement : à part pour de la vidéo premium, utiliser Flash est une hérésie.

Et quand au jeu, j’ai un tout petit peu de mal à voir comment Adobe va s’en sortir. Depuis 3 ans, Adobe nous rabâche chaque année des nouvelles démos de jeux en 3D époustouflantes avec des gros éditeurs : Square Enix, Epic Games et l’Unreal Engine, … Mais ces 3 dernières années, tout ceci en est resté au stade de vidéo de présentation.
En comparaison, ces 3 derniers mois, on a vu arriver les portages en HTML5 de deux des jeux les plus vendus l’année dernière : Angry Birds et Cut the Rope. Il ne s’agit pas de vidéos de promesses de ce que pourraient potentiellement être des jeux en HTML5. Non, il s’agit du vrai truc.

Adobe en profite pour détailler sa feuille de route pour 2012 avec de nouvelles versions de Flash Player (noms de code « Cyril » et « Dolores »), et présente vaguement les prochaines fonctionnalités de Flash pour les années à venir (« Flash Player Next »).

Adobe présente également le support fourni pour Flash pour les différents systèmes et plate-formes, en rappelant la toute fraîche annonce de l’abandon de Flash Player pour Linux aux mains de Google. Voici un petit récapitulatif du support de Flash pour le web :

  • Apple OS X : Flash Player est toujours supporté, mais n’est plus installé par défaut sur aucun Mac.
  • Microsoft Windows : Flash Player est supporté (pour le moment).
  • Windows 8 : Flash Player (comme tout autre plugin) ne fonctionnera pas dans la version Metro de Windows 8 (destinée aux écrans tactiles).
  • Linux : Flash Player est supporté, désormais par Google, uniquement sous Chrome.
  • Mobile : Flash Player n’est plus supporté.
  • Télévision : Flash Player n’est plus supporté.

Je ne voudrais pas vendre la peau de l’ours avant de l’avoir tué, mais ça me fends le coeur de voir un ours agoniser ainsi.

En 2012, Google pète un câble

Depuis le début de l’année, j’ai l’impression que chaque semaine voit son lot de nouveaux scandales autour de Google. En voici une petite liste non exhaustive :

  • Google a monté une vaste escroquerie au Kenya pour se faire passer pour un annuaire local et inciter les entreprises à créer un site sur l’équivalent du très mauvais « Mon entreprise en ligne ». (source)
  • Des employés de Google ont été surpris en train de vandaliser les données d’OpenStreetMap. (source)
  • Google a pénalisé Chrome dans ses résultats de recherche, lui faisant perdre 0,17% de parts de marché en janvier, après avoir violé ses propres règles de SEO pour promouvoir Chrome. (source)
  • Google a changé sa politique de respect de la vie privée, les autorisant à faire du croisement de données entre tous leurs services pour mieux vous profiler. Si vous n’êtes pas d’accord, vous n’avez aucune possibilité de refuser ce changement de politique. (source)
  • Google favorise désormais les résultats de son propre réseau social, Google+, au détriment de la pertinence et de la neutralité de son moteur de recherche (source)
  • Larry Page aurait dit à ses employés : « Comprenez Google+ ou partez »
  • Google contourne les préférences de vie privée de Safari et d’IE pour continuer de vous traquer. (source)
  • Google a supprimé les liens de ses logos pour revenir à l’accueil, le b.a.-ba de l’ergonomie depuis la nuit des temps. (source)

Et on est que le 53ème jour de 2012. Google devrait relire son propre code de conduite.

Le format PSD

Il y a deux semaines j’avais parlé sur Twitter de PSD.js, un fichier JavaScript pour lire des fichiers PSD. Après quelques tests avec les PSD que j’avais sous la main, j’ai vite compris que ça ne fonctionnait pas très bien. J’aurais pu blâmer les développeurs de la librairie, ou les faiblesses de mon navigateur. Et puis je me suis souvenu d’un commentaire laissé par un développeur de Xee, une visionneuse d’images sous Mac, en plein milieu de son code.

A ce stade, je voudrais prendre un moment pour vous parler du format PSD d’Adobe. PSD n’est pas un bon format. PSD n’est même pas un mauvais format. L’appeler ainsi serait une insulte pour les autres mauvais formats, comme PCX ou JPEG. Non, PSD est un format exécrable. Pour avoir travaillé sur ce code pendant plusieurs semaines maintenant, ma haine envers le format PSD a grandi en un feu ardent qui brûle avec la violente passion d’un million de soleils.

S’il existe deux façons différentes de faire quelque chose, le format PSD fera les deux, à des endroits différents. Ensuite il inventera trois autres façons qu’aucun humain sain d’esprit n’aurait pu imaginer, et il les fera également. Le format PSD fait de l’incohérence une forme d’art. Pourquoi, par exemple, est-ce qu’il a soudainement décidé que ces morceaux en particulier devraient s’aligner sur 4 octets, et que cet alignement ne devrait pas être inclus dans la taille ? D’autres morceaux à d’autres endroits ne sont pas alignés, ou alors alignés avec l’alignement compris dans la taille. Ici, pourtant, ce n’est pas compris. N’importe lequel de ces trois comportements serait bien. Un format sensé en choisirait un. Le format PSD, bien sur, utilise les trois, et plus.

Essayer d’extraire des données d’un fichier PSD c’est comme essayer de trouver quelque chose dans le grenier de votre vieil oncle excentrique qui est mort dans une attaque de requin en se baignant en eau douce le jour de son 58ème anniversaire. Ce dernier détail n’est peut-être pas important dans cette comparaison, mais à ce stade je passe beaucoup de temps à imaginer des destins amusants pour les gens responsables de ce format digne de Rube Goldberg.

Plus tôt, j’ai essayé d’obtenir les dernières spécifications du format PSD. Pour ça, j’ai du m’inscrire auprès d’Adobe pour obtenir la permission de faire une demande pour qu’ils puissent envisager de m’envoyer ce tome sacré. Ça impliquait de devoir leur faxer une copie de tel ou tel document, probablement signé de mon sang. J’imagine seulement qu’ils rendent ce processus si difficile parce qu’ils sont intensément honteux d’avoir créé cette abomination. Je n’étais naturellement pas suffisamment crédule pour aller au bout de la procédure, mais si je l’avais fait, j’aurais imprimé chacune des pages des specs, et je les aurais brûlées. Si j’en avais le pouvoir, je rassemblerais toutes les copies de ces specs, et je les lancerais dans une fusée directement vers le soleil.

Le format PSD n’est pas mon format préféré.

J’ai toujours ce coup de gueule bien en tête à chaque fois que j’utilise des formats de fichiers créés par Adobe.

Estimer un temps de développement, c’est difficile

Vu sur Quora il y a quelques semaines, une honnête question : « Pourquoi les tâches de développement logiciel sont en général fausses d’un facteur de 2 ou 3 ? ». Michael Wolfe, CEO de Pipewise, a posté une excellente réponse.

Partons en randonnée sur la côte de San Francisco à Los Angeles pour rendre visite à nos amis à Newport Beach. Je sors ma carte et je dessine notre route le long de la côte.

La ligne doit faire environ 600 kilomètres de long. On peut marcher 6 kilomètres par heure pendant 10 heures par jour, donc on sera là bas dans 10 jours. J’appelle nos amis et on réserve le dîner pour samedi soir prochain, quand on arrivera sur place triomphalement à 18h. Ils ont hâte !

On se lève tôt le lendemain, excité de partir à l’aventure. On enfile nos sacs à dos, on emporte notre carte, et on planifie notre premier jour. On regarde notre carte. Oh oh :

Waow, il doit y avoir un million de tours et détours sur la côte. Une journée de 60 kilomètres va à peine nous emmener à Half Moon Bay. Ce voyage doit faire au moins 800 kilomètres, pas 600. On appelle nos amis pour reculer le dîner au mardi. Mieux vaut être réaliste. Ils sont déçus, mais ils sont impatients de nous revoir. Et 12 jours pour aller de San Francisco à Los Angeles n’est toujours pas si mal.

Passé cette mauvaise surprise, on décolle. Deux heures plus tard, on a à peine dépassé le zoo. Comment ça se fait ? On regarde derrière nous :

Qu’est-ce que c’est long ! Du sable, de l’eau, des marches, des criques, et des lions de mer en colère ! On avance au mieux à 3 kilomètres par heure, la moitié de ce qu’on voulait faire. On peut soit commencer à marcher 20 heures par jour, ou on peut repousser notre dîner avec nos amis encore d’une semaine. OK, partageons la différence : on va marcher 12 heures par jour et repousser notre dîner avec nos amis au week-end suivant. On les appelle pour décaler le dîner au samedi suivant. Ils sont un peu agacés mais disent « OK, on vous verra là alors ».

On campe à Moss Beach après une dure journée de 12 heures. Merde, ça prends des plombes pour monter ces tentes avec le vent. On ne se couche pas avant minuit. Pas grave : on va s’endurcir un peu et on accélérera un peu demain.

On dort trop longtemps et on se réveille mal en point et fatigué à 10 heures. Putain ! Pas moyen qu’on arrive à faire nos 12 heures. On va viser 10, et on en fera 14 demain. On prends nos affaires et on y va.

Après une lente marche de quelques heures, je remarque que mon ami boîte. Oh merde, des cloques. Il faut qu’on s’occupe de ça maintenant… On est le genre d’équipe qui tue les problèmes dans l’oeuf avant qu’ils ne viennent nous ralentir. Je cours pendant 45 minutes, 5 kilomètres vers Pescadero, pour acheter des pansements, et file retrouver mon ami pour le soigner. Je suis épuisé, et le soleil est en train de se coucher, alors on abandonne pour la journée. On va se coucher après avoir parcouru seulement 10 kilomètres cette journée. Mais on a quelques ravitaillements. Ça va aller. On rattrapera la différence demain.

On se lève le lendemain matin, des pansements pleins les pieds et on se mets en route. On sort d’un virage. Et merde ! Qu’est-ce que c’est que ça ?

Notre satané carte ne montrait pas tout ça ! Il faut qu’on marche 5 kilomètres dans les terres, autour de terrains grillagés protégés par le gouvernement, qu’on se perde deux fois, puis qu’on retourne vers la côte autour de midi. Une partie de la journée est partie pour seulement 1,5 kilomètres de progrès. OK, on ne va pas appeler nos amis pour reculer encore une fois. On va marcher jusqu’à minuit pour essayer de rattraper notre retard et reprendre notre planning.

Après une nuit troublée de court sommeil dans le brouillard, mon ami se réveille le lendemain avec une violente fièvre et des maux de tête. Je lui demande s’il pense pouvoir reprendre. « Qu’est-ce que tu crois, trou du cul, ça fait 3 jours que je marche dans un brouillard glacial sans prendre une pause ! ». OK, c’est tout pour aujourd’hui. On va s’accrocher et se remettre sur pieds. Demain on marchera 14 heures vu qu’on sera reposé et entraîné… On n’est plus qu’à quelques jours, alors on va y arriver !

On se lève le lendemain un peu groggy. Je regarde notre carte :

Oh merde ! On commence le 5ème jour de notre voyage de 10 jours, et on n’a même pas quitté la baie. C’est ridicule ! Faisons l’effort de faire une estimation précise, appelons nos amis, quitte à se faire crier dessus, mais avec une date réaliste une bonne fois pour toutes.

Mon ami dit que nous avons fait 60 kilomètres en 4 jours, c’est un voyage d’au moins 1000 kilomètres, donc environ 60 jours, peut être 70 pour être sûrs. Je dis « Pas moyen… oui, je n’ai jamais fait cette marche avant, mais je sais qu’il ne faut pas 70 jours pour marcher de San Francisco à Los Angeles. Nos amis vont se moquer de nous si on les appelle et qu’on leur dit qu’on ne les verra pas avant Pâques! »

Je continue, « si tu peux t’engager à marcher 16 heures par jour, on peut rattraper la différence ! Ce sera dur, mais c’est un moment crucial. » « Va te faire foutre », me rétorque mon ami, « Ce n’est pas moi qui ait dit à nos amis qu’on serait là dimanche à la base ! T’es en train de me tuer parce que toi tu as fait une erreur ! »

Un silence tendu tombe entre nous. Aucun coup de fil ne sera passé. J’appellerais demain quand mon camarade aura repris ses esprits et sera prêt à s’engager sur quelque chose de raisonnable.

Le lendemain matin, on reste dans nos tentes jusqu’à que la pluie diluvienne s’arrête. On remballe nos affaires et on décolle à 10h après s’être occupé de nos cloques et nos muscles. La dispute de la veille n’est pas mentionnée, mais je parle un peu durement à mon idiot d’ami quand il oublie sa bouteille d’eau derrière, et qu’on doit perdre 30 minutes pour retourner la chercher.

Je me fais une note mentale qu’on va arriver à bout de papier toilette et qu’il faudra qu’on se restocke quand on arrivera dans la prochaine ville. On arrive au coin d’un détour : une imposante rivière nous barre le passage. Je sens une énorme diarrhée arriver…

Bret Victor et le futur des interfaces de développement

Bret Victor est un concepteur logiciel/développeur/visionnaire. Il a travaillé 4 ans chez Apple et a plus récemment travaille sur l’excellent livre interactif Our Choice sur iPad. Hier matin, la toile était en ébullition devant une vidéo d’une conférence de Bret Victor au CUSEC2012 : « Inventing on Principle« . Au cours de cette conférence, il explique l’importance dans le monde informatique d’avoir des principes qui guident vos choix, vos décisions techniques et vos créations. Et il détaille son propre principe :

Si nous écrivons du code sur un ordinateur, pourquoi est-ce que nous simulons ce que l’ordinateur devrait faire dans notre tête ? Pourquoi l’ordinateur ne peux pas juste le faire et nous le montrer ?

Au cours des 35 premières minutes de sa conférence, Bret présente différents outils et interfaces qu’il a développé pour faciliter sa créativité, et obtenir un rendu immédiat de tout son code. Si vous faites du développement JavaScript, du développement Flash, de l’animation pour le web ou du web en général, vous devez impérativement regarder cette conférence.

Au cas où vous n’auriez pas le temps de regarder cette vidéo ou ne seriez pas encore totalement convaincu, voici quelques détails sur sa présentation.

En premier lieu, Bret présente un éditeur Canvas HTML5. La particularité de cet éditeur, fidèle à son principe de création, est d’afficher en temps réel la moindre modification. Il présente d’abord l’exemple d’une illustration d’un paysage en Canvas (de 2’30 à 9’30), puis d’un mini jeu de plates-formes inspiré de Braid (de 10’30 à 16’30). Si vous n’avez que quelques minutes, prenez le temps de regarder ce deuxième exemple (et si Vimeo vous insupporte, j’ai uploadé cet extrait sur Youtube).

Un éditeur de jeux

Outre les petits détails bien pensés de son interface (comme la possibilité de moduler rapidement la valeur d’une variable, numérique ou d’une couleur par exemple), la nature même de JavaScript et son exécution à la volée est ici mise en avant de façon extraordinaire. Si vous faites du Flash, ça risque d’être difficile de revenir à la réalité et à votre routine habituelle : je code pendant 5 minutes, je compile pendant 1 minute, je teste 30 secondes, et je recommence.

Un des gros avantages de JavaScript et son exécution à la volée est également mis en avant à travers un 3ème exemple (de 17′ à 23′): la création d’un algorithme de tri binaire. Si vous développez, vous connaissez la routine : vous réfléchissez à un algorithme, vous codez une première version, vous testez un premier cas, vous ajustez si nécessaire, vous testez un deuxième cas, vous réajustez si nécessaire, etc… Ici, une partie de l’interface retranscrit en direct les valeurs des différentes variables de votre code, tout en précisant vous même les valeurs de tests des paramètres passés à votre fonction.

Un éditeur d'algorithme

S’en suit une présentation d’un 4ème exemple (de 23′ à 28′) démontrant cette fois-ci l’intérêt d’une interface en temps réel hors programmation informatique avec des circuits électroniques. Et enfin, le clou du spectacle (de 29′ à 34′), la réalisation en 2 minutes d’une animation sur iPad, littéralement faite à la main, qui aurait pris une journée à faire sur l’IDE de Flash pour un néophyte.

Cette conférence véhicule pleins de valeurs que j’essaie de défendre à travers mes articles : l’importance d’un mantra, la pertinence de JavaScript comme étant un langage digne de ce nom, ou encore le fait que HTML5 pousse à la créativité au delà des limites de tout IDE. Comprenez, donc, mon emballement.

 

Un exemple de mauvais design

Vu la semaine dernière sur Twitter via Asa Dotzler, un article de Mark Shead intitulé « Pourquoi vous devez avoir des connaissances de votre domaine » :

Le pistolet à air comprimé Feinwerkbau P11 Piccolo

Voici le pistolet à air comprimé Feinwerkbau P11 Piccolo. Il coûte aux alentours de 1500$, et on dirait qu’il a été conçu principalement pour des gens qui font de la compétition. Le canon noir est ce qui propulse la bille, et le canon argenté contient l’air comprimé.

Si vous avez un pistolet qui fonctionne à l’air comprimé, ce serait bien de savoir combien d’air il vous reste n’est-ce pas ? Je ne suis pas sûr que le design ait été bien réfléchi cependant.

"Boom headshot !"

Je ne connais pas l’histoire de ce pistolet, mais je sais que vous ne devriez pas avoir à pointer un canon vers votre visage pour lire une jauge.

Quand je vois quelque chose comme ça, j’aime bien m’arrêter et me demander si je fais des erreurs similaires dans mon domaine de développement logiciel. Des erreurs de pauvre conception ne sont pas limitées aux pistolets.

Ce qui me fascine avec ce genre d’exemple, c’est qu’il s’agit d’un produit récent réalisé par une grande société spécialisée dans la fabrication d’armes. La conception de ce produit a très certainement fait intervenir des dizaines de personnes avant de passer en production. A aucun moment, personne n’a eu la présence d’esprit de se dire que ce n’était peut être pas une très bonne idée.

Google rachète Motorola Mobility

Les États-Unis et l’Union Européenne viennent de donner leur approbation pour le rachat de Motorola Mobility par Google annoncé en août dernier, pour la modique somme de 12,5 milliards de dollars. MG Siegler avait publié il y a quelques semaines un très bon article résumant ce que Google achetait pour cette somme :

Motorola Mobility ont livré — livré, pas vendu — 5,3 millions de smartphones au cours du trimestre. Pour rappel, Apple en a vendu 37 millions.

Sur toute l’année, Motorola a livré — livré, pas vendu — 18,7 millions de smartphones. Pour rappel, Apple a vendu 37 millions de smartphones ce dernier trimestre.

Ils ont livré — livré, pas vendu — 200 000 tablettes ce dernier trimestre. DEUX CENT MILLE. Pour rappel, Apple a vendu 15 millions de tablettes.

Sur toute l’année, Motorola a livré — livré, pas vendu — 1 million de tablettes. Pour rappel, Apple a vendu 15 millions de tablettes ce dernier trimestre.

La société a perdu 80 millions de dollars au cours du trimestre — dont 70 millions étaient de la division mobile. L’unité a perdu 285 millions de dollars au cours de l’année.

Et tout ça pour DOUZE VIRGULE CINQ MILLIARDS DE DOLLARS. En août dernier, John Gruber rappelait ce que cette somme représentait pour Google :

Regardez les résultats financiers de Google. Ils ont rapporté 8,5 milliards de revenus nets cette année, et 6,5 milliards l’année dernière. C’est pour la totalité de Google. Ils offrent 12,5 milliards de dollars pour Motorola. Donc Google vient de dépenser quasiment deux années de ses bénéfices pour acheter un fabricant de téléphone de seconde classe qui est lui même peu rentable, a quasiment fait faillite, et est sans doute seulement le troisième meilleur fabricant d’appareils sous Android, derrière HTC et Samsung.

J’ai un tout petit peu de mal à croire que Google ait dépensé autant pour laisser Motorola « opérer comme une unité commerciale distincte ».

Le mantra de l’intégrateur

Après le débat lancé par le W3C face aux préfixes des navigateurs, Raphaël Goetter d’Alsacréations a partagé sa solution pour facilement adapter ses sites en utilisant le script -prefix-free.

Comme beaucoup d’outils de ce genre, -prefix-free nécessite une requête HTTP et un traitement du JavaScript, au détriment des performances du navigateur.

En ce qui me concerne, je considère que les avantages fournis contrebalancent ce handicap. Mais sur mobiles, où les temps de chargement sont prépondérants, la question mérite le détour.

J’ai d’abord cru à une blague, mais il est apparemment très sérieux. Jérémie Patonnier a ce matin très bien détaillé la problématique, en titrant son article « Lier CSS à JavaScript : une mauvaise idée ».

De manière générale, ce genre d’interrogations arrive rarement quand on applique un mantra, une philosophie globale, un fil conducteur qu’on applique dans n’importe quelle situation. Personnellement, ma philosophie se résume en une question.

Qu’est-ce qui est le mieux pour l’utilisateur ? 

Le graphiste a maquetté des listes déroulantes personnalisées. Je peux utiliser un script pour simuler une liste déroulante avec la charte maquettée, au détriment des performances de la page, ou laisser les listes déroulantes par défaut du navigateur, au détriment de la charte graphique. Qu’est-ce qui est le mieux pour l’utilisateur ?

Je dois intégrer une page simple avec quelques éléments à rendre dynamique (apparition au clic ou au survol). Je peux utiliser une librairie type jQuery pour coder ça rapidement, ou prendre un peu plus de temps pour coder la même chose en JavaScript seul. Qu’est-ce qui est le mieux pour l’utilisateur ?

J’ai du texte dans une police personnalisée. Je peux importer une police en CSS3 de plusieurs dizaines de Ko, ou découper une image de quelques Ko. Qu’est-ce qui est le mieux pour l’utilisateur ?

En octobre dernier, je partageais déjà mon point de vue sur la finalité d’une page web :

On ne fait pas un site web pour le client. On fait un site web pour un utilisateur. Un utilisateur est une vraie personne. Un utilisateur a son terminal (ordinateur, smartphone, télévision, …), son entrée (clavier/souris, tactile, …), sa sortie (écran 16/9, 4/3, 72 dpi, 326 ppi, …), sa connexion internet (56k, ADSL, Fibre, Edge, 3G, …). Un terminal à son système d’exploitation (Windows, Mac OS, iOS, Android, …), son processeur, sa carte graphique, … En pratique, vous aurez quasiment autant de configurations possibles que de visiteurs. Quand vous travaillez pour le client, vous rendez 1 personne heureuse. Quand vous travaillez pour l’utilisateur, vous rendez des milliers voire des millions de personnes heureuses.

D’autres intégrateurs auront surement un mantra différent, privilégiant par exemple la charte graphique, le temps de réalisation ou le coût d’un projet. On peut y trouver un intérêt sur le court terme. Mais je pense que seule une conception pensée pour l’utilisateur reste valable sur le long terme.

« Le Web Ouvert a besoin de vous »

Daniel Glazman, co-président du groupe de travail CSS du W3C, a lancé aujourd’hui un appel à tous les acteurs du web pour éviter que les fabricants de navigateurs n’implémentent les préfixes -webkit- sur le long terme.

Je demande à toute la communauté des acteurs du web d’arrêter de concevoir des sites pour WebKit seulement, en particulier quand le support d’autres navigateurs n’est qu’une question d’ajouter quelques lignes de propriétés CSS avec des préfixes.

Je demande à toute la communauté des acteurs du web de supprimer immédiatement et d’arrêter d’implémenter la détection (sniffing) de navigateurs basés sur WebKit. Vous possédez un tel site ? Montrez votre soutien pour le Web Ouvert et supprimer cette détection immédiatement après avoir lu cet appel.

Je demande à la communauté des utilisateurs du web et des designers du web d’arrêter de recommander des sites qui nécessitent un navigateur en particulier alors qu’ils pourraient être ouverts à plusieurs navigateurs. Ne faites pas de lien vers ces sites, et mentionnez les uniquement pour faire savoir à la communauté qu’ils échouent dans leur service du Web Ouvert. Ne nourrissez pas les trolls, blacklistez les, peu importe à quel point le service qu’ils fournissent est cool.

Je suis totalement d’accord avec Daniel Glazman sur les deux premiers paragraphes. Je plaide coupable d’avoir moi même déjà utilisé des propriétés CSS avec uniquement leur préfixe WebKit (en particulier il y a 1 ou 2 ans, avant que Firefox ne revienne dans la course et commence à implémenter pleins de nouvelles propriétés).

Par contre, je suis convaincu qu’il se trompe de combat en cherchant à lancer une chasse aux sorcières. Mais puisqu’il insiste…

http://www.w3.org/2008/site/css/minimum
Ligne 134: .w3c_leftCol a:hover,.w3c_leftCol li a:focus{ -moz-transition-property:background-color;-webkit-transition-property:background-color;-o-transition-property:background-color;-moz-transition-duration:.3s;-webkit-transition-duration:.3s;-o-transition-duration:.3s;}
Ligne 181: .button{border:0;-moz-border-radius:3px;-moz-box-shadow:0 1px 3px rgba(0,0,0,0.5);-webkit-border-radius:3px;-webkit-box-shadow:0 1px 3px rgba(0,0,0,0.5);border-bottom:1px solid rgba(0,0,0,0.25);background-color:#555;color:#FFF;cursor:pointer;font-size:81%;font-weight:bold;left:5px;padding:2px 5px;position:relative;text-shadow:0 -1px 1px rgba(0,0,0,0.25);}
http://www.w3.org/2008/site/css/advanced
Ligne 31: .secondary_nav{ -webkit-box-shadow:0 1px 2px #fff;-moz-box-shadow:0 1px 2px #fff;-webkit-border-radius:5px;-moz-border-radius:5px; }
Ligne 35: #search-form{ -webkit-border-radius:5px;-moz-border-radius:5px;}
Ligne 233: #request_form fieldset input:focus,#request_form fieldset textarea:focus{ -webkit-transition:border .2s linear,-webkit-box-shadow .2s linear;-moz-transition:border .2s linear,-moz-box-shadow .2s linear; }

Le site du W3C lui-même n’utilise pas systématiquement les noms de propriétés non-préfixées, et jamais les préfixes pour l’ensemble des navigateurs (pourquoi tant de haine envers -ms- ?). Je suppose que je devrais faire comme Daniel Glazman, et lui envoyer un e-mail.

C’est facile de dénoncer et de pénaliser. 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.

Avant de vouloir pointer du doigt et pénaliser les sites qui favorisent WebKit, il serait peut être bon d’éduquer les acteurs du web. Nous sommes en 2012 et le W3C ne propose aucune documentation simple et claire, compréhensible par le commun des mortels, indiquant le bon usage et le bon fonctionnement des propriétés CSS. C’est regrettable, mais pas étonnant qu’on se retrouve dans une telle situation.

Tous les navigateurs veulent implémenter le préfixe -webkit-

Hier, lors d’un comité du groupe www-style du W3C, réunissant Daniel Glazman (co-président du groupe de travail CSS du W3C), Tantek Çelik (Mozilla), Florian Rivoal (Opera) et Sylvain Galineau (Microsoft), la discussion la plus hallucinante que j’ai pu lire à ce jour.

glazou: Title is: Why and How to Implement Other Vendors’ Prefixes
tantek: This is a specific subtopic of vendor prefixes
tantek: The problem statement right now, and this is a problem for
Mozilla and any other non-WebKit browser
tantek: Sites have webkit-specific content, and serve backup content to
everyone else. Specifically for mobile content.
tantek: Non-WebKit browsers face prisoners dilemma
tantek: similar to quirks in 2003 or so
tantek: At this point we’re trying to figure out which and how many webkit
prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.
Florian, Sylvain: Zero is not an option for us anymore either.

Vous avez bien lu : pour Mozilla, Opera et Microsoft, il n’est plus envisageable de ne pas implémenter les propriétés en utilisant les préfixes -webkit-. Et ça ne va pas s’arrêter là :

tantek: We will also need to send a webkit-tricking UA string.
tantek: Just like WebKit sent « like Gecko » in its UA string, we have to do
the same thing again

Je ne sais pas trop comment on peut s’y prendre, mais il va falloir gentiment dire à Mozilla, Opera et Microsoft d’arrêter leurs âneries.

Chrome sous Android ne supporte pas Flash

Hier, une toute première beta de Chrome sous Android est sortie. L’application est disponible uniquement sur Ice Cream Sandwich (qui 3 mois après sa sortie représente 1% des appareils sous Android).

Signe des temps, Adobe et Google ont confirmé que Chrome sous Android ne supportera jamais Flash Player. A terme, Chrome va remplacer le navigateur par défaut sous Android. Si vous pensiez encore pouvoir faire des sites en Flash pour mobiles, repensez-y.