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