Produits Entr'ouvert » Publik

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.

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

États erreur et succès :
https://gouvfr.atlassian.net/wiki/spaces/DB/pages/217088099/Champs+de+saisie+-+Input#Champs-de-saisie-(input)

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.

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é ?

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.

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.

À 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)

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

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

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.

• 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

Suite à cette remarque de Jean-Philippe Morvan sur la liste du club :

L'exemple le plus problématique pour moi étant les listes dont le mode d'affichage est "Liste" et dont l'option "Remarque" a été détournée de son usage intrinsèque à savoir pouvoir mettre un affichage permettant de laisser la valeur à vide.

J'ai ajouté en lien le ticket #22048, où je proposais de ne plus ainsi détourner "remarque".