Trop d’ajax tue l’ajax

J’ai assisté à un petit déjeuner du Groupe Clever Age hier matin aux aurores : 8h30. D’habitude à cette heure là je prends mon café en finissant de lire mes flux RSS tranquillement installé sur mon immense canapé en cuir de Nubuc ambré. Pas là. Le sujet de cette présentation matinale Ajax, zone de confort et pièges à éviter. J’y suis allé sur les bons conseils du rédac’ chef de ZDNet qui avait déjà eu l’occasion d’assister aux présentations de Clever Age et me les avait chaudement recommandées. Personnellement j’étais moyen enthousiaste m’attendant plutôt à une présentation commerciale de prestation de service de la boîte en question.

Et bien pas du tout. Ce fut une présentation de très bonne facture, pointue et pas chiante du tout.

Ajax était abordé sous l’angle du client léger[1] car cette « techno » est avant tout destinée à être utilisée dans des applications en ligne. Un site de contenu qui servirait toutes ses pages en ajax serait le truc le plus ridicule du web2.0 (quoique, il y a quand même les podcast de Loïc Lemeur). Dans un environnement ajaxisé, on perd l’essence même du web à savoir l’équation une ressource = une adresse web (d’où l’acronym URL Universel Rerssource Location).

Avec Ajax, on ne peut plus :

• bookmarquer une page (allez sur digg spy et essayez pour voir),
• utiliser les boutons « stop » ou « retour » (le navigateur ne sert pas plusieurs pages mais plusieurs requêtes dans une seule page)
• référencer efficacement ses pages (forcément, y’en a moins)

Ajax est à utiliser uniquement dans un cadre applicatif. Traduction pour le web : dans les formulaires et dans leurs nécessaire corollaire, les pages de résultats. S’il n’y avait qu’une seule chose à retenir de cette présentation, ce serait ça : ajax est à utiliser avec précaution car comme dirait Clever Age : trop d’ajax tue l’ajax.

L’un des gros problèmes de cette techno est que les interfaces qui l’utilisent sont suceptibles de déstabiliser les utilisateurs. L’utilisation d’ajax casse littéralement des comportements ancrés de longue date chez les internautes tels que l’utilisation des boutons stop et retour ou la navigation page par page [2]. D’où un autre thème particulièrement intéresssant abordé au cours de cette présentation: l’utilisabilité. Il faut habituer doucement l’utilisateur à ces nouvelles interfaces et ne pas leur balancer un truc flashy qui n’a plus rien à voir avec une page web sans l’avoir prévenu avant.

Ca me fait penser aux 2 approches adoptées par google et yahoo quant à leurs webmails respectifs[3].

Yahoo mail est la reproduction d’une interface desktop sur le web (application type desktop signifie une application locale. Desktop veut dire qu’on lance à partir du bureau, outlook par exemple). Ca marche bien, c’est joli mais qu’est ce que c’est lourd !! Impossible d’imaginer l’utiliser avec un connexion type 56 k.

Gmail lui est beaucoup plus light et utilise ajax avec parcimonie. Ca ressemble toujours à une page web. L’interface est légère et destabilise moins l’utilisateur. bha oui l’utilisateur lorsqu’il lance son navigateur s’attend plus à trouver un tuc qui ressemble à une page web qu’à une application classique. De ce point de vue là je trouve l’approche de google beaucoup plus sioux que celle de yahoo.

Clever Age a également dressé un tableau de l’approche des gros de l’indsutrie web, type google, yahoo, IBM, mais cela fera l’objet d’un prochain billet. Celui-ci est déjà long et le teasing, c’est efficace 😉

Précision : je ne reçois aucune gratification de la part de Clever Age pour dire du bien d’eux. Enfin s’ils veulent me donner un petit quelque chose, y’a pas de problème !

1. à opposer aux clients lourds comme la Java Virtuel Machine ou le mec que j’ai vu la dernière fois au prisu en faisant mes course
2. (cf plus haut et dans ce billet)
3. Lire à ce propos le billet de techrcrunch sur le nouveau webmail d’apple et les commentaires associés