Le terme de RIA est apparue en mars 2002 dans une publication de Macromedia. Depuis de nombreux autres termes sont utilisés pour parler de ces clients légers permettant de se connecter à un serveur d’applications tout en proposant des interfaces plus avancées que de simples pages HTML : on parle de "Client riche", "Interface riche" ou "application internet riche".
Les applications web traditionnelles s’articulent sur une architecture client-serveur où les rôles sont bien délimités. Les traitements sont réalisés sur le serveur, qui envoie ensuite le résultat au client. Celui-ci ne sert qu’à l’interprétation du résultat, afin de l’afficher sous une forme compréhensible par l’utilisateur (HTML par exemple).
Par conséquent, à chaque intéraction de l’utilisateur avec le client, les données sont envoyées au serveur qui enverra alors une page de résultat entièrement nouvelle à l’utilisateur
Au fil des ans, la majorité des efforts se sont portés sur la partie serveur. L’évolution du matériel à permis de faire progresser la puissance de calcul, et de nombreux investissements se sont portés sur le développement des applications serveurs. C’est ainsi qu’en quelques années, les applications serveurs sont passées de script CGI à des architectures orientées web-services.
En revanche, les interfaces web sont limitées par l’évolution des navigateurs. Bien sûr des évolutions ont été réalisées et de gros investissements ont été faits dans le domaine de la standardisation et de l’ergonomie : malgré tout, les interfaces web étaient souvent largement inférieures aux interfaces d’applications compilées.
C’est justement cet objectif que souhaitent atteindre les clients riches : proposer des interfaces équivalentes à celles d’applications compilées.
Pour l’instant, les applications classiques proposent peu de choses aux utilisateurs :
des pages de textes et images,
des liens,
des formulaires.
Les pages webs sont donc bien adaptées pour les fonctions initiales de l’internet qui étaient de mettre à disposition de l’information textuelle.
Le premier intérêt des applications riches est de fournir une connection invisible au serveur. Cela permet de récupérer des informations sans que l’utilisateur en soit conscient. De plus, on peut coupler à ce dialogue transparent, la possibilité de modifier l’affichage directement au niveau client. A partir de là, il est possible de diminuer le flux de données à remonter du serveur afin qu’il ne retourne que les modifications à réaliser.
On obtient donc une page web capable de se connecter au serveur, de traiter le retour serveur, et de se modifier pour faire apparaître les changements.
De plus, comme on peut réaliser des traitements au niveau client, il est possible de choisir entre :
demander au serveur de nous retourner du code à afficher,
ou seulement des informations.
Dans le deuxième cas, le traitement des informations sera déporté sur le client, et il générera lui-même le code à afficher.
Dans le cas d’une application autonome (calculatrice par exemple), on peut même envisager de travailler en mode déconnecté, puisqu’une fois que l’application est chargée, elle n’a plus besoin de se connecter au serveur.
Pour comparer avec le modèle traditionnel, dans le cas de client riche on obtient :
Utilisation de fenêtre dépliante ou flottante,
Information contextuelle,
Pas de rechargement de la page,
Plus grande réactivité.
Comme l’utilisateur ne voit plus de chargement de page, il est possible de copier le fonctionnement des interfaces d’applications compilées. Il est ainsi possible de capitaliser sur les connaissances en ergonomie de ce domaine, ainsi que de profiter de l’expérience utilisateur.
Il semble donc que les clients riches soient la prochaine révolution du web, même si, comme nous allons le voire : "tout n’est pas rose".
Il y a bien entendu quelques limites aux avantages des clients riches. En effet, comme il n’existe pas réellement de standard, tout le monde propose ses solutions, et il y a souvent des contraintes comme l’utilisation de plugins ou l’utilisation de navigateur spécifique.
De plus, il existe également dans certains cas des problèmes d’accessibilité. Il existe également de nombreuses difficultés lors de la visualisation de certains contenus avec l’impossibilité d’utiliser un synthétiseur vocal ou une plage braille.
De nombreuses solutions techniques existent pour proposer des applications internet riches. Plusieurs éditeurs proposent des solutions :
Adobe avec le lecteur Flash intégré dans le navigateur et des technologies serveurs telles que Flash, Central, Breeze et Flex. Il est également possible d’utiliser d’autres technologies serveurs telles que PHP en récupérant ensuite des flux XML.
Oracle avec Java et notamment les applets placées dans une page web ou des applications indépendantes.
Microsoft avec .NET et l’utilisation d’ActiveX ce qui nécessite d’utiliser Internet Explorer.
Mozilla avec XUL (XML User interface Language). Une des limites de XUL (prononcé ZOOL) est qu’il ne fonctionne qu’avec les navigateurs de types Mozilla.
Indépendant avec AJAX (Asynchonous JavaScript And XML). En effet, il est possible de communiquer directement avec le serveur en JavaScript grâce à la fonction XMLHttpRequest. Il est bien entendu nécessaire d’avoir un navigateur acceptant le JavaScript pour utiliser cette solution. Cela permet de ne pas avoir à rafraîchir l’ensemble de la page mais seulement les éléments à mettre à jour.
Voici donc les technologies les plus utilisées même s’il en existe d’autres telles que : SVG (Scalable Vector Graphics), SMIL (Synchronized Multimedia Integration Language), ou encore les XFORMS qui sont des technologies libres.
Comme pour beaucoup de langages, il existe de nombreuses solutions pour ne pas partir de zéro. Voici donc quelques solutions existantes :
Pour ASP avec Telerik,
Pour ASP avec Web.UI,
Pour Ajax avec Rialto,
Pour Ajax avec OpenLaszlo,
Pour Java avec Eclipse RCP.
Les formulaires sont souvent un des points les plus critiqués des sites web au niveau ergonomie. Il est donc naturel que beaucoup d’efforts soient faits dans ce domaine.
Tout d’abord voici un exemple où l’on utilise l’auto-complétion (que l’on trouve déjà dans les téléphones portables ou les traitements de textes) afin de faciliter la saisie. Ce n’est autre que Google qui affiche, à l’avance, le nombre de résultats que l'on peut espérer trouver en fonction de ce que l'on va rechercher
Un autre formulaire exceptionnel est celui disponible ici. En effet, au fur et à mesure de la saisie, il vous dit si les informations saisies sont valides, et ceci de façon très claire.
Une autre mise en oeuvre très appréciée des RIAs, est destinée au e-commerce. En effet, la meilleure chance de transformer un visiteur en acheteur et de lui permettre de trouver ce qui l’intéresse.
Pour commencer voici l’interface développée pour Amazone en XUL.
Flickr propose également une navigation agréable avec un diaporama en flash.
Voici quelques exemples permettant de préciser les caractéristiques des produits susceptible d’intéresser le client, afin de l’aider à trouver facilement un produit :
Voici un exemple de site d’actualités ayant également opté pour une interface différente en flash.
Certains ont même poussé la chose jusqu’à réaliser de véritables applications sur internet. On peut, par exemple, trouver un portail entièrement personnalisable en AJAX.
Gliffy propose, entre autre, une interface pour dessiner des diagrammes
De même, au niveau des clients mail, on a vu de nombreuses évolutions initiées par Google avec Gmail suivi par Hotmail.
Google garde tout de même une longueur d’avance avec des services très novateurs tels que :
des cartes vituelles,
l’agenda collaboratif.
Voici également d'autres Framework/API fort intéressante pour les développeurs web :
Comme nous avons pu le voir, les possibilités sont très nombreuses et ne sont limitées que par l’imagination des développeurs. Bien sûr, tout n’est pas parfait, et même si les applications semblent illimitées, il est très important d’utiliser les possibilités offertes à bon escient et sans oublier les contraintes d’accessibilité.