Étiquette : rda

Etat de l’art des interfaces riches

Voilà plus de 6 ans que je parle des interfaces riches sur ce blog (en fait depuis la première année). Au cours de cette période, il s’est passé beaucoup de choses et les usages se sont fortement diversifiés et intensifiés. Je souhaiterais aujourd’hui faire un tour d’horizon des interfaces riches pour plusieurs raisons :

  1. Parce que les interfaces riches existent depuis plus de 10 ans et sont indissociables de l’internet ;
  2. Parce qu’il y a toujours ce très désagréable débat de fond sur HTML5 qui va remplacer Flash (une belle ineptie : Pourquoi HTML5 et Flash ne peuvent être comparés) ;
  3. Parce que l’on en parle trop peu et que le sujet est néanmoins délicat à traiter ;
  4. Parce que je suis en train de finaliser une formation sur ce sujet : Interfaces riches, quelles opportunités pour votre marque ou votre activité.

Bref, j’ai envie de mettre les interfaces riches à l’honneur. Mais commençons par le commencement…

Définition et historique

Lancé en 1996 par Macromedia, Flash est la technologie la plus emblématique des interfaces riches. Cela fait donc 15 ans que les interfaces riches existent. Le terme “Rich Internet Application” est par contre plus jeune puisqu’il a été introduit pour la première fois en mars 2002 (on utilisait également les termes “client riche“, “client léger“, “client web“…).

Pour bien comprendre ce que sont les interfaces riches, intéressons-nous d’abord à ce qu’elles ne sont pas. Les interfaces pauvres désignent ainsi les pages web statiques composées de textes ou d’images. N’y voyez pas un quelconque jugement de valeur, des sociétés comme Amazon ou Ebay ont gagné des milliards de dollars avec des pages web composées exclusivement de textes, images, tableaux et formulaires.

Il est également important de ne pas opposer interfaces riches et pages HTML : les interfaces riches sont un complément du HTML, pas un substitut. Les interfaces riches sont ainsi des modules encapsulés dans des pages HTML. Donc dans tous les cas de figure, les interfaces riches ne remplacent pas le HTML, elles le complètent, l’enrichissent.

La définition communément admise est que ce sont des interfaces web qui proposent les mêmes fonctionnalités et la même expérience qu’une application traditionnelle, mais je trouve cette vision trop restrictive, car elle se limite à l’aspect applicatif. Nous en venons donc à ma définition : Les interfaces riches sont des interfaces web offrant plus de possibilités d’affichage et de manipulation que les pages web traditionnelles. Cette définition englobe donc des usages plus vastes dont le rich media. Mais cela n’empêche pas les éditeurs de solutions de présenter les interfaces riches comme une alternative très intéressante aux applications classiques.

Vous noterez également que ma définition ne mentionne pas explicitement les navigateurs web. Et pour cause, les interfaces riches se scindent en deux grandes familles :

  • Les Rich Internet Applications (RIA) qui sont exécutées dans le navigateur ;
  • Les Rich Desktop Application (RDA) qui sont lancées depuis le bureau.

Autant les RIAs restent confinées dans votre navigateur, autant les RDAs sont indépendantes de ce dernier et sont lancées depuis le menu “Démarrer” ou un raccourci. Elles se comportent donc comme des applications natives et ne sont pas installées sur le système d’exploitation mais sur une couche intermédiaire (la machine virtuelle). Cette différence entre RIA et RDA est subtile, mais peut parfois être confusante à l’image de logiciels qui peuvent être exécutés indifféremment dans votre navigateur ou sur votre bureau comme Balsamiq ou le Project Rome.

Il y a quelques années j’avais rédigé un article pour expliquer ces différences types d’interfaces riches: 10 ans d’évolution des interfaces web au service de l’expérience utilisateur. Même si certaines technologies ont disparu ou évolué, le schéma d’ensemble est toujours valide :

Comparaison des différents types d'interfaces riches

Nous en venons donc à la grande question : les interfaces riches sont-elles mieux que les interfaces pauvres ?

Pourquoi utiliser les interfaces riches ?

En fait la question de la supériorité des interfaces riches est subjective : mieux par rapport à quoi ? Comme avec toute technologie informatique, tout est une question de contexte et de contraintes. Les interfaces riches sont plus sophistiquées, mais plus lourdes qu’une page HTML. Elles sont plus puissantes, mais plus complexes. Elles sont plus performantes, mais plus risquées.

Il existe de nombreux avantages et inconvénients à utiliser les interfaces riches, mais nous pouvons néanmoins isoler 3 motivations principales :

  • Afficher des contenus multimédia (vidéos, musiques, animations…) ;
  • Offrir une expérience utilisateur plus sophistiquée ;
  • Proposer un outil de travail plus performant.

Autant il ya quelques années la question avait son importance, autant maintenant les interfaces riches sont partout, sous la forme de modules enrichis exploitant différentes technologies (javascript, Flash…). Les sites de commerce en ligne font ainsi un usage quasi-systématique des interfaces riches : Différentes interfaces riches pour différentes fonctions.

Les interfaces riches appliquées au commerce en ligne

La question à laquelle vous devez donc répondre est plus de savoir si telle interface ou tel module mérite un enrichissement en fonction du contexte (vos cibles, vos contraintes…). Il n’existe pas de méthode universelle pour savoir quand une interface riche est plus appropriée qu’une page HTML classique, encore une fois tout est question de contexte, il n’y a pas de bon ou mauvais choix.

Nous pouvons cependant isoler quatre grandes familles d’usages où les interfaces riches sont particulièrement bien adaptées :

Les quatre grandes familles d'usages des RIAs

Ce panorama des usages n’est pas forcément exhaustif, mais il dresse un tableau assez complet de ce pour quoi les interfaces riches sont conçues. Il vous est toujours possible de faire ce que vous voulez avec les RIAs (pourquoi pas un site textuel en Flash) mais il est toujours préférable de choisir la bonne technologie pour le bon usage. Ce qui me fait une parfaite transition avec la suite…

Quelles technologies pour quels usages ?

Le moins que l’on puisse dire est que les gros éditeurs sont particulièrement actifs pour promouvoir leurs technologies. Les grands acteurs ainsi présent sont les suivants :

  • Adobe avec Flash/Flex mais aussi AIR et l’OpenScreen Project ;
  • Microsoft avec Silverlight et WindowsClient (WPF et Windows Forms) ;
  • Google avec GWT, NaCl, O3D et différents sites d’évangélisation de javascript comme Chrome Experiments ou 20ThingsILearned ;
  • Sun, Oracle et IBM qui sont les grands promoteurs de Java et des technologies qui vont avec ;
  • Apple qui se fait très discret mais exploite son format Quicktime ainsi qu’un framework javascript (Gianduia) ;
  • Le W3C qui oeuvre à standardiser tout ça et à faire évoluer les spécifications au travers des ses groupes de travail.

Je ne rentrerais pas dans une explication laborieuse sur les intérêts croisés de ces différents éditeurs, mais je pense ne pas me tromper en disant que les enjeux sont de taille et qu’aucun des acteurs cités plus haut ne sont à considérer comme bienfaiteur ou néfaste (la réalité est plus contrastée).

Toujours est-il qu’il existe un sacré nombre de technologies et qu’il est parfois difficile de s’y retrouver. Je vous propose donc cette classification des différentes familles technologiques liées aux interfaces riches :

Les familles technologiques des interfaces riches

Deux précisions importantes : ce panorama n’est pas exhaustif ; il existe des subtilités qui empêchent le rattachement de certaines technologies à telle ou telle famille (notamment XUL, OpenLaszlo, NativeClient, XForms) mais j’ai fait le choix de la simplification pour ne pas compliquer le travail d’évangélisation. Si vous avez une meilleure classification, n’hésitez pas à la mentionner dans les commentaires.

Le choix d’une technologie par rapport à une autre est encore une fois question de contexte : en fonction des ressources disponibles, de l’historique du projet et de son héritage, des contraintes, du budget et des délais… Il existe une infinité de critères, mais souvenez-vous qu’il n’y a pas de mauvais choix, juste des compromis.

Les nouveaux facteurs à prendre en compte

Autant il y a trois ans le choix se résumait à choisir entre Flash et Ajax, autant la situation est nettement plus compliquée aujourd’hui. Et ceci pour plusieurs raisons :

  • Les navigateurs récents sont de plus en plus performants (Chrome, Opera et Firefox se battent à coup de benchmarks) et permettent aux interfaces riches et applications réalisées en javascript de rivaliser avec les RIAs plus “lourdes” (réalisées en Flash, Silverlight…) en terme de stabilité et de rapidité d’exécution. De même, le W3C et les industriels du web (Google, Apple…) ont fait de gros efforts pour promouvoir HTML5 ainsi que CSS3 et inciter les éditeurs à mieux exploiter les opportunités offertes (cf. CSS3 et javascript seront-elles les technologies RIA du future ?). Les technologies standards du web rentrent maintenant en concurrence avec les technologies propriétaires pour la réalisation d’enrichissements de premier niveau (transitions, petites animations, effets graphiques…). Et ne pensez pas qu’Internet Explorer va se laisser facilement distancer par ses concurrents, car Microsoft s’apprête à lancer IE9 qui devrait leur permettre de rattraper une bonne partie de leur retard (avec notamment un bien meilleur support de HTML5 et CSS3).
  • Les smartphones et terminaux alternatifs prennent une place toujours plus importante dans nos usages quotidiens et notre consommation des services et contenus en ligne (cf. 2011, l’année du point de bascule). Il convient donc d’intégrer cette contrainte dans votre choix dès le départ et de réfléchir aux meilleurs moyens d’exploiter les opportunités offertes par ces terminaux.
  • Une très grosse bataille est en cours sur les codecs utilisés pour diffuser de la vidéo avec HTML5. Ce point rejoint les deux précédents, ou plutôt cristallise les tensions liées à l’exploitation de la vidéo en ligne (énorme marché) sur les terminaux alternatifs (smartphones, tablettes, TV connectées…). En fait, les enjeux de cet affrontement sont tellement importants que ce sujet mérite d’être isolé.

Rajouter à cela les contraintes d’accessibilité, de référencement, d’utilisabilité, de ROI, de performances, de disponibilité des ressources… et vous aurez un contexte extrêmement complexe à maitriser. Est-ce une mauvaise nouvelle ? Non pas du tout, car si ce sujet est aussi complexe, c’est qu’il est au coeur de l’internet et du quotidien des utilisateurs. En d’autres termes : Bien appréhender les enjeux liés aux interfaces riches conditionne le succès de votre présence sur le web.

Native Client, la technologie RIA de Google qui risque de faire long feu

La sortie de Native Client, une technologie encore expérimentale du Google Labs, est passée complètement inaperçue à quelques rares billets près. Le problème n’est pas que les blogueurs soient peu inspirés par cette nouvelle, mais plutôt que ce produit a tellement été mal présenté au public que personne ne sait trop à quoi ça va servir. Pour information il m’a fallu près de deux semaines de cogitation avant d’attaquer la rédaction de ce billet.

Pas réellement un concurrent de Flash ou de AIR

Force est de constater que ce nouveau produit est plutôt obscur, que les explications sont rares et que même les équipes à l’origine de ce projet sont incapables de fournir une explication claire (cf. Native Client: An OS in Your Browser). Pour faire simple, Native Client est une extension que vous installez sur votre ordinateur pour pouvoir exécuter au travers de votre navigateur des applications en ligne écrites en code natif (C ou C++). Si vous avez le courage vous pouvez toujours lire l’annonce officielle mais vous n’y apprendrez pas grand chose de plus : Native Client, A Technology for Running Native Code on the Web.

Ne vous y trompez pas, même s’il est beaucoup question de RIA, NaCl n’est ni un plugin à la Flash ou Silverlight, ni un runtime à la AIR. Ce n’est pas non plus une technologie qui exploite une machine virtuelle à la JavaFX et pour finir c’est encore moins un mini-système d’exploitation. En fait c’est un peu tout ça à la fois (bien que pas tout à fait). Lire à ce sujet : Why Google Native Client is not a Flash competitor.

En tout cas le moins que l’on puisse dire c’est que Native Client laisse un certain nombre d’observateurs avertis très sceptiques : Google Native Client: A Game Changer or an Also-Ran? et Google Native Client: web deluxe, or ActiveX redux?.

Avec Native Client ne gaspillez plus la ressource de votre processeur

Pour bien comprendre tout l’intérêt de Native Client (NaCl pour les intimes), il faut se pencher sur l’architecture des ordinateurs et surtout sur le fonctionnement des plug-in. Pour faire simple un ordinateur est composé de couches matérielles (la carte mère, le processeur, la carte graphique…) et de couches logiciels (le système d’exploitation, les applications…). Quand vous consultez une interface riche en Flash, celle-ci repose sur du code qui est interprété par le plug-in, par le navigateur, par le système d’exploitation et finalement par le processeur. Ce dernier traite l’instruction et remonte un résultat dans l’autre sens. Toutes ces couches sont autant d’intermédiaires qui traduisent, interprêtent et ne font que vous gaspiller de la ressource (mémoire et puissance de calcul). Voilà pourquoi les animations 3D exécutées dans Flash vous paraissent minables comparé à ce que votre carte graphique est capable de faire.

Avec Native Client, la promesse est de ne plus gaspiller cette ressource en évitant les intermédiaires (les différentes couches logicielles) et de faire en sorte que les applications en ligne exécutées dans votre navigateur ne soient que 1% moins lentes que celles qui sont installées sur le système d’exploitation. Lire à ce sujet l’excellent mais très technique article de Samy : Avec Native Client, Google invente l’OS dans le navigateur.

Si la promesse est belle (des performances sans commune mesure) et l’exploit technologie réel, il y a une contre-partie : les applications en ligne doivent être développées en C ou C++. Et c’est là où ça coince : le C et le C++ sont des langages de programmation contraignants qui ne sont pas réellement adaptés aux interfaces riches. Il existe maintenant de nouveaux langages beaucoup plus sophistiqués qui se sont imposés sur ce créneau avec des environnement de développement dédiés beaucoup plus productifs (à l’image d’Eclipse ou de Flex Builder). Donc concrètement pour bénéficier des performances de NaCl il faut revenir 20 ans en arrière et se réapproprier des langages qui font dramatiquement chuter la productivité. En clair il va vous falloir beaucoup plus de temps pour développer la même application. Tout ça pour quoi ? Pour de  meilleures performances, mais est-ce que la performance est réellement un problème ?

PS : Ceci est une tentative naïve de l’auteur d’expliquer de façon simple le fonctionnement des ordinateurs pour pouvoir mieux comprendre la prise de position sur NaCl. Les premières versions de cette explication étaient approximatives et ont engendrés des commentaires très aggréssifs qui ont polués la discussion avec un débat de forme (“le C n’est pas mort et il est plus performant que Java”) au détriment d’une discussion de fond (NaCl est une belle avancée technologique mais qui ne trouvera pas forcément son public dans la mesure où les usages de l’outil informatique sont amenés à beaucoup changés dans les prochaine années, notamment avec les approches centrées sur la collaboration de l’Entreprise 2.0).

Le faux débat de la performance

Oui, la performance est importante, car il en faut pour faire tourner dans votre navigateur des applications équivalentes à ce que vous avez sur votre disque dur. Mais d’un autre côté est-ce que c’est un but légitime ? Traduction : Quel est l’intérêt de faire tourner Word 2007 dans votre navigateur quand un wiki peut vous apporter un bien meilleur service ? Quel est l’intérêt de faire tourner un mastodonte comme Photoshop dans votre navigateur alors que dans 90% des cas vous pouvez vous suffir de Photoshop Express ou de Picnick ?

Nous entrons ici dans la partie délicate de la discussion autour de NaCl, la partie où l’on va se rendre compte que cette technologie est surtout révolutionnaire pour les éditeurs de logiciels, pas pour les concepteurs d’interfaces riches. L’industrie du logiciel est en effet en train de se scinder en deux clans : d’un côté les applications lourdes (Photoshop, 3DSMax…) qui sont avant tout destinées à un petit nombre de professionnels spécialisés dans un domaine et nécessitant beaucoup de ressources (mémoire, puissance de calcul, capacité de stockage…), de l’autre des applications plus légères (SalesForce, Basecamp…) qui sont avant tout orientées collaboration et qui consomment très peu de ressources. Le modèle SaaS est donc parfaitement adapté à la seconde catégorie avec des technologies parfaitement maîtrisées (HTML + Javascript, Flash…) qui ne posent pas de problème de performance.

Vous pourriez me dire que le débat sur la performance est revenu sur le devant de la scène avec la mode des ordinateurs low cost (les EeePC et autres netbooks) qui ne disposent pas du tout de la même puissance de calcul. Pour ce segment bien particulier il serait intéressant de voir s’il est rentable d’adapter des applications desktop existantes pour les reformater aux contraintes de ces ordinateurs (petit écran…). Mais encore une fois la solution se trouve plutôt dans une nouvelle approche de l’outil informatique (avec les intranets wikifiés et les mashups d’entreprise) plutôt que dans l’exploit technique de faire tourner Office 2007 et Vista sur un EeePC.

Ceci est d’autant plus vrai que les dernières versions de navigateurs comme Firefox, Opera ou Chrome ont fait un bond spectaculaire et ont réussi à décupler les performances d’exécution de code Javascript. Et comme une bonne nouvelle ne vient jamais seule, les plug-in progressent aussi à pas de géant puisque Flash 11 et Silverlight 3 devront également marquer une nette rupture de performance avec une prise en charge beaucoup plus poussée de l’accélération matériel, donc un recours plus intensif aux composants hardware (notamment la carte graphique) et moins de gaspillage de mémoire. Ca ne vous rappelle rien ? Bref, toutes ces améliorations à venir nous font relativiser le gain de performance annoncé par NaCl. Mais bon… l’idée n’est pas neuve car Microsoft avait tenté d’introduire une technologie équivalente avec les fameux ActvieX (cf. Google Native Client : Un ActiveX-Like ?) et n’oublions pas non plus que le javascript a ses limites (cf. L’invasion des machines virtuelles).

Donc au final NaCl doit être avant tout considéré comme un environnement d’exécution et de déploiement révolutionnaire car il permet aux éditeurs de ne développer qu’une seule version de leurs applications et de les distribuer via le web (en évitant les circuits de distribution classique avec boîtes et DVD). Vous noterez au passage que cette solution n’a été rendu viable que depuis l’adoption d’une architecture commune (x86) par les constructeurs et éditeurs de système d’exploitation (Microsoft / Windows, Apple / Mac OSX, Linux). Pour en savoir plus sur le potentiel de NaCl dans ce domaine je vous recommande cet article de Louis Naugès : Web 2.0, Lla marginalisation, définitive, de Windows sur les PC.

C’est quoi déjà une interface riche ?

Mais revenons à nos moutons : les interfaces riches. Dans la vision de Google, les interfaces riches sont avant tout destinées à être exploitées dans le cadre d’applications en ligne. Mais cette vision est très réductrice car que fait-on des innombrables interfaces riches qui reposent sur de la vidéo, des animations, du son, des transitions et autres effets spéciaux ?

Même si Native Client intègre un moteur de rendu vectoriel, Flash (et dans une certaine mesure Silverlight) reste la technologie la plus appropriée et de très loin pour faire ce type d’interface. Est-ce que vous vous imaginez faire un carrousel, un configurateur ou un assistant au choix en C ou C++ ? Non bien évidement car ce n’est pas pour cela que ces langages ont été conçus. L’avantage de Flash est d’autant plus net qu’il est couplé avec un environnement de production parfaitement adapté à ce type d’interface ainsi qu’une infinité de bibliothèques prêtes à l’emploi pour gagner du temps. Vous noterez que l’approche de Google centrée sur les applications en ligne se vérifie également avec d’autres produits comme GWT, un framework Ajax qui est exclusivement tourné vers une logique applicative.

Bref, ce n’est pas demain que nous allons voir des studios de production comme 2advanced, Blitz, Megalos ou Soleil Noir abandonner Flash pour faire du C. Ces studios sont capables de faire des prouesses que le C n’autorise pas.

Conclusion

Si nous résumons :

  • NaCl n’est pas un plug-in, c’est un projet encore expérimental qui n’est même pas en phase alpha ;
  • NaCl n’est pas un mini-système d’exploitation, c’est un complément qui permet de court-circuiter des intermédiaires pour profiter des pleines performances du matériel ;
  • NaCl n’est pas concurrent de Flash ou Silverlight qui sont bien plus performants pour faire de belles interfaces riches ;
  • NaCl dépend de langages de programmation (C et C++) qui sont plus plus performant mais plus contraignant ;
  • NaCl propose une approche tout à fait intéressante de la distribution de logiciels, mais les gros éditeurs disposent de leviers très puissants (accords cadres, partenariats, lobbying…) pour défendre leur modèle de distribution (et je ne parle pas que de Microsoft).

Voilà pourquoi NaCl va très certainement chambouler la longue traîne de l’industrie logiciel bien que cette technologie ne soit en l’état pas viable pour survivre sur le marché des RIA. Marché déjà bien encombré avec Flash, Silverlight, JavaFX ou des acteurs de niche comme Curl ou Unity3D (respectivement pour des applications en ligne d’entreprise et pour des jeux en 3D comme Cmune).

Reste donc deux possibilités : Soit Google fait fortement évoluer son produit pour le rendre réellement attractif (en expliquant clairement ce à quoi il sert et ce qu’il n’est pas), soit NaCl restera une expérimentation intéressante mais qui sera confinée à un usage interne chez Google.

Adobe MAX08 : Jour 2

Nette amélioration de la situation à Milan avec un beau soleil et des transports à nouveau fonctionnels. Deuxième journée de conférence avec de très intéressantes sessions.

General Session

benforta

Ambiance Men in Black pour une démonstration de Flash et Photoshop CS4 :

  • Prise en charge avancée de MXML ;
  • Insertion d’une “structure osseuse” à un objet pour pouvoir l’animer et le déformer (avec des os et des articulations) ;
  • Déformation intelligente des images en exploitant les zones creuses sans compresser les sujets principaux ;
  • Application de textures et motifs aux objets 3D.

Nouvelle démonstration de Flash Catalyst avec une description encore plus fine des composants d’une interface (barres de défilement, différents états…) et plus de richesse dans les comportements (déformations, rotations 3D…).

Inévitable revue de code avec les nouveautés du futur Flex Builder :

  • Possibilité d’interpréter du code C ou C++ dans Flash avec AS3 ;
  • Prise en charge de nouveaux formats comme RAW et PDF dans Flash ;
  • Démonstration d’un émulateur en C d’un console Nintendo avec AIR (ça sert à rien mais c’est toujours sympa).

Amélioration des capacités de référencement des contenus Flash et Flex avec l’élaboration conjointe par Google et Adobe d’un virtual user qui sait bien mieux discerner les textes, boutons, liens…

Démonstration des nouvelles fonctions de dynamic streaming de Flash Video (pour s’aligner sur ce que propose Microsoft avec Silverlight) et du live streaming (avec possibilité de jouer avec la timeline pour passer du flux live à l’enregistrement).

Nouvelle stratégie communautaire sur groups.adobe.com (un réseau social dédié aux utilisateurs de produits Adobe) avec les classiques profils, groupes, événements… prise en charge de nombreuses langues (internationalisation de l’interface prévue pour 2009).

Interviews avec Andrew Shorten et Ryan Stewart

J’ai eu la chance de pouvoir interviewer deux évangélistes de renom chez Adobe (Andrew Shorten et Ryan Stewart).

Concernant la multiplication des logiciels, scinder l’offre leur permet de mieux répondre aux attentes des différentes populations, voilà pourquoi nous sommes passer de Flash à Flash Pro + Flex Builder + Flash Catalyst.

Il existe chez Adobe un groupe de travail sur les workflows pour pouvoir mieux comprendre les contraintes “métier” des agences.

Concernant Flash 10 et la 3D, la dernière version du Flash Player utilise déjà l’accélération matériel pour les fonctions vidéos et pour le pixel bender (ce n’est le processeur mais la carte graphique qui est sollicitée). Il va donc falloir s’attendre à des effets graphiques encore plus spectaculaires dans le futur Flash 11.

Le casual gaming est un secteur particulièrement porteur où Flash est en position ultra-dominante, les équipes d’Adobe y porte une attention toute particulière pour ne pas perdre l’héritage de Shockwave (un des plus anciens portails).

Architecture 4.0

architecture4

Hervé Crespel, directeur de l’innovation chez Orange, sur les architectures de quatrième génération :

  • Les générations accompagnent des changements technologiques majeurs (interfaces textuelles, Client/Serveur, Web) ;
  • Les piliers des architectures de quatrième génération = Interfaces riches, comportements et interactions déportés sur le poste client, gestion de la collaboration et de la synchronisation, API & mashup, data-on-the-cloud…) ;
  • Les interfaces riches ne sont pas nouvelles (un service comme le one screen reservation de iHotelier existe depuis 2001) ;
  • Cette architecture n’est pas sans problème (gestion du cache, du mode déconnecté, des conflits lors de l’édition simultanée) ;
  • Évolution du modèle IHM (interface homme-machine) vers un modèle IHS (interface homme-service) ;
  • Le challenge du futur sera de construire des applications en ligne viables avec des composants partagés et remplaçables.

Wireframing experience et applications

wireframing

Enfin une session entièrement dédiée aux aspects prototypage et documentation :

  • Le gros problème avec les outils de prototypage actuellement utilisés (Visio, PPT) est qu’ils produisent des livrables sur lesquels il n’est pas possible de capitaliser ;
  • Flash Catalyst introduit la notion de Freeform UI sketching en piochant dans le catalogue de composants graphiques de Flex ;
  • Possibilité de partager des composants entre les différents écrans du prototype ;
  • Les custom components fonctionnent comme des modules indépendants qui peuvent être utilisés dans différentes pages / états ;
  • Les action sequences sont idéales pour les animations et autres comportements exotiques ;
  • Possibilité de rajouter des conditions dans le code source pour enrichir encore plus le comportement des modules ;
  • Le processus de substitution d’un élément d’interface brut par un élément designé (sous Photoshop ou Illustrator) a été facilité.

MAX Awards

Michelle Turner et Ted Patrick pour révéler la liste des gagnants :

Sneaks Peek

Très intéressante session où ont été présentés une dizaine de projet expérimentaux (dont seul une petite partie risque de se concrétiser) :

sneakspeek

Dans la catégorie Client :

  • RTMFP Application-level Multicast in Flash Player, qui permet de faire dialoguer deux Flash player en mode P2P ;
  • Nitro, un environnement de conception / création / distribution de widgets multi-supports ;
  • Durango, un outil de création de mashup qui repose sur AIR.

Dans la catégorie Services :

  • Connecting Live Cycle and Creative Suite, un espace de collaboration entre les équipes de production vidéo et le commanditaire ;
  • Meer Meer, un service de test multi browser / OS très impressionnant qui permet de faire de l’affichage comparatif de plusieurs versions côte à côte et même superposées (le rêve des intégrateurs HTML) ;
  • Server-Side Action Script Server, la possibilité de faite tourner du code AS sur le serveur (visiblement ça a beaucoup plu aux développeurs présents dans la salle…).

Dans la catégorie Tools :

  • Content Intelligence Toolkit, un outil de création de meta-données sur des contenus vidéos avec reconnaissance de formes, de visages et même transcription de la bande son (très impressionnant) ;
  • Image Compositing, un outils de composition d’images avec une intégration très puissante d’éléments graphiques dans une scène déjà existante (détourage automatisé, gestion de la luminosité et des ombres…), idéal pour faire du scrapbooking sans que ça y ressemble ;
  • Dreamweaver’s Support for Web Widgets, une extension pour… gérer les widgets web dans Dreamweaver ;
  • Infinite Images, un outils de création de scènes 3D en compilant un certain nombre d’image et offrant la possibilité de naviguer au sein de cette scène (assez proche de Photosynth) avec un gros potentiel artistique car il est possible de définir des évènements pour substituer une image par une autre et ne jamais passer deux fois au même endroit.

Plein de belles démos et une salle enthousiasmée par ces prototypes.

A demain pour la suite.

L’avenir du desktop réside-t-il dans le browser ?

En voilà une bonne question a laquelle tente de répondre Nova Spivack dans cet excellent article : The Future of the Desktop. Son propos est équivoque et il anticipe ainsi une évolution à moyen terme (2 ans) de nos outils de travail vers un nouveau modèle de Webtop.

Web browser + Desktop = Webtop

Selon l’auteur (et je partage son avis) les récents progrès et innovations techniques vont complètement bouleverser les architectures actuellement exploitées par les utilisateurs lambda (OS + applications + disque dur) pour les amener à complètement revoir la façon dont ils vont stocker et exploiter les données et applications (Weptop + SaaS + Data on the Cloud).

Voici une petite synthèse de l’article :

  • Les tentatives de portage d’application desktop vers des applications en ligne sont vouées à l’échec. Les seules applications en ligne viables sont celles qui savent exploiter les spécificité de l’internet (légèreté, accès unifié, édition simultanée de documents, gestion de l’historique…).
  • Nous passons progressivement d’une gestion spatiale de l’information (stockée dans des fichiers, répertoires, serveurs…) à une gestion temporelle de l’information (répartie sur des timeline, diffusée par des newsfeed / lifestream…).
  • Le problème n’est plus de trouver l’information, mais de gérer la surinformation (infobésité). Nous passerons donc moins de temps à chercher de l’information (Google fait ça très bien) et plus de temps à la filtrer. L’objectif finale étant d’améliorer notre productivité par une meilleur gestion de notre attention.
  • La logique de documents et de fichiers sera remplacée par celle de données partagées au sein de wikis. Ce format de stockage, d’exploitation et de partage présente ainsi le très grand avantage de résoudre les conflits de versions, de synchronisation…
  • Les données devront être formatées dans des standards ouverts pour favoriser l’adoption massive de solutions de SaaS et de Data on the Cloud afin d’éviter les problématiques de verrouillage grâce à des formats propriétaires (dont l’industrie du logiciel est la spécialiste).
  • Avec l’avènement des applications et des espaces de collaboration en ligne, nous ne lancerons plus notre browser depuis notre desktop mais notre desktop (dans le sens espace de travail) depuis notre browser.

Tout ceci vous semble sur-réaliste ? Réfléchissez-y à nouveau car lorsque l’on regarde de plus près des initiatives comme AppExchange, ContactOffice, Zoho ou encore Live Mesh, on est en droit de se dire que tous les éléments sont déjà en place.

Vers un Smart Webtop

Poursuivant sur sa lancée, l’auteur nous propose également quelques pistes de réflexion sur les fonctionnalités avancées que pourrait proposer le webtop du futur :

  • Des agents intelligents seront là pour structurer vos données en tâche de fond avec un travail horizontal (associant ainsi des données entre elles en fonction de leur signification ou du contexte).
  • Peu importe la puissance de l’ordinateur que vous utiliserez, les traitements seront de toute façon réalisés par des data centers. Votre puissance de calcul sera ainsi adapté à vos besoins. Vous serez donc facturé en fonction de ce que vous aurez “consommé”. Nous nous rapprochons donc d’un concept de Personal Cloud Computing.
  • Vous aurez la possibilité de dialoguer avec votre webtop pour lui faire exécuter des tâches à faible valeur ajoutée (“trouve-moi les fichiers rédigés par telle personne et publié entre telle et telle date“, “liste-moi toutes les conversations avec telle personne sur tel sujet“…). Les requêtes pourront être formulées par écrit en langage naturel ou via un système de reconnaissance vocale.

Ouf, que d’imagination ! Là nous ne sommes plus réellement dans une optique à moyens termes, mais quand je vois des initiatives comme Aurora je me dis que le futur n’est peut-être pas si loin ! En tout cas ils y travaillent.

Toujours est-il que j’abonde complètement dans le sens de l’auteur qui fait preuve d’une grande clairvoyance et d’une vision tout à fait intéressante de la convergence entre desktop et browser.

Adobe AIR officiellement lancé

Ce matin Adobe vient de lancer officiellement AIR dans sa version 1.

on_adobe_air_logo

 

Pour faire court, AIR est un acronyme pour “Adobe Integrated Runtime“, il s’agit donc d’un programme que vous installez sur votre ordinateur pour faire tourner d’autres programmes. L’équivalent de la machine virtuelle du monde Java sauf qu’ici les applications reposent sur les technologies d’Adobe.

C’est à mon sens un grand pas dans la banalisation des applications connectées (autrement appelées Rich Desktop Applications) et dans l’évolution des habitudes de consommation des services en ligne (cf. 10 ans d’évolution des interfaces web au service de l’expérience utilisateur).

Le site dédié à AIR regorge d’exemples d’applications possibles, mais sachez qu’il existe aussi d’autres technologies permettant de faire sensiblement la même chose. Exemples avec des applications pour la FNAC (Bientôt une RDA pour la FNAC ?) ou encore pour Otto (Otto-Store, le rich media futur du e-commerce ?).

Plus d’infos sur le blog officiel : Its On – Flex 3.0 and Adobe AIR 1.0 Are Here! et sur cet article un peu plus fourni : Adobe AIR v1.0 & Flex 3.0 Released; New Adobe Open Source Site Launched.

(via Mike Chambers)