Project

General

Profile

Development #70037

Aide à la saisie des usagers (validation des champs à la volée)

Added by Anaïs Ecuvillon 4 months ago. Updated 3 months ago.

Status:
En cours
Priority:
Normal
Category:
Fabriques et traitement (wcs)
Target version:
Start date:
10 October 2022
Due date:
20 April 2023
% Done:

0%

Estimated time:
Patch proposed:
No
Planning:
No
Club:
Yes

Description

Finalité : aider les usagers lors du remplissage d'un champ en contrôlant la validité du format attendu sans attendre qu'il clique sur le bouton Suivant en bas de page.
Pour éviter qu'une erreur de saisie soit notifiée après que l’utilisateur ait soumis le formulaire.

Périmètre à affiner :
  • quand il existe un regex (Validation), s’assurer que la validation apparaisse "immédiatement" à côté du champ
  • ne pas vérifier pendant la frappe mais quelques micro-secondes après, le message ne doit pas s’afficher pendant que l’utilisateur saisit le texte

Impact sur les perfs à évaluer.


Files

exemple-saisie-erreur.png (39.7 KB) exemple-saisie-erreur.png Frédéric Péters, 21 October 2022 05:41 PM

History

#2

Updated by Anaïs Ecuvillon 4 months ago

  • Tracker changed from Support to Development
  • Club changed from No to Yes
#3

Updated by Frédéric Péters 4 months ago

Quel comportement pour les champs obligatoires ? J'imagine qu'on les mettrait en erreur quand l'usager passe sur le champ mais ne remplit pas (c'est cependant un comportement que je ne vois pas trop comment apporter aux champs type cases à cocher).

Aussi, j'imagine que tout ça se fait après avoir modifié l'ordre d'affichage des éléments, pour avoir libellé/remarque/champ/erreur, pour éviter le décalage du champ lors de la saisie.

#4

Updated by Anaïs Ecuvillon 4 months ago

Frédéric Péters a écrit :

Quel comportement pour les champs obligatoires ? J'imagine qu'on les mettrait en erreur quand l'usager passe sur le champ mais ne remplit pas (c'est cependant un comportement que je ne vois pas trop comment apporter aux champs type cases à cocher).

Je ne sais pas ce que tu appelles "passe sur le champ". Tu veux dire s'il commence à remplir un champ après un autre obligatoire ?

On ne peut pas savoir s'il va remplir les champs dans le désordre et du coup en oublier un ou le remplir après un autre. Donc s'il positionne son curseur sur le champ, mais ne le remplit pas alors oui, erreur. Sinon non (c'est une proposition, ça vaut échange avec les autres).

Aussi, j'imagine que tout ça se fait après avoir modifié l'ordre d'affichage des éléments, pour avoir libellé/remarque/champ/erreur, pour éviter le décalage du champ lors de la saisie.

oui, justement je voulais lier le ticket concernant l'ordre d'affichage, c'est même le pré-requis

#8

Updated by Anaïs Ecuvillon 4 months ago

J'ai repensé à ce que l'on s'est dit hier.
Si l'idée est de contrôler les champs au fur et à mesure de la saisie, on pourrait cadrer cette fonctionnalité de la façon suivante :

Quand on arrive sur un formulaire vierge, on affiche aucun picto. Le picto ❌ apparaît uniquement si un champs est invalide. Le picto ✅ apparaît à la volée quand l'usager a rectifié la saisie au format attendu.

On pourrait avoir un picto à droite du champ avec un symbole rouge ❌ quand le champ est invalide et un symbole vert ✅ quand il est valide.

Il est préférable d'indiquer en temps réel si une erreur est détectée plutôt que de faire une liste de toutes les erreurs sur le bouton de validation.
En temps réel étant entendu pas pendant la frappe mais quelques micro-secondes après, le message ne doit pas s’afficher pendant que l’utilisateur saisit le texte

Pour résumer, dans cette fonctionnalité, on s'attache à contrôler ce qui est invalide et à indiquer à l'usager quand sa correction rend le champ valide.

#9

Updated by Agate Berriot 4 months ago

Pour de la validation en temps réel (ou presque) ma maigre expérience me dit qu'il n'y a pas de recette magique:

1. Soit on applique la fonction de validation (et l'affichage correspondant) après un certain délai, par exemple 500ms après la dernière interaction utilisateur
2. Soit on attend que le focus quitte le champ (par exemple que l'utilisateur passe au champ suivant)

1. pose des problèmes pour les saisies plus lentes que le délai configuré, 2. fait perdre un certain intérêt à la fonctionnalité puisque l'information arrive après.

Pour avoir du contexte, on cherche à résoudre quel problème exactement ? Est-ce qu'on a des exemples de champs avec des contraintes importantes de validation qui bénéficieraient de cette fonctionnalité ?

#10

Updated by Anaïs Ecuvillon 4 months ago

Exemple trouvé ici, qui contrôle lorsque l'on passe au champs suivant : http://www.popscreen.com/join
Et qui indique le formatage attendu pour chaque champ quand il est mal rempli.

Mais est-ce que l'on veut faire ça pour tous les champs ? SI oui, ça impliquerait d'avoir un champ par ligne, comme c'est le cas de l'exemple.

#11

Updated by Pierre Cros 4 months ago

Agate Berriot a écrit :

Pour avoir du contexte, on cherche à résoudre quel problème exactement ?

Pour moi l'intérêt principal de la chose c'est être un peu moins perdu entre plusieurs champs mal/pas saisis lorsqu'on valide une page de formulaire.

#12

Updated by Frédéric Péters 4 months ago

À la base aussi on a des intégrations graphiques qui voudraient davantage marquer les champs en erreur et souvent je trouve alors que l'usager qui corrige la valeur saisie dans un champ marqué en erreur, il s'attend à voir disparaitre la marque d'erreur du champ. (Je ne sais pas si je suis clair)

#13

Updated by Thomas Jund 4 months ago

Pour compléter les remarque d'Agate, je rajoute que

  • La validation à la sortie du focus est délicate dans les cas où le champ suivant fait sortir de l'écran le champ qui a été validé.
  • Ce que l'on a toujours dit : faire apparaitre un champ en erreur alors que la saisie n'est pas terminée peut être contre-productif.
  • indiquer un champ valide, alors que pour certaines raisons, la validation côté serveur peut le retourner invalide devra absolument être évité.
  • Ce type de validation ne garanti pas une validation de la page : l'apparition d'erreurs lors de la validation de la page sera toujours possible.

Il y a beaucoup d'améliorations possibles / d'aides à l'usager qu'on avait évoqué avant de passer à la validation à la volée :

  • Ajouter la liste des champs en erreur avec un lien vers le champ depuis le message d'erreur en tête de page (je sais pas si on a encore la mise en focus du premier champ en erreur, mais c'est une très mauvaise pratique)
  • Indiquer visuellement les champs en erreur de manière plus explicite que simplement le message en bold noir
  • Supprimer l'indication du champ en erreur après correction par l'usager (ce qui est différent que de l'indiquer "valide")
  • améliorer les textes d'aide à la saisie et les messages d'erreurs
#14

Updated by Anaïs Ecuvillon 4 months ago

Cette fonctionnalité a sans doute besoin encore de discussion, j'ai donc ouvert un pad : https://pad.libre-entreprise.org/p/EO_Aide_%C3%A0_la_saisie_des_usagers

#15

Updated by Anaïs Ecuvillon 4 months ago

  • Status changed from En cours to Information nécessaire

Après échange dans le pad, voici le descriptif fonctionnel pour chiffrer :

L'objet de ce développement est d'aider les usagers lors de la saisie du formulaire :

  • modifier l'ordre d'affichage des éléments, pour avoir libellé/remarque/champ/erreur, pour éviter le décalage du champ lors de la saisie
  • contrôler à la volée uniquement les champs avec validation (et là je laisse les devs discuter du comment, comme ici : https://dev.entrouvert.org/issues/70037#note-9 )
  • indiquer visuellement les champs en erreur de manière plus explicite que simplement le message en bold noir
    • => associer symbole et couleur pour marquer de manière plus explicite le champ en erreur (picto ❌ et encadrer le champ d'un trait rouge)
  • indiquer visuellement (à la volée donc) quand un champ invalide a été corrigé par l'usager
    • en supprimant le picto ❌, l'encadré rouge et le message d'aide à la saisie.
  • permettre de personnaliser le message d'erreur, pas uniquement pour les regex, mais pour toutes les validations.

Et la proposition de description que je poserai dans Tracim :

Aide à la saisie des usagers
L'objet de ce développement est d'aider les usagers lors de la saisie du formulaire en contrôlant les champs en erreur à la volée (et non lors du chargement de la page suivante), avec une personnalisation possible de tous les messages d'erreurs et une indication visuelle quand le champ invalide à été corrigé par l'usager.

Fred, tu proposes de réfléchir visuellement par rapport à une intégration type, du coup, si c'est possible d'ajouter une capture de ce que ça rendrait, ça viendrait compléter la description qui est volontairement concise.

#16

Updated by Frédéric Péters 4 months ago

Fred, tu proposes de réfléchir visuellement par rapport à une intégration type, du coup, si c'est possible d'ajouter une capture de ce que ça rendrait, ça viendrait compléter la description qui est volontairement concise.

Voilà en pièce jointe sur base du style qu'on a dans l'intégration démo "grosboule-les-bains"; le premier rendu c'est le rendu erreur, le deuxième c'est erreur + champ en focus, le troisième c'est toujours focus mais le champ modifié/corrigé.

Ça te va ?

#17

Updated by Anaïs Ecuvillon 4 months ago

oui, je vais conserver uniquement les 2 derniers champs pour Tracim. Tu peux me confirmer le chiffrage ? Comme ça j'envoie avant mes congés.

#19

Updated by Chloé Girard 3 months ago

  • contrôle des champs en erreur à la volée (et non lors du chargement de la page suivante).
  • personnalisation possible de tous les messages d'erreurs ;
  • indication visuelle (à la volée) quand le champ invalide est corrigé par l'usager.

https://publik.tracim.fr/ui/workspaces/1/contents/html-document/1945?folder_open=1,1970

#20

Updated by Anaïs Ecuvillon 3 months ago

  • Due date set to 20 April 2023
  • Status changed from Information nécessaire to En cours

Financé par le club à hauteur de 15k€ HT. Livraison fin avril 2023.

Also available in: Atom PDF