Les interfaces enrichies sont "malheureusement" à la mode. En effet, comme toute mode, on tant à voir fleurir les interfaces riches sans réflexion particulière mais plus par effet de mode.
Ceci a fait beaucoup parler, et l’on a vu de nombreux articles sortir comme "mettez une technologie ici" est 99% mauvaise.
Aucune technologie n’est réellement mauvaise en soi, c’est souvent l’utilisation et la technique de développement qui est à revoir.
L’objectif est de vous présenter des régles de bonne utilisation des interfaces enrichies ainsi qu’une méthode permettant d’éviter bon nombre de dérives.
Deux critères de qualités qui me sont chères sont l’accessibilité et l’ergonomie. En effet, tout produit doit avant tout être pensé pour son l’utilisateur. Or, les technologies permettant de faire des interfaces riches sont souvent situées au niveau client. Comme tout le monde ne les a pas toujours, il est très facile d’écarter une partie des utilisateurs potentiels.
De plus, si le HTML est une technique bien maitrisée et dans un format ouvert, toutes les technologies ne le sont pas automatiquement. Il est alors possible que certains logiciels ne sachent pas interpréter le contenu. Par exemple, il est déjà difficile d’interpréter le texte d’une image avec un synthétiseur vocal, donc imaginez avec une vidéo ou une animation.
L’objectif à garder en tête tout au long du développement devra être le suivant : tout contenu doit être accessible à tout utilisateur souhaitant y accéder.
Une solution parfois employée, pour atteindre cet objectif est de faire deux applications, une riche puis une en HTML. C’est d’ailleurs cette solution qui a été choisie pour gmail. Cette solution à l’air de répondre aux besoins, cependant il est très rare que les deux applications évoluent de la même façon dans le temps. En effet, il est difficile d’investir le temps suffisant pour maintenir deux applications quand une seule aurait pu suffir.
Voici donc quelques pistes pour éviter de s’écarter de notre objectif.
Pour commencer, il faut faire la distinction entre application web et site web. Bien qu’il y ait eu de nombreuses discussions à ce sujet, on peut considérer qu’un site web est un ensemble de pages liées entre elles, dont le but est de mettre à disposition de l’information. Pour faire simple, on utilise des interfaces web enrichies dans le cas d’applications web.
Les principaux risques sont liés à l’expérience utilisateur sur laquelle il vaut mieux capitaliser. Voici quelques habitudes utilisateurs dont il faut tenir compte :
Utiliser le bouton "back" du navigateur pour revenir en arrière et retrouver une page visitée.
Pouvoir réaliser un "bookmark" d’une page intéressante.
Cliquer sur un lien pour qu’il se passe quelque chose.
Ouvrir une page dans une nouvelle fenêtre/onglet.
Pour illustrer ces exemples, prenons le cas d’AJAX. Si l’on utilise du JavaScript pour charger des pages de contenu sans recharger la navigation, ce qui rejoint la technique des frames employée il y a quelques années, on se heurtera alors aux mêmes problèmes. En effet, il sera impossible de revenir en arrière, faire un bookmark, ou ouvrir une page dans une nouvelle fenêtre.
Ceci est un exemple avec AJAX, mais il est très simple de le transposer avec Flash.
Voici maintenant quelques exemples pour illustrer quelques cas où l’utilisation des RIAs est appropriée.
Ouvrir un arbre de données de taille importante. Par exemple, il est désagréable de rafraichir toute une page pour ouvrir un élément d’un fil de discussion. Il est possible de rendre la navigation plus agréable en utilisant du JavaScript par exemple.
Rafraichir des données qui changent souvent. Il est en effet très désagréable de cliquer fréquemment sur un lien pour rafraichir une page. C’est par exemple le cas pour un chat ou un client mail.
Affichage d’aide contextuelle. Il est possible de présenter des informations en fonction de la saisie de l’utilisateur. En plus de messages d’erreur ou d’aide, il est possible de mettre en place la correction automatique ou l’auto completion.
Mettre en place des filtres pour trier des données. Il est ainsi possible de changer la couleur d’informations en fonction de paramètre pour les mettre en avant.
Maintenant que nous avons vu quelques exemples intéressants, voici un certain nombre de choses à ne pas faire.
Ne pas empécher l’utilisateur de revenir en arrière pour trouver une information si cela lui semble naturel.
Ne pas remplacer une partie du contenu sans que l’utilisateur ne s’en rende compte. Il est préférable de mettre en avant la modification si elle n’est pas évidente. On peut par exemple utiliser une couleur de fond différente et petit à petit revenir à la couleur par défaut.
Utiliser une technologie juste pour le plaisir de l’utiliser. En effet, si son utilisation n’apporte rien, alors mieux vaut ne pas le faire. Il est par exemple pertinent de se demander si un menu ou une animation en flash apporte réellement quelque chose. De même, il est possible de réaliser un menu déroulant en CSS plutôt qu’en JavaScript.
Modifier les éléments habituels d’une page. Il est déconseillé de créer ses propres widgets (boîte à cocher, liste déroulante, ascenseur, etc.). En effet, il est préférable d’utiliser ceux que l’utilisateur à l’habitude de voir.
D’une façon générale, il y a deux possibilités :
on parle de site web et on suit les régles de bonne conduite appliquées au web. Pour cela les publications de Nielsen Norman Group sont souvent intéressantes.
on parle d’application web, et l’on peut s’inspirer des travaux d’Apple pour leurs interfaces.
Une grosse réflexion a également été réalisée par yahoo, qui de plus a mis une partie de ces réflexions en ligne.
Le concept est simple, commencez par réaliser d’abord l’interface avec la méthode traditionnelle client server. Ensuite, étudiez les points qui peuvent être améliorés et ajoutez petit à petit des fonctionnalités offrant un plus. Au fur et à mesure, il faut vérifier que le fonctionnement initial soit toujours possible.
Par exemple, si comme dans Google calendar vous utilisez des champs textes, et qu’il soit nécessaire de cliquer dessus pour les transformer en champ input afin de modifier l’information, un utilisateur sans JavaScript ne pourra plus utiliser l’application. En revanche, si par défaut vous les mettez en input, et au chargement de la page vous les transformez en texte, alors un utilisateur n’ayant pas JavaScript les aura tout de même dans leur forme initiale (input) et donc pourra correctement utiliser l’application.
Pour un très bel exemple d’enrichissement progressif, voici un générateur de carte de visite :