Depuis maintenant 3 ans que l’AJAX a commencé à rentrer dans les usages du développement web, on a pu assister à un peu tout et surtout à n’importe quoi. Souvent, la tentation fut forte de mettre d’en mettre pour le seul principe de suivre la mode du moment, au mépris de l’expérience utilisateur et des besoins fonctionnels réels. S’il est très facile de se tromper, il existe pourtant des endroits assez génériques où ajouter une pointe d’AJAX par dessus le fonctionnement normal du site – et j’insiste sur ce point – améliore l’expérience de navigation, simplifie l’utilisation du site, et rend la vie bien plus agréable.

1– Vérifier la disponibilité d’un identifiant à l’inscription

Dans le cas où vous choisiriez de ne pas privilégier l’adresse email comme identifiant des utilisateurs de votre application, vous pouvez vérifier en temps réel la disponibilité de ce dernier. Vous évitez ainsi une première validation du formulaire, et un retour à la case départ des plus frustrants. Sans compter que vous risquez de devoir retaper le mot de passe et sa vérification.

J’en profite pour mettre l’accent sur un abus lié aux fonctionnalités de suggestion. La très grande majorité des sites que j’ai pu voir à ce jour qui valident en temps réel la disponibilité d’un identifiant n’imposent pas d’alternatives proches du login souhaité. Un clic sur un bouton de formulaire est nécessaire afin d’afficher (en AJAX) une liste d’identifiants disponibles. C’est une très bonne chose, même si cela peut sembler au premier abord moins dynamique.

  • Non seulement c’est moins intrusif : je n’ai pas forcément envie qu’on me force la main, et je peux au contraire décider de changer totalement d’identifiant.
  • L’affichage d’un plus ou moins grand nombre de lignes (5 me semble idéal) en fonction de la chaîne tapée par l’utilisateur risque d’avoir sur la page un effet “yoyo” qui pourra surprendre votre visiteur, quand il ne le convaincra pas que votre site est en train de faire planter son navigateur.

Zone d'inscriptiond de gmail

Gmail va mêtre un peu plus loin encore. Le site soumet la vérification de la disponibilité d’un identifiant à une demande explicite de l’utilisateur. En plus des avantages précédemment cités, cela leur permet d’éviter des requêtes incessantes sur leur serveur de base de données, tout en donnant toute latitude au visiteur dans le choix de son login.

Si vous souhaitez mettre en place une vérification automatique, faites le, mais au delà d’un nombre minimum de caractères, afin de soulager à la fois votre serveur, et votre visiteur qui se sentira moins agressé.

2– Faire de la saisie prédictive

La saisie prédictive vous propose de compléter pour vous votre saisie en fonction de ce que vous êtes en train de taper au clavier. Elle fonctionne exactement comme la barre d’URL de votre navigateur, mais sur un site web. Les premiers tests qui en ont été faits par Google et sa fonction Suggest ont à l’époque provoqué un tollé. On accusait alors le moteur de recherche de biaiser les résultats de recherche proposés en fonction des ventes d’Adwords, mais aussi de vouloir biaiser le choix des utilisateurs en affichant en face de chaque entrée le nombre de résultats possibles.

saisie prédictive sur ratp.fr Un des meilleurs exemples de saisie prédictive que j’ai jamais vus… n’utilise pas d’AJAX afin de récupérer les données. Ces dernières sont incluses dans le Javascript au chargement de la page. Il s’agit de la saisie des stations de départ et arrivée sur le site de la RATP, la société de transports en commun parisienne. Je pourrais continuer longtemps à vous parler de la saisie prédictive, mais ce n’est pas vraiment l’objet de cet article.

3– Vérifier les champs d’un formulaire

La vérification des champs d’un formulaire diffère de la validation de l’unicité d’un login, et c’est la raison pour laquelle j’ai souhaité traiter ce point à part. Le premier vérifie la possibilité pour un utilisateur d’obtenir ce qu’il souhaite, tandis que le second contrôle la conformité des informations à un certain nombre de règles. Le premier est là pour valider, le second pour permettre une correction à priori des données fausses.

Cette action ne nécessite pas forcément d’AJAX même si des échanges client / serveur peuvent s’avérer nécessaires. Je vous propose deux exemples de la vie de tous les jours.

  • Vérifier le format d’un numéro de téléphone par rapport à un pays donné relève d’une utilisation intelligente de Javascript, mais ne nécessite pas d’interaction client / serveur.
  • Contrôler des informations présentes en base et effectuer des traitements lourds impose l’utilisation d’une couche d’AJAX.

Quand valider la conformité d’un champs ? Eh bien pas n’importe quand, et en tout cas certainement pas durant la saisie. Effectuez le test au moment de la validation, et tirez-en les conséquences. Normalement, l’utilisateur ne devrait pas avoir la possibilité de valider son formulaire tant que la bonne saisie de tous les champs n’a pas été validée. C’est d’ailleurs ce qui se fait dans le software, où les boutons de validation restent grisés tant que les champs obligatoires n’ont pas été (correctement) remplis. On éviterait ainsi beaucoup de frustrations, ce traitement à priori ne devant surtout pas remplacer le traitement à posteriori des informations envoyées. En effet, d’une part certaines personnes n’ont pas de Javascript activé sur leur navigateur, et il est hors de question de les empêcher d’utiliser une application pour cette seule raison, mais en plus de cela, certaines chaînes qui semblent valides peuvent en fait tenter d’exploiter des vulnérabilités de sécurité, comme les injections SQL.

4– Live search

La recherche dynamique, ou live search, est une extension de la saisir prédictive dont nous avons parlé un peu plus haut. Simplement, au lieu d’aider l’utilisateur à remplir son formulaire, l’application lui affiche les résultats de le recherche au fur et à mesure de la saisie.

live search, ce qu'il ne faut pas faire

Parce qu’elle n’a pas de page dédiée sur laquelle afficher les résultats, offrir une recherche dynamique vraiment utilisable peut s’avérer particulièrement problématique. Ce site est d’ailleurs le parfait exemple de ce qu’il ne faut pas faire. Sur la plupart des sites, la zone de recherche simple se trouve soit dans l’en-tête du site, soit dans uns des menus latéraux. Par défaut, l’utilisateur s’attend à ce que le résultat de la recherche s’affiche en dessous du champ de saisie. C’est impossible dans le premier cas, et cela limite fortement les possibilités d’affichage dans le second cas. Mais cela fera l’objet d’un article spécifique à l’occasion.

5– Remplir dynamiquement les champs d’un formulaire

S’il existe un domaine dans lequel l’utilisation massive d’AJAX se justifie, je crois que c’est celui la.

Pendant des années, les formulaires ont été peuplés dynamiquement à grands renforts de display: none / display: block, quand il ne fallait pas recharger la page afin de remplir un simple menu déroulant, ceci plusieurs fois par saisie. Outre le fait qu’il fallait souvent embarquer tous les cas possibles et toutes les valeurs possibles dans la page et le javascript, à une époque où la bande passante était plus que limitée, l’utilisateur avait accès à des données qu’il n’aurait pas forcément du voir… ou rechargeait la page 20 fois. Bref… je pense sincèrement que ces limitations sur les formulaires ont été pour beaucoup pour le freinage de l’adoption des applications web dans le monde professionnel.

6– Sauvegarder des contenus pendant la saisie

La sauvegarde automatique a révolutionné les traitements de textes, permettants à ces derniers de pallier aussi bien les plantages récurrents d’un OS trop instable que les pannes de courant ou de batterie. De même qu’on n’imagine plus un traitement de textes sans sauvegarde automatique, je vois mal aujourd’hui un outil de saisie de contenu web ne proposant pas la même chose (c’est en cours sur Typo, patience).

Évidemment, on imagine mal une sauvegarde automatique qui obligerait l’utilisateur à interrompre son travail, afin d’attendre le rechargement de la page, et là, AJAX s’impose de lui-même. Cependant, comme nous l’avons rappelé plus haut, certaines personnes ne sont pas équipées de Javascript. La présence d’un bouton “sauver et continuer” est obligatoire, et doit même précéder la mise en place d’une sauvegarde automatique.

7– Modifier dynamiquement l’affichage de résultats

La possibilité de modifier dynamiquement l’affichage de résultats en fonction des changements des critères sélectionnés par l’utilisateur a révolutionné les configurateurs de produits. Ces outils qui permettent de choisir les options d’un produit et de voir directement le résultat (et le prix) ont connu un boom important avec l’arrivée des interfaces riches, et notamment de la combinaison Flash + XML. Le mini site de l’Audi A6 en est un exemple superbe.

Évidemment, les configurateurs ne sont pas les seuls à être concernés, et de nombreuses applications web profitent de l’AJAX pour modifier dynamiquement les résultats de leurs calculs. Dans le genre, j’aime particulièrement le curseur de Google Webmaster Tools qui permet de modifier la période sur laquelle on souhaite afficher les requêtes les plus fréquentes.

le slider des google webmaster tools

Et voilà, that’s all folks comme il disent dans les cartoons de mon enfance. J’espère que vous avez pris autant de plaisir à lire cet article que moi à le rédiger. Dans une seconde partie, nous étudierons tout ce qu’il ne faut pas faire. Avant de le mettre en pratique, n’oubliez pas le plus important : avant de mettre de l’AJAX partout, assurez-vous que votre site fonctionne bien sans Javascript.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: