[WIP] Ergonomie du formulaire instituer objet #196

Open
rastapopoulos wants to merge 4 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 2 weeks 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 2 weeks ago
rastapopoulos added 1 commit 2 weeks ago
rastapopoulos added 1 commit 2 weeks 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)
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).
Collaborator

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.
This pull request is marked as a work in progress. Remove the [WIP] prefix from the title when it's ready
This branch is out-of-date with the base branch
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No Assignees
6 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.