Projet

Général

Profil

Development #75382

Formulaires: amélioration design des widgets en erreur

Ajouté par Thomas Jund (congés, retour le 29/04) il y a environ un an. Mis à jour il y a 12 mois.

Statut:
Fermé
Priorité:
Normal
Version cible:
-
Début:
13 mars 2023
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

Description

Étape pour la validation des champs à la volée.
Améliorer le design des champs en erreur.
Basé sur ce qui est proposé dans le design system gouv.fr: https://gouvfr.atlassian.net/wiki/spaces/DB/pages/217088099/Champs+de+saisie+-+Input#%5BhardBreak%5D%C3%89tats-erreur-et-succ%C3%A8s


Fichiers

Champs-de-saisie-Input-Système-de-Design-de-l-État-Obsolète-Confluence.png (13,7 ko) Champs-de-saisie-Input-Système-de-Design-de-l-État-Obsolète-Confluence.png Thomas Jund (congés, retour le 29/04), 13 mars 2023 16:50
proposition-champ-erreur.png (13,6 ko) proposition-champ-erreur.png Thomas Jund (congés, retour le 29/04), 16 mars 2023 14:30
field-on-error-allred-only-hint.png (45,5 ko) field-on-error-allred-only-hint.png Thomas Jund (congés, retour le 29/04), 04 avril 2023 17:28
field-on-error-mutiples-red.png (38,1 ko) field-on-error-mutiples-red.png Thomas Jund (congés, retour le 29/04), 04 avril 2023 17:28
Capture d’écran du 2023-04-06 11-44-52.png (30,7 ko) Capture d’écran du 2023-04-06 11-44-52.png Thomas Jund (congés, retour le 29/04), 06 avril 2023 11:51
Capture d’écran du 2023-04-11 15-24-18.png (14,3 ko) Capture d’écran du 2023-04-11 15-24-18.png Thomas Jund (congés, retour le 29/04), 11 avril 2023 15:27
anais-uniquement-erreur-et-champ-rouge.png (156 ko) anais-uniquement-erreur-et-champ-rouge.png Thomas Jund (congés, retour le 29/04), 17 avril 2023 09:42
anais-tout-meme-rouge.png (159 ko) anais-tout-meme-rouge.png Thomas Jund (congés, retour le 29/04), 17 avril 2023 09:42
proposition-thomas.png (159 ko) proposition-thomas.png Thomas Jund (congés, retour le 29/04), 17 avril 2023 09:42

Demandes liées

Lié à Publik - Development #70037: Aide à la saisie des usagers (validation des champs à la volée)Fermé10 octobre 202220 avril 2023

Actions

Historique

#1

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Nouveau à En cours

Thomas Jund (tjund) a ouvert une pull request sur Gitea concernant cette demande :

#2

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

Partage du même style entre `$form-style; classic & light`;
Modification du rouge de color-error pour avoir un bon contraste en a11y.

Il y a une 30aine de thèmes qui personnalisent les widgets en erreur à checker.
Image d'un input en erreur avec le thème de Marseille.

#3

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

  • Lié à Development #70037: Aide à la saisie des usagers (validation des champs à la volée) ajouté
#4

Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a environ un an

Dans #70037#note-15, on indiquait 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, ça me semble être un pré-requis pour mieux me rendre compte du rendu.

Et du coup, je me demande si ça ne rend pas mieux avec la remarque dans sa couleur initiale (et non en rouge).

Pour info, le système de desgin de l'état que tu pointes est obsolète, voici l'url qui t'intéresse : https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/champ-de-saisie

ça gagnerait à ce que l'espacement entre le champ et le message d'erreur soit + important. (Pas autant que celui du design d'Etat, mais plus que sur ta capture d'écran).

#7

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

2 variantes :

  • Version où le texte de commentaire reste en $font-color;
  • Version où je mixe $font-color et $error-color pour créer des variantes

J'ai encore un peu assombri le rouge par défaut de $error-color pour garantir qu'il ai un contraste suffisant si on pose un #eee en $body-background

Avis bienvenus

#8

Mis à jour par Frédéric Péters il y a environ un an

Perso ça fait très bizarre j'ai cru que le "Expression rationnelle ..." était une erreur pour le champ code postal avec un problème de marge. Peut-être que si la remarque avait été en rouge ça l'aurait moins fait. Dans la seconde, moins, mais ça peut venir en partie du fait que je sache désormais quoi regarder.

#9

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

Peut-être que si la remarque avait été en rouge ça l'aurait moins fait

Laisser la remarque en $font-color était une proposition d'Anaïs, et je suis ok avec ta remarque, ça "coupe" la relation entre le label et l'input.

Du coup, je pense que d'indiquer l'input en erreur à travers une bordure left plutôt que bottom serait pertinent :

  • lier graphiquement le label et le message d'erreur avec un liseré rouge vertical
  • pouvoir élargir la bordure rouge à 3px par défaut sans provoquer un décalage vertical du layout (parce que le widget ne s'agrandit pas)

(et on reste sur une bordure bottom pour le style light)

#10

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de En cours à Solution proposée
#11

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

Petit changement d'icon.
Après avoir passé en revue les différentes customisations existantes, il s'avère qu'une majorité reprend l'icon "point d'exclamation" de .pk-error, ce que je trouve tout à fait logique et cohérent.

#12

Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a environ un an

ok pour moi pour le point d'exclamation, idem pour la bordure à gauche plutôt qu'en bas. C'est même très bien.

Je ne sais plus si je l'ai déjà dit, mais le libellé du champ et la remarque en rouge, je trouve ça trop de rouge (je ne sais plus si ça fait partie du RGAA), le message d'erreur et la bordure rouge me semble suffisant.

Et dans tous les cas, si ça doit rester rouge, alors la remarque devrait utiliser le même rouge que le libellé et le message d'erreur et pas une couleur supplémentaire.

#13

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

alors la remarque devrait utiliser le même rouge que le libellé et le message d'erreur et pas une couleur supplémentaire.

Je trouvais ça trop plat graphiquement, qu'on perd au niveau de la hiérarchie de l'information.
J'ai aussi fait ce choix en rapport avec les listes radios, si tout est dans le même rouge c'est pas terrible.
Après il faudrait vraiment que tu puisses te rendre compte sur un cas réel, j'ai isolé le code de ce design "par défaut", permettant de le faire évoluer et le modifier sans impacter les thèmes qui ont déjà posé des personnalisations.
Aucun problème pour moi de me ranger à ton avis, mais pour éviter les "mauvais choix" parce que captures d'écran, est-ce qu'il ne serait pas envisageable de discuter de cela et faire des ajustements une fois le patch en test ?

#14

Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a environ un an

Est-ce que tu peux faire 3 captures d'écran pour demander l'avis à l'équipe en réu lundi prochain ? Genre :
  • tout en rouge (le même rouge)
  • tout en rouge (la remarque avec un autre rouge)
  • le libellé et la remarque dans la couleur initiale
#15

Mis à jour par Thomas Jund (congés, retour le 29/04) il y a environ un an

Les 3 captures d'écran demandées par Anaïs.
J'ai pris des captures des pages entières, avec uniquement 2 champs en erreur (la majorité du temps, avec la validation à la volée, il n'y aura qu'un champ à la fois en erreur) : un input et la liste radio, parce que les boutons radios ne prennent pas de couleur particulière lorsqu'ils sont en erreur.

  • Ma proposition, avec label et commentaire en rouge mais des rouges différents, générés automatiquement en fonction de la couleur "erreur" choisie.
  • Demande d'anais 1 : idem que précédemment, mais avec le même rouge pour tous les éléments
  • Demande d'Anais 2 : uniquement le champ et le message d'erreur en rouge, les labels et les commentaires ne bougent pas (dans le cas de la liste radio, seul le message d'erreur sera rouge)

Les captures ont été prisent avec le thème Marseille. Veuillez noter qu'en fonction du thème, le rendu et les contrastes seront différents.
J'aimerais qu'on évite de multiplier les tests et captures et qu'on choisisse parmis les 3 options proposées.

#16

Mis à jour par Benjamin Dauvergne il y a environ un an

N'hésitez pas à me dire si je suis à l'ouest, mais n'a-t-on pas dit que les messages d'erreur devaient maintenant se positionner entre le libellé et le/les champ/s ? ou alors c'est uniquement les remarques, oubliez.

PS: pour participer utilement; je préfère le 1, les deux autres, trop de rouge inutile, on ne sait plus où sont les alertes/erreurs.

#17

Mis à jour par Emmanuel Cazenave il y a environ un an

Je préfère la proposition de Thomas.

#18

Mis à jour par Olivier Renard il y a environ un an

le 1 est minimaliste et fonctionne.
le 2 est trop rouge, et noie l'erreur entre le libellé la remarque, l'erreur (donc pas à retenir).
le 3 est subtile et fonctionne avec la déclinaison de rouge.

Donc en premier choix 3 (proposition de Thomas) ou en second choix 1 (uniquement erreur et champ rouge)

#19

Mis à jour par Pierre Cros il y a environ un an

Plutôt pour la proposition de Thomas parce qu'elle permet aussi d'obtenir Anaïs 1 ou Anaïs 2 si on choisit dûment la couleur d'erreur.

#20

Mis à jour par Benjamin Dauvergne il y a environ un an

Aussi je trouve la bordure rouge à gauche trop "subtile" je préfère le choix du système de design de l'état d'une bordure rouge en dessous (https://www.systeme-de-design.gouv.fr/elements-d-interface/composants/champ-de-saisie/) et je trouve qu'il n'y a toujours pas assez d'espace entre les champs, idem ça rend mieux dans le SDD, l'espace supplémentaire entre les champs rend plus agréable le lien entre l'erreur et le champ.

#21

Mis à jour par Brice Mallet il y a environ un an

Préférence pour la version la plus simple : anais-uniquement-erreur-et-champ-rouge.png

#22

Mis à jour par Frédéric Péters il y a environ un an

Pour le moment le code correspond à la "version de Thomas" et comme il y avait de l'assentiment dessus c'est celui-là que j'ai actualisé et il n'est pas là pour faire autre chose, donc en tout cas pour ce vendredi ce qui va se trouver déployé et en capture dans les notes de mise à jour ça sera ça. Libre ensuite d'hurler lundi pour que Thomas rapidement propose le code pour autre chose.

#23

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Solution proposée à Solution validée

Frédéric Péters (fpeters) a approuvé une pull request sur Gitea concernant cette demande :

#24

Mis à jour par Robot Gitea il y a environ un an

  • Statut changé de Solution validée à Résolu (à déployer)

Frédéric Péters (fpeters) a mergé une pull request sur Gitea concernant cette demande :

#25

Mis à jour par Transition automatique il y a environ un an

  • Statut changé de Résolu (à déployer) à Solution déployée
#26

Mis à jour par Anaïs Ecuvillon → en congés, retour le 30/04 il y a 12 mois

et après test en condition réel, ce qui est déployé en recette fonctionne très bien. Belle fonctionnalité ! Merci Thomas.

#27

Mis à jour par Transition automatique il y a 10 mois

Automatic expiration

Formats disponibles : Atom PDF