amelioration(champs.erreurs): ETQ usager, je retrouve les erreurs sous les champs + les champs de type text/number sont au format dsfr 🫖🥖

[mfo]

sumup :

• les champs de type texte au format DSFR
• l'espacement des titres de section à la olivier
• les erreurs sous les champs
• les feedback RNA/SIRET/text area au format ds
• un peu de tech design pour faire cohabiter notre style avec le dsfr temporairement

preview complète :

Homogénéisation du compteur de caractère sur le champ de type textarea :

Homogénéisation des feedbacks sur le champ siret :

sur un form existant :

[what-the-diff]

PR Summary

• Improved error messages for invalid dossiers
  Fixes the error message displayed when a dossier is invalid for better clarity

• Added anchor link to error messages
  Includes an anchor link in error messages that directs users to the specific field needing correction

• Updated IBAN validation error message for consistency
  Standardizes the IBAN validation error message with other field validations by adding a "Le champ « l »" prefix

[Olivier-Marcellin]

j'ai plusieurs remarques/retours avec des propositions de styles et de comportements :

• dans l'évolution vers dsfr le bandeau d'information est réservé aux informations, il ne sert pas pour notifier toutes les erreurs car s'il y en a un grand nombre cela devient le bazar (à la place dans une autre feature, je propose une page récapitulative du formulaire avec les erreurs à corriger avant le dépôt)
• les erreurs sont notifiées au niveau des champs, et elle guident l'usager à rectifier ses erreurs directement après la saisie (quand il est sur le champ même s'il n'est pas contraint de le faire à ce moment-là)
• les champs comportent pour la plupart d'entre eux une description (pré-remplie dans le configurateur de champs côté admin) avec un exemple (pour guider et anticiper et limiter les erreurs), le message est composé dans une formulation directe par exemple “ Renseignez une adresse…” plutôt que “ Veuillez renseigner une adresse…” ou bien encore “ Le numéro de téléphone saisi doit être valide”
• les notifications d'erreurs sont composées en deux parties : l'erreur + la correction à faire par exemple par exemple “Le champ n’est pas valide. Renseigner un numéro à 10 chiffres” (la conjugaison est ici l'infinitif pour rester neutre) exemple “Le champ n'est pas valide. Saisir une date"

- autres remarques hors Scop notification des erreurs mais en lien : • pour les champs obligatoires l'astérisque colle le mot qui le précède sans espace et de la même couleur que le label (donc en noir) et en rouge comme le label lorsque erreur. En haut de la page est indiqué dans un composant Alerte "Sauf mention contraire, les champs précédés d’une astérisque ( * ) sont obligatoires. 
Votre dossier est enregistré après chaque modification, vous pouvez à tout moment fermer la fenêtre et reprendre plus tard là où vous en étiez." - Les champs facultatif sont mentionnés en toutes lettres et entre parenthèses comme ceci : "Libellé du champ (facultatif)” cela répond aux enjeux d'accessibilité. • pour les titres de sections, il y a des problèmes on dirait d'espacements, normalement d'après la doc dsfr ceux-ci sont indiqués dans le code et je les ai rappelé dans le fichier Figma

sur le fichier Figma, page Styles et comportements j'ai orthographié l'ensemble des messages d'erreurs pour tous les types de champs : https://www.figma.com/proto/YKcafywdYhT6ABFlmy5d56/Am%C3%A9lioration-vue-usagers?page-id=1%3A2&node-id=2681-125753&viewport=-19420%2C-41992%2C0.91&scaling=min-zoom&starting-point-node-id=2681%3A125753&show-proto-sidebar=1

[mfo]

merci @Olivier-Marcellin pour ces retours ; en l'état ça se voulait plus être un point d'architecture du code pour solliciter les collègues voir si on est assez mature sur les bases du code actuel pour tenter l'aventure.

mais tes retours sont interessants, mes réponses :

dans l'évolution vers dsfr le bandeau d'information est réservé aux informations, il ne sert pas pour notifier toutes les erreurs car s'il y en a un grand nombre cela devient le bazar (à la place dans une autre feature, je propose une page récapitulative du formulaire avec les erreurs à corriger avant le dépôt).

je comprends ton point mais une nuance reste. C'est un go ou un no-go ? A mon sens c'est un go car aujourd'hui il y a du support qui est chronophage (tant coté bizdev, que dev.. et de maniere pragmatique : cote usager, ils sont bloqués, on les debloque) lié aux erreurs sur le formulaire. En substance sur 1 semaine glissante : 4 retours :

1. https://secure.helpscout.net/conversation/2230610926/2028352?folderId=1653799
2. https://secure.helpscout.net/conversation/2202674693/2025725/
3. https://secure.helpscout.net/conversation/2226253935/2028035?folderId=1653799
4. https://secure.helpscout.net/conversation/2230610926/2028352?folderId=1653799

+ je crois que ces remontées au support concernent des dossiers de subvention (donc la ou il y a de la thune ; un gain pour l'usager. J'imagine donc qu'ils nous sollicitent uniquement si la demarche en vaut la peine).

Bref, aujourd'hui pour solutionner ça ETQ dev faisant du support : de manière très expérimentale, ± a chaque fois qu'un user revient avec "c'est bogué, j'ai remplis tous les champs mais ça marche pas", j'envoie un lien vers l'element input [ca me prends entre 30min/1h] et ça suffit pour debloquer l'user.

les erreurs sont notifiées au niveau des champs, et elle guident l'usager à rectifier ses erreurs directement après la saisie (quand il est sur le champ même s'il n'est pas contraint de le faire à ce moment-là)

nous avons des formulaires avec +- 100 champs, dans ce cas scroller pour identifier le champs en erreur ne me semble pas si évident, qu'en penses tu?

j'imagine qu'on peut remonter ça au DSFR, dans l'intermediaire je propose cette rustine qui pointe vers l'irritant afin de permettre a l'usager d'être autonome.

les champs comportent pour la plupart d'entre eux une description (pré-remplie dans le configurateur de champs côté admin) avec un exemple (pour guider et anticiper et limiter les erreurs), le message est composé dans une formulation directe par exemple “ Renseignez une adresse…” plutôt que “ Veuillez renseigner une adresse…” ou bien encore “ Le numéro de téléphone saisi doit être valide”

La locution des messages d'err est top ! point d'attention cependant : https://secure.helpscout.net/conversation/2202674693/2025725/. il arrive que des admins formulent mal le libellé (ici, demandant un RIB plutot qu'un IBAN... resulat, j'ai appelé l'usager, 30min au tel, pour identifier avec elle le problème en plus du lien de correction). bref, c'est une belle 1ere itération, mais on peut je pense anticiper plusieurs aller/retour en fonction du support.

les notifications d'erreurs sont composées en deux parties : l'erreur + la correction à faire par exemple par exemple “Le champ n’est pas valide. Renseigner un numéro à 10 chiffres” (la conjugaison est ici l'infinitif pour rester neutre) exemple “Le champ n'est pas valide. Saisir une date"

same c'est top! on tend vers ça (sur tout le site, sauf le formulaire usager. mais ça arrive !). isoler l'erreur et proposer une locution qui oriente sur la correction.

PS: pour les remarques hors scope je propose de se cantonner au périmêtre de ce sujet afin d'eviter de la frustration

[colinux]

Trop bien déjà ! Je tique juste un peu sur le rouge en gras mais à ce stade c'est un détail ;)

[Olivier-Marcellin]

je compile ici toutes mes remarques suite aux éléments d'intégration postés à ce jour de haut en bas sur les pages :

• bandeau d'information : dans le cadre du passage au DSFR ce bandeau sera dédié aux seules informations, ce ne sera plus un bandeau polyvalent pour marquer une à la fois une validation, une information, et la notification des erreurs
• les notifications en erreurs ont un composant dsfr = Alerte, celles-ci sont à faire figurer au dessus des champs concernés de façon à mieux guider les usagers
• une page récapitulative avant l'envoi du dossier a été maquettée (il s'agit d'une proposition à donner à tester et si concluant mise en prod.) on pourrait avoir une évolution en deux temps d'abord le composant alerte au dessus des champs puis une évolution avec une page récapitulative ou pas selon les tests (à discuter au préalable).
• la mention les champs suivis d'un astérisque est un composant Alerte avec l'état Information, le texte est : Les champs précédés d’un astérisque ( * ) sont obligatoires.
• sur la mise en page des champs : deux largeurs et non pas trois, soit une largeur pleine, et 50% sur 8 colonnes au maximum soit un corps de page de 656 px (cette largeur plus petite est plus confortable pour des usagers qui possèdent des petits écrans sans réduction de la largeur des champs, et facilite la lecture lorsque un sommaire latéral (proposition de maquette) est ouvert, de plus c'est une exigence côté DSFR : les champs = 6 à 8 colonnes maximum pour les formulaires (voir le Figma Modèles puis Formulaires). voir les maquettes et simulations sur grand et petit écran sur Figma.
• sur les types de champs l'astérisque semble être en gras et/ou avec une force de corps supérieur au label, or la graisse devrait être identique et le corps également, et mis en exposant.
• type de champ date : Le label devrait être Date * (le label est présent par défaut depuis l'interface de configuration des champs sans la nécessité pour l'admin de le remplir, il peut néanmoins le modifier. Remarque : cette règle d'affiche ne s'applique que pour des types de champs avec un label commun comme date, téléphone, etc. pour le reste le label est à définir par l'admin lors de la configuration du type de champ) ; la description Format attendu : JJ/MM/AAAA. Exemple : 01/12/2022 ; le champ rempli 12/06/2023 avec les slash de couleurs mention-grey les chiffres en action-high-grey ; l'icône dans le placeholder est calendar-2 et le texte d'erreur est Le champ n’est pas valide. Saisir une date, lorsque le champ est en erreur un filet vertical à gauche est affiché (depuis la version 1.9)
• type de champ date et heure : la proposition de maquette divise les champs date et heure, pour faciliter le remplissage et ce qui permet lorsqu'il y a eu erreur de la cibler soit sur la date soit sur l'heure
• type de champ explication : la proposition de maquette inclus les variantes avec explication rétractable
• type de champ nombre entier label à saisir par l'admin ; description Saisissez un nombre entier sans décimale ni fraction ; le champ est rempli par un nombre entier en Regular (pas en Italique) de couleur action-high-grey et il n'y a pas de fonctionnalité d'aide à la saisie (la Culture n'en veut pas) ; pour ce type de champ lorsque succès, le filet horizontal passe en vert après avoir saisi
• champ adresse électronique : la largeur est 50% pas pleine largeur ; une fonctionnalité d'import du mail est présente celle-ci est disponible sur desktop tandis que sur mobile l'icône de suppression remplace cette fonctionnalité
• texte long l'cône en bas à droite devrait être champ de saisie
• proposition d'évolutions des boutons d'actions également maquettés je ne préconise pas les boutons continuer dans la barre sticky car j'ai ajouté un ensemble de boutons ou alors je dois revoir ma copie, peut être en dissociant le bouton d'action principal en sticky des boutons secondaires utiles à la navigation (cas des formulaires à étapes) (à discuter)
• je ne détaille pas ici tous les ajustements, voir la page Styles et comportements des types de champs dans le fichier Figma qui détaille chacun des types de champs, j'ai fait des propositions pour l'IBAN par exemple avoir les espaces entre les séries de chiffres à la saisie apporterait de la lisibilité
• footer interne au formulaire : pas de ligne bleu
• prochaine étape : passer les boutons radios au dsfr :)
• réserve bleu sous le header : bouton inviter une personne : il y a une autre feature (attribué à Simon) avec l'idée que ce bouton change pour un type de champ ce qui permettrait à l'admin de le placer dans le formulaire (à discuter) ; j'ai revu entièrement le header selon le souhait de Philippe d'avoir le moins de contenu au dessus du formulaire

n'hésite pas à consulter les maquettes que je mets à jour dès qu'il y a une nouvelle conception de manière à avoir une vision d'ensemble et prospective :
https://www.figma.com/file/YKcafywdYhT6ABFlmy5d56/Am%C3%A9lioration-vue-usagers?type=design&node-id=1%3A2&mode=design&t=pDy45z588QJdtcqI-1

sinon c'est top ça commence à prendre forme (form) :)

[Olivier-Marcellin]

pour information voici un exemple de mise en page de formulaire au dsfr intégré par les développeurs https://template.incubateur.net/formulaire

[colinux]

retours en cours

[colinux]

a priori on peut pas hardcoder les formats qui dépendent de la locale du navigateur, mais c'est peut-être plus à refactorer dans une autre PR

[mfo]

yeap, tchak a fait la mm remarque. la j'ai juste deplacé ça ds la trad du champs pr avoir les erreurs "automatique" au bon endroit. a voir pr un controller js qui internationalise le format

[colinux]

c'est beau en tout cas, bravo !