J’ai décidé de me rendre à Amsterdam pour entendre le discours des “guru’s” Ajax. En l’occurrence, je suis servi. Les deux intervenants principaux sont :

• Jesse James Garett d’Adaptive Path (inventeur du terme Ajax)
• et Bill Scott qui est Ajax Evangelist chez Yahoo

Il est amusant de noter que c’est un workshop très technique pourtant sur 30 participants, environ 20 sont designers. Cela s’explique probablement par le fait que le workshop précède le SIG-CHI.

Voilà une petite synthèse de ce qui c’est dit.

Jesse James Garett – Designing and building Ajax aplications

La première partie de la présentation s’attache à démontrer les aspects industriels d’Ajax. Jesse insiste sur le fait que Javascript n’est plus jouet mais un langage mature. Il rappelle également que Xml est devenu en quelques années une technologie clé pour l’échange de données. Bref Ajax repose sur des technologies solides et pérennes. L’une des raisons qui lui permette d’affirmer cela est que, pour lui, la guerre des navigateurs est terminée. Il n’a pas tort mais la guerre des plugins (Flash versus WPF/E) va commencer !

Le reste de sa présentation vise à expliquer comment bien designer une application Ajax. Il rappelle que

“Ajax makes design problems technology problems, and vice versa.”

Jesse nous met en garde contre la difficulté de réussir à concevoir des applications Ajax qui seront facilement comprises et adoptées par les utilisateurs. Ajax amène de nouvelles fonctionnalités dans les applications mais elles sont loin d’être toujours intuitives pour les utilisateurs finaux. Comment faire percevoir aux utilisateurs que telles zones de l’application est cliquable, que telle autre peut faire l’objet d’un drag’n drop ? La réponse qu’il apporte (et qui sera reprise et détaillée par Bill Scott) est “invitation” : changer le cursor d’apparence sur une zone clickable, faire un apparaître un tooltip pour indiquer à l’utilisateur qu’il peut éditer le texte placé sur le curseur, etc.

Jesse termine sa présentation en évoquant les cas où selon lui Flash est plus pertinent qu’Ajax. Il s’agit principalement des cas où l’application doit permettre la manipulation et la visualisation de données complexes. J’ajouterais à cela que Flash permet également de gérer nativement une webcam, un micro et la sauvegarde de données sur le poste de l’utilisateur bien utile pour d’éventuels modes offline (à ce sujet il est intéressant de noter que la première version des APIs de persistance du framework javascript dojo s’appuie sur Flash).

Bill Scott – DNA of Ajax Applications

Bill fait une excellente présentation sur les User Interfaces Pattern. Sa présentation est accessible sur son blog. Elle vaut le détour. Il y a deux principes à n’oublier sous aucun prétexte :

“Keep the goal in mind” et “Keep the user engaged”.

Une fois le décor planté, il est rentré dans des problématiques très techniques, notamment sur l’utilisation de Xml ou de Json dans les applications Ajax. Contrairement à Jesse, Bill est un promoteur de Json qu’il voit comme un moyen d’accélérer les temps de développement (pas besoin d’analyser la réponse contrairement au XML). Ce protocole est également plus rapide que XML car moins verbeux.
Puis il s’est attaché à démontrer qu’il est possible d’écrire du code javascript de façon propre pour gérer les événements qui surviennent sur une page web. Pour rester dans cette logique “industrielle”, il recommande bien sûr d’utiliser un framework javascript (son petit préféré est prototype), voir un framework hybride comme Atlas.

L’un des points marquants de la présentation de Bill est qu’il englobe dans Ajax toutes les technologies permettant au browser d’interagir dynamiquement avec le serveur. Bref, il engloble dans Ajax les interfaces homme machine qui s’appuie sur Flex/Flash. Il a d’ailleurs insisté à la fin de sa présentation sur la complémentarité entre l’Ajax (au sens classique) et Flash. Je suis heureux de voir que nous partageons la même vision sur l’intérêt de Flash (conf. supra). Je préfère tout de même utiliser le terme Application Internet Riche plutôt que de généraliser Ajax.

Bill fait un focus sur les nombreux problèmes soulevés par Ajax qui tiennent principalement au fait que :

Ajax application sates change, URL does not.

L’utilisation du “back button” dans une application Ajax est problématique. Bill rappelle qu’il est souvent confondu avec un “Undo” ! Il détaille plusieurs solutions possibles pour remédier à ce problème comme l’utilisation d’une ancre html qui évite le rechargement entier de la page ou encore le recours à des iframes. Il évoque une solution que je ne connaissais pas RSH – Really Simple History. C’est un projet qui a l’air intéressant.
Une autre difficulté des applications Ajax est le support des bookmarks. Il n’est plus possible de s’appuyer sur les mécanismes standards du navigateur. La solution est de gérer les bookmarks au niveau de l’application à l’instar de Google Maps qui génère une URL pour chaque position bookmarkée sur la carte. L’URL contient des paramètres qui permette de restaurer l’état de la carte.
Le dernier point qu’il mentionne est qui n’est pas des moindres est le support des différents navigateurs et OS du marché. La matrice pour le “Graded Browser Support@Yahoo!” vaut le détour !

Elle témoigne bien de l’ampleur du problème. Une seule conclusion : pour bâtir une solution pérenne et robuste, il faut absolument avoir recours à un framework Ajax !

Jesse James Garett – Documenting Ajax

La dernière session de la journée est consacrée à la “visual description of stateless interface”. Contrairement à ce que le titre laisse entendre, il ne s’agit pas de générer la documentation du code JavaScript mais d’écrire les spécifications de cette nouvelle génération d’interfaces.
Jesse part du constat que spécifier des interfaces riches en utilisant la technique classique des wireframes n’est plus pertinente puisque la navigation ne se fait plus de page en page mais à l’intérieur de la même page. Comment documenter l’ensemble des microstates, c’est-à-dire les changements qui interviennent dans une portion de la page ?

Les storyboards frame by frame sont un premier moyen de prototyper les microstates. C’est une représentation très inspirée de Flash. Elle montre les modifications (image par image) d’une partie de l’interface. L’inconvénient principal est qu’il n’est pas possible de se placer dans le context global de l’application. En d’autres termes, il est possible de montrer comment va se dérouler un drag’n drop sur une partie de l’interface mais pas de mettre en perspective cette séquence avec le reste de l’application. Ni d’ailleurs de montrer à quelle vitesse l’action va se dérouler.

La deuxième méthode proposée par Jesse est de recourir à des Lo-fi animations. Elles présentent l’avantage – justement – de prendre en compte la dimension temporelle. Elles permettent d’avoir un feeling sur l’interaction utilisateur. Mais il est difficile de récréer un drag’n drop ou d’autres formes d’interactions complexes sans recourir à des outils comme Flash ou Photoshop CS2. La maintenabilité de ce type de “document” me paraît un peu douteuse …

La troisième proposition de Jesse est d’adapter les wireframes. Il s’agit ici de montrer de manière statiques les modifications de chaque portion de page. Cette approche ne fonctionne que si une modification intervenant dans une portion de la page n’a pas d’impact sur les autres régions de la page. En d’autres termes, cela ne permet pas de montrer les interactions entre les microstates.

De mon point de vue, il existe une quatrième voie qui consisterait à réaliser des wireframes sous la forme d’applications Ajax ou Flex2. C’est d’ailleurs ce que nous faisons chez people in action .

Une derniere chose …

Dans les couloirs, j’ai eu de nombreux échanges avec des designers et des développeurs. J’ai également eu le chance de déjeuner avec Bill Scott. La majeure partie de ces discussions ont concerné Flex2, alors que le thème de la conférence était Ajax. Beaucoup de personnes avait entendu parler du produit mais ne l’avait jamais vu tourner. J’ai improvisé quelques démos. L’accueil a été excellent ! Flex a été perçu comme LE véritable environnement industriel de développement de RIAs …