InterfacesRiches.fr

Après trois mois de spéculations irraisonnées et d’escarmouches par articles interposés, il semblerait que la gue-guerre entre supporters d’HTML5 et supporters de Flash soit enfin calmée (cf. Pourquoi HTML5 et Flash ne peuvent être comparés). Maintenant que les arguments des uns et des autres ont été entendus, ceux qui sont réellement légitimes sur le sujet (les producteurs de contenus, pas les analystes du dimanche) commencent à s’exprimer et à faire entendre un son de cloche très différent des ayatollahs des standards web :

• HTML5 Vs. Flash. What You Haven’t Heard, où l’auteur nous explique qu’HTML5 n’est pas un choix suffisamment mature pour les jeux en ligne. Flash propose ainsi une solution plus intéressante notamment pour le preloading, pour la simplicité d’animation de sprites et de fonds, pour le P2P, pour l’encaspulation de jeux en un fichier unique,  pour les performances… Bref, les producteurs de jeux en ligne restent fidèle à Flash même si nous voyons des choses très intéressantes pour HTML5 (cf. Les jeux en HTML5 deviendront-ils une réalité ?).
• HTML5 And Flash: Why It’s Not A War, And Why Flash Won’t Die, où le fameux Smashing Magazine nous explique que Flash va progressivement reprendre la place qu’il aurait toujours dû occuper (animations multimédia, jeux…) mais qu’il ne va en aucun cas être remplacé par HTML5.
• Why Porn and the iPad Are Key for HTML5, où l’on nous explique que les éditeurs de contenus pornographiques en ligne migrent vers des lecteurs vidéo en HTML5 pour draguer les utilisateurs d’iPad et espérer vendre plus de services premium. Tout en sachant que ces fameux services premium exploiteront de toute façon un lecteur vidéo en Flash pour mieux protéger les contenus et bénéficier de DRM solides. Cet avis est également partagé et détaillé ici : Why HTML5 Video Won’t Replace Flash.
  

  Le gros problème d'HTML5 avec les contenus vidéo

• Pardon Our Dust, où les équipes de Hulu expliquent les avantages de Flash comme lecteur vidéo (adaptive streaming, égalisation du volume de publicités, flexibilité du sous-titrage, seek preview, video analytics…).
• Flash and the HTML5 <video> tag, où les équipes de YouTube listent les avantages de Flash (utilisation de nombreux codec dont le WebM, protection des contenus sous licence, exportation très simple du lecteur, vidéo en plein écran, accès très simple à la webcam et au micro…).

Et pour enfoncer le clou, les équipes de YouTube viennent même de publier un jeu qui mélange très habilement le contenu de plusieurs vidéos ainsi que des briques externes (formulaire, cartes…) : Google Chrome FastBall – A Race Across The Internet.

Un jeu sur Youtube qui mélange plusieurs types de contenu

Bon OK, même si ce jeu est surtout là pour vanter les mérites de Chrome, ça fait quand même du bien d’avoir des avis d’acteurs légitimes pour définitivement clore ce débat qui a trop duré.

Le moins que l’on puisse dire est que les équipes de Microsoft ne sont pas très loquaces sur les statistiques d’installation de Silverlight. Pourtant il semblerait que le plug-in de Microsoft progresse à un rythme constant (à raison de 2% supplémentaires tous les mois) et que la barre symbolique des 50% de taux d’installation ai été dépassée en Mars 2010. C’est en tout cas les chiffres que donne le site RIAStats :

Taux d'installation des différentes technologies RIA

Ces statistiques ne sont pas à prendre à la légère car elles sont fondées sur les données remontées par plus de 26 millions de navigateur dans 102 pays : Presque 55% pour Silverlight (versions 2 et 3) et plus de 98% pour Flash (versions 8 à 10). Un taux d’installation pas tout à fait confirmé par le site StatOwl (qui annone un peu plus de 43%) mais avec un rythme de progression plus important.

Impossible de vérifier ces chiffres auprès de Microsoft qui ne semble pas vouloir communiquer là-dessus (peut-être attendent-ils une confirmation formelle du dépassement de la barre des 50% ?), contrairement à Adobe qui exhibe fièrement ses chiffres : Flash Player penetration et Flash Player Version Penetration.

Alors bien sûr la grande question est : À partir de quand une technologie est-elle suffisamment bien déployée pour être viable ? Je ne pense pas qu’il faille axer la réflexion sur les chiffres mais plutôt sur l’engagement de l’éditeur : Microsoft est une maison solide qui a la ferme intention de s’installer durablement sur le marché des RIA / RDA avec Silverlight et ils mettront les moyens pour y parvenir. Il est vrai que les 99% de pénétration de Flash en font rêver plus d’un (ce taux est par exemple supérieur à celui de Javascript, et oui !), mais les possibilités de Silverlight en matière de Vidéo et son portage sur la gamme Windows Phone en font une technologie incontournable.

Je dirais même plus : Heureusement que Microsoft est là pour stimuler le marché car il ne faut pas compter sur Sun et son JavaFX (étonnamment silencieux) ni sur Curl (en silence radio depuis l’année dernière). Peut-être va-t-il également falloir observer de près ce que la communauté va faire avec HTML5 et SVG. Je ne suis pas persuadé que ce couple soit une solution réellement crédible pour le moment, mais il ne faut pas non plus sous-estimer la capacité d’une communauté à promouvoir des alternatives libres / standardisées.

Alors que la barre des 500.000 unités vendues vient d’être franchie par l’iPad, je m’interroge sur l’impact que cette machine pourrait bien avoir sur le marché, ou plutôt sur les éditeurs de sites web.

Tout à commencé avec l’iPhone : Belle machine, système d’exploitation robuste et certainement la meilleure expérience de surf sur le web en situation de mobilité (du moins à la date de sa sortie). Résumons une longue argumentation en disant que pour un usage d’appoint, l’iPhone et son Safari remplit largement sa promesse. Bien évidemment vous ne passeriez pas des heures à surfer sur le web avec votre iPhone car ce smartphone n’a pas été conçu pour ça. D’autant plus qu’il existe une myriade d’applications proposant une expérience plus riche et plus immersive. OK, jusque là tout va bien.

Prenons maintenant le cas de l’iPad : Belle machine, même système d’exploitation, même navigateur. Surfer sur le net avec un iPad veut donc dire être soumis aux mêmes limitations (pas de Flash, pas de survol avec la souris). Là c’est tout de suite un peu plus gênant dans la mesure où l’iPad est vendu comme  l’avenir de l’informatique domestique, le remplaçant de votre ordinateur (avec son clavier et sa souris).

Passée la première prise en main (où l’impression générale est très bonne), l’iPad se révèle au final un peu décevant pour surfer le web, pour les limitations que nous lui connaissons. Réponse d’Apple : “C’est la faute des éditeurs de sites qui ne sont même pas foutus de sortir des version iPad-ready“.

Exemple de site optimisé pour l'iPad

Nous avons mis une dizaine d’année à nous débarrasser de la logique du “Site optimisé pour XYZ“ et Apple voudrait nous faire replonger dedans ? Oui et non. Oui parce qu’une compatibilité HTML5 suffit pour être “iPad-ready” (ils se cachent donc derrière l’argument des standards web). Non car les éditeurs ont aussi la possibilité de sortir une application (en fait un widget).

La tentation est grande de se lancer dans la confection d’une application pour plusieurs raisons :

• L’expérience utilisateur est parfaitement maîtrisée ;
• L’attention de l’utilisateur est concentrée ;
• Elle est disponible en mode déconnecté.

Par contre il y a des contreparties à ne pas négliger :

• Vous devez soit apprendre le bon langage (Objective C), soit sous-traiter la réalisation à un spécialiste ;
• Vous devez faire approuver votre application pour qu’elle intègre l’App Store d’iTunes ;
• Vous devez vous plier au mécanisme de mises à jour imposé par Apple ;
• Vous devez vous assurer que l’application est compatible avec le format iPad ;
• Vous devez développer autant de version de l’application que vous ciblez de smartphones.

Autant vous dire qu’il faut y réfléchir à deux fois avant de lancer votre application iPhone / iPad car il y a des coûts cachés. C’est effectivement une très bonne chose que d’être présent sur l’un des panneaux de l’écran d’accueil de l’iPhone / iPad (qui fonctionne comme des bookmarks), mais le ROI est loin d’être probant.

Autant le développement de widgets et autres micro-applications a été grandement simplifié / viabilisé par des technologies comme AIR, autant pour les applications mobiles tout reste à faire. D’autant plus que le marché des smartphones évolue vite (iPhone OS still dominates mobile web; Android on the way up) et que celui des touchbooks devraient aussi être amené à bouger avec l’arrivée de machines propulsées par Android.

Je suis intimement persuadé que ce phénomène de widgetisation du web (”développez une application pour mes machines et tout se passera bien“) est néfaste car elle disperse les ressources et donc les budgets des annonceurs. Je suis beaucoup plus partisan d’une approche raisonnée qui consiste à développer une version smartphone d’un site web plutôt que de se lancer dans le développement de x versions d’une application mobile (pour iPhone, Android, Symbian, BlackBerry…).

Cette solution permet de bien mieux maîtriser les coûts de développement, de s’affranchir des contraintes de déploiement / mises à jour, de cibler un panel bien plus large de smartphones, de capitaliser de l’expérience sur une technologie pérenne (HTML 5). Illustration avec la version mobile de Twitter :

La version mobile de Twitter

Même si les possibilités par rapport à une application sont restreintes, le ROI est imbattable. Peut-être que la combinaison gagnante est de proposer une version mobile de votre site web ou service en ligne et de proposer une application payante avec des services à valeur ajoutée (la grande question étant : “Qu’est-ce qu’un service à valeur ajoutée“).

Donc au final, je trouve cette idée de sites web “iPad-ready” complètement rétrograde. Mais transposée en “Smartphone-ready” ou en “Touchbook-ready“, là ça devient beaucoup plus intéressant (surtout avec une redirection automatique vers la bonne version).

Bon en fait la combinaison réellement gagnante serait d’avoir un site web avec des versions smartphone / touchbook et une application mobile payante mais reposant sur un code-source unique. C’est en quelque sorte ce que promet Adobe avec son Open Screen Project et la possibilité dans CS5 de compiler une application Flash en une application iPhone. Le nirvana des Rich Mobile Applications, nous y sommes presque !

À moins que tout ceci ne soit remis en cause avec le lancement ce soir de la V.4 de l’iPhone OS…

Mise à jour (9 avril 2010) : Voilà c’est fait, Apple vient d’inclure une close dans sa licence pour interdire l’utilisation du compilateur Flash de CS5. D’un côté je me dis qu’il faut des mesures extrêmes comme celle-là pour garantir une expérience utilisateur cohérente sur l’iPhone, d’un autre je pense que celà complique la tâche des annonceurs et des éditeurs d’applications. Les produits d’Apple et d’Adobe font partie de mon quotidien professionnel depuis des années et je m’attriste de voir ce conflit s’envenimé…

Ces dernières semaine j’ai vu passer un certain nombre d’articles qui annonçait la mort prochaine de Flash avec l’avènement de HTML 5. Je dois bien avouer ne pas du tout comprendre cette “polémique” dans la mesure où ce sont deux technologies qui ne peuvent pas réellement être comparées. A la limite nous pourrions peut-être comparer les usages que l’on peut en faire (au travers des applications) mais là encore c’est très limité.

Avant toute chose remettons tout de suite les choses à leur place : Flash est aujourd’hui déployé sur près de 99% des ordinateurs, alors que HTML5 n’est supporté que par les navigateurs de dernière génération qui représentent à peine 10% du marché (et encore…). Vous pourriez me dire que les parts de marché de ces fameux navigateurs progressent vite, mais il faudra sûrement une décennie avant que HTML5 devienne un standard de facto (pénétration supérieure à 90%). Il est donc important de préciser que de toute façon ce débat n’a pas lieu d’être pour une simple raison arithmétique.

Mais revenons aux usages : Flash est à la base prévu pour faire tourner des animations vectorielles mais au fil du temps nous lui avons trouvé toutes sortes d’usages comme les jeux, les applications, la 3D ou encore les players multimédia (musique et vidéo). Nous avons récemment vu l’émergence du SublimeVideo Player, un lecteur vidéo en HTML 5 qui semble très bien fonctionner, mais est-ce une raison pour annoncer dès maintenant le remplacement des Flash player ? Non pas réellement, d’une part pour des raisons de performance (cf. Does HTML5 Really Beat Flash? The Surprising Results of New Tests) et d’autre part car les players de dernières générations ne font pas que jouer de la vidéo, ils peuvent aussi rajouter des sous-titres, de la publicité contextualisée et même adapter la résolution au débit. Et c’est bien sur ce dernier point que les placers vidéo en HTML5 ont de gros progrès à faire, surtout comparés à des technologies comme Flash ou Silverlight qui sont capables de faire de l’adaptive streaming mais aussi du smooth streaming (cf. Sorry, HTML5 Crowd, Flash Ain’t Dead Yet).

De même, HTML5 va apporter beaucoup de choses pour les applications en ligne avec le stockage local des données… mais est-il bien réaliste d’envisager des applications de retouche photo / audio / vidéo (comme la suite Aviary) en HTML5 ? Signalons aussi que Flash n’est que le dernier maillon d’une longue chaine : Flex propose en effet un environnement de développement tout à fait mûr pour développer et maintenir des applications métier.

Il y a aussi le cas particulier des applications mobiles (cf. The Future of Web Content – HTML5, Flash & Mobile Apps) où HTML5 peut apporter des choses intéressantes… tout en présentant de grosses limitations par rapport aux applications natives. Mais là encore, une solution de Rich Mobile Application comme AIR va mettre tout le monde d’accord.

Autre élément important à prendre en compte, derrière Flash il y a aussi tout un écosystème d’agences, de SSII, de développeurs indépendants, d’organismes de formation et de clients qui ne sont pas prêt à abandonner Flash pour relever l’exploit technique de l’HTML 5. Même s’il s’agit d’une technologie propriétaire, la Flash Platform a su faire ses preuves. En définitif je pense qu’il n’est pas faux de dire que ce débat n’existe que par la volonté de 2 ou 3 blogueurs / journalistes en mal de sujet fort et de visites facilement gagnées avec des titres accrocheurs.

Néanmoins je pense que pour aborder cette question et faire un choix en toute objectivité il y a deux critères essentiels :

• Le ROI (quelle solution est la plus viable en terme de coûts de développement / intégration / maintenance ?) ;
• L’expérience utilisateur que vous aller proposer à vos visiteurs (qui se moquent éperdument de la technologie employée).

Le pire dans ce débat à la noix c’est que vous n’êtes et ne serez jamais obligé de choisir entre ces deux technologies : Rien nous vous empêche d’utiliser les deux pour optimiser le ROI et l’expérience. Sur ce point là je rejoins tout à fiat l’avis de Dan Mall (Flash and Standards: The Cold War of the Web).

Fin du débat.

Voilà maintenant 2 semaines que l’iPad a été annoncé… et deux semaines que le marché se demande quand Apple va se décider à implémenter Flash. Autant le dire tout de suite : Je ne pense pas que Flash soit un jour disponible sur l’iPad (ni sur l’iPhone) et je n’y tiens pas car cela ruinerait toute l’expérience utilisateur.

Le succès de l’iPhone (et celui de l’iPad) repose sur une parfaite maitrise de l’interface

Quand vous y réfléchissez bien, quels facteurs ont participé au succès de l’iPhone : Des interfaces et modalités d’interactions homogènes et un usage quotidien reposant sur les applications. Pour être exacte, il s’agit plus de mini-applications qui sont utilisées de façon intermittente et ponctuelle.

En lançant un iPad propulsé par le même système d’exploitation que l’iPhone, Apple souhaite ainsi capitaliser sur cet héritage et même enrichir l’expérience avec des contenus multimédia (des comics comme chez PanelFly ou des magazine digitalisés comme chez Condé Nast).

Le web sans Flash est-il encore le web ?

L’iPad est également vendu comme le terminal de référence pour surfer sur le web depuis votre canapé. OK, mais tout comme l’iPhone, l’iPad ne permet pas d’afficher des contenus Flash. Ors d’après Adobe, Flash est devenu un élément indispensable du web : Open Access to Content and Applications et Apple’s iPad, a broken link?. Je ne peux qu’abonder dans ce sens car une grosse partie des contenus que nous consommons repose tout ou partie sur Flash (les vidéos sur YouTube, les jeux dans Facebook, une très grosse majorité de sites de marque, une part non-négligeable des applications en ligne… Lire à ce sujet l’article suivant : iPad Limits User’s Web Surfing.

Impossible d'afficher des contenus Flash sur l'iPad

À partir de là nous en venons donc à nous demander si le web sans Flash n’est pas un web limité, amoindri. Mais au fond, un web consulté à partir d’un terminal sans souris / clavier est de toute façon un web limité. D’autant plus si vous êtes habitué à surfer sur un écran plus grand que 1024*768 (soit 80% des lecteurs de ce blog) ou avec un navigateur comme Firefox et ses nombreuses extensions (plus de 60% des lecteurs de ce blog).

Bref, je suis convaincu que surfer sur un iPhone ou un iPad ne rend pas le même service que surfer depuis un ordinateur. Il s’agit donc d’un surf d’appoint, qui peut rendre de très précieux services, mais qui ne risque pas réellement de faire de la concurrence aux ordinateurs (et notamment les netbooks). Mais au final ce n’est pas très grave car cette limitation est compensée par la disponibilité de très nombreuses applications et par certains sites adaptés (comme Wikipedia).

À partir du moment où Apple à la capacité de fournir un service équivalent aux travers de ces applications (grande stabilité, basculement très rapide d’une application à l’autre) cela ne dérange pas les utilisateurs d’iPhone, moi le premier. Je dirais même plus que dans certains cas les applications sont plus performantes que les sites web (Facebook, Twitter…).

L’iPhone se passe très bien de Flash

Prenons un peu de recul et essayons de synthétiser l’usage de Flash et la gène que cela peut procurer aux utilisateurs d’iPhone :

• Les vidéos ? Il y a déjà une application YouTube et de toute façon la bande passante en 3G est trop faible.
• Les jeux ? Ceux disponibles en version native sont parfaitement adaptés aux capacités de l’iPhone et tournent plus vite.
• Les applications en ligne ? Soyons sérieux, quelle application est réellement exploitable avec une surface d’affichage si restreinte et l’absence de souris / clavier.

Certes avec l’iPad et son écran beaucoup plus grand la gêne risque d’être plus forte, mais de toute façon les interactions reposant sur l’écran tactile sont beaucoup moins précises et efficientes qu’avec un clavier et une souris. Mieux vaut passer par une version de l’application spécifiquement adaptée aux contraintes / opportunités de la machine. De plus Flash est très gourmand et risquerait de fortement diminuer l’autonomie de l’iPad.

Donc au final l’iPhone se passant très bien de Flash, il n’y a pas de raison apparente pour que cela soit différent sur l’iPad. Ceci venant en plus s’ajouter à des histoires de DRM et de modèle économique qui font que Flash est perçu comme un danger pour l’iPhone (cf. Flash is the Real iPhone Killer).

Flash risque de remettre en cause l’intégrité de l’expérience d’utilisation de l’iPhone / iPad

Mais ce qui est à mon avis un facteur rédhibitoire pour Flash, c’est l’impact qu’il pourrait avoir sur l’expérience utilisateur de l’iPad. Depuis le début de l’iPhone, les interfaces et interactions des applications doivent se conformer à la charte définie par Apple. C’est cette charte qui garantie l’intégrité et la cohérence des interface. Implémenter Flash veut dire s’extraire de la contrainte des applications native donc remettre en cause cette intégrité. Je suis convaincu que le succès de l’iPhone (et probablement celui de l’iPad) repose sur cette maitrise des interfaces.

Nous verrons bien ce que cela donnera sur les smartphones équipés d’Android (le système d’exploitation de Google qui permettra très bientôt de faire tourner des contenus Flash) ou sur les futurs touchbooks tournant sous Chrome OS, mais je pense que l’expérience sera moins bien maitrisée. Cela ouvrira beaucoup plus de possibilités, mais cela va rendre la prise en main plus complexe. Je reste donc fidèle à l’approche plus fermée d’Apple mais à ses interfaces parfaitement maitrisées (cf. Flash Is Never Coming To the iPhone).

Existe-t-il des alternatives ?

Oui bien sur, il existe toujours des alternatives :

• La possibilité de compiler des contenus Flash en application iPhone avec la Creative Suite 5 (dont les performances et la stabilité restent encore à prouver);
• La possibilité de passer par HTML5 et sa fameuse balise <video> ;
• Le probable portage de Silverlight sur iPhone / iPad.

Silverlight sur l’iPhone OS ? Oui je sais ça peut sembler étrange comme idée mais je me devais de lister toutes les hypothèses. Pour le moment l’alternative technologique la plus crédible semble donc être HTML5. Mais n’oublions pas qu’Apple a l’entière maîtrise de la version mobile de Safari, donc ils peuvent tout à fait imposer des limitations de ce côté-là s’ils sentent une menace.

Donc au final il y a très peu de chances pour qu’une alternatives viable à Flash fasse sont apparition sur l’iPhone / iPad. De toutes façon ces machines n’en ont pas réellement besoin de Flash, et ça tombe bien car Apple n’est pas prêt à l’implémenter !

L’idée d’associer les interfaces riches à javascript peut vous sembler banale, mais je rappelle pour certain(e)s que l’époque du web pre-Ajax n’est pas si éloignée de nous (à peine 5 ans). Bref, tout ça pour dire qu’avec les dernières générations de navigateurs (Chrome, Firefox, Safari…) les améliorations apportées aux moteurs de rendu CSS ainsi qu’au moteurs javascript remettent en cause une partie des usages de technologies RIA que l’on croyait immuables, et plus particulièrement Flash.

Autant Flash reste la technologie de référence pour tout ce qui est animation vectorielle et manipulation de vidéos / sons, autant pour des usages plus basiques la question se pose… Elle se pose notamment chez Youtube, Dailymotion et Vimeo qui expérimentent tous les trois des lecteurs vidéo en HTML5. Et ce n’est que le début !

Prenons par exemple les techniques de remplacement d’image, elles deviennent obsolètes avec @font-face : Using @font-face.

Bien évidemment nous aurons toujours besoin de Flash, Silverlight et cie pour des interfaces véritablement riches, mais pour faire de petits enrichissements “locaux”, CSS3 va nous permettre de faire des choses tout à fait intéressantes comme en témoigne le dernier article de Smashing Magazine : The New Hotness: Using CSS3 Visual Effects. C’est ainsi un festival d’exemples comme ces boutons lumineux (Radioactive buttons) :

Des boutons qui flashent avec... CSS3

Mais aussi des petits effets de zoom comme ces simili polaroids :

Superbe galerie avec CSS3

Ou encore ces très beaux dégradés assortis d’animations (sliding vinyl) :

Animations et dégradés avec CSS3

Et puisque l’on parle d’animations, il serait aussi possible de les utiliser pour des menus de navigation (Nicer Navigation with CSS Transitions) ou des effets de zoom : Make An Elastic Thumbnail Menu. Plus d’exemples ici : 45 Powerful CSS/JavaScript-Techniques.

Un menu en fish-eye avec CSS3

Il serait même possible d’aller beaucoup plus loin comme nous le prouve les différentes expérimentations présentées sur Chrome Experiment dont l’incroyable jeu Crystal Galaxy :

Un shoot-them-up en javascript et HTML5

Tout ceci est très encourageant, mais ne sera viable que dans quelques années quand ces navigateurs de nouvelle génération se seront répandus. Comptez ainsi 5 à 6 ans avant qu’IE 8 et ses prédécesseurs soient sur le déclin et que le marché se sente prêt à tourner la page. Cette période étant bien sûr sujette à une petite rallonge de quelques années si Microsoft décide de ne pas intégrer HTML5 et CSS3 à IE 9 (fort probable).

Le plus surprenant dans cette histoire (navrante) c’est que nous pourrions commencer à exploiter HTML5 et CSS3 très prochainement, non pas dans le navigateur mais en dehors : Adobe AIR 2 brings Advanced CSS3 Support to the Desktop. Et oui, car la prochaine version de AIR embarquera un moteur de rendu HTML de dernière génération qui bénéficiera de toutes ces avancées.

Comme c’est ironique : Utiliser une technologie Adobe pour faire mûrir les usages d’alternatives technologiques à Flash. Méditons là-dessus…

Voilà, la grande convention annuelle d’Adobe s’achève. Il est maintenant temps pour moi de vous faire une synthèse des nouveautés de ce MAX 2009.

Un nouveau Flash Player universel

Flash Player 10.1 disponible au premier trimestre 2010, cette nouvelle version sera la première “compatible” avec l’initiative Open Screen Project : Adobe Unveils First Full Flash Player for Mobile Devices and PCs. Concrètement cela veut dire que le prochain Flash Player sera disponible pour un très grand nombre de terminaux alternatifs (téléphones mobiles, smartphones, set-top-boxes…) et qu’il garantira un comportement homogène quel que soit l’environnement ciblé. Pour faire simple : un Flash Player universel.

Est-ce une bonne chose ? Oui tout à fait car cela permettra aux développeurs d’animations / applications Flash de les déployer n’importe où. Est-ce réaliste ? Non pas réellement dans la mesure où chaque terminal possède des spécificités dont il faut impérativement tenir compte (affichage, périphériques de saisie…).

Ce Flash Player universel est une première étape qui ne sera validée qu’avec la livraison d’outils d’édition permettant d’anticiper et de tester les particularités de chacun de ces terminaux. Device Central est l’outil idéal pour faire ça mais il faudrait le remettre à niveau.

Meilleure prise en compte des terminaux alternatifs

Outre des poids lourds comme Google et RIM qui ont annoncé leur volonté de rejoindre le consortium Open Screen Project, un certain nombre de partenariats industriels ont été passé avec des acteurs comme Nvidia, Qualcomm et Nokia pour améliorer l’expérience des interfaces riches sur les terminaux alternatifs comme les netbooks et smartphones.

C’est une très bonne chose car force est de constater que jusqu’à présent les interfaces riches n’étaient pas réellement viables sur ces terminaux : impossible par exemple de regarder une vidéo de plus de 30 secondes sur un netbooks sans de gros ralentissements de l’image. Ces industriels ont bien compris que la solution n’est pas d’équiper ces terminaux de processeurs plus puissants mais plutôt de donner accès à la carte graphique via de l’accélération matérielle.

Flash sur l’iPhone (presque)

Belle pirouette d’Adobe qui proposera bientôt la possibilité d’exporter une applications depuis Flash Professional CS5 vers l’iPhone : Adobe Opens iPhone to Flash Developers. Donc en clair il s’agit d’une astuce pour pouvoir palier au refus d’Apple (plus d’infos sur le site dédié Applications for iPhone).

Très honnêtement je ne pense pas que l’on verra du Flash sur l’iPhone avant de nombreuses années. Dans tous les cas de figure Apple est maitre sur son terrain et continuera d’imposer le passage obligatoire par iTunes. De toute façon je doute que l’expérience d’utilisation d’animations et applications Flash conçues pour un ordinateur soit réellement agréable à regarder / consommer sur un iPhone (cf. ce qui est dit plus haut sur Flash et les netbooks).

Une nouvelle version majeure de AIR

Autre nouvelle, la disponibilité au premier trimestre 2010 de la V.2 de AIR : Previewing Adobe AIR 2 at Adobe MAX. Au programme des nouveautés :

• Amélioration des performances, de la sécurité et de l’accessibilité ;
• Meilleur prise en charge du hardware, avec notamment la détection de supports de stockage externes (clés USB…) et l’accès à plus de périphériques (micro, accéléromètre…) ;
• Support du multi-touch pour les terminaux compatibles ;
• Prise en charge de l’HTML 5 et des CSS 3.

Avec un runetime toujours plus proche de la machine, les équipes d’Adobe vont très certainement frapper un grand coup et attirer toujours plus d’annonceurs. Il reste néanmoins du travail pour convaincre les éditeurs d’applications critiques nécessitant de la puissance. Idéalement je verrais bien une fusion de AIR et de Native Client (ha mince, on me signale que ce produit existe déjà, c’est Google Chrome).

Bon en tout cas moi je crois toujours en la nécessité pour Adobe d’éditer son propre browser (cf. Adobe pourrait-il sortir un browser ?). Ceci a d’ailleurs été confirmé à demi-mot lors qu’une session “presse” avec les équipes de la Flash Platform qui ont déclaré réfléchir sérieusement à la fusion du Flash Player avec Acrobat Reader (l’appellation “Adobe Reader” porterait alors tout son sens).

Plus de productivité dans les outils de développement

Autres annonces :

• Nouvelles version de Flash Pro avec l’implémentation d’un moteur physique (certainement pour simplifier la tâche des développeurs de jeux en ligne) ;
• Nouvelle version de Flash Catalyst avec pleins de nouveaux éléments d’interface, une meilleure gestion du texte et de nouveaux effets visuels (cf. Flash Catalyst Beta 2: New Features).

Très clairement l’accent est mit sur la productivité et la collaboration entre les différents membres d’une équipe de conception / développement. Tout ceci devrait encore s’améliorer avec la livraison de la suite complète CS5.

———

Voilà, ça fait donc une belle moisson de nouveautés que j’attends de pied ferme pour le début de l’année prochaine.

Après avoir explorer les représentations en mosaïques et sur des cartes du monde, je continue mon tour d’horizon des dernières expérimentation des sites de presse en matière d’interfaces riches.

Il y a tout d’abord l’interface façon “feuilletage rapide” de Google Fast Flip dont vous avez certainement déjà (trop) entendu parler :

L'interface de Google Fast Flip

En mode de visualisation sans grand intérêt si ce n’est de valoriser un mode de consommation boulimique de l’information : toujours plus de news en un minimum de temps. C’est très certainement pour répondre à ce besoin que certains acteurs repensent leur interface dans une logique d’agrégateur.

USA Today expérimente ainsi une interface baptisée NewsDeck qui fait furieusement penser à Netvibes :

USA Today + Netvibes = News Deck

Vous apprécierez au passage le défilement automatique des catégories en fonction de la position de la souris au dessus de chacune des catégories.

Toujours dans une logique d’agrégation, Microsoft est en train de travailler sur une application qu’ils définissent comme un “Next-Generation Newspaper” (cf. Microsoft’s vision for a “next-gen newspaper” looks like TweetDeck) :

Microsoft + News +Sobees = Microsoft Newspaper

Les observateurs avertis y voient une forte ressemble à des outils comme TweetDeck, et pour cause puisque ce prototype a été développé en partenariat avec Sobees.

Dans leur vision des choses, cette interface serait comme un “hub” où se côtoieraient de la news et des alertes “sociales” (venant de Facebook, Twitter…) et qui serait disponible sur différents terminaux (ordinateur, notebook, smartphone…).

À suivre…

Adobe ? Sortir un navigateur “maison” ? Oui tout à fait, lorsque l’on prend du recul sur ce qu’est devenu la gamme Adobe (et notamment la Flash Platform), on se dit que l’idée n’est pas si farfelue.

Flash Platform, la nébuleuse de produits d'Adobe

Avant toute chose, il faut savoir qu’Adobe a aujoud’hui une part de marché proche de 99% (Flash Player Statistics). Un très bon chiffre qui aurait contenté Macromedia mais qui n’est pas assez pour Adobe car Flash ne concerner qu’une petite partie de la gamme. Ils doivent donc voir plus grand et grignoter petit à petit des parts de marché ou plutôt des parts d’installation sur leurs différents player pour pousser les ventes des produits de la gamme.

Si l’on récapitule, cela concerne :

• Flash player (pour les contenus RIA) ;
• AIR (pour les Rich Desktop Applications) ;
• Shockwave Player (pour les jeux en 3D) ;
• Adobe Reader (pour les PDF) ;
• Media Player (pour les contenus vidéo) ;
• Genesis (pour la collaboration en ligne) ;
• Alchemy (pour les applications en C et C++).

Voilà, le compte est bon : 7 “technologies” pour couvrir une très large gamme de besoins. Le problème c’est que cela fait 7 players à installer et à maintenir. Même si la direction d’Adobe a toujours travaillé dur pour maintenir le Flash player en dessous de la barre symbolique des 5 Mo, la logique de gamme risque de l’emporter et nous risquons de voir apparaitre un Adobe Bundle (ou un Flash Bundle) permettant de télécharger tout ces players. Tout ça ne vous rappelle rien ? Google Pack peut-être ?

Le Google Pack qui inclut un produit Adobe

Vu sous cet angle, une suite de petits players plutôt qu’un gros logiciel, il semblerait que l’Adobe Browser soit déjà sur votre machine au travers de l’Adobe Updater. Oseront-ils un jour “sortir du bois” et s’afficher au grand jour ? Pas évident dans la mesure où cela les métraient dans une position délicate :

• En concurrence avec Mozilla (sur des produits comme Firefox ou Prism) mais dont la communauté travaille sur une version open source du moteur de scripting (Vers un flash player en open source pour la fondation Mozilla ?) ;
• En concurrence avec Microsoft (en plus de Silverlight et de la gamme Expression) ;
• En concurrence avec Google (qui commence à faire monter la pression avec Chrome) mais avec lequel ils collaborent pour améliorer le référencement des contenus Flash (Adobe collabore avec Google et Yahoo! pour améliorer l’indexation de Flash).

Bref, ça n’est pas simple mais la question mérite d’être posée. Quelle serait selon vous la probabilité pour un Adobe Browser ?

J’avais publié en début d’année un article sur les CSS Animations et le fait qu’elles ne concurrençaient pas réellement les technologies RIA fondées sur un plug-in mais plutôt les framework d’animations en javascript (Pourquoi les CSS Animations ne sont pas concurrentes de Flash ou Silverlight). Le débat est relancé cette semaine avec la publication d’un article sur Six Revisions : 10 Impressive JavaScript Animation Frameworks.

L’idée de cet article est de faire le point sur 10 frameworks d’animation Javascript. Parmi les frameworks présentés, je retiens $fx (pour les soucoupes volantes) et scripty2 (pour sa démo de Solitaire). Plusieurs autres framewokrs ont été proposés dans les commentaires de l’article : script.aculo.us, jQuery, cakejs… Vous noterez qu’aucun de ces framework ne s’orthographie avec une majuscule au début (je dis ça, je dis rien).

Un solitaire tout en javascript

Comme il est question d’animations en javascript, comment ne pas parler de Chrome Experiment, le portail d’expérimentation des possibilités du moteur javascript du navigateur de Google (qui fonctionnent forcément mieux avec … Chrome).

Les expérimentations d'animations en javascript chez Google

Cette article relance le débat sur la performance des moteurs javascript des différents navigateurs. Dans ce domaine, le vainqueur est généralement celui qui publie les résultats de sa propre étude, ici le benchmark d’Apple :

Comparaison des moteurs javascript des différents navigateurs

Pourquoi est-ce que je vous parle de tout ça ? Car les animations sont un élément essentiel des interfaces : elles illustrent, focalisent l’attention et améliorent grandement l’expérience d’usage (cf. Vive les transitions !). Du moins si elles sont utilisées à bon escient, mais c’est la même chose pour toute technologie de RIA.

Ces frameworks sont donc un bon moyen d’insérer des animations dans une interface en attendant l’arrivée à maturation des CSS Animations. Le tout étant de ne pas chercher à réaliser un exploit technologique là où des technologies comme Flash sont plus appropriées.

Au final je pense que nous n’en sommes qu’au tout début d’une nouvelle ère d’innovation pour les navigateurs qui après 10 ans d’existence sont en train de se métamorphoser (cf. Opera 10, Chrome 4, Firefox 4 : Vers des plateformes sociales et applicatives). Faire évoluer les technologies de base des navigateurs (HTML, CSS, Javascript) est un préambule indispensable, encore faut-il que cela se fasse dans la voie de la standardisation. Dans cette optique, des frameworks open source et largement rependus comme jQuery sont peut-être un choix plus pérene. Mais n’étant pas un spécialiste, je suis ouvert à toute argumentation à ce sujet (ça tombe bien les commentaires sont là pour ça).