Blog · Réussir ses formulaires
Envoyer sans perdre la page
L'envoi sans rechargement fait honnêtement : les quatre états qu'un bouton Envoyer doit au visiteur, pourquoi ce qui a été tapé doit survivre à chaque échec, et comment rendre le succès audible autant que visible.
Le rechargement est un pari avec le travail de quelqu'un d'autre
L'envoi traditionnel d'un formulaire est un petit acte de foi : le visiteur appuie sur le bouton, la page où il se trouvait est jetée, et une nouvelle page arrive pour dire ce qui s'est passé. Quand tout marche, c'est bien. Quand quelque chose échoue (une erreur de validation, un hoquet du serveur, une connexion perdue), l'échec atterrit sur ce que le serveur renvoie, et dans trop de configurations cette page arrive avec tous les champs vides. Les dix minutes d'écriture soignée du visiteur ont été échangées contre une phrase sur un numéro de téléphone invalide.
C'est la vraie raison d'envoyer sur place, sans quitter la page. Non parce que les rechargements sont démodés, mais parce que garder la page garde le travail du visiteur sous ses propres mains. Les paragraphes qu'il a tapés, les options qu'il a choisies, sa position dans la page : tout survit à ce qui vient ensuite, parce que rien n'a été jeté.
Ne pas recharger n'est pas le but. La certitude l'est.
Mais un envoi sur place retire aussi quelque chose : la navigation de page qui, malgré ses défauts, était la preuve indubitable que quelque chose s'était passé. Retirez-la et remplacez-la par rien, et vous obtenez la pire version de ce formulaire : le visiteur clique, la page reste inchangée, et le voilà à interroger un écran immobile. Est-ce parti ? Il reclique. Vous avez peut-être deux envois maintenant, ou aucun, et il ne le sait toujours pas.
La décision n'est donc pas rechargement contre absence de rechargement. C'est de savoir si chaque état de l'envoi est indubitable. Un formulaire qui envoie sur place prend la charge de raconter ce que la navigation racontait autrefois. Cette charge est le vrai travail.
Les quatre états qu'un bouton Envoyer doit au visiteur
Au repos : le bouton invite au clic. En cours : à l'instant où le clic atterrit, le bouton le dit. Il se désactive pour qu'un second clic nerveux ne puisse pas créer de doublon, et son propre texte devient quelque chose comme « Envoi… » pour que la preuve soit exactement là où le visiteur regarde déjà.
Échec : un message en langage clair apparaît près du problème, et chaque champ contient encore ce que le visiteur a tapé. Succès : le formulaire cède la place à une confirmation qui semble définitive (ce qui a été reçu et ce qui se passe ensuite), pas à un formulaire qui se réinitialise en silence en espérant que le visiteur tire la bonne conclusion.
L'état d'échec mérite le plus d'attention de conception, parce que c'est celui qui décide si le visiteur réessaie. Un envoi échoué qui préserve les mots du visiteur est un hoquet ; il rappuie sur le bouton et passe à autre chose. Un envoi échoué qui les avale est souvent la fin de la conversation. Très peu de gens réécrivent de mémoire un long message au profit d'un formulaire qui vient de jeter le premier brouillon.
Le succès a une dimension d'accessibilité facile à manquer : si la confirmation ne fait qu'apparaître (un message substitué dans la page), un visiteur utilisant un lecteur d'écran peut n'entendre rien du tout. La page a changé et personne ne l'a dit. La confirmation doit être annoncée, pas seulement affichée, soit en y déplaçant le focus, soit en marquant la région pour que les technologies d'assistance lisent le changement à voix haute. Pour les sites du secteur public, c'est la même norme que tout le reste de la page : des changements d'état que tout le monde peut percevoir.
Quand le script échoue, le formulaire ne doit pas échouer
L'envoi sur place repose sur JavaScript, et JavaScript est la couche la moins fiable de toute page : les scripts sont bloqués par des réseaux d'entreprise stricts, cassés par une erreur sans rapport ailleurs sur la page, ou n'arrivent simplement pas sur une mauvaise connexion. Un formulaire qui ne fonctionne que lorsque son script fonctionne a un mode de panne silencieux visant exactement les visiteurs les moins équipés pour le diagnostiquer.
La construction honnête est un vrai formulaire dessous : un formulaire ordinaire qui s'envoie de façon traditionnelle par lui-même, avec le comportement sur place ajouté par-dessus quand le script est présent et sain. Le script se charge, les visiteurs ont l'expérience calme sans rechargement. Il ne se charge pas, le formulaire s'envoie quand même et une page de confirmation ordinaire répond quand même. Personne ne tient jamais un bouton qui ne fait rien.
La même humilité s'applique au réseau lui-même. Quand un envoi expire en cours de route, le formulaire ne peut pas savoir si le message est arrivé, il doit donc le dire clairement, garder le texte du visiteur et proposer de réessayer. Deviner « succès » quand la vérité est « inconnu », c'est ainsi que des organisations finissent par s'excuser pour des messages qu'elles n'ont jamais reçus.
Le bouton Envoyer est une promesse
Tout ce qui précède est un seul principe porté de quatre façons : à l'instant où quelqu'un appuie sur Envoyer, il a fait sa part, et tout risque après cela appartient au formulaire. Son travail est protégé, son incertitude est levée, son échec lui coûte au plus un clic de plus. Réussissez cela et le formulaire inspire confiance d'une façon que les visiteurs ne savent pas nommer, ce qui est la seule façon dont la plupart des gens évaluent la compétence d'une institution en ligne.
Et quand l'état d'échec se déclenche, les mots qu'il emploie comptent autant que la mécanique. C'est la prochaine décision de cette série : des messages d'erreur qui aident vraiment, au lieu d'annoncer « invalide » et de laisser le visiteur deviner à quoi ressemblerait une vie valide.