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.