HTeuMeuLeu

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.

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

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.

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.

 

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 » :

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.

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.

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 ».

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.

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.

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.

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.

R Blank, entrepreneur, formateur ActionScript et fondateur de la communauté Flash à Los Angeles, a écrit un article qui m’a fait sortir de mes gonds : « La mode majeure du développement interactif » (ou « Le coût grandissant du développement interactif » dans sa première publication).

D’un point de vue d’entreprise, la clé à retenir de cette période est que, dollar pour dollar, les expériences fourniront moins de fonctionnalités, pour un plus petit pourcentage de visiteurs. Dit autrement, produire la même fonctionnalité, livrée au même pourcentage du marché, coûtera plus cher.

Cette conclusion n’est pas un commentaire sur les valeurs particulières ni de HTML ou de Flash. C’est plutôt le reflet d’un fait sous-jacent : Adobe absorbe une portion non-insignifiante des coûts de production pour nous autres qui utilisons Flash pour livrer des expériences riches dans un navigateur. Adobe s’assure que Flash tourne de la même manière, dans n’importe quel navigateur, sur n’importe quelle plate-forme, et que vous n’avez pas à vous en préoccuper. Ainsi, Flash représente une subvention significative de la part d’Adobe au reste d’Internet.

Il n’y a aucune société investissant de manière similaire et aussi consistante pour HTML5.  Au lieu de ça, HTML5 fonctionne juste comme les précédentes versions de HTML. C’est un standard international, et les différents fabricants de navigateurs l’implémente différemment. Chaque navigateur que  vous souhaitez supporter accroît les coûts et le temps de production, d’abord en augmentant le temps passé en tests d’assurance qualité, puis au temps de développement passé à résoudre des problèmes spécifiques à des navigateurs qui sont inévitablement découverts.

Son point de vue est évidemment biaisé, et il y tellement de choses fausses ou erronées dans cet extrait que je ne sais pas par où commencer. Mais je partage son interrogation : un développement interactif va-t-il coûter plus cher en HTML5 qu’en Flash ?

Il n’y a aucun débat sur le fait qu’aujourd’hui, faire du développement interactif en HTML5 coûte sensiblement plus cher que du développement en Flash. Dit autrement : développer sur une plate-forme jeune de quelques années coûte plus cher que développer sur une plate-forme lancée en 1996. Ce n’est surement pas pour rien que la plupart des démos interactives qui me viennent à l’esprit (20 Things I Learned, RO.ME, Cut The Rope) sont sponsorisées par les navigateurs eux-mêmes.

Mais je suis convaincu que sur le long terme, le coût du développement interactif tendra vers zéro. Le seul coût imputé au client sera à la hauteur de ses demandes spécifiques. Je suis convaincu que de la même manière que ces 10 dernières années ont vu émerger des tonnes de CMS de grande qualité permettant de créer des sites gratuitement, ces 10 prochaines années vont voir fleurir le même genre de solutions pour l’interactivité côté client. J’en reviens exactement à ce que j’expliquais en novembre dernier, dans mon article « Flash vs. HTML5« .

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 Flash est exclusive; elle pousse à la créativité aux dépends de la technique, à la fermeture et à la lucrativité.

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

Mais évidemment, il s’agit ici de mon point de vue biaisé d’intégrateur. Alors voici maintenant quelques considérations factuelles pour l’avenir.

• 2007 : Apple ne supporte pas Flash sur iOS.
• 2010 : Apple n’installe plus Flash par défaut sur aucun de ses ordinateurs.
• 2011 : Adobe arrête le support de Flash sur mobiles et sur télévision.
• 2011 : Les applications HTML5 de Spotify ne supportent pas Flash.
• 2012 : Internet Explorer 10 ne supportera pas Flash dans sa version Metro.

Plus le temps passe, et moins de plate-formes supporteront Flash. En 2011, la vente d’ordinateurs a continué de chuter, au profit quasiment unique de l’iPad.

Kaelig a publié cette semaine une très bonne conclusion pour « sortir du débat Standards vs. pragmatisme » :

Ne cédez pas au buzz du moment, ne sautez pas sur les nouveautés pour l’amour du risque. Ce n’est pas seulement une affaire de professionnels du web, vous pourriez carrément mettre votre client dans le pétrin si vous manquez de vigilance sur la pérénité des choix techniques que vous effectuez.

En choisissant Flash aujourd’hui, vous assurez à vos clients que votre travail ne fonctionnera plus sur une majorité de plate-formes utilisées dans les 2 ans à venir. Qu’on le veuille ou non, Flash Player va disparaître. Ce n’est plus qu’une question de temps. Vous n’avez pas le choix. A mon avis, la vraie question à se poser pour un professionnel n’est pas « combien ça coûte ? », mais « quand dois-je m’y mettre pour rester compétitif ? ».

J’ai récemment lu Bossypants, l’autobiographie de l’excellente Tina Fey, auteur et comédienne découverte dans le Saturday Night Live, désormais à la tête de la série 30 Rock. A travers le livre, elle raconte son expérience et ce qu’elle a appris en travaillant à la télévision. Elle détaille notamment ce qu’elle retient de son producteur, Lorne Michaels. En voici le premier point qui m’a rappelé pas mal de choses.

Produire, c’est décourager la créativité

Une émission de TV comprends de nombreux départements : costumes, accessoires, talent, graphiques, décors, transports. Chaque personne dans chaque département veut montrer ses compétences et contribuer de manière créative à l’émission, ce qui est une bénédiction. C’est gratifiant de travailler avec des gens qui sont talentueux et enthousiastes pour leur travail. Vous pourriez penser qu’en tant que producteur, votre travail consiste à pousser la créativité, mais la plupart du temps votre travail consiste à contrôler l’enthousiasme. Il peut arriver que le script demande un muffin aux céréales sur une assiette blanche et le Département Accessoires débarque avec un cake aux céréales en forme de père noël servi sur un plateau en argent où il est écrit « Bienvenue au Danemark. » « On pensait que ce serait drôle. » Et vous devez trouver une façon polie d’expliquer que le personnage est juif, donc le fait qu’il mange la tête du père noël peut avoir des connotations négatives, et le plateau en argent, bien que magnifique, donne un reflet bizarre à la caméra et partons plutôt sur un muffin aux céréales sur une assiette blanche.

D’après les statistiques de NetMarketShare relevant le pourcentage de liens référants des plus gros sites, Google+ vient d’atteindre le mois dernier 0,00000%.

Voilà, mon travail ici est terminé.

Cette semaine, Bertrand Keller a traduit un article de Kevin Dees publié chez ThinkVitamin sobrement intitulé « La séparation de la structure, de la présentation et du comportement est morte« .

Prenons l’exemple d’un lien avec un effet visuel lors du survol de la souris. Vous avez le choix entre passer par la CSS pour un effet :hover et/ou utiliser une petite pincée de JavaScript pour la gestion d’un comportement plus complexe.

Avec un changement de couleur géré en CSS et un effet (une opacité par exemple) en JavaScript, le comportement du lien est spécifié dans deux couches différentes : c’est ce qu’on appelle la « divergence ». Ce lieu de gestion subtile de l’effet de survol par deux couches différentes.

L’intégration n’est pas la collage grossier de différentes couches mais plutôt l’emboîtement subtile de plusieurs technologies (ce qui définit, à mon avis, le principe de l’artisanat).

Je suis totalement d’accord sur les subtilités de l’intégration et de ces différents langages. Cependant, je pense sincèrement que la séparation de la structure, de la présentation et du comportement sur le web est tout sauf morte. Au contraire, je dirais qu’avec HTML5 et CSS3, elle vient juste de naître.

Prenez par exemple un tutoriel pour faire un joli menu publié chez WebDesignerWall en 2007. Le code HTML est pour l’époque particulièrement propre, mais il mélange cependant la structure et la présentation.
<ul id="menu">
<li><a href="#" class="home">Home <span></span></a></li>
<li><a href="#" class="about">About <span></span></a></li>
<li><a href="#" class="rss">RSS <span></span></a></li>
</ul>

Vous voyez ces <span> vides ? Dégoûtants, hein ? Mais avant CSS3, on était obligé d’ajouter du contenu supplémentaire (souvent vide de contenu et vide de sens) pour parvenir à reproduire une charte graphique avec un code un minimum propre. Si vous vouliez réutiliser du code de présentation, vous étiez obligé d’en reproduire la structure.

Maintenant, faisons un saut juste 2 ans plus tard, avec ce tutoriel pour faire des boutons super géniaux en CSS3 publié chez Zurb en 2009. Ce tutoriel ne contient plus que du code CSS. Plus besoin d’une structure imposée. Reprenez les styles de boutons créés, et appliquez les sur n’importe quel contenu, n’importe quelle balise, n’importe quelle structure.

Les nouveaux langages du web nous donnent donc plus de pouvoir pour plus facilement distinguer HTML, CSS et Javascript. Mais comme le disait Spider-Man (ou Voltaire, au choix) : « De grands pouvoirs impliquent de grandes responsabilités ».

On peut utiliser CSS et la pseudo classe :hover pour gérer l’affichage d’un sous-menu. Mais est-ce vraiment la bonne méthode ? Ne s’agit-il pas plutôt là d’un comportement ? Comme je le disais il y a 2 semaines : « Juste parce que vous pouvez le faire ne signifie par que vous devez le faire« . C’est notre responsabilité d’auteur du web de faire bon usage des nouvelles fonctionnalités du web. A moins que ce ne soit Halloween, la séparation de la structure, présentation et du comportement devrait être de plus en plus nette.

Hier, j’ai appris via Nofrag que Michel Hazanavicius, le réalisateur de The Artist était aussi le réalisateur de La Classe Américaine, un de mes films préférés. J’ai aussi appris qu’il est un fervent défenseur de la HADOPI. Monde de merde.

En parlant d’Apple, le week-end dernier, le New York Times a publié un excellent article sur Apple, et comment les Etats-Unis sont passé à côté de la production de l’iPhone.

Les cadres d’Apple disent qu’à ce stade, aller outre-pacifique est leur seule option. Un ancien cadre décrit comment la société comptait sur une usine chinoise pour réorganiser la fabrication de l’iPhone seulement quelques semaines avant que l’appareil ne sorte. Apple avait reconçu l’écran de l’iPhone à la dernière minute, obligeant un remaniement de la chaîne de production. Les nouveaux écrans ont commencé à arriver à l’usine aux alentours de minuit.

Un chef d’équipe a immédiatement réveillé 8000 ouvriers à l’intérieur des dortoirs de la société, d’après le cadre. Chaque employé s’est vu offrir un biscuit et une tasse de thé, puis a été guidé vers une station de travail, et en moins d’une demi heure commença une garde de douze heures passée à installer des écrans en verre dans des cadres biseautés. En 96 heures, l’usine produisait plus de 10 000 iPhones par jour.

« La vitesse et la flexibilité sont à couper le souffle », déclara le cadre. « Aucune usine Américaine ne peut rivaliser avec ça. »

La semaine dernière, je découvrais également avec stupéfaction à quel point Apple prenait sérieusement son rôle dans son partenariat avec des usines chinoises :

Nous exigeons de nos fournisseurs qu’ils renvoient les travailleurs mineurs à l’école et qu’ils paient pour leurs dépenses scolaires, leurs allocations de vie, et les salaires perdus pendant 6 mois ou jusqu’à ce que le travailleur atteigne l’âge de 16 ans, en prenant la période la plus longue. Nous nous assurons également que les étudiants ont le soutien dont ils ont besoin pour réussir à l’école. Nous aidons les étudiants à contacter leurs familles, à identifier leurs possibilités d’études, et à s’inscrire à l’école – et nous suivons leurs progrès. Si des travailleurs mineurs ont déjà quitté l’usine, nous essayons de les localiser et de leur offrir le même soutien dans leur éducation.

« Apple c’est le mal ».

Via le communiqué de presse officiel d’Apple :

Apple® a annoncé ses résultats financiers pour le son premier trimestre fiscal 2012 qui s’est étendu pendant 14 semaines et s’est terminé le 31 décembre 2011. La société a publié un record trimestriel de revenus de 46,33 milliards de dollars et un record de bénéfice trimestriel de 13,06 milliards de dollars.

Et maintenant, quelques chiffres complémentaires :

1. C’est la première fois qu’Apple dépasse 30 milliards de dollars de chiffres d’affaires en un trimestre (et ils ont dépassé ça de 16 milliards) (source)
2. Les bénéfices d’Apple (13 milliards de dollars) dépassent le chiffre d’affaire total de Google (10,6 milliards de dollars) (source)
3. En 2009, Apple a vendu plus d’iPhone qu’en 2007 et 2008 confondus. En 2011, Apple a vendu plus d’iPhones qu’en 2007, 2008 et 2009 confondus. L’année dernière, Apple a vendu 93,1 million d’iPhones, soit un peu plus qu’en 2007, 2008, 2009 et 2010 confondus. (source)
4. Apple a vendu 62 millions d’appareils sous iOS ce trimestre. C’est plus que tous les modèles de tous les appareils sous Android confondus. (source)
5. Ce trimestre est le 2ème record historique de bénéfices enregistrés pour une société américaine, juste derrière ExxonMobil en 2008 et ses 14,8 milliards de dollars de bénéfices. (source)

Waow.

Le mois dernier, en regardant une vidéo de Ryan Singer de 37Signals en train de faire des maquettes en HTML et sous Photoshop, j’ai découvert un raccourci Photoshop qui a changé ma vie. Ça nous est tous déjà arrivé au moins une fois de devoir agrandir un onglet, ou une forme avec un dégradé et des bordures particulières. Si vous étirez simplement votre sélection sous Photoshop, les coins seront alors déformés. Voici comment utiliser simplement la fonction « Décalage » (ou Nudge en anglais) de Photoshop sur une sélection, et ainsi facilement ou agrandir un onglet.

Le raccourci est simple : alt + maj + droite (ou gauche) sur une sélection, sous Windows ou Mac, dans Photoshop. Photoshop va alors dupliquer une bande de 10px de large (et de la hauteur de votre sélection). Si besoin, vous pouvez également faire le même raccourci sans la touche maj pour dupliquer uniquement une bande de 1px de large.

Je me suis senti très bête de ne pas avoir connu ce raccourci auparavant.

En avril 2011, Google lançait en grande pompe Mon Entreprise En Ligne, une « énième initiative pour inciter les PME à ouvrir un site Web« . Le site a été créé en partenariat avec SFR (pour le support téléphonique), et Oxatis (pour la plate-forme de création de sites). A l’époque, je croyais alors qu’il s’agissait d’un projet bien français, visant à pousser les 70% de PME n’ayant pas de site Internet. Mais récemment, alors que Google s’est fait prendre en pleine escroquerie au Kenya, je me suis rendu compte qu’il s’agissait d’une initiative mondiale, plus connue sous le nom de « Getting Business Online ». Australie, Irelande, Angleterre, Inde, Canada, Kenya, mais aussi chaque état Américain (New York, Ohio, Vermont, …). A chaque fois, Google s’est associé avec des entreprises locales pour monter son projet. L’objectif pour Google est de proposer un site gratuit la première année, tout en incitant fortement les entreprises à créer des annonces sur AdWords.

L’initiative est louable, mais bizarrement, la version française est assez différente des autres. En particulier, la qualité des sites français semble particulièrement médiocre. Voici par exemple 3 sites mis en avant dans la rubrique Best-of de Mon Entreprise En Ligne : www.tif-annie.fr, www.photoptic.fr et www.canichebleu.fr (mon préféré). Prenez quelques instants pour visiter ces sites, et revenez lire la suite.

Là, normalement, si vous travaillez dans le web, vous avez un peu de vomi qui vient de vous remonter du fond de la gorge. Que dire ? Ces designs, tous similaires. Ce code HTML, parsemé de quelques tableaux de mise en page et de styles en ligne TOUT EN MAJUSCULE. A titre de comparaison, voici quelques exemples de sites réalisés et mis en avant par Google comme des bons exemples dans les autres pays : www.themagherainn.com, www.geronimocoffee.com.au et www.thepurpledoor.eu. Ces sites ont leurs lots de défauts, mais on est clairement un niveau au dessus des sites réalisés en France. La différence ? Dans la plupart des pays, Google a soit proposé directement son outil de création de sites, Google Sites, ou incité à travailler avec des agences web locales. En France, Google a travaillé avec Oxatis et son CMS maison.

Autre spécificité française, le projet a été lancé avec le soutien du Ministère de l’Economie, et surtout par Echangeur PME Paris Île-de-France, une initiative publique liée à la Chambre du Commerce et de l’Industrie de Paris. Avec autant de partenaires, la force de frappe de Google et le soutien de l’Etat, on peut au moins espérer que de nombreuses sociétés ont profité de ce service. L’objectif affiché était de 50 000 nouveaux sites d’entreprise pour la fin 2011. Curieusement, aucun chiffre officiel n’a été communiqué pour faire le point sur cette initiative. Mais j’avais bien ma petite idée pour connaître le nombre de site créé grâce à Mon Entreprise En Ligne. En effet, chaque site contient une petite phrase « Oxatis – création sites E-Commerce » accompagnée du logo MEEL dans son footer. Avec un petit coup de pouce pour plus de précisions (merci Aurélien !), voici la requête effectuée sur Google pour connaître tous les sites ayant cette mention.

"Oxatis - création sites E-Commerce" inurl:Default.asp -site:oxatis.com

Réponse : « Environ 3 270 résultats ». Et encore, cette requête n’est pas précise à 100% puisqu’elle inclut également les sites réalisés par Oxatis depuis une dizaine d’années en dehors de l’initiative MEEL. En filtrant sur Google les résultats datant de moins d’un an, on arrive alors à « Environ 475 résultats« . Et encore, on n’exclut toujours pas les sites réalisés par Oxatis seul.

Google, SFR, Oxatis, et l’Etat n’ont même pas atteint 1% de leur objectif. Je n’ai aucune idée des montants publics mis en jeu dans ce projet, mais j’ai bien peur vu le résultat que ce ne soit beaucoup trop…

Avik Chaudhuri, expert en design de langage de programmation chez Adobe, écrit un article trollesque sur son blog intitulé « Le Mythe du V8 : Pourquoi JavaScript n’est pas un concurrent digne de ce nom » :

Les programmes en JavaScript sont non typés, (relativement) petits et sont publiés/chargés comme du code source, puis compilés et exécutés à la volée. En comparaison, les programmes en ActionScript sont typés, (relativement) gros et sont compilés en code binaire, publiés/chargés en code binaire, puis exécutés à la volée.

Il y a quelque chose d’intrinsèquement mauvais dans un débat qui se base sur le fait que JavaScript peut faire tout ce lourd travail après chargement, et aussi bien, si ce n’est mieux, qu’un langage qui a l’opportunité de faire tout ce lourd travail avant le pré-chargement. Ce qui ne va pas dans un tel argument est qu’il repose sur, qu’il dépends de la magie. Malheureusement, tôt ou tard, on apprends tous que le père Noël n’existe pas : la question est, peut-on faire ça plus tôt ?

Basé sur le même argument, alors PHP ne serait pas un langage digne de ce nom en comparaison avec du .NET. Dans son argument, Avik oublie également de mentionner qu’il compare JavaScript, un langage ouvert inclus par défaut dans un navigateur, à ActionScript, un langage propriétaire nécessitant un plugin pour fonctionner. La conclusion de son article m’a fait beaucoup rire.

Alors, arrêtons de nous en faire avec JavaScript, et visons plus haut. Alors qu’on se concentre sur le jeu, les programmes en ActionScript nécessiteront de meilleures optimisations pour la performance. ActionScript a le bon mélange d’ADN pour réussir, et il deviendra le langage du 21ème siècle qu’il aurait toujours pu être.

Et le tout, mesdames et messieurs, via un plugin (Flash Player) qui prends pourtant 100% des ressources de mon processeur dès le moindre affichage de bannière publicitaire. Ça, c’est de la magie.

« Chaque nouvelle technologie voit arriver son lot de bonnes et mauvaises utilisations, et c’est particulièrement vrai sur le web. » J’écrivais ça il y a 8 mois à propos des media queries. Ces derniers temps, j’ai l’impression que les mauvaises pratiques des nouvelles technologies du web se sont multipliées de manière phénoménale. La plupart du temps, il s’agit de démontrer les nouvelles possibilités de CSS3. Voici quelques exemples apparus ces derniers mois :

• CSS Panic, un mini-jeu fait tout en CSS3
• Un iPhone 4 entièrement en CSS3
• Des animaux trop mignons en CSS3
• Une calculatrice de chmod toute en CSS3
• Une calculatrice toute en CSS3

Si ces démos sont toutes effectivement très impressionantes, elles sont toutes aussi particulièrement stupides et dangereuses. Comme le disait le docteur Ian Malcolm* :

Vos savants étaient si pressés par ce qu’ils pourraient faire ou non qu’ils ne se sont pas demandé s’ils devaient le faire.

Dans la vraie vie, sur un vrai projet web, aucune personne saine d’esprit n’irait s’amuser à coder entièrement une calculatrice ou un mini-jeu en CSS3. Parce que dans la vraie vie, on doit aussi tenir compte de pleins de contraintes implicites à n’importe quel projet (le temps qu’on peut passer dessus, la facilité qu’on aura à le maintenir dans le futur). Du coup, on n’a aucune raison pour ne pas utiliser des technologies prévues pour ça à la base. Vous voulez dessinez des animaux trop mignons avec du code ? Utilisez SVG. Vous voulez créer un mini-jeu ? Utilisez JavaScript.

Il y a quelques mois, Ubelly écrivait le compte-rendu d’une de leurs conférences intitulée « Améliorations excessives : est-ce que nous prenons bien soin du web ? » :

Les développeurs web sont séduits par les techniques modernes du web au point où ils en oublient parfois les leçons fondamentales qui ont été apprises ces 20 dernières années. Il est de la responsabilité de chaque développeur web, en tant que professionnel, d’utiliser les techniques avant-gardistes de manière responsable et prendre un peu de temps en plus pour s’assurer que nos applications respectent le web.

J’encourage les développeurs web et intégrateurs à découvrir les nouvelles technologies et à faire leur petit bac à sable pour s’amuser. Mais avant de publier le résultat de vos découvertes, réfléchissez bien à leur pertinence.

Juste parce que vous pouvez le faire ne signifie pas que vous devez le faire.

* Les puristes auront reconnu une légère adaptation de ma part de la traduction française du film. La citation d’origine, en anglais, dit : « Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should. » La traduction originale française était un peu plus orientée : « Vos savants étaient si pressés par ce qu’ils pourraient faire ou non qu’ils ne se sont pas demandé s’ils en avaient le droit.«