Microsoft lance les applications universelles pour smartphones, tablettes, ordinateurs et Xbox

La semaine dernière, Microsoft a réunissait tout le gratin de l’écosystème IT pour sa conférence annuelle Build. Même si les conférences annuelles de Microsoft ne font pas autant de bruit que les événements d’Apple, Google ou même SalesForce, la firme de Redmond a présenté des nouveautés tout à fait intéressantes :

Comme vous pouvez le constater, cette édition 2014 a été très riche en annonces, elle coïncide également avec la première grosse sortie publique du nouveau CEO (Satya Nadella engage la transformation de Microsoft). Cerise sur le gâteau, les équipes de Microsoft ont présenté un principe d’application universelle : Microsoft’s new universal Windows apps run everywhere, from phones to the Xbox One.

Exemple d'application universelle pour Windows
Exemple d’application universelle pour Windows

Les Universal Windows Apps sont des applications capables de tourner sous Windows et Windows Phone, donc sur les smartphones, tablettes, ordinateurs, la Xbox One. Est-ce un miracle ? Non pas réellement, car l’environnement de développement Visual Studio ne vous permet “que” de créer avec un pacquage avec deux versions d’une même application partageant des sources. Autant le dire tout de suite : je suis terriblement injuste vis-à-vis du travail titanesque réalisé par les équipes de Microsoft pour rapprocher ses deux systèmes d’exploitation. Dans les faits, Windows et Windows Phone sont BEAUCOUP plus proches l’un de l’autre que ne peuvent l’être iOS et Mac OS ou Chrome OS et Android.

Tout l’intérêt des Universal Apps est de factoriser un maximum de chose (on nous annonce 90% de code commun entre deux versions d’une application) et de faire gagner du temps aux développeurs, notamment au niveau de l’interface qui devra être adaptée à chaque terminal (Visual Studio 2013 Update 2 RC: Windows Phone 8.1 Tools, Shared).

Adaptation des interfaces des Universal Apps
Adaptation des interfaces des Universal Apps

Il n’y a pas encore de date de fusion entre les deux places de marché d’application (Windows Store et Windows Phone Store), mais on se doute bien de leur objectif à terme. Dans cette optique, je pense ne pas me tromper en disant que Microsoft a pris une grosse longueur d’avance sur Apple ou Google, même si ce dernier semble opter pour une approche différente avec les packaged apps (20 ans d’évolution des IHM web).

Vous noterez que Microsoft n’est pas le seul à se lancer dans ce chalenge (Ubuntu relève le défi du système d’exploitation universel). La société Canonical avait annoncé l’année dernière le lancement d’un OS unique pour tous les terminaux, mais ce projet ne fait plus trop parler de lui…

Le projet de système d'exploitation universel de Ubuntu
Le projet de système d’exploitation universel de Ubuntu

Microsoft fournit donc des efforts considérables pour améliorer l’hétérogénéité de son parc d’utilisateurs, une très bonne chose, d’autant plus qu’ils sont durs à bouger (plus d’1/4 des ordinateurs de la planète tournent encore sous Windows XP : Attention, Windows XP holdouts: The end is near). Mais ne vous y trompez pas : le véritable enjeu n’est pas de fournir des applications universelles, mais des services universels (ou des contenus universels). La bataille ne se situe donc pas réellement au niveau des systèmes d’exploitation, mais plutôt dans les nuages : This Chart From IBM Explains Why Cloud Computing Is Such A Game-Changer. Ceci explique sûrement la nouvelle orientation de Microsoft et la réorganisation interne (Scott Guthrie is officially the top cloud guy at Microsoft). En misant sur le cloud computing, Microsoft espère reprendre l’initiative sur les nouveaux terminaux (Microsoft veut apporter ses tuiles Windows dans le tableau de bord de votre voiture) et surtout sur l’internet des objets qui force les éditeurs à intégralement revoir leur approche de l’outil informatique.

De la 3D encore plus performante dans votre navigateur grâce à WebGL et WebCL

L’année dernière, Mozilla avait fait sensation en annonçant le portage du moteur Unreal dans son navigateur : Des jeux en 3D toujours plus performants avec HTML5. Précisons que Unreal Engine est un moteur graphique permettant de faire de la 3D, principalement utilise dans des jeux sur PC ou consoles. Ce moteur 3D avait déjà été porté dans Flash (pour faire de la 3D en utilisant le même environnement de création de contenus 3D), et il a ensuite été “traduit” en javascript pour pouvoir tourner de façon native dans un navigateur, en l’occurrence Firefox.

Rebelote cette semaine avec le portage de la dernière version du moteur : Mozilla and Epic Preview Unreal Engine 4 Running in Firefox. En moins de 12 mois, les équipes de Mozilla ont été capables d’améliorer de 40% les performances de asm.js, un sous-ensemble de Javascript, plus facile à optimiser. Les contenus 3D (animations, jeux…) créés pour le moteur Unreal 4 peuvent maintenant être affichés nativement dans votre navigateur grâce à asm.js, qui exploite lui-même WebGL, dont nous avons déjà parlé il y a quelques années : WebGL, le nouveau standard de la 3D sur le web.

Le résultat est visuellement très impressionnant et va permettre aux développeurs de jeux de toucher une cible beaucoup plus large. Pour se faire, ils viennent tout juste de proposer un nouveau modèle de licence pour rendre son moteur plus accessible : Epic Games Tries Something New, Licenses All Of Unreal Engine 4 For $19 A Month.

Le lendemain de cette annonce, Unity3D annonce à son tour que la prochaine version de son moteur de rendu 3D pourra être exécutée dans un navigateur : Mozilla and Unity Bring Unity Game Engine to WebGL. Les mêmes technologies seront utilisées (asm.js et WebGL) pour “traduire” le moteur 3D, mais celui-ci sera toujours disponible sous forme de plug-in.

Le but de ces annonces est de séduire le plus grand nombre de développeurs pour qu’ils adoptent  l’un ou l’autre de ces moteurs 3D dans leurs prochaines réalisations (jeux ou applications). Le fait de proposer une exécution native dans les navigateurs (Firefox ou Chrome) est un plus indéniable pour séduire le plus grand nombre de joueurs sans leur imposer l’installation d’un plug-in. Si le moteur d’Unreal est reconnu pour sa sophistication, le moteur de Unity est plus simple et largement utilisé par les développeurs de jeux mobiles qui y voient un moyen de faciliter la distribution de leurs jeux : Unity 5.0 announced, with direct-to-web, plugin-free publishing.

Et comme si ça ne suffisait pas, le Khronos Group vient d’annoncer la sortie de nouvelles spécifications et versions de spécifications précédentes : Khronos Releases Wave of New Standards and Initiatives for 3D Graphics, Heterogeneous Computing and API Interop. Pour vous résumer une longue explication, Le Khronos Group est un consortium en charge des spécifications de nombreuses normes en matière de 3D, notamment OpenGL (pour que des applications puissent exploiter la puce graphique) et OpenCL (pour que des applications puissent faire des calculs en parallèle sur le processeur ou la puce graphique). Le Khronos Group est notamment à l’initiative de WebGL, l’équivalent d’OpenGL pour les navigateurs et de la toute nouvelle WebCL, une APIs qui permet aux navigateurs d’utiliser le processeur pour faire des calculs parallèles : Khronos publishes a range of specs to take GPU computing to the Web et WebCL Will Soon Let Web Developers Harness The Power Of Multi-Core GPUs And CPUs From The Browser.

Traduction : l’industrie se mobilise pour que les navigateurs soient capables d’afficher de la 3D de façon aussi performante que les applications. Ceci étant valable pour les navigateurs sur votre ordinateur, mais également sur votre smarpthone ou tablette. Illustration avec cette vidéo de démonstration de WebCL par Samsung :

Toutes ces nouvelles spécifications et portages convergent vers un seul objectif : démocratiser la 3D et la rendre accessible au plus grand nombre au travers des navigateurs web, quel que soit le terminal utilisé. Qui s’en plaindra ?

Adobe et Google en désaccord sur les techniques de mise en page avancée

Saviez-vous que les feuilles de styles (Cascading Style Sheets en anglais) ont été lancées en 1997 ? La normalisation de cette technologie par le W3C a permis de dissocier la présentation du contenu et sortir le web design de l’âge de pierre. L’intérêt des feuilles de style a notamment été démontré avec des initiatives communautaires comme le CSS Zen Garden. Mais les choses se sont vraiment accélérées avec l’arrivée de la troisième version des feuilles de styles (CSS3) qui permettent notamment de faire des transitions, des arrondis, ombres protées et surtout de choisir sa propre police (CSS @ Ten: The Next Big Thing).

Les dernières évolutions en date concernent la possibilité de définir des formes pour des éléments (Creating Non-Rectangular Layouts with CSS Shapes et Animating CSS Shapes with CSS Animations & Transitions) et de définir des conteneurs pour figer une mise en page (Killer Responsive Layouts With CSS Regions).

Pouvoir faire des mises en page aussi sophistiquée et rigoureuse que sur les magazines est un vieux rêve pour nombreux designeurs. Adobe a toujours été moteur pour promouvoir les techniques avancées de mise en page, notamment avec sa politique de soutien. Ils sont donc naturellement aujourd’hui les plus gros promoteurs des CSS Shapes et CSS Regions. Ils ont à ce sujet présenté une très belle démonstration technique, Alice in Wonderland, faisant un usage malin de ces techniques de mise en page pour scénariser le texte.

Alice in Wonderland réalisé avec les CSS Regions
Alice in Wonderland réalisé avec les CSS Regions

Le résultat est tout simplement bluffant, mais nécessite un navigateur très récent et une petite manipulation : Using CSS Shapes to  Enhance Visual Storytelling. Cette réalisation est d’autant plus intéressante qu’elle vient d’un studio français (Alice au Pays d’Adobe, un conte interactif). Tous les détails techniques sont ici : Cutting edge web development with CSS Shapes and CSS Regions

Il est important de préciser que cette réalisation est une étape très importante dans le travail de lobbying mené par Adobe pour faire accepter ces spécifications par le W3C (Adobe issues CSS Web publishing prototype et CSS3 regions: Rich page layout with HTML and CSS3).

CSS-Regions-1

Le problème est que, dans leur philosophie, les CSS Regions sont en désaccord avec la notion essentielle de flux de contenu (en contraignant des portions de contenu dans des zones particulières, vous figez la page). Håkon Wium Lie, l’inventeur des CSS et directeur technique de Opera, a ainsi publié un long article pour en dénoncer les limitations : CSS Regions Considered Harmful. Ses principaux arguments sont les suivants : les CSS Regions alourdissent le code avec des balises de présentation (le retour des DIVs) et perturbent le défilement naturel du texte.

Confusing-text-flow

Ne vous y trompez pas : l’auteur n’est pas hermétique au changement, il craint seulement que ces nouvelles propriétés CSS soient utilisées à tort et nous renvoient à une époque sombre où les bidouillages de mise en page étaient légion. Du coup, d’autres designeurs argumentent à leur tour en faveur des CSS Regions et plaident pour une plus grande liberté de choix dans les possibilités de mise en page : CSS Regions Matter.

Je dois bien vous avouer avoir beaucoup de mal à me faire un avis tranché sur la question : d’un côté je suis un grand fan de la scénarisation des contenus (HTML5 donne de la profondeur à la narration) ; d’un autre côté, il nous faut IMPÉRATIVEMENT simplifier et normaliser la syntaxe des pages HTML pour en faciliter la diffusion sur les terminaux alternatifs.

Coup de théâtre le mois dernier, car Google vient d’annoncer que les CSS Regions ne seront pas supportées par le moteur de rendu de Chrome : Google plans to dump Adobe CSS tech to make Blink fast, not rich. Pour mémoire, les navigateurs utilisent tous des moteurs de rendu différents pour interpréter le code HTML / CSS et afficher les pages web (Blink pour Chrome, Webkit pour Safari, Gecko pour Firefox…). Chrome étant un des navigateurs les plus populaires, c’est donc un très gros coup dur pour les CSS Regions. La raison invoquée par Google est qu’ils ne veulent pas sacrifier les performances de leur moteur de rendu.

Ceci étant dit, l’histoire de l’évolution des technologies web est ponctuée de revers de ce style. Les CSS Regions ne sont donc pas enterrées, mais leurs spécifications vont très certainement être revues et discutées jusqu’à être acceptées par les différents éditeurs de navigateur.

Affaire à suivre…

Microsoft cherche à relancer son navigateur en misant sur les tablettes

Voilà de nombreuses années que Microsoft cherche à limiter l’érosion des parts de marché de son navigateur Internet Explorer. Il faut dire que ce dernier a pris un terrible coup de vieux ces dernières années avec l’ascension fulgurante de Chrome et Firefox, sans compter les bonnes performances de Safari et Opera. Pour cela, ils ont régulièrement organisé des campagnes et réalisé des démos techniques pour tenter de prouver au grand public que IE n’était pas le vilain petit canard que l’on croyait (La guerre des navigateurs relancée par Microsoft), jusqu’à la récente campagne The Browser You Love to Hate. Cette année, nous avons droit à une approche différente avec une campagne ambitieuse : Internet Explorer Invites You to Rethink What the Web Can Be.

Avec RethinkIE, les équipes de Microsoft ont mis le paquet pour assurer la promotion de la version 11, mais le positionnement est différent : (“It’s a new browser, it might surprise you“) : Regardless of what you think of IE, Microsoft wants you to Rethink IE. Ils ne communiquent ainsi plus du tout sur les performances techniques, mais sur d’autres arguments :

  • Une expérience différenciante sur les tablettes avec de la navigation en plein écran ;
  • Du multitâche (ex : Skype dans un onglet pendant que l’on surfe sur un autre) ;
  • Un mode “lecture à l’écran” (déjà présent sur Safari et Opera il me semble) ;
  • La possibilité d’épingler des sites ou pages sur l’écran d’accueil de Windows…

Comme il faut un minimum épater la galerie, cette nouvelle campagne s’appuie sur plusieurs réalisations très spectaculaires pour démontrer les capacités techniques de cette 11e version :

  • Red Bull Rampage 2013, un mini-site mêlant contenus vidéo et interactivité ;

    L'interface de Red Bull Rampage 2013
    L’interface de Red Bull Rampage 2013
  • GlacierWorks, un autre mini-site pour partir à la découverte de l’Everest, avec de très beaux panoramas en plein écran ;

    L'interface de Glacier Works
    L’interface de Glacier Works
  • Contre Jour, l’adaptation du célèbre jeu pour tablette ;
  • Hover, l’adaptation d’un autre jeu mythique, dans la lignée de Atari Arcade ;

    L'interface de Hover, façon retro gaming
    L’interface de Hover, façon retro gaming
  • Just a Friend, qui mélange musique et expériences visuelles.

Tout ceci est très réjouissant et surtout très bien exécuté. Mais le problème est de parvenir à reconquérir la confiance des développeurs. Pour cela, les équipes ont lancé l’initiative Modern.ie l’année dernière, sur laquelle on retrouve des explications sur les réalisations précitées (Behind the Scene) : Saving Developers over 1 Million Hours: Celebrating the 1 Year Anniversary of modern.IE.

Je ne me prononcerais pas sur les qualités de cette onzième version puisque je ne peux pas l’installer, mais je crois savoir qu’elle apporte entière satisfaction aux possesseurs de tablettes Windows que j’ai pu interroger. Je ne peux que saluer les efforts fournis par Microsoft pour ne pas se laisser distancer. Il faut dire que la tâche est rude, surtout avec les nombreuses annonces de la concurrence (Mozilla’s major user interface overhaul Australis lands in Firefox Nightly et Chrome + LEGO: You can build whatever you like).

Que le meilleur gagne !

20 ans d’évolution des IHM web

En 15 ans, le web a complètement modifié notre façon d’accéder et de consommer l’information. Le web est maintenant une composante essentielle de notre quotidien : biens dématérialisés, services en ligne, formation et éducation, jeux en ligne, objets connectés… Je pense ne pas me tromper en disant que le web a façonné la société dans laquelle nous vivons : transparence absolue, peur du micro-ennuie, hyper-individualisme avec la mode des selfies… 15 années très riches, et un nombre incalculable d’innovations technologiques. Je vous propose à travers cet article de faire le point sur l’évolution des technologies liées aux interfaces web.

Dans sa définition la plus stricte, une interface est la couche entre deux éléments par laquelle ont lieu des échanges et des interactions. Dans le cas de l’internet, les interfaces web sont donc la couche permettant aux utilisateurs de consommer et d’interagir avec les nombreux contenus et services en ligne. Nous allons donc passer en revue les différentes technologies d’interface web, étudier leur évolution et constater la façon dont les grands éditeurs essayent encore et toujours de ramener la couverture à eux.

Des sites web aux rich desktop applications

Aux origines du web, les contenus et services n’étaient disponibles qu’à travers les pages HTML : du texte, des tableaux, des images et des formulaires. Mais au fil du temps, les choses se sont compliquées : Panorama des IHM connectés.

Evolution_IHM-1

Si le navigateur était l’interface de référence entre les contenus et les internautes, différentes technologies ont été successivement exploitées pour enrichir l’expérience :

  • Les applets Java pour faire les premières applications en ligne ;
  • Les plugins comme Flash et Silverlight pour faire des Rich Internet Applications ;
  • Les moteurs de widget pour pouvoir diffuser du contenu directement sur le bureau ;
  • Les machines virtuelles comme AIR pour faire tourner des Rich Desktop Applications.

Tout ceci peut vous sembler complètement superflu, mais souvenez-vous qu’à cette époque le W3C souffrait d’une crise interne et que les spécifications de HTML faisaient du sur-place. D’où l’émergence de nombreuses technologies d’interfaces riches pour pouvoir étendre les possibilités du HTML et proposer des modalités d’affichage et d’interaction plus sophistiquées (3D, drag&drop…).

Très clairement cette première décennie de l’histoire des interfaces web a été dominée par Adobe et ses deux technologies phares (Flash et AIR). Puis Apple a lancé son iPhone, et le marché s’est complètement retourné.

Des applications mobiles aux applications packagées

C’est en début d’année 2007 que Steve Jobs a présenté pour la première fois son iPhone. Nous étions très loin de nous douter à l’époque de la révolution que cela allait engendrer, d’autant plus que dans sa première version, il n’y avait pas d’App Store, d’ailleurs ils n’envisageaient pas à l’époque d’ouvrir leur smartphone à des éditeurs externes d’applications. Et pourtant… avec la version 2 et surtout la version 3 du système d’exploitation de l’iPhone, les applications mobiles vont connaitre un succès phénoménal : même si les contenus et les services étaient les mêmes, le fait de les consommer à travers une interface tactile en situation de mobilité a poussé les mobinautes à s’enfermer dans la logique des applications.

Evolution_IHM-2

Loin de moi l’idée de refaire l’histoire, mais les applications mobiles sont à la fois la meilleure et la pire chose qui a pu arriver au web : la meilleure, car cela a permis de démocratiser les interfaces tactiles et de donner un second souffle créatif aux designers ; la pire, car cet écosystème fermé d’applications va à l’encontre du principe d’ouverture et d’universalité du web. C’est d’ailleurs pour protéger son monopole qu’Apple est entré en guerre avec Adobe pour empêcher aux applications Flash de détourner les revenus provenant de son app store. Mais dans une certaine mesure, la volonté d’Apple de diaboliser Flash pour protéger ses revenus a fortement contribué au succès d’HTML5. La montée en puissance de navigateurs alternatifs comme Chrome et Firefox, combinée à un fort enthousiasme autour du renouveau d’HTML a permis de viabiliser l’exploitation à très grande échelle d’applications web comme Gmail, Twitter ou encore SalesForce. Si aujourd’hui, il ne vous venait plus à l’idée d’installer un logiciel pour consulter vos emails ou pour interagir avec vos amis ou collègues, sachez qu’à une époque pas si lointaine le débat faisait rage.

Avec la montée en puissance d’Android, de Windows Phone, et plus généralement la fragmentation des terminaux mobiles, certains éditeurs de contenus et service se sont rapidement rendu compte qu’éditer des applications natives n’était pas forcément une stratégie rentable. Ils se sont tournés vers des frameworks de développement multi-plateforme comme Phonegap, Titanium ou Sencha pour faire des applications hybrides : des contenus et services HTML encapsulés dans une application native. Aujourd’hui le débat entre applications mobiles natives, hybrides ou HTML est toujours actif (Le choix se complique entre application mobile et application HTML5), d’autant plus que l’on a maintenant un minimum de recul sur les mises en page adaptatives (Le Responsive Web Design n’est pas une solution, c’est un compromis).

Personne ne peut nier le rôle primordial de l’iPhone et l’iPad dans l’évolution radicale des usages autour des interfaces. Mais pendant ce temps là, d’autres préparaient leur contre-attaque, à commencer par Adobe qui s’est repositionner en un temps record sur les technologies standards (cf. Adobe & HTML) et qui a même lancé une suite complète d’outils de développement HTML5.

De même, Google a patiemment conçu et perfectionné les différentes pièces d’un plan dont on commence seulement à deviner les contours : ils ont commencé par populariser le navigateur Chrome en utilisant des briques logicielles communes à d’autres produits, dont le moteur de rendu Webkit. Puis ils ont adopté leur propre moteur de rendu HTML (Blink) et ont implémenté la technologie NaCl pour pouvoir exécuter des applications C++ (L’adoption de NativeClient passera par les jeux… et la bureautique). Plus récemment, ils ont commencé à faire la promotion des Chrome Apps, des applications HTML pouvant tourner en mode déconnecté avec Chrome ou ChromeOS (Google transforme son navigateur en environnement d’exécution avec les Chrome Apps). Les choses se sont accélérées tout dernièrement avec l’annonce d’un environnement de développement dédié et le portage des Chrome Apps sur iOS (Google veut accélérer le développement des Chrome Apps). En quelques années, Google s’est imposé comme l’acteur principal du renouveau des interfaces web, aussi bien sur les ordinateurs (avec les applications packagées) que sur les terminaux mobiles (Google prépare la révolution des interfaces Android).

Nous sommes quasiment à la fin de cette seconde décennie et nous y voyons maintenant beaucoup plus clair dans les plans de Google : s’appuyer sur les technologies standards (HTML, javascript…) pour généraliser ses environnements d’exécution (Chrome, ChromeOs et Android). Tout ceci n’est pas sans rappeler les manoeuvres de Microsoft ou Adobe, mais force est de constater que nous allons tout de même vers plus de simplicité et de performance pour les utilisateurs finaux (le fait de pouvoir éditer des documents Office directement dans Chrome avec QuickOffice est quand même un grand plus).

Voilà où nous en sommes en ce début d’année 2014. Vous constaterez que malgré une domination écrasante de son système d’exploitation, Microsoft n’est jamais réellement parvenu à prendre le leadership sur les interfaces web et à imposer ses technologies (le flop de Silverlight est un bel exemple). Il est pour le moment très difficile de prédire l’avenir, mais je suis persuadé que les choses ne vont pas beaucoup bouger : la communauté des développeurs va se détourner des plugins et s’orienter à nouveau vers HTML, que ce soit pour scénariser du contenu, perfectionner des applications en ligne ou se réapproprier les terminaux mobiles. Ceci fera l’objet d’un prochain article…

Google veut accélérer le développement des Chrome Apps

Depuis ses débuts, Google a toujours misé sur les technologies web et a été un fervent défenseur des applications en ligne. Il existe bien des applications Google que l’on installe sur son ordinateur (Picasa, Sketchup…), mais elles sont anecdotiques. Google avait fait sensation en 2009 en annonçant le lancement de ChromeOS, un système d’exploitation pour les chromebooks reposant sur un noyau Linux, mais avec une interface 100% web. Traduction : un ordinateur sur lequel on ne peut pas installer de logiciels et où tout se passe dans le navigateur, en l’occurrence Chrome. Un choix très avant-gardiste que j’ai eu l’occasion de commenter (Avec Chrome OS, Google parie sur le CloudBook et La fin de l’ordinateur individuel est programmée). Quatre ans après, ce choix s’avère payant, car les chromebooks représentent maintenant plus d’1/5 des ventes d’ordinateurs portables : Google’s Chromebooks Have Hit Their Stride.

Exemple de Chromebook fabriqué par Acer
Exemple de Chromebook fabriqué par Acer

Le problème est que si tout le monde est d’accord pour dire que ces machines proposent un rapport qualité / prix imbattable, leur utilisation en mode hors connexion est très hasardeuse. Non en fait pour être exacte, les termes généralement employés sont : “sans une connexion internet, un chromebook est un gadget complètement inutile“. Pour pallier a cette faiblesse, les équipes de Chrome ont travaillé d’arrache-pied pour améliorer la gestion du mode hors connexion. Le résultat sont les Chrome Apps, des applications web qui fonctionnent hors-ligne, en d’autres termes : des applications en ligne qui se comportent comme des logiciels (cf. What Are Chrome Apps?). Vous noterez d’ailleurs que ces Chrome Apps ne sont pas uniquement réservées aux Chromebooks, mais à tous les ordinateurs qui utilisent Chrome (Google transforme son navigateur en environnement d’exécution avec les Chrome Apps). Vous pourriez me dire qu’une application en ligne fonctionnant sans connexion ne pourra jamais réellement remplacer un “gros” logiciel, mais là encore, Google a réfléchi à la question (Tous vos documents bureautique consultables directement dans votre navigateur).

Google cherche donc à faire de Chrome le coeur de son écosystème. Mais le problème est que pour qu’un écosystème informatique soit viable, il faut un minimum d’applications et de développeurs. Dans ce contexte, il semblerait que Google soit en train de travailler sur un certain nombre d’outils pour leur simplifier la tâche. L’infatigable François Beaufort a ainsi repéré en fin d’année dernière un projet d’environnement de développement de Chrome Apps : Google building Spark, a Web-based development tool. Le projet Spark est donc un IDE (Integrated Development Environment), un ensemble d’outils permettant aux développeurs de créer beaucoup plus facilement des applications pour Chrome.

L'environnement de développement de Chrome Apps
L’environnement de développement de Chrome Apps

Cet environnement de développement présente deux particularités intéressantes :

Dart, Polymere, Spark, Native Client… force est de constater que Google ne ménage pas ses efforts pour séduire la communauté des développeurs et imposer sa vision d’une informatique plus “légère”. Et puisque l’on parle d’alléger l’outil informatique, comment ne pas évoquer Android, le système d’exploitation mobile de Google. Figurez-vous qu’avec les Chrome Apps, ils ont réussi à faire la liaison entre les deux OS : Google is building Chrome apps support for Android and iOS, beta release coming as soon as January 2014. Une autre équipe est en train de finaliser un mécanisme de portage des Chrome Apps pour qu’elles puissent être exécutées sur un terminal Android, toujours par l’intermédiaire de Chrome.

Les Mobile Chrome Apps sont donc l’arme secrète de Google pour révolutionner les concepts de logiciel et d’application mobile. En d’autres termes : plutôt que de développer une application pour un terminal ou un système d’exploitation spécifique (PC, Mac ou Android), vous pouvez utiliser les Chrome Apps pour déployer des applications web partout où vous le souhaitez. “Arme secrète” est vraiment le bon terme, car les équipes de Google se font très discrètes sur ce chantier. En cherchant bien, il est possible de trouver quelques informations (Chrome DevTools for Mobile: Emulate and Screencast), mais il n’y a qu’une seule personne qui communique ouvertement là-dessus : Porting Chrome Packaged Apps to Mobile using Cordova.

J’imagine que cette discrétion est due aux nombreuses difficultés techniques que les équipes devront résoudre afin de stabiliser les Chrome Apps et l’environnement de développement Spark. Pour mémoire, je vous rappelle que la fondation Mozilla s’était aventurée il y a peu de temps dans un chantier similaire avec Bespin, rebaptisé plus tard SkyWriter et finalement fusionné avec le projet Ace (Mozilla Skywriter has been merged into Ace).

Tout ceci est encore un peu complexe à comprendre et soulève de nombreuses difficultés techniques. Mais c’est le prix à payer pour pouvoir exploiter dans de bonnes conditions des applications en ligne sans connexion. C’est le prix à payer pour réinventer l’outil informatique…

HTML5 donne de la profondeur à la narration

L’année dernière, le NY Times avait bluffé tout le monde en sortant un dossier superbement illustré et mis en scène grâce à HTML5, mais soulevait d’importantes questions quant à la viabilité de ce type de création : Le NY Times innove avec Snow Fall, mais illustre les limites de la narration multimédia. Si l’on ne peut que s’émerveiller devant l’impeccable réalisation de Snow Fall, je m’étais interrogé sur la capacité des éditeurs de contenus en ligne à financer ce type de projet. Il faut croire que j’avais sous-estimé cette capacité : 12 wonderful examples of immersive online storytelling.

Sur l’année passée, nous avons ainsi été les témoins de l’émergence d’une nouvelle forme de narration enrichie grâce à HTML5. Parmi les réalisations les plus marquantes, j’ai retenu :

Tout est parfait dans ces réalisations : la mise ne page du texte, les illustrations et vidéos, les infographies et éléments interactifs… c’est un véritable plaisir de lire ces longs articles, aussi bien sur l’écran de votre ordinateur que sur votre tablette. Je ne peux que me réjouir de voir que cette forme de narration enrichie fonctionne bien et semble donner un souffle nouveau aux éditeurs : Recent Trends In Storytelling And New Business Models For Publishers. Le magazine en ligne Grantland d’ESPN ou la section Longform de The Verge viennent confirmer le fait que les micro-contenus et articles vites torchés / vites oubliés de sites comme BuzzFeed ou Upworthy ont une limite.

Est-ce réellement surprenant de constater que les internautes apprécient les articles de qualité (long form journalism) parfaitement valorisés par une mise en scène enrichie, le tout au service de la narration et de l’immersion ? Non, pas réellement : Le retour de la revanche du contenu (bis). Vous remarquerez d’ailleurs que les énergies convergent vers ce modèle de narration enrichie. C’est en tout cas la façon dont j’interprète le dernier article d’Eve William au sujet du nouveau positionnement de Medium, sa plateforme de publication : A New Storytelling Experience.

Certes, la technologie n’est qu’un outil et non une fin en soi, mais force est de constater qu’avec HTML5 et CSS3, il est beaucoup (BEAUCOUP) plus facile de produire et diffuser du contenu avec une narration enrichie sur différents supports (tablettes, smartphones, netbooks…).

Google prépare la révolution des interfaces Android

Android est incontestablement le système d’exploitation le plus populaire sur les smartphones. En témoignent les derniers chiffres publiés par Strategy Analytics : Android Captures Record 81 Percent Share of Global Smartphone Shipments in Q3 2013. Non, vous ne rêvez pas : 4 smartphones sur 5 livrés aux distributeurs sont propulsés par le système d’exploitation mobile de Google. Non pas que les smartphones Android sont meilleurs que les iPhones (je ne rentrerais pas dans ce débat), simplement qu’ils proposent un bien meilleur rapport qualité / prix.

Évolution des parts de marché des OS de smartphones
Évolution des parts de marché des systèmes d’exploitation de smartphones

Il aura fallu 5 ans à Google pour imposer son système d’exploitation mobile, et de nombreuses évolutions. La toute dernière version d’Android (la 4.4, baptisée KitKat) n’échappe pas à la règle et s’annonce comme étant bien plus disruptive que les précédentes. Non pas qu’il va y avoir d’énormes changements dans l’ergonomie ou les fonctionnalités (10 Things Developers And Users Need To Know About Android KitKat 4.4), mais c’est plutôt sous le capot que les changements les plus intéressants vont se produire. Cette nouvelle version est sortie il y a presque 10 jours et l’on commence seulement à comprendre l’ampleur des changements et surtout leur finalité.

Première annonce avec la livraison par défaut de QuickOffice, l’application rachetée par Google l’année dernière qui permet d’éditer des fichiers bureautiques Office : Google Quickoffice ships with Android KitKat. Ceci intervient juste après l’annonce de sa mise à disposition gratuite et de son couplage avec Google Drive : Freeing Quickoffice for everyone.

Éditez vos fichiers bureautique sur Android avec QuickOffice
Éditez vos fichiers bureautiques sur Android avec QuickOffice

N’importe quel fichier bureautique va maintenant pouvoir être édité nativement depuis votre smartphone ou tablette Android. Ceci va simplifier pas mal de choses, car il fallait jusqu’à présent passer par des applications tiers.Entre ça et la mise à disposition gratuite de la nouvelle version de la suite bureautique d’Apple, ça doit grincer des dents à Redmond !

Deuxième découverte qui fait beaucoup de bruit, la mise à disposition d’ART, une nouvelle version de l’environnement d’exécution des applications : Google starts testing ART, a potential replacement for Dalvik in Android. Pour vous résumer une longue explication, Java est le langage de programmation utilisé pour les applications tournant sur Android. La particularité de Java est d’être multi-plateforme, contrairement aux autres langages natifs comme ObjectiveC (le langage de programmation d’iOS). Avec ce dernier, une fois que vous avez développé votre application en code natif, vous la compilez en langage machine pour qu’elle puisse être exécutée. Avec Java, le code source est compilé en bytecode qui est exécuté par la machine virtuelle Java (l’environnement d’exécution). Jusqu’à présent, les smartphones Android utilisaient un environnement d’exécution appelé Dalvik qui compilait le bytecode à la volée pour pouvoir l’interpréter. Avec ART (l’acronyme de Android RunTime), le bytecode sera précompilé pour gagner en performance : Meet ART, The New Super-Fast Android Runtime Google Has Been Working On In Secret For Over 2 Years.

Concrètement, c’est une mise à jour majeure du système, mais comme elle se passe sous le capot, les équipes de Google ont choisi de ne pas trop communiquer dessus. Pour la tester, il faut fouiller dans les préférences système et choisir le runtime ART, le smartphone sera alors redémarré et toutes les applications seront précompilées.

L'accès à ART est caché dans les préférences du système
L’accès à ART est caché dans les préférences du système

D’après les premiers tests réalisés, cette opération est un peu longue (comme une mise à jour), mais le gain de performance est notable. Le but de l’opération est donc d’accélérer le lancement et l’exécution des applications, il en résulte une expérience plus fluide. La contre-partie est que les applications précompilées prennent plus de place, mais les testeurs parlent de 10 à 20%, ça reste donc très largement acceptable. Pour le moment la bascule n’est pas conseillée aux amateurs, seulement aux développeurs, car elle risque de faire planter certaines applications. Il n’ a pas encore été précisé quand ce nouvel environnement d’exécution sera généralisé, mais on présuppose que ça viendra avec la prochaine mise à jour majeure (donc pour la version 5).

Autre nouveauté avec une nouvelle version de WebView, l’API qui permet aux applications d’afficher du code HTML / CSSIntroducing Chromium-powered Android WebView. Jusqu’à présent, le code HTML encapsulé dans une application était affiché par le moteur de rendu du navigateur d’origine qui n’était pas optimisé. Avec cette nouvelle version de l’API WebView, c’est le moteur de rendu de Chromium qui est utilisé (la version open source de Chrome), celui qui exploite le fameux moteur javascript V8. Le bénéfice pour les développeurs est de pouvoir exploiter à son plein potentiel du code HTML / CSS / Javascript : KitKat’s WebView is powered by Chromium, enabling Android app developers to use new HTML5 and CSS features. Traduction : des web apps plus performantes, plus rapides, plus stables…

Dernière annonce avec le lancement de Portable Native Client, la technologie qui permet aux développeurs de compiler du code C ou C++ et de l’exécuter directement dans le navigateur sans perte de performance : Google launches Portable Native Client, lets developers compile their code to run on any hardware and website. Comme pour la nouvelle version de WebView, ceci n’est possible que grâce au remplacement du navigateur par défaut par Chrome. Les smartphones Android, vont donc pouvoir exécuter des applications “lourdes” au travers de Chrome, tout comme il est possible de le faire sur les ordinateurs grâce à NaCl (le grand frère de Portable NaCl). Là encore, c’est une avancée majeure, mais sur laquelle les équipes ne communiquent pas, car cela concerne des technologies un peu trop complexes à expliquer au grand public, notamment le fait que PNaCl permette de compiler en bytecode une application C++ pour qu’elle puisse indifféremment être exécutée sur un smartphone avec un processeur d’architecture ARM, x86 ou MIPS, et qu’il est même possible de le faire avec un autre navigateur que Chrome grâce à l’API Pepper.

Au final, cette version 4.4 d’Android amorce une refonte complète des environnements d’exécution des applications natives (en Java ou en C/C++) , des applications mobiles HTML5, et donc des applications hybrides. Pour le moment il est encore tôt pour bien mesurer l’impact de ces changements sur l’expérience utilisateur, les performances ou l’autonomie, mais dans tous les cas de figure, ça sera forcément bénéfique.

Apprenez les gestes qui sauvent sur vos ordinateurs, smartphones et tablettes

J’ai déjà eu de multiples occasions de vous parler des vidéos interactives. Depuis la généralisation des navigateurs web modernes, les vidéos sont d’autant plus simples à exploiter qu’elles peuvent être lues nativement avec les players vidéo en HTML5. Je suis récemment tombé sur une vidéo particulièrement intéressante, car elle intègre des éléments d’interactivité pour vous apprendre les premiers gestes à apporter à un blessé.

La vidéo, éditée par l’association St John Ambulance, commence de façon très traditionnelle avec une histoire de petit garçon qui tombe d’un arbre :

La vidéo vous incite à vous rendre sur le mini-site Save the Boy pour en savoir plus. Ce site est plutôt sobre, mais propose une vidéo interactive en HTML5 pour pouvoir être lu sur un smartphone ou une tablette. Cerise sur le gâteau, les éléments d’interactivité sont justement conçus pour les terminaux mobiles avec des zones d’interaction bien larges pour nos gros doigts, et des gestuelles simples pour favoriser la mémorisation.

Exemple de vidéo interactive compatible avec les terminaux mobiles
Exemple de vidéo interactive compatible avec les terminaux mobiles

Les premiers gestes sont ainsi décomposés en différentes étapes et l’utilisateur est amené à reproduire les gestes sur l’écran (dégager les voies respiratoires, placer la victime en PLS…). L’ensemble est réaliste, sobre et parfaitement bien réalisé. Un bel exemple de dispositif multi-canal bien pensé et surtout en phase avec son temps.

Notez que ce site n’est pas le premier à proposer des vidéos interactives ni à intégrer une vidéo nativement dans une page. Si vous cherchez un exemple particulièrement impressionnant dans ce domaine, je vous recommande la visite de HotelStyle, un superbe site mélangeant textes, photos et vidéos, le tout dans une interface compatible avec les terminaux mobiles.

(via Fast Company)

Google et Mozilla cherchent-ils à tuer les plugins ?

Depuis l’arrivée de Google sur le marché des navigateurs et la course à la performance des machines virtuelles javascript, les technologies reposant sur des plugins se font beaucoup plus discrètes. Dans l’absolu, nous ne pouvons que nous féliciter de la disparition progressive de technologies propriétaires dans nos navigateurs (Flash, Silverlight, Java…) au profit de technologies standards (javascript, WebGL…). Mais dans la pratique, ce n’est pas si simple, car il n’y a pas de bonnes ou mauvaises technologies. Nous avons cependant pu constater ces dernières années une authentique chasse aux sorcières contre Flash, menée de main de maître par Apple. Une manoeuvre logique dans la mesure où ce plugin représentait un danger pour l’intégrité de son écosystème si fermé. Vous noterez cependant que ce n’est pour autant qu’ils ont cherché à faire disparaître ou évoluer Quicktime, autre plugin et technologie propriétaire, mais c’est un autre débat…

Bref, tout ça pour dire que, à un jour d’intervalle, Google et Mozilla viennent d’annoncer l’abandon prochain d’une brique essentielle pour les pluginsGoogle looks to drop Netscape Plugin API support in Chrome, starting with blocking most plugins in January 2014 et Plugin Activation in Firefox. Pour vous la faire simple, le Netscape Plugin Application Programming Interface est la brique logicielle permettant aux plugins de dialoguer avec les couches basses du système. Le problème est que cette brique a été conçue il y très longtemps et que les éditeurs de navigateurs aimeraient s’en passer.

Un certain nombre de plugins seront touchés par cette restriction, mais rassurez-vous, le Flash Player et le PDF Viewer n’utilisent pas NPAI, ils ne seront donc pas affectés. Parmi tous les plugins l’exploitant, les équipes de Google ont identifié 6 plugins utilisés le mois dernier par plus de 5% des utilisateurs : Silverlight, Unity, Google Earth, Java, Google Talk et Facebook Video. L’argument avancé par Google est tout à fait légitime (pourquoi continuer à supporter une API datant du siècle dernier), mais je ne peux m’empêcher de penser qu’il s’agit plutôt d’un message fort envoyé aux éditeurs de plugins : “Vous êtes sur mes terres, alors pliez-vous à mes règles. Il n’aura échappé à personne que Google ne gagne rien à accepter la prolifération des plugins venant se greffer sur son navigateur. D’autant plus que les équipes ont fait des progrès décisifs sur NaCl, l’environnement d’exécution “maison” : Google’s Bet On Native Client Brings Chrome And Google+ Photos Closer Together.

De même, Mozilla n’a pas grand-chose à gagner à laisser des éditeurs tiers greffer leur technologie sur Firefox. Hasard du calendrier, ils ont également annoncé la semaine dernière la disponibilité d’une version HTML5 du Flash Player : Shumway, Mozilla’s HTML5-Based Flash Player Replacement, Lands In Firefox Nightly. Pour mémoire, ce projet de réécriture avait été initié il y a presque 7 ans (Vers un flash player en open source pour la fondation Mozilla ?). Autant les équipes de Google s’essayent à des technologies propriétaires, autant la fondation Mozilla mise tout sur javascript, et ils le font visiblement avec brio : Surprise! Mozilla can produce near-native performance on the Web. Mozilla est-il en train de réinventer la roue ? Non, ils sont simplement en train d’accomplir leur mission : oeuvrer pour un web plus ouvert.

Peut-on en conclure que la fin des plugins est programmée ? Non, et ce n’est pas l’objectif. Je pense ne pas me tromper en disant que les technologies propriétaires des années 2000 se sont développées en profitant de l’immobilisme du W3C qui n’a pas su faire évoluer HTML suffisamment rapidement. Les choses ont maintenant changé et les éditeurs de navigateurs web essayent simplement de remettre de l’ordre dans cette pagaille en limitant le nombre et l’usage de technologies propriétaires.

Dans l’absolu, les plugins ne sont pas un problème, à partir du moment où leur utilité est restreinte à un domaine d’application bien précis : l’animation vectorielle pour Flash, la vidéo pour Quicktime, les jeux 3D pour Unity. Mais il ne faut pas jeter le bébé avec l’eau du bain, n’oubliez pas que les plugins ne sont que la partie visible de l’iceberg : Adobe n’a jamais gagné de l’argent avec le Flash Player, tout comme Unity ne gagne rien avec son Unity Web Player. Par contre, ces éditeurs se rémunèrent sur les environnements de développement qui, eux, proposent une réelle valeur ajoutée. Ce n’est ainsi pas un hasard si Google vient de lancer son propre outil de développement : Google launches public beta of Web Designer, a free design tool for creating HTML5 ads and campaigns. Le but de la manoeuvre pour Google est de se positionner plus en amont sur la chaîne de valeur et de dégager les intermédiaires. Jusqu’à présent, les belles bannières animées qui pullulent sur le web étaient réalisées en Flash, mais avec ce nouvel outil, Google tente de proposer un service intégré de bout en bout : de la création (Web Designer), à la distribution (DoubleClick), à mesure de la performance (Google Analytics).

Dans le cas particulier de Unity, la valeur ajoutée ne provient pas des capacités du player à afficher le plus grand nombre de polygones, mais dans la simplicité et la sophistication de l’environnement de développement. Si je suis admiratif devant la fluidité d’un HexGL, force est de constater que le développement d’un jeu multiplateforme sous Unity est beaucoup plus rapide, surtout si vous souhaitez le distribuer sur les terminaux mobiles (avez-vous essayé Superhot ?). D’où mon assertion du début d’article : il n’y a pas de bonnes ou mauvaises technologies. Certes, Unity est un éditeur privé qui vend des licences, mais du moment que leur technologie, même propriétaire, vous permet de concevoir / réaliser / déployer une application ou un jeu en ligne plus facilement et rapidement, pourquoi s’en priver ? Ceci justifie mon ambivalence autour des standards du web ET des technologies propriétaires comme Flash ou Unity. Et je pense ne pas être le seul (cf. Occupy HTML).

Conclusion : inutile d’annoncer la mort des plugins, car ce n’est pas demain la veille. La très grande majorité des internautes ne s’intéresse pas à ce débat sur les standards web, tout ce qui l’intéresse, c’est d’avoir accès à des contenus et services de qualité. Et les éditeurs de navigateur ne se risqueront pas à donner l’impression à leurs utilisateurs qu’ils sont bridés (il n’y a qu’Apple pour faire ça). Mais il est par contre tout à fait légitime que ces derniers cherchent à optimiser leur code source, notamment en faisant un petit nettoyage. Et c’est le but de cette opération, ni plus, ni moins.