Revenir en arrière sur la tremblote de tous les formulaires #5317

Open
opened 3 months ago by rastapopoulos · 9 comments
Owner

Pour une raison qui m'échappe totalement (et il semblerait que je ne sois pas le seul), tous les formulaires se mettent maintenant à trembler à chaque validation. Et ça en 4.1 en prod.

Je n'ai même pas souvenir de quand comment ça a été introduit, car ya aucun ticket ou PR spécifique à ça, ça a été ajouté au milieu d'un autre truc n'ayant rien à voir.

Le problème est que ce n'est pas juste un choix esthétique : faire trembler un élément, dans la majorité des interfaces, ça signifie une erreur, un truc qui ne s'est pas bien passé.

J'ai d'ailleurs déjà commencé à avoir quelques remarques là dessus ("tiens qu'est-ce que j'ai fait").

Il me semble qu'il faut carrément revenir en arrière là-dessus, et si on le désire, ne faire trembler que quand ya vraiment une erreur.

Pour une raison qui m'échappe totalement (et il semblerait que je ne sois pas le seul), *tous* les formulaires se mettent maintenant à trembler à *chaque* validation. Et ça en 4.1 en prod. Je n'ai même pas souvenir de quand comment ça a été introduit, car ya aucun ticket ou PR spécifique à ça, ça a été ajouté au milieu d'un autre truc n'ayant rien à voir. Le problème est que ce n'est pas juste un choix esthétique : faire trembler un élément, dans la majorité des interfaces, ça signifie **une erreur**, un truc qui ne s'est pas bien passé. J'ai d'ailleurs déjà commencé à avoir quelques remarques là dessus ("tiens qu'est-ce que j'ai fait"). Il me semble qu'il faut carrément revenir en arrière là-dessus, et si on le désire, ne faire trembler que quand ya vraiment une erreur.
rastapopoulos added the
formulaires
ergonomie
bug
labels 3 months ago
Owner

Ça ne concerne pas tous les formulaires à chaque validation, mais uniquement les quelques formulaires qui sont en ajax et dont le traiter() fait un appel à refuser_traiter_formulaire_ajax().

Dans ce scénario on a un premier post ajax avec un feedback visuel qui dit qui se passe quelque chose (opacité réduite, roue qui tourne), puis le serveur réponds "fuck recommence sans ajax" et là si ça marche ça marche, si ça marche pas ben c'est pareil ça mache pas et le premier feedback visuel continue à l'infini et il ne se passe plus rien.

Ce second feedback visuel ajouté permet donc

  1. de différencier les étapes
  2. en tant que développeur de savoir ce qui se passer et de remarquer que ça bloque au milieu le cas échéant
  3. quand un utilisateur remonte qu'un formulaire ne marche pas, on peut avoir une idée de où ça bloque selon ce qu'il a comme retour visuel

Ça a été introduit "au milieu de quelque chose" justement en réparant un formulaire qui ne marchait pas dans certaines circonstances et dont il était impossible de comprendre pourquoi et comment.

Maintenant c'est clair que j'ai fait un truc rapide sans réunir un panel d'utilisateurs pour comparer différents feedbacks visuels, et que par exemple sur le formulaire d'admin plugin qui est très haut le skew en degré introduit un gros déplacement, d'où les remarques.

Donc on peut travailler sur un feebback plus approprié, plus discret ou moins perturbant, mais par contre je pense pas du tout que ce soit une bonne idée de supprimer ce feedback visuel.

Ça ne concerne pas *tous* les formulaires à *chaque* validation, mais uniquement les *quelques* formulaires qui sont en ajax et dont le `traiter()` fait un appel à `refuser_traiter_formulaire_ajax()`. Dans ce scénario on a un premier post ajax avec un feedback visuel qui dit qui se passe quelque chose (opacité réduite, roue qui tourne), puis le serveur réponds "fuck recommence sans ajax" et là si ça marche ça marche, si ça marche pas ben c'est pareil ça mache pas et le premier feedback visuel continue à l'infini et il ne se passe plus rien. Ce second feedback visuel ajouté permet donc 1. de différencier les étapes 2. en tant que développeur de savoir ce qui se passer et de remarquer que ça bloque au milieu le cas échéant 3. quand un utilisateur remonte qu'un formulaire ne marche pas, on peut avoir une idée de où ça bloque selon ce qu'il a comme retour visuel Ça a été introduit "au milieu de quelque chose" justement en réparant un formulaire qui ne marchait pas dans certaines circonstances et dont il était impossible de comprendre pourquoi et comment. Maintenant c'est clair que j'ai fait un truc rapide sans réunir un panel d'utilisateurs pour comparer différents feedbacks visuels, et que par exemple sur le formulaire d'admin plugin qui est très haut le skew en degré introduit un gros déplacement, d'où les remarques. Donc on peut travailler sur un feebback plus approprié, plus discret ou moins perturbant, mais par contre je pense pas du tout que ce soit une bonne idée de supprimer ce feedback visuel.
cerdic added
amélioration
and removed
bug
labels 3 months ago

Ca vient de là : e6d9fe83b7 pour corriger #5256

Ca vient de là : https://git.spip.net/spip/spip/commit/e6d9fe83b7c072090b31adbf0512fa08dd3ab85d pour corriger https://git.spip.net/spip/spip/pulls/5256
Owner

Merci pour les explications, en effet il faudrait réfléchir à un retour visuel plus doux je pense. Et s'assurer aussi que ça fonctionne si les animations sont désactivées dans les navigateurs (prefers-reduced-motion).

Merci pour les explications, en effet il faudrait réfléchir à un retour visuel plus doux je pense. Et s'assurer aussi que ça fonctionne si les animations sont désactivées dans les navigateurs (prefers-reduced-motion).

Si ce signalement s'adresse aux devs, ne devrait-ce pas être un spip_log ou un console.log ?
(Et si les simples utilisateurs doivent aussi quand même le voir, ne devrait-ce pas plutôt être un message d'erreur ou un avertissement textuel auto explicatif ?)

Si ce signalement s'adresse aux devs, ne devrait-ce pas être un `spip_log` ou un `console.log` ? (Et si les simples utilisateurs doivent aussi quand même le voir, ne devrait-ce pas plutôt être un message d'erreur ou un avertissement textuel auto explicatif ?)
b_b added this to the 4.1 milestone 3 months ago
Poster
Owner

Donc on peut travailler sur un feebback plus approprié, plus discret ou moins perturbant, mais par contre je pense pas du tout que ce soit une bonne idée de supprimer ce feedback visuel.

Ah mais oui oui je suis d'accord, moi je dis surtout qu'il faut revenir sur le tremblotement, qui n'est à priori pas approprié quand il n'y a aucune erreur, je ne dis pas qu'il ne faut pas de retour du tout.

Yavait pas un message_ok affiché après quand yavait ce refuser ajax ? genre "Vous allez être redirigé…" ?

Si le JS reçoit bien l'info technique "recommance sans ajax", on pourrait pas effectivement afficher un truc plus clair ? Même si moins long qu'avant, une chaine "Redirection en cours…" ou bien ?

> Donc on peut travailler sur un feebback plus approprié, plus discret ou moins perturbant, mais par contre je pense pas du tout que ce soit une bonne idée de supprimer ce feedback visuel. Ah mais oui oui je suis d'accord, moi je dis surtout qu'il faut revenir *sur le tremblotement*, qui n'est à priori pas approprié quand il n'y a aucune erreur, je ne dis pas qu'il ne faut pas de retour du tout. Yavait pas un message_ok affiché après quand yavait ce refuser ajax ? genre "Vous allez être redirigé…" ? Si le JS reçoit bien l'info technique "recommance sans ajax", on pourrait pas effectivement afficher un truc plus clair ? Même si moins long qu'avant, une chaine "Redirection en cours…" ou bien ?
Owner

non il y a jamais eu de message et rien ne te dit que tu vas être redirigé, c'est possiblement juste que le form ne veut pas être traité en ajax et finira avec un message_ok etc

non il y a jamais eu de message et rien ne te dit que tu vas être redirigé, c'est possiblement juste que le form ne veut pas être traité en ajax et finira avec un `message_ok` etc
Poster
Owner

Bah même si ça redirige sur self, ça va vers une URL complète quoi, pas juste le rechargement d'un bloc précis. "Rechargement complet en cours…" sinon, un truc comme ça, si c'est pour donner une indication au visiteur classique. Pour les devs, ya console.log sinon

Bah même si ça redirige sur self, ça va vers une URL complète quoi, pas juste le rechargement d'un bloc précis. "Rechargement complet en cours…" sinon, un truc comme ça, si c'est pour donner une indication au visiteur classique. Pour les devs, ya console.log sinon
Owner

Concernant le type de retour visuel, ahma un message conviendrait mieux. Car la tremblote les premières fois que ça c'est produit j'ai pensé que c'était mon écran qui freezait ou que je devais changer la carte graphique. Sinon, ça fait quand même un peu trop gadget genre java qui calcule un tourbillon :)

Concernant le type de retour visuel, ahma un message conviendrait mieux. Car la tremblote les premières fois que ça c'est produit j'ai pensé que c'était mon écran qui freezait ou que je devais changer la carte graphique. Sinon, ça fait quand même un peu trop gadget genre java qui calcule un tourbillon :)
Collaborator

J'ai lu cette discussion, je la comprenais pas. Et puis il y a quelques secondes, j'ai eu cette tremblote. Et oui c'est incompréhensible pour l'utilisateurice lambda. Donc je vais dans le sens de tout le monde.

J'ai lu cette discussion, je la comprenais pas. Et puis il y a quelques secondes, j'ai eu cette tremblote. Et oui c'est incompréhensible pour l'utilisateurice lambda. Donc je vais dans le sens de tout le monde.
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.