[WIP] Ergonomie du formulaire instituer objet #196

Open
rastapopoulos wants to merge 8 commits from dev/instituer_ergo into master
Owner

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 - [ ] 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 : ![](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 1 year ago

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"
Poster
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 1 year ago
rastapopoulos added 1 commit 1 year ago
rastapopoulos added 1 commit 1 year ago
Poster
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)
Eric commented 1 year ago
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 ?
Poster
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)
Poster
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.
Poster
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.
Poster
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 8 months ago
rastapopoulos added 1 commit 8 months ago
Poster
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 8 months ago
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.
Poster
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 8 months ago
rastapopoulos added 8 commits 5 months ago
Poster
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. :)
This pull request is marked as a work in progress.
This branch is out-of-date with the base branch
Sign in to join this conversation.
Loading…
There is no content yet.