Ergonomie du formulaire instituer objet #196

Merged
marcimat merged 3 commits from dev/instituer_ergo into master 2024-02-12 19:59:13 +01:00

Cette PR a pour but d'améliorer l'ergonomie du formulaire instituer générique pour tout objet, celui qui est sur les pages dédiées de chaque contenu, en suivant les idées évoquées par @touti dans le forum :
https://discuter.spip.net/t/amelioration-de-la-zone-de-changement-de-statut/153733/48

Le but est :

  • ne pas mélanger visualisation du statut actuel, avec les éléments d'interaction permettant de le changer
  • mieux comprendre qu'on peut changer ce statut, avec des termes explicites
  • sans permettre de le changer sans faire exprès

Sur l'implémentation :

  • le statut actuel est désormais toujours affiché, que ce soit éditable ou pas (= qu'on ait le droit de changer ou pas)
  • quand on a le droit de changer, les statuts possibles ne comprennent pas celui qui est déjà actif ! C'est bien plus compréhensible pour les gens maintenant :D
  • j'ai tenté d'être accessible dès le départ, mais on peut sûrement encore améliorer :
    1. ya un aria-expanded pour le bouton, mais vraiment il faudrait qu'on ait une lib/comportement générique pour ça, pour ne pas avoir à recoder ce comportement à chaque fois
    2. le formulaire utilise des vrais boutons radios, dans un bon fieldset.editer comme attendu désormais pour tous les radios, c'est vraiment la manière accessible de changer qui correspond à la maquette de Touti. On pourrait toujours styler mieux, masquer les radios et ne garder que les labels, ce genre, mais ça sera de l'amélioration par dessus ce HTML correct.
  • il manque encore un bouton "Annuler" à ajouter pour replier
  • les termes sont volontairement sans chaine de langue pour l'instant le temps qu'on décide quoi
  • j'ai pour l'instant utilisé "Statut" tout simplement pour le label qui précède le statut actuel
  • j'ai pour l'instant utilisé "Changer" pour le bouton qui déplie, car c'est le même ailleurs, sur le form de Date par exemple, et que c'est bien ça qu'on veut faire
  • j'ai pour l'instant utilisé "Nouveau statut" pour le legend du fieldset qui regroupe les radios

TODO :

  • ajouter un bouton Annuler
  • se mettre d'accord sur les labels ajoutés
  • faire des vraies chaines de langue
  • vérifier/améliorer l'accessibilité
  • éventuellement améliorer les styles graphiques (masquer les boutons radios ? etc)

Au départ :

Après ouverture, on choisit son statut :

Après validation :

Cette PR a pour but d'améliorer l'ergonomie du formulaire instituer générique pour tout objet, celui qui est sur les pages dédiées de chaque contenu, en suivant les idées évoquées par @touti dans le forum : https://discuter.spip.net/t/amelioration-de-la-zone-de-changement-de-statut/153733/48 Le but est : - ne pas mélanger visualisation du statut actuel, avec les éléments d'interaction permettant de le changer - mieux comprendre qu'on peut changer ce statut, avec des termes explicites - sans permettre de le changer sans faire exprès Sur l'implémentation : - le statut actuel est désormais toujours affiché, que ce soit éditable ou pas (= qu'on ait le droit de changer ou pas) - quand on a le droit de changer, les statuts possibles ne comprennent pas celui qui est déjà actif ! C'est bien plus compréhensible pour les gens maintenant :D - j'ai tenté d'être accessible dès le départ, mais on peut sûrement encore améliorer : 1) ya un aria-expanded pour le bouton, mais vraiment il faudrait qu'on ait une lib/comportement générique pour ça, pour ne pas avoir à recoder ce comportement à chaque fois 2) le formulaire utilise des vrais boutons radios, dans un bon fieldset.editer comme attendu désormais pour tous les radios, c'est vraiment la manière accessible de changer qui correspond à la maquette de Touti. On pourrait toujours styler mieux, masquer les radios et ne garder que les labels, ce genre, mais ça sera de l'amélioration par dessus ce HTML correct. - il manque encore un bouton "Annuler" à ajouter pour replier - les termes sont volontairement sans chaine de langue pour l'instant le temps qu'on décide quoi - j'ai pour l'instant utilisé "Statut" tout simplement pour le label qui précède le statut actuel - j'ai pour l'instant utilisé "Changer" pour le bouton qui déplie, car c'est le même ailleurs, sur le form de Date par exemple, et que c'est bien ça qu'on veut faire - j'ai pour l'instant utilisé "Nouveau statut" pour le legend du fieldset qui regroupe les radios TODO : - [x] ajouter un bouton Annuler - [x] se mettre d'accord sur les labels ajoutés - [x] faire des vraies chaines de langue - [x] vérifier/améliorer l'accessibilité - [x] éventuellement améliorer les styles graphiques (masquer les boutons radios ? etc) Au départ : ![](https://git.spip.net/attachments/38125df9-701e-4598-8ad4-0714e15efaad) Après ouverture, on choisit son statut : ![](https://git.spip.net/attachments/0e680d7b-c1b6-4d75-9f63-440961eef19b) Après validation : ![](https://git.spip.net/attachments/0ab8b9fb-ed15-4200-be8a-03fd1f4253e0)
rastapopoulos added 1 commit 2021-06-06 20:26:28 +02:00
Contributor

Je trouve ça pratique et clair.

Un détail sur les puces de statuts : ici, il me semble qu'elles sont purement décoratives, donc que le alt pourrrait être vide, et pas de title du tout.

Je trouve ça pratique et clair. Un détail sur les puces de statuts : ici, il me semble qu'elles sont purement décoratives, donc que le alt pourrrait être vide, et pas de title du tout.
Owner

éventuellement améliorer les styles graphiques

J'ai une question con, mais… je trouve ça bien la décoration actuelle qui met la couleur du statut actif en fond…

On peut pas garder ça ? (sans le sélect bien entendu)

> éventuellement améliorer les styles graphiques J'ai une question con, mais… je trouve ça bien la décoration actuelle qui met la couleur du statut actif en fond… On peut pas garder ça ? (sans le sélect bien entendu)
Owner

Bon, j'ai une impression désagréable que je vais exposer pour m'en débarrasser et me permettre de poursuivre et améliorer possiblement les rapports et discussions futures. L'impression du "couper l'herbe sous le pied" car on avait pas fini de discuter ni répondu à ma dernière proposition de discussion. Non pas que ce soit "ma" propale ou "ma" PR, juste la question de peut-on essayer au maximum de faire collectif et de prendre le temps pour s'accorder ?
Bref …

Ici, amha, Le terme "changer" et "nouveau statut" se téléscopent.
Dans SPIP on utilise le plus souvent "Nouvel objet" quand le titre n'existe pas encore On a ainsi Nouvel article, Nouvelle rubrique à la création.

Là on est sur un changement de statut (voire permutation), pas une création, quand il faut choisir de permuter avec la liste des autres statuts : "Choix du statut" / "Autres statuts" / "Statuts possibles"

Bon, j'ai une impression désagréable que je vais exposer pour m'en débarrasser et me permettre de poursuivre et améliorer possiblement les rapports et discussions futures. L'impression du "couper l'herbe sous le pied" car on avait pas fini de discuter ni répondu à ma dernière proposition de discussion. Non pas que ce soit "ma" propale ou "ma" PR, juste la question de peut-on essayer au maximum de faire collectif et de prendre le temps pour s'accorder ? Bref … Ici, amha, Le terme "changer" et "nouveau statut" se téléscopent. Dans SPIP on utilise le plus souvent "Nouvel objet" quand le titre n'existe pas encore On a ainsi Nouvel article, Nouvelle rubrique à la création. Là on est sur un changement de statut (voire permutation), pas une création, quand il faut choisir de permuter avec la liste des autres statuts : "Choix du statut" / "Autres statuts" / "Statuts possibles"
Author
Owner

En ce qui me concerne, depuis qu'on a la forge, les PR sont une manière bien plus pratique et simple de discuter une proposition précise, à partir du moment où ça devient un peu précis et implémentable (vs une discussion brainstorm qui débrousaille dans tous les sens), liée à une branche précise, qu'on peut alors voir s'améliorer au fur et à mesure qu'on modifie suivant les remarques que l'on débat (quand on commit dans la branche la PR est toujours à jour).

C'est bien pour ça qu'on appose le [WIP] dans le titre (ce qui interdit à la PR d'être fusionnable), et que j'ai listé les choses encore à y faire, dont, comme tu le dis aussi là : se mettre d'accord sur les labels.

Je suis bien d'accord pour le legend, tentons donc avec "Choix du statut" qui indique bien que dedans c'est un choix à faire. :)

En ce qui me concerne, depuis qu'on a la forge, les PR sont une manière bien plus pratique et simple de discuter une proposition précise, à partir du moment où ça devient un peu précis et implémentable (vs une discussion brainstorm qui débrousaille dans tous les sens), liée à une branche précise, qu'on peut alors voir s'améliorer au fur et à mesure qu'on modifie suivant les remarques que l'on débat (quand on commit dans la branche la PR est toujours à jour). C'est bien pour ça qu'on appose le [WIP] dans le titre (ce qui interdit à la PR d'être fusionnable), et que j'ai listé les choses encore à y faire, dont, comme tu le dis aussi là : se mettre d'accord sur les labels. Je suis bien d'accord pour le legend, tentons donc avec "Choix du statut" qui indique bien que dedans c'est un choix à faire. :)
rastapopoulos added 1 commit 2021-06-06 22:50:40 +02:00
rastapopoulos added 1 commit 2021-06-06 23:14:45 +02:00
rastapopoulos added 1 commit 2021-06-06 23:17:08 +02:00
Author
Owner

Il y a maintenant un bouton Annuler qui permet de fermer la modification, sur le même principe que dans le form de Date.

Il y a maintenant un bouton Annuler qui permet de fermer la modification, sur le même principe que dans le form de Date. ![](https://git.spip.net/attachments/67c3eb0c-dbab-4228-860b-05d78814f14a)
Owner

Quelques remarques:

  • J'aime bien comme le dit @marcimat le le fond de couleur transversal sous le libellé du statut. Je me demande d'ailleurs si le label Statut est nécessaire.
  • Quand le formulaire est fermé le bouton changer est mini en haut à droite. Il passe en grand en bas à droite lors de l'ouverture : je trouverais plus logique que le bouton soit toujours mini et toujours en bas à droite.
  • Choix du statut : pourquoi pas le libellé Changer de statut ?
Quelques remarques: * J'aime bien comme le dit @marcimat le le fond de couleur transversal sous le libellé du statut. Je me demande d'ailleurs si le label Statut est nécessaire. * Quand le formulaire est fermé le bouton changer est mini en haut à droite. Il passe en grand en bas à droite lors de l'ouverture : je trouverais plus logique que le bouton soit toujours mini et toujours en bas à droite. * Choix du statut : pourquoi pas le libellé Changer de statut ?
Author
Owner

Je me demande d'ailleurs si le label Statut est nécessaire.

Peut-être qu'on pourra le masquer accessiblement, mais ce label doit être présent il me semble, pour indiquer humainement à quoi correspond le texte qui suit. Sinon ça sort de nulle part, les gens non encore habitués aux objets de SPIP ne sont pas censés savoir d'eux-mêmes que "en cours de rédaction" ou "en attente de paiement" etc, sont explicitement "le champ Statut" de l'objet où on se trouve.

Pour moi il faut bien faire comprendre que c'est ce champ Statut très important.

je trouverais plus logique que le bouton soit toujours mini et toujours en bas à droite.

Ce n'est pas la "norme" ergonomique partout ailleurs. À chaque fois qu'on a un bouton qui ouvre une boite ou qui l'agrandit, il est en haut à droite de la boite à son état fermée. C'est le cas pour le formulaire de Date, et c'est le cas pour les boites de liaison. Ça évite notamment d'ajouter une ligne en plus, puisque la majorité du temps ça reste fermé. Pour moi c'est donc très cohérent avec le reste que ce bouton soit bien là.

Par ailleurs il ne faut pas confondre le bouton d'ouverture de la boite, avec la barre des boutons du formulaire lui-même. Là encore c'est cohérent avec le formulaire de Date :

  • le bouton pour ouvrir la boite est petit et discret, tout en étant voyant à droite (et quand le même type de bouton est toujours placé au même endroit, on s'attend alors à le trouver là et on le voit d'autant plus)
  • une fois le formulaire ouvert, il s'agit des vrais boutons du formulaire, qui n'ont plus de raison d'être minis : on a demandé explicitement à ouvrir un formulaire de modification, il ne s'agit plus de choses qu'on voudraient discrètes pour ne pas surcharger l'interface, il s'agit de la validation d'un formulaire ouvert.

Choix du statut : pourquoi pas le libellé Changer de statut ?

Pour moi :

  1. parce que c'est pas une action, c'est les boutons qui portent les actions, là c'est une description de la liste incluses dans ce groupe
  2. justement les actions, ya déjà des boutons "Changer", alors si le legend est lui aussi "Changer", c'est franchement confusionnant

Là encore c'est cohérent avec le form de Date : "Changer" sert à ouvrir la boite (première action qui va donner accès à la possibilité de changer), puis à valider le formulaire (deuxième action qui finalise le changement). Avec jamais deux fois le même mot affiché en même temps (une fois ouvert le premier bouton disparait).

> Je me demande d'ailleurs si le label Statut est nécessaire. Peut-être qu'on pourra le masquer accessiblement, mais ce label doit être présent il me semble, pour indiquer humainement à quoi correspond le texte qui suit. Sinon ça sort de nulle part, les gens non encore habitués aux objets de SPIP ne sont pas censés savoir d'eux-mêmes que "en cours de rédaction" ou "en attente de paiement" etc, sont explicitement "le champ Statut" de l'objet où on se trouve. Pour moi il faut bien faire comprendre que c'est ce champ Statut très important. > je trouverais plus logique que le bouton soit toujours mini et toujours en bas à droite. Ce n'est pas la "norme" ergonomique partout ailleurs. À chaque fois qu'on a un bouton qui ouvre une boite ou qui l'agrandit, il est en haut à droite de la boite à son état fermée. C'est le cas pour le formulaire de Date, et c'est le cas pour les boites de liaison. Ça évite notamment d'ajouter une ligne en plus, puisque la majorité du temps ça reste fermé. Pour moi c'est donc très cohérent avec le reste que ce bouton soit bien là. Par ailleurs il ne faut pas confondre le bouton d'ouverture de la boite, avec la barre des boutons du formulaire lui-même. Là encore c'est cohérent avec le formulaire de Date : - le bouton pour ouvrir la boite est petit et discret, tout en étant voyant à droite (et quand le même type de bouton est toujours placé au même endroit, on s'attend alors à le trouver là et on le voit d'autant plus) - une fois le formulaire ouvert, il s'agit des vrais boutons du formulaire, qui n'ont plus de raison d'être minis : on a demandé explicitement à ouvrir un formulaire de modification, il ne s'agit plus de choses qu'on voudraient discrètes pour ne pas surcharger l'interface, il s'agit de la validation d'un formulaire ouvert. > Choix du statut : pourquoi pas le libellé Changer de statut ? Pour moi : 1) parce que c'est pas une action, c'est les boutons qui portent les actions, là c'est une description de la liste incluses dans ce groupe 2) justement les actions, ya déjà des boutons "Changer", alors si le legend est lui aussi "Changer", c'est franchement confusionnant Là encore c'est cohérent avec le form de Date : "Changer" sert à ouvrir la boite (première action qui va donner accès à la possibilité de changer), puis à valider le formulaire (deuxième action qui finalise le changement). Avec jamais deux fois le même mot affiché en même temps (une fois ouvert le premier bouton disparait).
Owner

Perso je trouve cela hyper-compliqué

on donne un combo de 4 élements à lire

  • un radio
  • "+" un carre image (moche rond et carre)
  • "+" un label à lire
  • "+" un bouton "changer"

si vous voulez faire simple, autant avoir 3 ou 4 boutons simples:

  • demander la publication
  • publier
  • poubelle (avec un choix poubelle / archive)

ce que fait wp avec 2 boutons pending / publish (et c'est tout)

Perso je trouve cela hyper-compliqué on donne un combo de 4 élements à lire - un radio - "+" un carre image (moche rond et carre) - "+" un label à lire - "+" un bouton "changer" si vous voulez faire simple, autant avoir 3 ou 4 boutons simples: - demander la publication - publier - poubelle (avec un choix poubelle / archive) ce que fait wp avec 2 boutons pending / publish (et c'est tout)
Author
Owner

@erational personne a dit que "on voulait faire simple" :p (enfin si tu entends par là rapide, en peu de clics)

On veut faire plus compréhensible, plus explicite, et sans nous plus permettre de modifier en un clic sans le vouloir.

Le fonctionnement d'un formulaire classique est connu de tout le monde : on choisit une option dans des boutons radios, puis on valide quand on est sûr de soi. Le nombre de clics n'est pas très important, on est là sur la page dédiée d'un objet, pour faire une opération sensible (publier ou mettre une commande en payée, c'est pas à la légère), il ne s'agit pas de faire des opréations en masse ni d'aller super vite.

Et non on ne peut pas remplacer des choix de statuts par des verbes d'action comme ça à l'arrache du tout. Il s'agit là d'une amélioration ergonomique du fonctionnement existant. Qui je le rappelle est générique et vaut pour n'importe quels statuts de n'importe quels objets du monde. Donc tu ne dois surtout pas réfléchir à ça uniquement en imaginant les articles.

Pour les verbes d'actions, c'est un tout autre chantier, qui est celui des workflows décirt dans le brainstorm sur le forum. Mais ce n'est pas l'objet de cette PR dont le but est juste de rendre plus compréhensible et accessible le changement actuel basé sur les statuts.

@erational personne a dit que "on voulait faire simple" :p (enfin si tu entends par là rapide, en peu de clics) On veut faire plus compréhensible, plus explicite, et sans nous plus permettre de modifier en un clic sans le vouloir. Le fonctionnement d'un formulaire classique est connu de tout le monde : on choisit une option dans des boutons radios, puis on valide quand on est sûr de soi. Le nombre de clics n'est pas très important, on est là sur la page dédiée d'un objet, pour faire une opération sensible (publier ou mettre une commande en payée, c'est pas à la légère), il ne s'agit pas de faire des opréations en masse ni d'aller super vite. Et non on ne peut pas remplacer des choix de statuts par des verbes d'action comme ça à l'arrache du tout. Il s'agit là d'une amélioration ergonomique *du fonctionnement existant*. Qui je le rappelle est générique et vaut pour n'importe quels statuts de n'importe quels objets du monde. Donc tu ne dois surtout pas réfléchir à ça uniquement en imaginant les articles. Pour les verbes d'actions, c'est un tout autre chantier, qui est celui des workflows décirt dans le brainstorm sur le forum. Mais ce n'est pas l'objet de cette PR dont le but est juste de rendre plus compréhensible et accessible le changement actuel basé sur les statuts.
Owner

Testé, c'est pas mal du tout.
Avec le même nombre de clics qu'avant, on a quelque chose de plus clair et ergonomique. Et plus despace blanc énorme dessous qui sert à rien :)

Quelques remarques par-ci par-là :

  • Je trouve aussi que la couleur de fond autour du statut actuel avait son utilité, ça permet de repérer de suite quand on scanne rapidement la page de l'oeil. Mais bon, à voir comment pour que ça reste lisible, avant c'était autour du select qui avait lui-même un fond blanc, maintenant y a plus. Et je ne sais plus comment cet aspect était géré pour les statuts personnalisés des plugins.
  • Navigation clavier : ça serait pas mal de mettre le focus là où il faut quand on change le statut, idem form de date qui le met sur l'input. Mais ça pose question : ça se mettrait sur quelle entrée, la 1ère option de la liste ? Ou alors sur le statut qui suit logiquement dans le worklow ?
  • Détails visuels : peut-être mieux indiquer les limites du bloc qui s'affiche quand on change le statut. Un fond gris clair ou chose dans le genre.
Testé, c'est pas mal du tout. Avec le même nombre de clics qu'avant, on a quelque chose de plus clair et ergonomique. Et plus despace blanc énorme dessous qui sert à rien :) Quelques remarques par-ci par-là : * Je trouve aussi que la couleur de fond autour du statut actuel avait son utilité, ça permet de repérer de suite quand on scanne rapidement la page de l'oeil. Mais bon, à voir comment pour que ça reste lisible, avant c'était autour du select qui avait lui-même un fond blanc, maintenant y a plus. Et je ne sais plus comment cet aspect était géré pour les statuts personnalisés des plugins. * Navigation clavier : ça serait pas mal de mettre le focus là où il faut quand on change le statut, idem form de date qui le met sur l'input. Mais ça pose question : ça se mettrait sur quelle entrée, la 1ère option de la liste ? Ou alors sur le statut qui suit logiquement dans le worklow ? * Détails visuels : peut-être mieux indiquer les limites du bloc qui s'affiche quand on change le statut. Un fond gris clair ou chose dans le genre.
Author
Owner

La couleur de fond n'a strictement rien de générique actuellement, c'est défini en dur pour les 5 pauvres statuts des articles uniquement dans forms.css.html. Au niveau graphique ya que les puces de déclarées en générique et ce sont des images donc, pas des couleurs. On peut éventuellement remettre ça en dur pareil pour l'instant, en mettant la couleur de texte en rapport avec la luminosité du fond, sur la ligne qui indique le statut actuel uniquement.

Quand on clique sur le premier "Changer", la navigation clavier est déjà au bon endroit, ensuite quand on tabule, ça rentre bien immédiatement dans le fieldset.editer et ça parcourt les radios. Donc je ne vois pas trop le soucis. Et il n'y a pas de raison de mettre le focus sur un statut particulier, au contraire.

Ok oui pour un léger fond.

La couleur de fond n'a strictement rien de générique actuellement, c'est défini en dur pour les 5 pauvres statuts des articles uniquement [dans forms.css.html](https://git.spip.net/spip/spip/src/branch/master/prive/themes/spip/forms.css.html#L1526). Au niveau graphique ya que les puces de déclarées en générique et ce sont des images donc, pas des couleurs. On peut éventuellement remettre ça en dur pareil pour l'instant, en mettant la couleur de texte en rapport avec la luminosité du fond, sur la ligne qui indique le statut actuel uniquement. Quand on clique sur le premier "Changer", la navigation clavier est déjà au bon endroit, ensuite quand on tabule, ça rentre bien immédiatement dans le fieldset.editer et ça parcourt les radios. Donc je ne vois pas trop le soucis. Et il n'y a pas de raison de mettre le focus sur un statut particulier, au contraire. Ok oui pour un léger fond.
Owner

La couleur de fond n'a strictement rien de générique actuellement

Alternativement pour la couleur de fond, on pourrait juste faire :

  • objet publié : couleur de fond "positive" choisie en dur, la même pour tous les objets, quelque soit le statut correspondant à la publication
  • objet pas publié : rien

Et là pour le coup c'est générique, via #PUBLIE ou objet_test_si_publie.

Ça permettrait de repérer rapidement si l'objet est publié ou pas quand on scanne la page de l'oeil.

> La couleur de fond n'a strictement rien de générique actuellement Alternativement pour la couleur de fond, on pourrait juste faire : * objet publié : couleur de fond "positive" choisie en dur, la même pour tous les objets, quelque soit le statut correspondant à la publication * objet pas publié : rien Et là pour le coup c'est générique, via `#PUBLIE` ou `objet_test_si_publie`. Ça permettrait de repérer rapidement si l'objet est publié ou pas quand on scanne la page de l'oeil.
Author
Owner

Je plussoie à cette proposition : la déclaration de "quoi est publié" est explicite dans la déclaration des objets et ça peut être plusieurs statuts à la fois. Donc "être publié" est un concept de l'API en soi, sans rapport avec tel ou tel statut précis.

Du coup oui, seulement une unique couleur de mise en avant lorsque c'est le cas.

Je plussoie à cette proposition : la déclaration de "quoi est publié" est explicite dans la déclaration des objets et ça peut être plusieurs statuts à la fois. Donc "être publié" est un concept de l'API en soi, sans rapport avec tel ou tel statut précis. Du coup oui, seulement une unique couleur de mise en avant lorsque c'est le cas.
rastapopoulos added 1 commit 2021-11-13 12:43:57 +01:00
rastapopoulos added 1 commit 2021-11-13 12:49:43 +01:00
Author
Owner

Voilà modifié :

  1. comme demandé par plusieurs personnes, le bloc affichant le statut actuel se remet en bandeau vert (plus précisément : de la couleur variable "success" tout comme "reponse_formulaire_ok") SI l'objet est considéré comme étant "publié" par l'API, et donc quelque soit le statut dont il est question (ça peut être "publie" ou moult autre)
  2. comme évoqué par @tcharlss plus haut, j'ai ajouté pour tester de délimiter le bloc qui s'ouvre, et j'ai mis un léger fond de la couleur du thème, ainsi même longtemps après l'avoir ouvert, on voit tout de suite ce qui a été déplié bien délimité
Voilà modifié : 1) comme demandé par plusieurs personnes, le bloc affichant le statut actuel se remet en bandeau vert (plus précisément : de la couleur variable "success" tout comme "reponse_formulaire_ok") SI l'objet est considéré comme étant "publié" par l'API, et donc quelque soit le statut dont il est question (ça peut être "publie" ou moult autre) 2) comme évoqué par @tcharlss plus haut, j'ai ajouté pour tester de délimiter le bloc qui s'ouvre, et j'ai mis un léger fond de la couleur du thème, ainsi même longtemps après l'avoir ouvert, on voit tout de suite ce qui a été déplié bien délimité
Owner

Avec la capture qui va bien :)
Moi je trouve ça bien.

Avec la capture qui va bien :) Moi je trouve ça bien. ![](/attachments/583dcfbc-4ca1-49fd-aa6a-67a1ee3ad133)
rastapopoulos added 1 commit 2021-11-13 15:45:27 +01:00
Owner

Graphiquement je ne trouve pas cela terrible:

  • La liste est peu harmonieuse: les radios boutons et les images font des doublons peu harmonieux . Je trouve cela très lourd: un radio, une image carrée, un texte .... ca fait beaucoup d'informations pour l'oeil. On clique où ?
  • l'alignement du bouton changer ... ne faudrait mieux l'aligner avec 'publié en ligne' ? ou alors ne pas mettre le fond coloré sur "statut" ?

Je suis toujours un peu sceptique sur le bien fondé de cette amélioration.

Graphiquement je ne trouve pas cela terrible: * La liste est peu harmonieuse: les radios boutons et les images font des doublons peu harmonieux . Je trouve cela très lourd: un radio, une image carrée, un texte .... ca fait beaucoup d'informations pour l'oeil. On clique où ? * l'alignement du bouton changer ... ne faudrait mieux l'aligner avec 'publié en ligne' ? ou alors ne pas mettre le fond coloré sur "statut" ? Je suis toujours un peu sceptique sur le bien fondé de cette amélioration.
Author
Owner

Pour le bouton : j'ai argumenté plus haut la même chose déjà : tous les boutons "Changer" du même type, pour changer une information unitairement (dates, ajout de liens, etc), c'est toujours, toujours, calé en haut à droite. Donc ça fait une cohérence partout, on s'attend à le trouver là par mimétisme, et donc c'est facile à retrouver et comprendre.

Pour les puces, bah tu cliques bien où tu veux : toute la ligne est cliquable vu que c'est un label d'input. Donc même si tu hésites ça marchera forcément. Les boutons radios sont toujours de mon point de vue le meilleur élément pour choisir dans une liste de taille moyenne : tout est visible, c'est bien bien mieux qu'un select. Et le fait qu'il faille confirmer est très bien (et non pas que ça valide direct en cliquant sur le statut) : 1) c'est un changement de statut, c'est pas à la légère, on choisit puis qune confirme, et 2) le fait que ce soit avec une vraie validation finale permet des cas plus complexes : il est alors possible d'ouvrir un champ de commentaire pour tel statut par ex (obligation de commenter un refus ou autre), alors que c'est si c'est que des boutons direct, on peut rien complexfier quand on a besoin.

Perso je trouve ça bien plus lisible compréhensible qu'avant (cf les critiques de l'actuel de Touti), tout est plus clair et explicite. Et plus léger visuellement par défaut aussi (puisque pas de form tant qu'on ouvre pas avec le premier Changer).

Pour le bouton : j'ai argumenté plus haut la même chose déjà : tous les boutons "Changer" du même type, pour changer une information unitairement (dates, ajout de liens, etc), c'est toujours, toujours, calé en haut à droite. Donc ça fait une cohérence partout, on s'attend à le trouver là par mimétisme, et donc c'est facile à retrouver et comprendre. Pour les puces, bah tu cliques bien où tu veux : toute la ligne est cliquable vu que c'est un label d'input. Donc même si tu hésites ça marchera forcément. Les boutons radios sont toujours de mon point de vue le meilleur élément pour choisir dans une liste de taille moyenne : tout est visible, c'est bien bien mieux qu'un select. Et le fait qu'il faille confirmer est très bien (et non pas que ça valide direct en cliquant sur le statut) : 1) c'est un changement de statut, c'est pas à la légère, on choisit puis qune confirme, et 2) le fait que ce soit avec une vraie validation finale permet des cas plus complexes : il est alors possible d'ouvrir un champ de commentaire pour tel statut par ex (obligation de commenter un refus ou autre), alors que c'est si c'est que des boutons direct, on peut rien complexfier quand on a besoin. Perso je trouve ça bien plus lisible compréhensible qu'avant (cf les critiques de l'actuel de Touti), tout est plus clair et explicite. Et plus léger visuellement par défaut aussi (puisque pas de form tant qu'on ouvre pas avec le premier Changer).
Owner

2 petites images pour illustrer mon propos:

  • un essai avec un fond uniquement sur publié en ligne
  • une image pour illustrer le rythme graphique de la liste que je trouve peu harmonieux
2 petites images pour illustrer mon propos: * un essai avec un fond uniquement sur publié en ligne * une image pour illustrer le rythme graphique de la liste que je trouve peu harmonieux
rastapopoulos added 1 commit 2021-11-13 20:10:39 +01:00
rastapopoulos added 8 commits 2022-01-30 11:31:13 +01:00
Author
Owner

Pour moi c'est assez super comme ça, rien n'est jamais parfait mais c'est pour moi bien bien mieux que l'ancienne manière, plus ergonomique, plus explicite, plus simple à comprendre pour tout le monde (et je n'ai aucun soucis avec radio + picto au contraire, on pourra toujours s'amuser à faire une amélioration progressive par dessus pour masquer le radio et surligner la ligne choisie si on veut pousser le bouchon, en css/js…).

J'ai testé en arabe, c'est excellent aussi (faut juste traduire 2 chaines en plus), pareil en japonais.

Bref, pour moi ça peut être nettoyé, enlevage de WIP et fusionné pour 4.2. :)

Pour moi c'est assez super comme ça, rien n'est jamais parfait mais c'est pour moi bien bien mieux que l'ancienne manière, plus ergonomique, plus explicite, plus simple à comprendre pour tout le monde (et je n'ai aucun soucis avec radio + picto au contraire, on pourra toujours s'amuser à faire une amélioration progressive par dessus pour masquer le radio et surligner la ligne choisie si on veut pousser le bouchon, en css/js…). J'ai testé en arabe, c'est excellent aussi (faut juste traduire 2 chaines en plus), pareil en japonais. Bref, pour moi ça peut être nettoyé, enlevage de WIP et fusionné pour 4.2. :)
Owner

Cette PR est en WIP depuis 2 ans et n’a pas bougé.

Ça en est où ?

Cette PR est en WIP depuis 2 ans et n’a pas bougé. Ça en est où ?
rastapopoulos added 8 commits 2023-12-29 20:17:58 +01:00
Author
Owner

@marcimat Cf commentaire d'avant : sans du tout penser que c'est "parfait", la modif ici me semble déjà bien bien mieux qu'avant sur de nombreux points ergos. Du coup, quand bien même ça pourrait toujours continuer d'être amélioré ensuite, c'est déjà mieux de passer à cette version que la manière actuelle.

  • ne pas mélanger visualisation du statut actuel, avec les éléments d'interaction permettant de le changer
  • mieux comprendre qu'on peut changer ce statut, avec des termes explicites
  • sans permettre de le changer sans faire exprès
  • voir toutes les possibilités d'un coup quand on décide de le changer
  • laisser la possibilité à des plugins de faire des ajouts suivant les statuts (champs en plus à remplir, commentaires etc, donc sans valider d'un seul clic)

J'ai mis à jour la branche à jour avec le master du moment.

@marcimat Cf commentaire d'avant : sans du tout penser que c'est "parfait", la modif ici me semble déjà *bien bien mieux* qu'avant sur de nombreux points ergos. Du coup, quand bien même ça pourrait toujours continuer d'être amélioré ensuite, c'est déjà mieux de passer à cette version que la manière actuelle. > - ne pas mélanger visualisation du statut actuel, avec les éléments d'interaction permettant de le changer > - mieux comprendre qu'on peut changer ce statut, avec des termes explicites > - sans permettre de le changer sans faire exprès > - voir toutes les possibilités d'un coup quand on décide de le changer > - laisser la possibilité à des plugins de faire des ajouts suivant les statuts (champs en plus à remplir, commentaires etc, donc sans valider d'un seul clic) J'ai mis à jour la branche à jour avec le master du moment.
Owner

J'ai rebasé chez moi et fait quelques petites modifs qui me chagrinaient :

  • j'ai repris le label "Cet article est :" au lieu de l'impersonnel "Statut" puisqu'on a les chaines pour tous les objets et que ça me semble plus clair
  • du coup le second label au changement est "Changer vers :" au lieu de "Choix du statut :"
  • en terme de comportement j'étais gêné de cliquer à un endroit pour dépiler puis de devoir aller cliquer à un autre endroit pour refermer, j'ai donc mis le bouton "annuler" au même endroit que le "changer" initial
  • si on valide sans rien choisir le formulaire revient en erreur et dans ce cas on ne pouvait plus refermer (annuler), j'ai corrigé ce comportement

Cela donne les screenshot ci-dessous. J'ai mis dans une branche dev/instituer_ergo_cedric pour pas foirer cette PR mais si ça convient je peux envoyer ici.

Mon avis général c'est que au final on a un truc pas si mal qui en effet corrige nombre de critiques du formulaire et me parait bien utilisable. Je serai d'avis de merger dans la version de dev, et on affinera au fur et à mesure de l'usage et des feedbacks.

J'ai rebasé chez moi et fait quelques petites modifs qui me chagrinaient : - j'ai repris le label "Cet article est :" au lieu de l'impersonnel "Statut" puisqu'on a les chaines pour tous les objets et que ça me semble plus clair - du coup le second label au changement est "Changer vers :" au lieu de "Choix du statut :" - en terme de comportement j'étais gêné de cliquer à un endroit pour dépiler puis de devoir aller cliquer à un autre endroit pour refermer, j'ai donc mis le bouton "annuler" au même endroit que le "changer" initial - si on valide sans rien choisir le formulaire revient en erreur et dans ce cas on ne pouvait plus refermer (annuler), j'ai corrigé ce comportement Cela donne les screenshot ci-dessous. J'ai mis dans une branche dev/instituer_ergo_cedric pour pas foirer cette PR mais si ça convient je peux envoyer ici. Mon avis général c'est que au final on a un truc pas si mal qui en effet corrige nombre de critiques du formulaire et me parait bien utilisable. Je serai d'avis de merger dans la version de dev, et on affinera au fur et à mesure de l'usage et des feedbacks.
cerdic changed title from [WIP] Ergonomie du formulaire instituer objet to Ergonomie du formulaire instituer objet 2024-01-29 18:05:36 +01:00
Author
Owner

Ouais je pense que tu peux tout mettre dans cette branche :)

Ouais je pense que tu peux tout mettre dans cette branche :)
cerdic force-pushed dev/instituer_ergo from f7124113cb to 434aff617e 2024-01-29 18:30:25 +01:00 Compare
Owner

Juste, le message d'erreur n'est pas explicite.
"Vous ne pouvez pas choisir ce statut" alors qu'on a rien choisi, ce sera à améliorer.
Sinon ça me parait bien, et ça serait bien aussi de reporter en 4.2 quand ce sera ok.
Et je fermerai donc ma PR #5845

Juste, le message d'erreur n'est pas explicite. "Vous ne pouvez pas choisir ce statut" alors qu'on a rien choisi, ce sera à améliorer. Sinon ça me parait bien, et ça serait bien aussi de reporter en 4.2 quand ce sera ok. Et je fermerai donc ma PR https://git.spip.net/spip/spip/pulls/5845
Owner

oui ben je peux pas en fait. Franchement cette forge c'est du grand n'importe quoi. Donc mon force-push a été refusé par le hook de camille parce que dans la branche il y avait des commits à moi

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Info          This is not a fast-forward update.
remote: Info          cmd : ./hooks/update.d/update
remote: Info          arg1 refs/heads/dev/instituer_ergo
remote: Info          rastapopoulos@spip.org
remote: Info          arg2 f7124113cb7834a4e314ebd3067574477e93b341
remote: Info          rastapopoulos@spip.org
remote: Info          arg3 4c109e59fb0f05167a9500be035f81247dcf3c59
remote: Info          cedric@yterium.com
remote: Info          mb 9be7c44ab5762aae1928df0a62b2b4402834856e
remote: Info          isff y
remote: Info          is same author false
remote: Deny          This is not a fast-forward update.
remote: error: hook declined to update refs/heads/dev/instituer_ergo
To git.spip.net:spip/spip.git
 ! [remote rejected]     dev/instituer_ergo -> dev/instituer_ergo (hook declined)
error: failed to push some refs to 'git.spip.net:spip/spip.git'

Donc je me suis remis sur le dernier commit de @rastapopoulos j'ai force-pushé, là il semble avoir été d'accord

Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Info          This is not a fast-forward update.
remote: Info          cmd : ./hooks/update.d/update
remote: Info          arg1 refs/heads/dev/instituer_ergo
remote: Info          rastapopoulos@spip.org
remote: Info          arg2 f7124113cb7834a4e314ebd3067574477e93b341
remote: Info          rastapopoulos@spip.org
remote: Info          arg3 434aff617ef5aa3b54d0d360e7978e39ae801f1c
remote: Info          rastapopoulos@spip.org
remote: Info          mb 9be7c44ab5762aae1928df0a62b2b4402834856e
remote: Info          isff y
remote: Info          is same author true
remote: Grant         There are no more rules to check.  Grant access
remote:
remote: Visit the existing pull request:
remote:   https://git.spip.net/spip/spip/pulls/196
remote:
remote: . Processing 1 references
remote: Processed 1 references in total
To git.spip.net:spip/spip.git
 + f7124113c...434aff617 dev/instituer_ergo -> dev/instituer_ergo (forced update)

$ git lg -1
* 434aff617 - (HEAD -> dev/instituer_ergo, origin/dev/instituer_ergo) Suivre la proposition d'erational de ne mettre un fond que sur le statut lui-même sans le label (RastaPopoulos 76 minutes ago)

et ici il dit bien

cerdic a forcé dev/instituer_ergo de f7124113cb à 434aff617e

mais en vrai pas du tout : https://git.spip.net/spip/spip/commits/branch/dev/instituer_ergo on voit que la branche est restée sur les anciens commits de rasta, le force-push semble avoir foiré, on est donc dans un état foireux interméidaire

oui ben je peux pas en fait. Franchement cette forge c'est du grand n'importe quoi. Donc mon force-push a été refusé par le hook de camille parce que dans la branche il y avait des commits à moi ``` Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 remote: Info This is not a fast-forward update. remote: Info cmd : ./hooks/update.d/update remote: Info arg1 refs/heads/dev/instituer_ergo remote: Info rastapopoulos@spip.org remote: Info arg2 f7124113cb7834a4e314ebd3067574477e93b341 remote: Info rastapopoulos@spip.org remote: Info arg3 4c109e59fb0f05167a9500be035f81247dcf3c59 remote: Info cedric@yterium.com remote: Info mb 9be7c44ab5762aae1928df0a62b2b4402834856e remote: Info isff y remote: Info is same author false remote: Deny This is not a fast-forward update. remote: error: hook declined to update refs/heads/dev/instituer_ergo To git.spip.net:spip/spip.git ! [remote rejected] dev/instituer_ergo -> dev/instituer_ergo (hook declined) error: failed to push some refs to 'git.spip.net:spip/spip.git' ``` Donc je me suis remis sur le dernier commit de @rastapopoulos j'ai force-pushé, là il semble avoir été d'accord ``` Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 remote: Info This is not a fast-forward update. remote: Info cmd : ./hooks/update.d/update remote: Info arg1 refs/heads/dev/instituer_ergo remote: Info rastapopoulos@spip.org remote: Info arg2 f7124113cb7834a4e314ebd3067574477e93b341 remote: Info rastapopoulos@spip.org remote: Info arg3 434aff617ef5aa3b54d0d360e7978e39ae801f1c remote: Info rastapopoulos@spip.org remote: Info mb 9be7c44ab5762aae1928df0a62b2b4402834856e remote: Info isff y remote: Info is same author true remote: Grant There are no more rules to check. Grant access remote: remote: Visit the existing pull request: remote: https://git.spip.net/spip/spip/pulls/196 remote: remote: . Processing 1 references remote: Processed 1 references in total To git.spip.net:spip/spip.git + f7124113c...434aff617 dev/instituer_ergo -> dev/instituer_ergo (forced update) $ git lg -1 * 434aff617 - (HEAD -> dev/instituer_ergo, origin/dev/instituer_ergo) Suivre la proposition d'erational de ne mettre un fond que sur le statut lui-même sans le label (RastaPopoulos 76 minutes ago) ``` et ici il dit bien ``` cerdic a forcé dev/instituer_ergo de f7124113cb à 434aff617e ``` mais en vrai pas du tout : https://git.spip.net/spip/spip/commits/branch/dev/instituer_ergo on voit que la branche est restée sur les anciens commits de rasta, le force-push semble avoir foiré, on est donc dans un état foireux interméidaire
Owner

non @nicod on ne peux pas reporter pas ça en 4.2, pour 2 raisons

  • il faut le temps de laisser murir
  • si des gens utilisent le formulaire instituer dans des devs perso ça casse des choses potentiellement
non @nicod on ne peux pas reporter pas ça en 4.2, pour 2 raisons - il faut le temps de laisser murir - si des gens utilisent le formulaire instituer dans des devs perso ça casse des choses potentiellement
Owner

Et donc là @cam.lafit on fait quoi ? on dit que c'est la faute à quoi ? on peut pas continuer à perdre des branches, des commits et du temps et de l'énergie sur des problèmes comme ça sans arrêt...

Et donc là @cam.lafit on fait quoi ? on dit que c'est la faute à quoi ? on peut pas continuer à perdre des branches, des commits et du temps et de l'énergie sur des problèmes comme ça sans arrêt...
Owner
Owner

Ça me semble sympa, quelques idées pour aller dans le sens de @erational pour affiner ensuite :

  • masquer les radios dans cette liste
  • passer les labels de ces radios en font-weight normal (trop de gras tue le gras)
  • appliquer le gras uniquement sur l'item sélectionné (ou un autre effet)

Ce qui donnerait ça visuellement :

image

Ça me semble sympa, quelques idées pour aller dans le sens de @erational pour affiner ensuite : - masquer les radios dans cette liste - passer les labels de ces radios en font-weight normal (trop de gras tue le gras) - appliquer le gras uniquement sur l'item sélectionné (ou un autre effet) Ce qui donnerait ça visuellement : ![image](/attachments/5db5edf4-dd23-484a-a197-71e029856297)
Author
Owner

Je recherche dès que j'ai le temps, mais ergonomiquement uneétudeaméricainemontreque pour une liste de choix, les gens ne comprennent pas bien intuitivement si ya pas les éléments habituels. Là sans vrai input/check/radio impossible de savoir du premier coup d'œil comment ça marche : mauvaise pratique.

Il est donc mieux pour l'ergo d'avoir ces radios, ce qui n'empêchent pas de trouver comment mieux les styler avec panache plus tard.

Je recherche dès que j'ai le temps, mais ergonomiquement uneétudeaméricainemontreque pour une liste de choix, les gens ne comprennent pas bien intuitivement si ya pas les éléments habituels. Là sans vrai input/check/radio impossible de savoir du premier coup d'œil comment ça marche : mauvaise pratique. Il est donc mieux pour l'ergo d'avoir ces radios, ce qui n'empêchent pas de trouver comment mieux les styler avec panache plus tard.
Owner

Il est donc mieux pour l'ergo d'avoir ces radios, ce qui n'empêchent pas de trouver comment mieux les styler avec panache plus tard.

Désolé pour le bruit, on verra plus tard pour le panache :p

> Il est donc mieux pour l'ergo d'avoir ces radios, ce qui n'empêchent pas de trouver comment mieux les styler avec panache plus tard. Désolé pour le bruit, on verra plus tard pour le panache :p
Owner

Hello

@cerdic merci pour le troll. À la différence de vous les experts c'est que j'attends toujours de l'aide à ramer tout seul et me prendre dans la tronche vos sarcasmes, et vous êtes bien gentils de dire que c'est de la merde et sans oublier de bien la tartiner.

Je suis disponible et j'essaye d'analyser avec les bonnes volontés pour réparer la forge. Le seul dépôt qui pose problème est spip/spip. jusqu'à présent il me semble qu'aucun incident n'est remonté pour le reste de la plateforme. Ce qui est au vu de sa volumétrie est loin d'être un mauvais score.
De plus spip/spip est historiquement un dépot tordu avec un passif non neutre , qui se paye des reliquats de saloperie depuis des années, ce qui n'aide pas lors des analyses des dysfonctionnements.

J'ai rajouté des hooks de sécurité pour essayer de mieux borner le comportement de la forge et de comprendre ce qui se passe.
Suite aux retours de @marcimat on a pu identifier un bogue coté gitea qui semble à un problème de droit.
Pour ce faire j'ai déjà fait la montée de version de la forge pour éliminer un bogue éventuel dans le fonctionnement même de la forge.

Mais effectivement je ne fous rien, je cherche à vous empêcher de bosser et je cherche à vous emmerder, ah le salaud !!
Les bizous, l'amour de SPIP il est bien loin.

Au delà de ce coup de gueule qui me fatigue un peu à la longue, je regarde ce qu'il en est. Je pense qu'on peut déjà désactiver ce hook qui ne semble pas le plus efficace malgré tout.
Je regarde les droits fichier sur les head des branches concernés.

En complément, il me semble qu'il y a une mauvaise pratique concernant l'usage des push force. Ce qui ne change rien au problème technique mais qui sera aussi un point à clarifier de votre coté.

Edit :

Hello @cerdic merci pour le troll. À la différence de vous les experts c'est que j'attends toujours de l'aide à ramer tout seul et me prendre dans la tronche vos sarcasmes, et vous êtes bien gentils de dire que c'est de la merde et sans oublier de bien la tartiner. Je suis disponible et j'essaye d'analyser avec les bonnes volontés pour réparer la forge. Le seul dépôt qui pose problème est spip/spip. jusqu'à présent il me semble qu'aucun incident n'est remonté pour le reste de la plateforme. Ce qui est au vu de sa volumétrie est loin d'être un mauvais score. De plus spip/spip est historiquement un dépot tordu avec un passif non neutre , qui se paye des reliquats de saloperie depuis des années, ce qui n'aide pas lors des analyses des dysfonctionnements. J'ai rajouté des hooks de sécurité pour essayer de mieux borner le comportement de la forge et de comprendre ce qui se passe. Suite aux retours de @marcimat on a pu identifier un bogue coté gitea qui semble à un problème de droit. Pour ce faire j'ai déjà fait la montée de version de la forge pour éliminer un bogue éventuel dans le fonctionnement même de la forge. Mais effectivement je ne fous rien, je cherche à vous empêcher de bosser et je cherche à vous emmerder, ah le salaud !! Les bizous, l'amour de SPIP il est bien loin. Au delà de ce coup de gueule qui me fatigue un peu à la longue, je regarde ce qu'il en est. Je pense qu'on peut déjà désactiver ce hook qui ne semble pas le plus efficace malgré tout. Je regarde les droits fichier sur les head des branches concernés. En complément, il me semble qu'il y a une mauvaise pratique concernant l'usage des push force. Ce qui ne change rien au problème technique mais qui sera aussi un point à clarifier de votre coté. Edit : * le head a été forcé de la branche * j'ai coupé le cache redis pour voir * j'ai trouvé un vieux ticket https://github.com/go-gitea/gitea/issues/4835 * j'ai ouvert une nouveau ticket https://github.com/go-gitea/gitea/issues/28986
Owner

Bonjour

Le head sur le serveur concernant la branche n'a pas été actualisé.
J'ai forcé l'information de f7124113cb vers 434aff617e ce qui permet de restaurer de ce que j'ai compris la navigation de la branche
https://git.spip.net/spip/spip/src/branch/dev/instituer_ergo

Cela ne répare par l'interface de merge pour la PR en soit. Il y a d'autres données en base de donnée qui n'ont pas du s'aligner pour ce faire. Un commit normal sur la branche pourrait restaurer les information manquantes pour rétablir l'interface.
C'est ce que j'ai pu constater sur d'autres PR où le problème s'est présenté.

Je ne vois pas de problème de droit dans le git bare, je viens de solliciter l'équipe gitea pour voir si un cas connu ou si c'est bien un problème interne au dépot.

Bonjour Le head sur le serveur concernant la branche n'a pas été actualisé. J'ai forcé l'information de f7124113cb7834a4e314ebd3067574477e93b341 vers 434aff617ef5aa3b54d0d360e7978e39ae801f1c ce qui permet de restaurer de ce que j'ai compris la navigation de la branche https://git.spip.net/spip/spip/src/branch/dev/instituer_ergo Cela ne répare par l'interface de merge pour la PR en soit. Il y a d'autres données en base de donnée qui n'ont pas du s'aligner pour ce faire. Un commit normal sur la branche pourrait restaurer les information manquantes pour rétablir l'interface. C'est ce que j'ai pu constater sur d'autres PR où le problème s'est présenté. Je ne vois pas de problème de droit dans le git bare, je viens de solliciter l'équipe gitea pour voir si un cas connu ou si c'est bien un problème interne au dépot.
cerdic added 3 commits 2024-01-30 09:57:27 +01:00
Owner

Oui désolé, je comprends que tu sois fatigué, et visiblement tout le monde l'est un peu...

J'ai donc fait un pull sur la branche, et son head est revenu sur 434aff617

$ git fetch origin dev/instituer_ergo
From git.spip.net:spip/spip
 * branch                dev/instituer_ergo -> FETCH_HEAD
 + f7124113c...434aff617 dev/instituer_ergo -> origin/dev/instituer_ergo  (forced update)
$ git lg -4
* 4c109e59f - (HEAD -> dev/instituer_ergo, origin/dev/instituer_ergo_cedric, dev/instituer_ergo_cedric) fix: apres erreur on peut toujours refermer le formulaire + le bouton changer/annuler est au même endroit l'un prenant la place de l'autre selon le stattut ouvert/ferme + une classe 'form-closed' sur le bloc div.instituer_objet que l'on ajoute/enleve et des CSS pour gerer l'affichage du form et des boutons selon l'etat (Cerdic 16 hours ago)
* 8406e5b44 - chores: code mort (Cerdic 16 hours ago)
* abc3f889c - fix: reprendre le label historique 'cet article est..' au lieu de 'Statut', et 'Changer vers' au lieu de 'Chois du statut' (Cerdic 16 hours ago)
* 434aff617 - (origin/dev/instituer_ergo) Suivre la proposition d'erational de ne mettre un fond que sur le statut lui-même sans le label (RastaPopoulos 17 hours ago)

Du coup j'ai push mes commits par dessus

$ git push origin dev/instituer_ergo
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote:
remote: Visit the existing pull request:
remote:   https://git.spip.net/spip/spip/pulls/196
remote:
remote: . Processing 1 references
remote: Processed 1 references in total
To git.spip.net:spip/spip.git
   434aff617..4c109e59f  dev/instituer_ergo -> dev/instituer_ergo

et ça semble bon, la branche semble ok et la PR est revenue dans un état prête à merger donc ça semble bon, merci

Oui désolé, je comprends que tu sois fatigué, et visiblement tout le monde l'est un peu... J'ai donc fait un pull sur la branche, et son head est revenu sur `434aff617` ``` $ git fetch origin dev/instituer_ergo From git.spip.net:spip/spip * branch dev/instituer_ergo -> FETCH_HEAD + f7124113c...434aff617 dev/instituer_ergo -> origin/dev/instituer_ergo (forced update) ``` ``` $ git lg -4 * 4c109e59f - (HEAD -> dev/instituer_ergo, origin/dev/instituer_ergo_cedric, dev/instituer_ergo_cedric) fix: apres erreur on peut toujours refermer le formulaire + le bouton changer/annuler est au même endroit l'un prenant la place de l'autre selon le stattut ouvert/ferme + une classe 'form-closed' sur le bloc div.instituer_objet que l'on ajoute/enleve et des CSS pour gerer l'affichage du form et des boutons selon l'etat (Cerdic 16 hours ago) * 8406e5b44 - chores: code mort (Cerdic 16 hours ago) * abc3f889c - fix: reprendre le label historique 'cet article est..' au lieu de 'Statut', et 'Changer vers' au lieu de 'Chois du statut' (Cerdic 16 hours ago) * 434aff617 - (origin/dev/instituer_ergo) Suivre la proposition d'erational de ne mettre un fond que sur le statut lui-même sans le label (RastaPopoulos 17 hours ago) ``` Du coup j'ai push mes commits par dessus ``` $ git push origin dev/instituer_ergo Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 remote: remote: Visit the existing pull request: remote: https://git.spip.net/spip/spip/pulls/196 remote: remote: . Processing 1 references remote: Processed 1 references in total To git.spip.net:spip/spip.git 434aff617..4c109e59f dev/instituer_ergo -> dev/instituer_ergo ``` et ça semble bon, la branche semble ok et la PR est revenue dans un état prête à merger donc ça semble bon, merci
cerdic added 2 commits 2024-01-30 10:24:30 +01:00
Owner

Du coup j'ai corrigé le message d'erreur en l'absence de selection + allégé les choix en supprimant le cadre dans le cadre et j'ai repris la proposition de @b_b pour ne mettre en gras que le statut sélectionné

Pour les radios je pense que c'est le voisinage avec la puce qui n'est pas totalement heureux. Peut-être il faudrait aligner la puce un peu mieux, ou la mettre à gauche du radio, il y a peut-être un peu à affiner là dessus sans contrevenir aux bonnes pratiques, mais je pense qu'on pourrait considérer qu'on a atteint un point acceptable et merger, quitte à améliorer progressivement avec d'autres PR ensuite, ce sera plus simple que cette PR fleuve...

Du coup j'ai corrigé le message d'erreur en l'absence de selection + allégé les choix en supprimant le cadre dans le cadre et j'ai repris la proposition de @b_b pour ne mettre en gras que le statut sélectionné Pour les radios je pense que c'est le voisinage avec la puce qui n'est pas totalement heureux. Peut-être il faudrait aligner la puce un peu mieux, ou la mettre à gauche du radio, il y a peut-être un peu à affiner là dessus sans contrevenir aux bonnes pratiques, mais je pense qu'on pourrait considérer qu'on a atteint un point acceptable et merger, quitte à améliorer progressivement avec d'autres PR ensuite, ce sera plus simple que cette PR fleuve...
Owner

mais je pense qu'on pourrait considérer qu'on a atteint un point acceptable et merger

+1

> mais je pense qu'on pourrait considérer qu'on a atteint un point acceptable et merger +1
b_b approved these changes 2024-01-30 10:38:03 +01:00
cerdic approved these changes 2024-01-30 10:44:44 +01:00
Owner

Hello

Je vois que gitea considére qu'il y un rebase à faire, il est possible qu'au moment du merge ça se comporte mal. Il est possible que le pointeur sur master soit bloqué si c'est le cas merci de me bipper de suite que je corrige le dépot avant tout nouveau commit.

Pour le reste pas d'avis.

Hello Je vois que gitea considére qu'il y un rebase à faire, il est possible qu'au moment du merge ça se comporte mal. Il est possible que le pointeur sur master soit bloqué si c'est le cas merci de me bipper de suite que je corrige le dépot avant tout nouveau commit. Pour le reste pas d'avis.
marcimat force-pushed dev/instituer_ergo from c49b8113d1 to 83f02bfb3f 2024-01-31 10:31:49 +01:00 Compare
Owner

Hello there,

Je viens de squasher tous les commits et de regarder un peu.

Il reste quelques points à traiter : 

  • Créer les chaînes de langue Choisissez un nouveau statut et Changer vers :

En cas d’erreur:

  • Le fond rouge est à moitié sur le texte Changer vers :
  • le border radius autour de la liste est bof

Par ailleurs je suis partagé sur 2 points :

  • Ma lecture est la suivante "Cet article est : Changer ; Publié en ligne", et je trouve cela assez bizarre.
  • Il faut vraiment cliquer le radio ou son texte, mai l’espace blanc à droite des statuts n’est pas cliquable, ce qui me semble peu pratique ; Mais ça voudrait dire passer sur du flex sur le .choix et le .label je présume.
Hello there, Je viens de squasher tous les commits et de regarder un peu. Il reste quelques points à traiter :  - Créer les chaînes de langue `Choisissez un nouveau statut` et `Changer vers :` En cas d’erreur: - Le fond rouge est à moitié sur le texte `Changer vers :` - le border radius autour de la liste est bof Par ailleurs je suis partagé sur 2 points : - Ma lecture est la suivante "Cet article est : Changer ; Publié en ligne", et je trouve cela assez bizarre. - Il faut vraiment cliquer le radio ou son texte, mai l’espace blanc à droite des statuts n’est pas cliquable, ce qui me semble peu pratique ; Mais ça voudrait dire passer sur du flex sur le .choix et le .label je présume.
Owner

Il reste quelques points à traiter : 

  • Créer les chaînes de langue Choisissez un nouveau statut et Changer vers :

+1. "Nouveau statut : " peut être ?

En cas d’erreur:

  • Le fond rouge est à moitié sur le texte Changer vers :
  • le border radius autour de la liste est bof

+1

Par ailleurs je suis partagé sur 2 points :

  • Ma lecture est la suivante "Cet article est : Changer ; Publié en ligne", et je trouve cela assez bizarre.

+1. Pour le bouton : "Valider" ?

  • Il faut vraiment cliquer le radio ou son texte, mai l’espace blanc à droite des statuts n’est pas cliquable, ce qui me semble peu pratique ; Mais ça voudrait dire passer sur du flex sur le .choix et le .label je présume.

Je passe toujours les .choix en flex, côté public et privé, pour un affichage plus propre.

.formulaire_spip .choix {
  display: flex;
  align-items: center;
  gap: .75rem;
}

.formulaire_spip .choix .radio, 
.formulaire_spip .choix .checkbox {
  margin: 0;
  flex-shrink: 0;
  /* et en option, pour le côté esthétique */
  transform: scale(1.2);
  accent-color: #bc2612; /* ma couleur primaire */
}

.formulaire_spip .choix label {
  margin: 0;
}
> Il reste quelques points à traiter :  > - Créer les chaînes de langue `Choisissez un nouveau statut` et `Changer vers :` +1. "Nouveau statut : " peut être ? > En cas d’erreur: > - Le fond rouge est à moitié sur le texte `Changer vers :` > - le border radius autour de la liste est bof +1 > Par ailleurs je suis partagé sur 2 points : > - Ma lecture est la suivante "Cet article est : Changer ; Publié en ligne", et je trouve cela assez bizarre. +1. Pour le bouton : "Valider" ? > - Il faut vraiment cliquer le radio ou son texte, mai l’espace blanc à droite des statuts n’est pas cliquable, ce qui me semble peu pratique ; Mais ça voudrait dire passer sur du flex sur le .choix et le .label je présume. Je passe toujours les `.choix` en flex, côté public et privé, pour un affichage plus propre. ```css .formulaire_spip .choix { display: flex; align-items: center; gap: .75rem; } .formulaire_spip .choix .radio, .formulaire_spip .choix .checkbox { margin: 0; flex-shrink: 0; /* et en option, pour le côté esthétique */ transform: scale(1.2); accent-color: #bc2612; /* ma couleur primaire */ } .formulaire_spip .choix label { margin: 0; } ```
Owner

A part pour se fixer un "avant c'était mieux" je ne pige toujours pas pourquoi vous voulez garder "Cet article est :" lorsqu'on doit en plus indiquer ensuite qu'on change de statut ! "Cet article est:" semble une formule qui ne signifie pas grand chose, on pourrait mettre aussi des lieux des verbes ou des adjectifs à la suite. "Cet article est super/magnifique" "Cet article est en dehors de la zone de confort."

Statut tout court, c'est quand même simple, ça marche avec tous les objets, et on a besoin dessous seulement d'un bouton changer et un bouton valider. Sans autre explication. L'interface de gestion est simplifiée grandement et l'UX aussi.

En plus du fait que lors de toutes les formations à l'interface on indique que pour changer de statut, on va sur "Cet article est", ben, pas trop, aller à la boite de statut c'est bien aussi.

voilou :)

A part pour se fixer un "avant c'était mieux" je ne pige toujours pas pourquoi vous voulez garder "Cet article est :" lorsqu'on doit en plus indiquer ensuite qu'on change de statut ! "Cet article est:" semble une formule qui ne signifie pas grand chose, on pourrait mettre aussi des lieux des verbes ou des adjectifs à la suite. "Cet article est super/magnifique" "Cet article est en dehors de la zone de confort." Statut tout court, c'est quand même simple, ça marche avec tous les objets, et on a besoin dessous seulement d'un bouton changer et un bouton valider. Sans autre explication. L'interface de gestion est simplifiée grandement et l'UX aussi. En plus du fait que lors de toutes les formations à l'interface on indique que pour changer de statut, on va sur "Cet article est", ben, pas trop, aller à la boite de statut c'est bien aussi. voilou :)
Owner

Ah oui, aussi un autre point concernant les éléments graphiques devant les statuts, et la nécessité de simplifier la compréhension de l'utilisation.

Je relis le fil et je vois que tout le monde est ok pour faire sauter les boutons radios devant qui sont comme une redondance des éléments graphiques.
En modifiant les éléments graphiques avec un on/off visualisable (comme une visu cochée par exemple), on pourrait peut-être masquer les radios même si R dit

uneétudeaméricainemontreque pour une liste de choix, les gens ne comprennent pas bien intuitivement si ya pas les éléments habituels.

par ailleurs, argument en faveur de faire sauter les radios, quand on change le statut sur une liste d'articles, on comprend que le carré vert signifie statut publié et qu'on peut en changer pour un carré orange sans qu'il n'y est de bouton radio.

Ah oui, aussi un autre point concernant les éléments graphiques devant les statuts, et la nécessité de simplifier la compréhension de l'utilisation. Je relis le fil et je vois que tout le monde est ok pour faire sauter les boutons radios devant qui sont comme une redondance des éléments graphiques. En modifiant les éléments graphiques avec un on/off visualisable (comme une visu cochée par exemple), on pourrait peut-être masquer les radios même si R dit > uneétudeaméricainemontreque pour une liste de choix, les gens ne comprennent pas bien intuitivement si ya pas les éléments habituels. par ailleurs, argument en faveur de faire sauter les radios, quand on change le statut sur une liste d'articles, on comprend que le carré vert signifie statut publié et qu'on peut en changer pour un carré orange sans qu'il n'y est de bouton radio.
Author
Owner

Je dis justement qu'il ne faut rien faire si on ne remplace pas par un truc similaire qui ergonomiquement montre c'est que c'est une liste de choix à pré-cocher avant de valider. Alors que si ya rien on peut penser que ça fait une action directement. On peut rendre plus joli avec un autre style, mais il faut que ça fasse "comme si" des cases/radios à cocher.

Ce qui est très exactement le cas des puces rapides (qui ne marchent surtout que comme raccourcis pour les gens ayant des bons yeux et des bonnes mains avec souris) : ce sont des liens-boutons qui font une action immédiate, pas du tout un formulaire à choisir puis valider à la fin. C'est là toute la différence.

(Et pour le cas du vrai gros form en haut de page, ça doit bien rester un vrai formulaire, car c'est justement ça qui permet par pipelines d'ajouter des complexités si besoin comme ajouter un commentaire à remplir obligatoirement pour tel statut, ou autres subtilités, faut pas que ce soit une action directe).

Je dis justement qu'il ne faut rien faire *si on ne remplace pas par un truc similaire* qui ergonomiquement montre c'est que c'est une liste de choix à pré-cocher *avant de valider*. Alors que si ya rien on peut penser que ça fait une action directement. On peut rendre plus joli avec un autre style, mais il faut que ça fasse "comme si" des cases/radios à cocher. Ce qui est très exactement le cas des puces rapides (qui ne marchent surtout que comme raccourcis pour les gens ayant des bons yeux et des bonnes mains avec souris) : ce sont des liens-boutons qui font une action immédiate, pas du tout un formulaire à choisir puis valider à la fin. C'est là toute la différence. (Et pour le cas du vrai gros form en haut de page, ça doit bien rester un vrai formulaire, car c'est justement ça qui permet par pipelines d'ajouter des complexités *si besoin* comme ajouter un commentaire à remplir obligatoirement pour tel statut, ou autres subtilités, faut pas que ce soit une action directe).
Owner

Ok, donc on reste bien sur un formulaire avec action/validation
voici une proposition à voir, avec les explications de l'image jointe

1/ intitulés simplifiés
2/ le bouton "Changer/Annuler" descend sous la liste des statuts
3/ fond gris pour différencier le bloc qui s'est ouvert
4/ écartements revus en css (le statut actuel s'aligne sur les autres)
5/ les puces disparaissent au profit d'une icône modifiée et d'une coloration de son background (au survol et au choix)

Ok, donc on reste bien sur un formulaire avec action/validation voici une proposition à voir, avec les explications de l'image jointe 1/ intitulés simplifiés 2/ le bouton "Changer/Annuler" descend sous la liste des statuts 3/ fond gris pour différencier le bloc qui s'est ouvert 4/ écartements revus en css (le statut actuel s'aligne sur les autres) 5/ les puces disparaissent au profit d'une icône modifiée et d'une coloration de son background (au survol et au choix)
Author
Owner

Le bouton annuler était en bas au départ et justement Cédric l'a remonté pour qu'il switch avec le bouton d'ouverture (qui reprend pile comme tout les autres forms qui s'ouvrent comme celui de date pour la changer), et il avait aussi enlevé les cadres dans des cadres exprès pour que ce soit plus léger.

Je suis plutôt d'accord que pour le premier label, juste "Statut" ça me parait mieux : ça colle à tous les objets d'un coup et surtout ça fait pas "phrase à trou à terminer" et qui ne dit absolument rien de ce que c'est réellement au final (un statut).

Et du coup justement si on remplace par Statut, ça ne fait plus l'effet lecture à la suite dont parlait marcimat ("cet article est : changer"), là on a bien Statut | Changer (donc changer quoi : le statut, c'est clair)

Le bouton annuler était en bas au départ et justement Cédric l'a remonté pour qu'il switch avec le bouton d'ouverture (qui reprend pile comme tout les autres forms qui s'ouvrent comme celui de date pour la changer), et il avait aussi enlevé les cadres dans des cadres exprès pour que ce soit plus léger. Je suis plutôt d'accord que pour le premier label, juste "Statut" ça me parait mieux : ça colle à tous les objets d'un coup et surtout ça fait pas "phrase à trou à terminer" et qui ne dit absolument rien de ce que c'est réellement au final (un statut). Et du coup justement si on remplace par Statut, ça ne fait plus l'effet lecture à la suite dont parlait marcimat ("cet article est : changer"), là on a bien Statut | Changer (donc changer quoi : le statut, c'est clair)
marcimat force-pushed dev/instituer_ergo from 83f02bfb3f to 08373a36ac 2024-02-01 11:54:57 +01:00 Compare
Owner

Alors juste pour dire que remplacer "Cet article est :" par "Statut" ça me paraît effectivement bien plus précis.
Et ça évite ce sentiment de lire une phrase de travers.
Donc +1 pour ça.

Alors juste pour dire que remplacer "Cet article est :" par "Statut" ça me paraît effectivement bien plus précis. Et ça évite ce sentiment de lire une phrase de travers. Donc +1 pour ça.
Author
Owner

Ça tombe bien c'est ce que proposait la PR au départ 😋

Ça tombe bien c'est ce que proposait la PR au départ 😋
marcimat force-pushed dev/instituer_ergo from 08373a36ac to 0283647619 2024-02-02 16:16:56 +01:00 Compare
Owner

Je viens d’envoyer une adaptation graphique (et des traductions), et du CSS / focus

Ça fait beaucoup de CSS en vrac au pied de ce formulaire au final, c’est peut être pas la meilleure idée du siècle.
C’est compliqué de styler le fieldset.editer.erreur legend par ailleurs.
J’ai noté aussi que "Annuler" ne réactualise pas le formulaire (ce qui était coché reste coché, ou en erreur reste en erreur quoi)

En tout cas voilà quelques résultats.
J’ai caché les radios en CSS tout en maintenant la navigation clavier possible (si je ne me suis pas trompé)

Il y a

  • un hover léger à la souris,
  • un fond plus foncé si le radio est actif
  • un fond encore plus foncé si le radio est focus
  • les images de statuts sont plus petites, et grossissent si radio actif
Je viens d’envoyer une adaptation graphique (et des traductions), et du CSS / focus Ça fait beaucoup de CSS en vrac au pied de ce formulaire au final, c’est peut être pas la meilleure idée du siècle. C’est compliqué de styler le `fieldset.editer.erreur legend` par ailleurs. J’ai noté aussi que "Annuler" ne réactualise pas le formulaire (ce qui était coché reste coché, ou en erreur reste en erreur quoi) En tout cas voilà quelques résultats. J’ai caché les radios en CSS tout en maintenant la navigation clavier possible (si je ne me suis pas trompé) Il y a - un hover léger à la souris, - un fond plus foncé si le radio est actif - un fond encore plus foncé si le radio est focus - les images de statuts sont plus petites, et grossissent si radio actif
Owner

Et l’erreur

Et l’erreur
Owner

Ça me semble top @marcimat !

Ça me semble top @marcimat !
Author
Owner

Chacun y aura mis sa papatte :p fuuuusiooon
(même si je suis pas fan des cadres dans des cadres dans des cadres : je trouvais au contraire logique la modif de les enlever et d'aplatir tout, d'autant plus dans une mini colonne comme ça ; on est plutôt dans une optique de les limiter au maximum normalement, me semblait-il)

Chacun y aura mis sa papatte :p fuuuusiooon (même si je suis pas fan des cadres dans des cadres dans des cadres : je trouvais au contraire logique la modif de les enlever et d'aplatir tout, d'autant plus dans une mini colonne comme ça ; on est plutôt dans une optique de les limiter au maximum normalement, me semblait-il)
Owner

Oui, je peux (ou quelqu’un·e) ; j’avais commencé comme ça sans réussir à faire un truc qui me satisfaisait…

Oui, je peux (ou quelqu’un·e) ; j’avais commencé comme ça sans réussir à faire un truc qui me satisfaisait…
marcimat added 1 commit 2024-02-02 18:34:47 +01:00
Owner

Autre proposition donc

Autre proposition donc
Owner

Autre proposition donc

Je pense que cette fois c'est la bonne (ou la dernière pour cette PR ^^).

Bravo à toutes les personnes qui ont collaboré là dessus !

> Autre proposition donc Je pense que cette fois c'est la bonne (ou la dernière pour cette PR ^^). Bravo à toutes les personnes qui ont collaboré là dessus !
Owner

Eh ouais @marcimat bien sympa !

[EDIT] Un peu comme @rastapopoulos je trouve l'encadré arrondi pas nécessaire (ce qui permet de simplifier la css)

Et d'autre part, je trouve gênant que le bouton annuler soit en haut, si on se réfère juste à droite à l'encadré de Date de publication en ligne : le bouton modifier disparait au profit de Annuler|changer en bas.

sinon c'est cool, ça avance 👍

Eh ouais @marcimat bien sympa ! [EDIT] <strike>Un peu comme @rastapopoulos je trouve l'encadré arrondi pas nécessaire (ce qui permet de simplifier la css)</strike> Et d'autre part, je trouve gênant que le bouton annuler soit en haut, si on se réfère juste à droite à l'encadré de Date de publication en ligne : le bouton modifier disparait au profit de Annuler|changer en bas. sinon c'est cool, ça avance 👍
Author
Owner

Eh oui @touti c'était bien ça au départ : j'avais copié exactement la même ergo que pour le formulaire de datation qui s'ouvre par bouton mini, mais ensuite une fois ouvert tous les boutons en bas. Et c'est pareil pour la boite de langues.

On peut laisser comme ça pour l'instant, mais je me dis que ce serait bien d'harmoniser quand même, que toutes les "form qui s'ouvrent" aient une ergonomie similaire, pas chacune à sa sauce.

Eh oui @touti c'était bien ça au départ : j'avais copié exactement la même ergo que pour le formulaire de datation qui s'ouvre par bouton mini, mais ensuite une fois ouvert tous les boutons en bas. Et c'est pareil pour la boite de langues. On peut laisser comme ça pour l'instant, mais je me dis que ce serait bien d'harmoniser quand même, que toutes les "form qui s'ouvrent" aient une ergonomie similaire, pas chacune à sa sauce.
Owner

Ben c'est surtout que le bouton annuler juste devant le statut actuel me parait pas très opportun. Mais oui, on peut laisser comme ça, c'est déjà chouette d'avoir bien avancé dessus et aussi nombreux.

La css pourrait être optimisée et je vois si je peux rapidement faire une proposition.
Sinon @nicod qu'en penses-tu niveau accessibilité actuellement ?

Et en attendant d'ajouter un span autour du statut déjà choisi, soit sur le div .statut qui permettrait de faire un flex centré en vertical de l'icone et son titre, si quelqu'un peu rajouter ça pour descendre un peu l'icône :

.statut img {
  top: 2px;
  position: relative;
}

Oui, je suis exigeante mais c'est pour la bonne cause :)

Ben c'est surtout que le bouton annuler juste devant le statut actuel me parait pas très opportun. Mais oui, on peut laisser comme ça, c'est déjà chouette d'avoir bien avancé dessus et aussi nombreux. La css pourrait être optimisée et je vois si je peux rapidement faire une proposition. Sinon @nicod qu'en penses-tu niveau accessibilité actuellement ? Et en attendant d'ajouter un span autour du statut déjà choisi, soit sur le div .statut qui permettrait de faire un flex centré en vertical de l'icone et son titre, si quelqu'un peu rajouter ça pour descendre un peu l'icône : ``` .statut img { top: 2px; position: relative; } ``` Oui, je suis exigeante mais c'est pour la bonne cause :)
Jack31 approved these changes 2024-02-02 21:26:28 +01:00
Owner

Voila une proposition en PJ, avec la CSS et son rendu en image avant/après, j'ai gardé la disposition et n'ai modifié que les écarts en optimisant la CSS

à peu de chose près il y a le même nombre de lignes cependant,
ajout d'un max-width et un min-width pour éviter des horreurs en responsive et un white-space nowrap pour que les labels des statuts restent sur une seule ligne
Les anciens radios sont calés juste devant chaque icone.

Si une bonne âme peut tester et l'intégrer, je pense que c'est un petit plus avantageux.

Voila une proposition en PJ, avec la CSS et son rendu en image avant/après, j'ai gardé la disposition et n'ai modifié que les écarts en optimisant la CSS à peu de chose près il y a le même nombre de lignes cependant, ajout d'un max-width et un min-width pour éviter des horreurs en responsive et un white-space nowrap pour que les labels des statuts restent sur une seule ligne Les anciens radios sont calés juste devant chaque icone. Si une bonne âme peut tester et l'intégrer, je pense que c'est un petit plus avantageux.
Author
Owner

@touti mmmh bizarre ton "avant" : avec la version actuelle de la branche je n'ai pas du tout ça, mais bien comme la dernière capture de @marcimat : le bouton changer/annuler n'est pas collé à la ligne au-dessus, il n'y a pas de bordure qui se balade seule au dessus de Modifier le statut, ya bien des padding dans la légende grise, etc, tout est déjà bien.

Ah et au fait, sans parler de changement, marcimat tu faisais la remarque (sous entendu pas top) que ça faisait beaucoup de CSS posé à l'arrache sous le formulaire… mais du coup pourquoi j'avais commencé ça dans le premier commit ? Vu que dans la vraie CSS des forms, il y a bien déjà une section dédiée /* formulaire instituer */, je comprends pas trop pourquoi j'ai séparé en deux endroits, alors qu'en plus je l'avais bien vu puisque j'avais aussi fait des modifs dans l'autre CSS… peut-être yavait une logique mais je vois pas quoi…

@touti mmmh bizarre ton "avant" : avec la version actuelle de la branche je n'ai pas du tout ça, mais bien comme la dernière capture de @marcimat : le bouton changer/annuler n'est pas collé à la ligne au-dessus, il n'y a pas de bordure qui se balade seule au dessus de Modifier le statut, ya bien des padding dans la légende grise, etc, tout est déjà bien. Ah et au fait, sans parler de changement, marcimat tu faisais la remarque (sous entendu pas top) que ça faisait beaucoup de CSS posé à l'arrache sous le formulaire… mais du coup pourquoi j'avais commencé ça dans le premier commit ? Vu que dans la vraie CSS des forms, il y a bien déjà une section dédiée `/* formulaire instituer */`, je comprends pas trop pourquoi j'ai séparé en deux endroits, alors qu'en plus je l'avais bien vu puisque j'avais aussi fait des modifs dans l'autre CSS… peut-être yavait une logique mais je vois pas quoi…
marcimat added 1 commit 2024-02-03 10:50:26 +01:00
Owner

marcimat tu faisais la remarque (sous entendu pas top) que ça faisait beaucoup de CSS posé à l'arrache sous le formulaire…

Alors ma remarque ne t’était pas destinée ! c’était un constat : 

  • on fait beaucoup de surcharge des styles par défaut d’un formulaire pour ce cadre
  • et oui, il faudrait probablement déplacer tout cela dans le fichier CSS

Et aussi clairement la capture «avant» de @touti, c’est n’est pas du tout ce que j’ai envoyé :)

Je viens d’envoyer encore un autre patch, qui remet le bouton Annuler en bas et déplace les CSS

Alors par contre, il ne se comporte pas comme sur les autres formulaires ; ce formulaire n’étant pas ajax (il doit y avoir une raison j’imagine ?) ça recharge toute la page de le poster si on submit annuler, c’est pas terrible. Du coup j’en ai juste fait un bouton qui referme le formulaire.

> marcimat tu faisais la remarque (sous entendu pas top) que ça faisait beaucoup de CSS posé à l'arrache sous le formulaire… Alors ma remarque ne t’était pas destinée ! c’était un constat :  - on fait beaucoup de surcharge des styles par défaut d’un formulaire pour ce cadre - et oui, il faudrait probablement déplacer tout cela dans le fichier CSS Et aussi clairement la capture «avant» de @touti, c’est n’est pas du tout ce que j’ai envoyé :) Je viens d’envoyer encore un autre patch, qui remet le bouton Annuler en bas et déplace les CSS Alors par contre, il ne se comporte pas comme sur les autres formulaires ; ce formulaire n’étant pas ajax (il doit y avoir une raison j’imagine ?) ça recharge toute la page de le poster si on submit annuler, c’est pas terrible. Du coup j’en ai juste fait un bouton qui referme le formulaire.
marcimat force-pushed dev/instituer_ergo from 6b4099a8e1 to 259dc34565 2024-02-03 10:58:56 +01:00 Compare
Owner

Accessoirement j’ai commenté (en adaptant) dans le CSS la couleur qui était mise sous les statuts "prop", "refuse", "poubelle"…
Si y a besoin de les remettre, autre que lorsqu’un objet est considéré "publié", c’est dedans.

Accessoirement j’ai commenté (en adaptant) dans le CSS la couleur qui était mise sous les statuts "prop", "refuse", "poubelle"… Si y a besoin de les remettre, autre que lorsqu’un objet est considéré "publié", c’est dedans.
Contributor

Il y a un autre élément d'ergonomie de ce formulaire qui est passé sous le radar.
Scénario :

  1. je change le statut
  2. j'ai une mise à jour du navigateur qui se fait et qui redémarre le navigateur
  3. et là, quand le navigateur me recharge la page résultat de 1), au lieu d'afficher la page, il m'affiche un cache miss et me propose de renvoyer les valeurs du formulaire. Si je le fais (par un F5), le formulaire affiche une erreur : le statut a déjà été changé.

C'est pareil si j'actualise la page juste après avoir changé le statut.

C'est le seul cas dans SPIP où l'action ne passe pas par une URL intermédiaire faisant l'action et redirigeant vers la page de résultat.

Il y a un autre élément d'ergonomie de ce formulaire qui est passé sous le radar. Scénario : 1. je change le statut 2. j'ai une mise à jour du navigateur qui se fait et qui redémarre le navigateur 3. et là, quand le navigateur me recharge la page résultat de 1), au lieu d'afficher la page, il m'affiche un cache miss et me propose de renvoyer les valeurs du formulaire. Si je le fais (par un F5), le formulaire affiche une erreur : le statut a déjà été changé. C'est pareil si j'actualise la page juste après avoir changé le statut. C'est le seul cas dans SPIP où l'action ne passe pas par une URL intermédiaire faisant l'action et redirigeant vers la page de résultat.
marcimat added 1 commit 2024-02-03 11:11:18 +01:00
Owner

C'est le seul cas dans SPIP où l'action ne passe pas par une URL intermédiaire faisant l'action et redirigeant vers la page de résultat.

heu non @RealET c'est le cas de tous les formulaires non ajax qui submit toute la page. Et ce n'est pas un scénario passé sous les radars puisque justement il y a les sécurités dans le formulaire pour ne pas faire n'importe quoi dans ce cas. On génère une erreur, et c'est normal, et si le formulaire a été re-soumis c'est pas très grave. Il suffit de recharger la page pour voir que tout va bien.

Et pour info la PR ne change rien à ce cas, c'était déjà exactement pareil avant...

> C'est le seul cas dans SPIP où l'action ne passe pas par une URL intermédiaire faisant l'action et redirigeant vers la page de résultat. heu non @RealET c'est le cas de tous les formulaires non ajax qui submit toute la page. Et ce n'est pas un scénario passé sous les radars puisque justement il y a les sécurités dans le formulaire pour ne pas faire n'importe quoi dans ce cas. On génère une erreur, et c'est normal, et si le formulaire a été re-soumis c'est pas très grave. Il suffit de recharger la page pour voir que tout va bien. Et pour info la PR ne change rien à ce cas, c'était déjà exactement pareil avant...
Contributor

C'est le seul cas dans SPIP où l'action ne passe pas par une URL intermédiaire faisant l'action et redirigeant vers la page de résultat.

heu non @RealET c'est le cas de tous les formulaires non ajax qui submit toute la page. Et ce n'est pas un scénario passé sous les radars puisque justement il y a les sécurités dans le formulaire pour ne pas faire n'importe quoi dans ce cas. On génère une erreur, et c'est normal, et si le formulaire a été re-soumis c'est pas très grave. Il suffit de recharger la page pour voir que tout va bien.

Ça n'est pas très grave, oui.
Mais au redémarrage du navigateur, c'est tout sauf ergonomique.
D'autant plus que le statut aurait pu être entre-temps modifié par une tierce personne.

Et pour info la PR ne change rien à ce cas, c'était déjà exactement pareil avant...

Je sais bien.
C'est pour cela que c'est passé sous le radar de l'amélioration ergonomique (VPTCS, OPQUAST).

> > C'est le seul cas dans SPIP où l'action ne passe pas par une URL intermédiaire faisant l'action et redirigeant vers la page de résultat. > > heu non @RealET c'est le cas de tous les formulaires non ajax qui submit toute la page. Et ce n'est pas un scénario passé sous les radars puisque justement il y a les sécurités dans le formulaire pour ne pas faire n'importe quoi dans ce cas. On génère une erreur, et c'est normal, et si le formulaire a été re-soumis c'est pas très grave. Il suffit de recharger la page pour voir que tout va bien. Ça n'est pas très grave, oui. Mais au redémarrage du navigateur, c'est tout sauf ergonomique. D'autant plus que le statut aurait pu être entre-temps modifié par une tierce personne. > Et pour info la PR ne change rien à ce cas, c'était déjà exactement pareil avant... Je sais bien. C'est pour cela que c'est passé sous le radar de l'amélioration ergonomique (VPTCS, OPQUAST).
Owner

@rastapopoulos j'ai bien fait pull et un checkout sur la bonne version de la branche avant, sauf que j'ai omis de dire que j'ai présenté une réduction adaptative de la page à 300px où les éléments se déplacent et ne se positionnent pas correctement (pareil dans la dernière version tiré d'aujourd'hui), c'est pour ça que j'ai proposé ces modifs avec des line-height plutôt que des padding et optimisé la CSS que j'ai posé en PJ.

Notamment pour optimiser la css, sa compréhension, son traitement.
Par exemple

.infos .instituer_objet .formulaire_instituer .editer_statut div.choix label
{
  font-weight: 400;
  flex-grow: 1;
  padding-top: .2em;
  padding-bottom: .2em;
  margin-left: 0;
  margin-right: 0;
  padding-left: var(--spip-form-spacing-x);
  padding-right: var(--spip-form-spacing-x);
}

peut être réduit et écrit ainsi

.infos .formulaire_instituer .choix label
{
  font-weight: 400;
  flex-grow: 1;
  padding: .2em var(--spip-form-spacing-x);
  margin: auto 0;
}

Et donc maintenant, on arrive doucement au stade où chacun·e comprend par l'expérience des boutons et aussi visuellement que la phrase "Modifier le statut" est devenue inutile :D C'est de l'ergonomie UX sur plus de 3 ans quand même !

https://discuter.spip.net/t/amelioration-de-la-zone-de-changement-de-statut/153733/17


@rastapopoulos j'ai bien fait pull et un checkout sur la bonne version de la branche avant, sauf que j'ai omis de dire que j'ai présenté une réduction adaptative de la page à 300px où les éléments se déplacent et ne se positionnent pas correctement (pareil dans la dernière version tiré d'aujourd'hui), c'est pour ça que j'ai proposé ces modifs avec des line-height plutôt que des padding et optimisé la CSS que j'ai posé en PJ. Notamment pour optimiser la css, sa compréhension, son traitement. Par exemple ``` .infos .instituer_objet .formulaire_instituer .editer_statut div.choix label { font-weight: 400; flex-grow: 1; padding-top: .2em; padding-bottom: .2em; margin-left: 0; margin-right: 0; padding-left: var(--spip-form-spacing-x); padding-right: var(--spip-form-spacing-x); } ``` peut être réduit et écrit ainsi ``` .infos .formulaire_instituer .choix label { font-weight: 400; flex-grow: 1; padding: .2em var(--spip-form-spacing-x); margin: auto 0; } ``` Et donc maintenant, on arrive doucement au stade où chacun·e comprend par l'expérience des boutons et aussi visuellement que la phrase "Modifier le statut" est devenue inutile :D C'est de l'ergonomie UX sur plus de 3 ans quand même ! https://discuter.spip.net/t/amelioration-de-la-zone-de-changement-de-statut/153733/17 [](https://discuter.spip.net/uploads/spip/original/2X/e/ebc80b9f003a83a83db7a297c22e38816e1c0dc1.png) [](https://discuter.spip.net/uploads/spip/original/2X/2/2c8eb42de9b04dee88a5957b2103d97c8aeb0669.png)
Owner

Et donc maintenant, on arrive doucement au stade où chacun·e comprend par l'expérience des boutons et aussi visuellement que la phrase "Modifier le statut" est devenue inutile :D

+1

C'est de l'ergonomie UX sur plus de 3 ans quand même !

:)

> Et donc maintenant, on arrive doucement au stade où chacun·e comprend par l'expérience des boutons et aussi visuellement que la phrase "Modifier le statut" est devenue inutile :D +1 > C'est de l'ergonomie UX sur plus de 3 ans quand même ! :)
Owner

En 231px de large, ça dessine actuellement cela ; donc je doute @touti que tu vois ce qu’il faut. (tu as bien recalculé les CSS, par exemple avec &var_mode=recalcul dans l’espace privé ?).


Accessoirement l’UX «de plus de 3 ans», alors que la PR était là, marquée WIP depuis ce temps, et celleux qui plaident ce changement n’ont pas trouvé l’énergie de poursuivre, heu…

Je trouve l’exemple que tu pointes pas forcément clair au niveau du html dessous ; comment la navigation clavier doit se comporter. Est-ce ça voudrait dire que tu remets le radio aussi de «publié en ligne» ? Et sinon ça serait assez étonnant de ne naviguer au clavier que sur les 4 autres statuts non ?

Il me semble que c’est déjà pas mal ce qui est proposé là, non ?

En 231px de large, ça dessine actuellement cela ; donc je doute @touti que tu vois ce qu’il faut. (tu as bien recalculé les CSS, par exemple avec `&var_mode=recalcul` dans l’espace privé ?). ---- Accessoirement l’UX «de plus de 3 ans», alors que la PR était là, marquée WIP depuis ce temps, et celleux qui plaident ce changement n’ont pas trouvé l’énergie de poursuivre, heu… Je trouve l’exemple que tu pointes pas forcément clair au niveau du html dessous ; comment la navigation clavier doit se comporter. Est-ce ça voudrait dire que tu remets le radio aussi de «publié en ligne» ? Et sinon ça serait assez étonnant de ne naviguer au clavier que sur les 4 autres statuts non ? Il me semble que c’est déjà pas mal ce qui est proposé là, non ?
Owner

Est-ce qu'il ne serait pas intéressant de merger cette amélioration dans l'état et de tenter d'affiner par la suite dans une autre PR ? (proposition déguisée en question ^^)

Est-ce qu'il ne serait pas intéressant de merger cette amélioration dans l'état et de tenter d'affiner par la suite dans une autre PR ? (proposition déguisée en question ^^)
Owner

Oui, très bien.

Oui, très bien.
Owner

@touti

je fatigue de cette habitude et mise en doute constante de mes compétences

Je suis attristé que les commentaires de cette PR te fassent ressentir ça :(

Mais, je peux t'assurer que de mon côté j'avais bien le même résultat que la capture de marcimat quand il l'a posté après effectué un recalcul dans le privé (ou avoir vidé le cache).

Comme tu le dis, c'est chouette d'avoir pu avancer à plusieurs sur ce point, et je ne doute pas qu'on pourra en faire de même pour affiner par la suite :)

@touti > je fatigue de cette habitude et mise en doute constante de mes compétences Je suis attristé que les commentaires de cette PR te fassent ressentir ça :( Mais, je peux t'assurer que de mon côté j'avais bien le même résultat que la capture de marcimat quand il l'a posté après effectué un recalcul dans le privé (ou avoir vidé le cache). Comme tu le dis, c'est chouette d'avoir pu avancer à plusieurs sur ce point, et je ne doute pas qu'on pourra en faire de même pour affiner par la suite :)
First-time contributor

Est-ce qu'il ne serait pas intéressant de merger cette amélioration dans l'état et de tenter d'affiner par la suite dans une autre PR ? (proposition déguisée en question ^^)

Oui tout à fait d'accord, et après une ou des PR pour améliorer !
C'est déjà beaucoup mieux :)

>Est-ce qu'il ne serait pas intéressant de merger cette amélioration dans l'état et de tenter d'affiner par la suite dans une autre PR ? (proposition déguisée en question ^^) Oui tout à fait d'accord, et après une ou des PR pour améliorer ! C'est déjà beaucoup mieux :)
Owner

mais depuis l'image "AVANT" que je postais tu as apporté des changements.

Bah non justement (juste le bouton Annuler en bas)

Mais est-ce que maintenant tu as le CSS qui est généré correctement où ça te fait encore comme sur ta capture d’avant ?

> mais depuis l'image "AVANT" que je postais tu as apporté des changements. Bah non justement (juste le bouton Annuler en bas) Mais est-ce que maintenant tu as le CSS qui est généré correctement où ça te fait encore comme sur ta capture d’avant ?
Author
Owner

Je ne dis pas que c'est ça, mais moi qui suis vraiment une quiche en Git, je dis ce que j'ai eu : j'ai cru plusieurs fois avoir mis à jour cette branche et à la toute fin du print (et sans couleur de mise en avant) en fait Git me disait que c'était Fatal et qu'il avait rien fait. Cela parce qu'il y a dû avoir des push force ou ce genre de changement de hash. Du coup pour remettre j'ai dû fetch --all puis reset --hard origin/dev/instituer_ergo, et là c'était bon. Si ça arrive à d'autres…

Je ne dis pas que c'est ça, mais moi qui suis vraiment une quiche en Git, je dis ce que j'ai eu : j'ai cru plusieurs fois avoir mis à jour cette branche et à la toute fin du print (et sans couleur de mise en avant) en fait Git me disait que c'était Fatal et qu'il avait rien fait. Cela parce qu'il y a dû avoir des push force ou ce genre de changement de hash. Du coup pour remettre j'ai dû `fetch --all` puis `reset --hard origin/dev/instituer_ergo`, et là c'était bon. Si ça arrive à d'autres…
Owner

J'ai effacé mon message précédent, peu importe ici mon ressenti ou les soucis techniques de GITea.

Ok pour merger mais si on souhaite optimiser et qu'il y a des courageux pour le faire, je propose de simplifier encore :

  • Masquer la legend Modifier le statut puisque le bouton Changer est à côté de Statut et qu'au clic il passe sous la liste qui s'ouvre
  • Aligner les icônes horizontalement (face aux labels et au statut déjà choisi) et verticalement entre elles.
  • Retirer le fond gris et les traits horizontaux
  • Réduire un peu le padding et margin des statuts

Cf images jointes

J'ai effacé mon message précédent, peu importe ici mon ressenti ou les soucis techniques de GITea. Ok pour merger mais si on souhaite optimiser et qu'il y a des courageux pour le faire, je propose de simplifier encore : - Masquer la legend _Modifier le statut_ puisque le bouton Changer est à côté de Statut et qu'au clic il passe sous la liste qui s'ouvre - Aligner les icônes horizontalement (face aux labels et au statut déjà choisi) et verticalement entre elles. - Retirer le fond gris et les traits horizontaux - Réduire un peu le padding et margin des statuts Cf images jointes
Owner

C’est joli @touti j’admets.

Tu n’as néanmoins pas répondu à ma question sur ta proposition de quel est le HTML derrière ;

Là typiquement si c’est juste faire du CSS pour remonter les radios sous le statut actif (dans ton exemple Publié en ligne), qui n’est lui pas un radio donc, le comportement va, il me semble paraître incohérent : tu vas pouvoir sélectionner un autre statut (au clavier ou à la souris), mais jamais pouvoir re-sélectionner «publié en ligne» qui n’est pas un radio. Alors que graphiquement ça semble tout cohérent pour pouvoir le faire.

Donc je suppose que c’est un peu plus compliqué que juste transformer le CSS pour obtenir ce résultat.

C’est joli @touti j’admets. Tu n’as néanmoins pas répondu à ma question sur ta proposition de quel est le HTML derrière ; Là typiquement si c’est juste faire du CSS pour remonter les radios sous le statut actif (dans ton exemple Publié en ligne), qui n’est lui pas un radio donc, le comportement va, il me semble paraître incohérent : tu vas pouvoir sélectionner un autre statut (au clavier ou à la souris), mais jamais pouvoir re-sélectionner «publié en ligne» qui n’est pas un radio. Alors que graphiquement ça semble tout cohérent pour pouvoir le faire. Donc je suppose que c’est un peu plus compliqué que juste transformer le CSS pour obtenir ce résultat.
Author
Owner

Oui pour l'ergo il faut distinguer ce qui est du champ de formulaire de ce qui ne l'est pas et qui est juste de l'information statique. D'autant plus justement que les vrais boutons radios ont été masqués. Soit il faut garder la légende (qui nomme et indique explicitement le champ de choix qui suit) soit faut montrer des cases/ronds à cocher.

C'est l'idée de l'affordance : sans du tout avoir ni survolé, ni cliqué nulle part, on doit comprendre juste à l'œil quels éléments sont interactifs. Pour les boutons on comprend bien que c'en est. Mais pour les radios masqués… Du coup la légende me parait toujours importante dans ce cas.

Oui pour l'ergo il faut distinguer ce qui est du champ de formulaire de ce qui ne l'est pas et qui est juste de l'information statique. D'autant plus justement que les vrais boutons radios ont été masqués. Soit il faut garder la légende (qui nomme et indique explicitement le champ de choix qui suit) soit faut montrer des cases/ronds à cocher. C'est l'idée de l'affordance : *sans du tout* avoir ni survolé, ni cliqué nulle part, on doit comprendre juste à l'œil quels éléments sont interactifs. Pour les boutons on comprend bien que c'en est. Mais pour les radios masqués… Du coup la légende me parait toujours importante dans ce cas.
Owner

Oui effectivement, seule la CSS joue dans ma proposition, pas de modification du html ou du js.

Un retour de test avec des personnes utilisatrices serait cool, au moins on verrait ce qu'elles font et si ça leur va bien ou pas.

En général pour repérer un élément sélectionné d'un autre non sélectionné, il existe différents moyens concomitants ou pas :

  • L'effet visuel, dans une liste d'articles, l'élément sélectionné est en gras (on / actif)
  • La désactivation ou activation du lien (ou sommes nous?) un peu de la même façon que le logo du site sur le sommaire n'est pas cliquable, le statut "ancien" ne l'est pas non plus.
  • L'indiquer par écrit ? Heureusement l'usage n'est plus de noter devant les liens d'une liste d'articles "Choisissez votre article", car les principes d'ergonomie suivent aussi la psychologie de l'utilisateur et l'évolution des usages.

L'affordance, c'est aussi l'aspect intuitif puisqu'il existe ici une action obligatoire préalable à l'affichage de la liste qui est de cliquer sur le bouton [Changer] l'internaute a donc conscience de passer du statut "X" à un autre à choisir dans une liste qui vient de s'ouvrir et qu'il lui faut en plus valider avec le bouton "Changer". Et si c'est une question d'accessibilité, son lecteur d'écran lui indique la liste des statuts radio à choisir en même temps qu'il lui a lu la légende masquée.

Cependant, si cela convient mieux à votre idée de l'ergonomie, je propose de mieux distinguer la liste en éteignant un peu les noirs, en omettant la couleur des icônes, en distinguant mieux le statut 'ancien' des autres qui sera le seul avec une pastille et un fond coloré ? A moins de réécrire le HTML et avoir un actif/disable sur le statut ancien en haut de liste ?

Si je suis la seule à trouver évident qu'il faire sauter le texte "Modifier le statut", ben tant pis, on merge tel quel même si l'interface apparait plus compliqué que le simple select actuellement en 4.2.8 🥲

Oui effectivement, seule la CSS joue dans ma proposition, pas de modification du html ou du js. Un retour de test avec des personnes utilisatrices serait cool, au moins on verrait ce qu'elles font et si ça leur va bien ou pas. En général pour repérer un élément sélectionné d'un autre non sélectionné, il existe différents moyens concomitants ou pas : - L'effet visuel, dans une liste d'articles, l'élément sélectionné est en gras (on / actif) - La désactivation ou activation du lien (ou sommes nous?) un peu de la même façon que le logo du site sur le sommaire n'est pas cliquable, le statut "ancien" ne l'est pas non plus. - L'indiquer par écrit ? Heureusement l'usage n'est plus de noter devant les liens d'une liste d'articles "Choisissez votre article", car les principes d'ergonomie suivent aussi la psychologie de l'utilisateur et l'évolution des usages. L'affordance, c'est aussi l'aspect intuitif puisqu'il existe ici une action obligatoire préalable à l'affichage de la liste qui est de cliquer sur le bouton [Changer] l'internaute a donc conscience de passer du statut "X" à un autre à choisir dans une liste qui vient de s'ouvrir et qu'il lui faut en plus valider avec le bouton "Changer". Et si c'est une question d'accessibilité, son lecteur d'écran lui indique la liste des statuts radio à choisir en même temps qu'il lui a lu la légende masquée. Cependant, si cela convient mieux à votre idée de l'ergonomie, je propose de mieux distinguer la liste en éteignant un peu les noirs, en omettant la couleur des icônes, en distinguant mieux le statut 'ancien' des autres qui sera le seul avec une pastille et un fond coloré ? A moins de réécrire le HTML et avoir un actif/disable sur le statut ancien en haut de liste ? Si je suis la seule à trouver évident qu'il faire sauter le texte "Modifier le statut", ben tant pis, on merge tel quel même si l'interface apparait plus compliqué que le simple select actuellement en 4.2.8 🥲
Author
Owner

La dernière phrase est un peu tirée par les cheveux :

  • il y a très exactement le même nombre de clics qu'avant pour faire l'opération (trois),
  • mais maintenant avec un bouton explicite "Changer" pour ouvrir la liste, cohérent avec les forms de date, langue, etc (donc apprentissage, pareil partout)
  • et en continuant de voir le statut actuel même quand on est en train de sélectionner autre chose (ce qui n'était pas le cas avant où une fois en train de faire, on ne voyait plus)

Donc je ne vois pas trop où serait le plus compliqué. :)

La dernière phrase est un peu tirée par les cheveux : - il y a très exactement le même nombre de clics qu'avant pour faire l'opération (trois), - mais maintenant avec un bouton explicite "Changer" pour ouvrir la liste, cohérent avec les forms de date, langue, etc (donc apprentissage, pareil partout) - et en continuant de voir le statut actuel même quand on est en train de sélectionner autre chose (ce qui n'était pas le cas avant où une fois en train de faire, on ne voyait plus) Donc je ne vois pas trop où serait le plus compliqué. :)
Owner

@rastapopoulos, je vois qu'on n'est pas du tout dans la même modalité dialectique, et j'ai peu goût à ce rapport de force continuel.
Si mon point de vue ne te convient pas, inutile de te focaliser dessus ou de contre argumenter indéfiniment sans rien retenir de ce que je propose.
Je constate et partage les défauts que je vois et je fais des propositions d'améliorations, c'est déjà pas mal, ah si, avec un effort incommensurable j'essaye de ne pas être dégoutée de participer.

Si on pouvait tenter d'être constructif ? il me semble avoir justement fait des propositions.

@rastapopoulos, je vois qu'on n'est pas du tout dans la même modalité dialectique, et j'ai peu goût à ce rapport de force continuel. Si mon point de vue ne te convient pas, inutile de te focaliser dessus ou de contre argumenter indéfiniment sans rien retenir de ce que je propose. Je constate et partage les défauts que je vois et je fais des propositions d'améliorations, c'est déjà pas mal, ah si, avec un effort incommensurable j'essaye de ne pas être dégoutée de participer. Si on pouvait tenter d'être constructif ? il me semble avoir justement fait des propositions.
marcimat added 1 commit 2024-02-05 17:15:37 +01:00
Owner

Je viens d’envoyer encore quelques modifications

  • pas de fond sur le formulaire
  • alignement vertical des différentes icones de statuts meilleure.
    • Notons que là tout est aligné aussi avec les icones de liens dessous (ie: Voir en ligne), mais cela fait un grand espacement du coup entre l’icone de statut et le texte.
    • J’ai commenté le CSS pour avoir ce gap plus petit (qui du coup désaligne avec les icones du bas) ; je posterai aussi la capture
  • Annuler décoche le radio qui était coché
  • J’ai grossi l’icone de statut actif

Des remarques ?

Je viens d’envoyer encore quelques modifications - pas de fond sur le formulaire - alignement vertical des différentes icones de statuts meilleure. - Notons que là tout est aligné aussi avec les icones de liens dessous (ie: Voir en ligne), mais cela fait un grand espacement du coup entre l’icone de statut et le texte. - J’ai commenté le CSS pour avoir ce gap plus petit (qui du coup désaligne avec les icones du bas) ; je posterai aussi la capture - Annuler décoche le radio qui était coché - J’ai grossi l’icone de statut actif Des remarques ?
Owner

Autre option avec le gap plus petit entre l’icone et le texte donc

Autre option avec le gap plus petit entre l’icone et le texte donc
marcimat added 1 commit 2024-02-05 17:38:13 +01:00
Owner

Ah et quant au décalage de l’icone (top: 2px) que tu proposais @touti (et qui maintenant ne semble se poser que pour la ligne de statut Actif) — j’avais un petit train de retard sur mes captures précédentes —

Et bien je ne suis pas certain que ça soit une bonne idée ; ce décalage semble du à la police de caractère utilisé à côté pour le texte ; si je passe à du Serif, par exemple, pff, ça parait verticalement mieux aligné… du coup je reste perplexe… Je n’ai pas trouvé de solution à cela pour le moment.

Ah et quant au décalage de l’icone (`top: 2px`) que tu proposais @touti (et qui maintenant ne semble se poser que pour la ligne de statut Actif) — j’avais un petit train de retard sur mes captures précédentes — Et bien je ne suis pas certain que ça soit une bonne idée ; ce décalage semble du à la police de caractère utilisé à côté pour le texte ; si je passe à du Serif, par exemple, pff, ça parait verticalement mieux aligné… du coup je reste perplexe… Je n’ai pas trouvé de solution à cela pour le moment.
marcimat added 1 commit 2024-02-05 18:02:22 +01:00
Owner

Ah je crois que j’ai enfin trouvé une parade de cet alignement là.
Ça semble correct.

Vous direz ce que vous préférez comme espacement entre l’icône et le texte (ie: aligner sur Voir en ligne ou pas ?)

Ah je crois que j’ai enfin trouvé une parade de cet alignement là. Ça semble correct. Vous direz ce que vous préférez comme espacement entre l’icône et le texte (ie: aligner sur Voir en ligne ou pas ?)
Author
Owner

Non mais @touti j'ai argumenté mille trucs plus haut, à chaque fois j'ai décrit ce qui me paraissait important ergonomiquement à ne pas évincer, et après plein d'améliorations par tout le monde un message qui se finit par "en fait pour l'instant ça parait encore plus compliqué que ce que c'était avant" et c'est toi qui parle de pas être dégoûtée de participer et de rapport de force ? mmmh…
Bon, continuons donc…

Ça parait donc super avec ce meilleur alignement supplémentaire et la légèreté de ne plus avoir de fond différent. Parfait le décochage du radio aussi quand on annule.

Pour moi ça a déjà dix fois plus de classe qu'avant. C'est déjà nickel à envoyer même si on continue d'améliorer plus tard.

Non mais @touti j'ai argumenté mille trucs plus haut, à chaque fois j'ai décrit ce qui me paraissait important ergonomiquement à ne pas évincer, et après plein d'améliorations par tout le monde un message qui se finit par "en fait pour l'instant ça parait encore plus compliqué que ce que c'était avant" et c'est toi qui parle de pas être dégoûtée de participer et de rapport de force ? mmmh… Bon, continuons donc… Ça parait donc super avec ce meilleur alignement supplémentaire et la légèreté de ne plus avoir de fond différent. Parfait le décochage du radio aussi quand on annule. Pour moi ça a déjà dix fois plus de classe qu'avant. C'est déjà nickel à envoyer même si on continue d'améliorer plus tard.
tcharlss approved these changes 2024-02-05 20:38:44 +01:00
tcharlss left a comment
Owner

C'est beau.

(je vote pour le gap + petit)

C'est beau. (je vote pour le gap + petit)
Owner

Autre option avec le gap plus petit entre l’icone et le texte donc

Personnellement, je préfère.

> Autre option avec le gap plus petit entre l’icone et le texte donc Personnellement, je préfère.
marcimat force-pushed dev/instituer_ergo from 5242731669 to 503ea16c46 2024-02-06 10:01:57 +01:00 Compare
Owner

Bon, donc j’ai rebasé tout cela (j’ai laissé un nouveau commit pour mes modifs)

J’ai réduit un peu le padding sur le statut actuel montré (qui est du coup maintenant le même que pour les statuts à venir).
C’était assez chouette pour le statut actif publié (qui a un fond vert), mais pour les autres statuts du coup sans fond, bah ça faisait un espace blanc moins cohérent. Donc à moins de colorer aussi (genre gris très clair) les autres statuts actifs autres que publié, bah ça me semble mieux comme cela.

Des z’avis ?

Bon, donc j’ai rebasé tout cela (j’ai laissé un nouveau commit pour mes modifs) J’ai réduit un peu le padding sur le statut actuel montré (qui est du coup maintenant le même que pour les statuts à venir). C’était assez chouette pour le statut actif publié (qui a un fond vert), mais pour les autres statuts du coup sans fond, bah ça faisait un espace blanc moins cohérent. Donc à moins de colorer aussi (genre gris très clair) les autres statuts actifs autres que publié, bah ça me semble mieux comme cela. Des z’avis ?
Owner

Je vois qu'il reste des règles commentées dans la CSS, c'est pour pouvoir revenir en arrière ou tu les retireras avant le merge ?

Je vois qu'il reste des règles commentées dans la CSS, c'est pour pouvoir revenir en arrière ou tu les retireras avant le merge ?
Owner

C’est, en gros, quelques points à discuter en fait…

  • padding du statut actif (plus haut ou pas) ?
  • background des statuts actifs
    • uniquement vert pour publié, transparent pour les autres (ce qui est actuellement sur la proposition)
    • gris clair pour les autres ?
    • fond coloré comme avant pour les autres ?
C’est, en gros, quelques points à discuter en fait… - padding du statut actif (plus haut ou pas) ? - background des statuts actifs - uniquement vert pour publié, transparent pour les autres (ce qui est actuellement sur la proposition) - gris clair pour les autres ? - fond coloré comme avant pour les autres ?
b_b approved these changes 2024-02-08 12:26:13 +01:00
b_b left a comment
Owner

Je revalide, pour moi c'est très bien ainsi, on peut virer les partie commentées pour test dans les CSS.

Je revalide, pour moi c'est très bien ainsi, on peut virer les partie commentées pour test dans les CSS.
Jack31 approved these changes 2024-02-08 12:30:57 +01:00
Jack31 left a comment
First-time contributor

Gogogo ! Reportable en 4.2 ?

Gogogo ! Reportable en 4.2 ?
marcimat referenced this issue from a commit 2024-02-08 12:34:39 +01:00
marcimat force-pushed dev/instituer_ergo from 503ea16c46 to 18c822a234 2024-02-08 12:34:43 +01:00 Compare
Owner

Bon, on arrive à un point de compromis pour merger donc ?

Personnellement je reste moins convaincu sur l’absence de décoration bien évidente du statut un cours (avant il y avait un fond qui se voyait bien quoi) ; mais ça pourra si besoin faire l’objet de suggestions future à mesure des retours des béta tests j’imagine.


Et non @Jack31 pas de report en 4.2
Qu’est-ce donc que vous ne comprenez pas dans «Correction de bugs» sur une branche ???

Si vous voulez des nouveautés, il faut se bouger sur les PR pour SPIP 5 et avancer dessus, ou se bouger pour proposer un SPIP 4.3 et s’organiser pour ça si vraiment vous voulez… Sinon ça ne sert à rien tout ce qu’on essaie de faire à peu près en Semver accessoirement

Bon, on arrive à un point de compromis pour merger donc ? Personnellement je reste moins convaincu sur l’absence de décoration bien évidente du statut un cours (avant il y avait un fond qui se voyait bien quoi) ; mais ça pourra si besoin faire l’objet de suggestions future à mesure des retours des béta tests j’imagine. ---- Et non @Jack31 pas de report en 4.2 Qu’est-ce donc que vous ne comprenez pas dans «Correction de bugs» sur une branche ??? Si vous voulez des nouveautés, il faut se bouger sur les PR pour SPIP 5 et avancer dessus, ou se bouger pour proposer un SPIP 4.3 et s’organiser pour ça si vraiment vous voulez… Sinon ça ne sert à rien tout ce qu’on essaie de faire à peu près en Semver accessoirement
Owner

Personnellement je reste moins convaincu sur l’absence de décoration bien évidente du statut un cours (avant il y avait un fond qui se voyait bien quoi)

Histoire de rallonger encore la discussion ici, je préférais aussi la couleur bien évidente.

> Personnellement je reste moins convaincu sur l’absence de décoration bien évidente du statut un cours (avant il y avait un fond qui se voyait bien quoi) Histoire de rallonger encore la discussion ici, je préférais aussi la couleur bien évidente.
Owner

Bon, je crois qu’on va merger ça, et faire un nouveau ticket de discussions

Bon, je crois qu’on va merger ça, et faire un nouveau ticket de discussions
marcimat referenced this issue from a commit 2024-02-12 19:58:31 +01:00
marcimat force-pushed dev/instituer_ergo from 18c822a234 to 224da03f06 2024-02-12 19:58:35 +01:00 Compare
marcimat merged commit 224da03f06 into master 2024-02-12 19:59:13 +01:00
marcimat deleted branch dev/instituer_ergo 2024-02-12 19:59:14 +01:00
Sign in to join this conversation.
No description provided.