Amélioration de la zone de changement de statut

Yop,

Je plussoie en partie aux remarques de Touti et à sa proposition.
Néanmoins, je pense qu’il y a peut-être une voie légèrement différente et plus générique.

Le sujet du changement de statut n’est rien d’autre qu’un cas de workflow, donc un graphe états-transitions où les états sont les statuts et les transitions les actions sous-jacentes déclenchées par le formulaire.
La « complexité » de l’interface vient en particulier du fait que notre graphe est un plat de nouilles : tous les états sont accessibles de n’importe quel état, ce qui est en soit irréaliste (pratique mais pas réaliste).
De mon point de vue, dans un workflow il faut que les actions soient déclenchées par des boutons qui portent le nom de la transition et pas celui de l’état de destination: Refuser, Publier, Proposer…

Si on considère qu’un graphe plus « réaliste » (et surement à amender en supprimant la transition publié vers poubelle) est celui indiqué ci-dessous, on pourrait très bien avoir comme interface un groupe de boutons sous le statut qui indiquerait les transitions possibles comme par exemple Publier/Refuser à partir de l’état prop, etc.
Je pense que c’est le plus naturel pour un workflow.
Après quand je fouille dans Contrib qui a des milliers d’articles, j’ai du mal à comprendre après plusieurs années l’intérêt de différencier l’état refusé et poubelle quand on laisse ad vitam eternam un article refusé.

wokflow

D’ailleurs en cela je rejoins @rastapopoulos car dans mes derniers plugins j’abandonne régulièrement les puces de changement rapide au profit de boutons regroupés. Par exemple, pour les inscriptions à la forge, j’ai un groupe accepter/refuser pour répondre à la demande d’inscription qui a le statut prop.

formulaire_instituer vaut pour n’importe quel contenu, qui peut avoir 3, 6, ou 15 statuts possibles (cf les Commandes par exemple). Pour de nombreux contenus on peut effectivement passer d’à peu près n’importe quel statut à n’importe quel autre, je vois pas trop le soucis (y compris pour les articles, encore heureux qu’un article publié, par erreur ou pas, puisse revenir en dépublié brouillon, sans pour autant le mettre à la poubelle ou archivé).

Mais bon les autorisations pour chaque statut (suivant l’utilisateurice connecté) c’est encore un autre soucis il me semble, et qui existe déjà en partie, qui peut être peaufiné, tous les utilisateurices ne voient pas tous les statuts, d’ors et déjà.

Il me semble qu’il faut réfléchir sur ces trois aspects à la fois :

  • la facilité de l’action, tout en faisant comprendre que ce n’est pas anodin (= pas de possibilité de changer le statut par erreur)
  • la cohérence entre la même action dans les listes et dans les pages dédiées (= environ le même nombre de clics, même confirmation, intitulés, etc)
  • le fait de laisser la porte ouverte (aussi bien ergonomiquement que code) à des workflows plus complets/détaillés, tout en ayant un truc simple par défaut (= par défaut ça ne fait que changer le champ statut, mais on doit permettre d’étendre pour que pour tel ou tel statut on puisse demander d’autres infos en plus, quelque soit le moyen ergo)

Un petit moment de compassion pour @RealET qui proposait juste une retouche de l’existant sans s’embarquer dans une remise à plat complète de tout le machin.

1 « J'aime »

Merci @tcharlss :wink:
Le pire, c’est que j’ai un truc qui marche en plus.

Je me le garderais en fork local au pire :wink:

Ben oui mais c’est pas réaliste, ni souhaitable ni nécessaire.
Si tu veux dépublier un article pourquoi aurais tu besoin de pouvoir faire une transition vers tous les autres états ? Ca n’a pas de sens, il suffirait que dépublier remette l’article en statut prepa.
C’est pratique je le conçois mais ça oblige à parler en statut alors que l’utilisateur lui parle en action : publier, dépublier, soumettre à la relecture…

Et le oups c’est aussi une facilité pas une action sémantique. On le fait bien déjà pour les mots-clés.
D’ailleurs puisque tu as publié à partir de n’importe quel état quand tu reviens en arrière tu vas où?
Je pense vraiment qu’il faut réfléchir en workflow et oublier un peu l’historique tordu ultra-disant.

Mais c’est exact que comme dit @tcharlss qui est mode « faut clore les discussions » :wink: on va un peu loin au vu de la question.
Mais par contre, je n’aime pas le bouton désactivé car il me semble que ce serait le seul cas non?

On peut discuter quand même où ça t’emmerde ?
On peut dire aussi qu’on est pas chaud sur la proposition même si ça marche ™ ?

Moi je te propose de faire une lame dans le Couteau Suisse…

2 « J'aime »

C’est pour cela que je proposais depuis le début d’adapter ce comportement pour tous les boutons invisibles avant action possible (Amélioration de la zone de changement de statut - #2 par RealET)

Alors ,

  1. oui, bien sûr on peut discuter, et c’est très intéressant en plus
  2. il me semble qu’il y a ce qui est possible encore possible pour la 4.0 (ma proposition, correctement stylée par @tcharlss ) et ce qui a l’air d’être un chantier 4.1+

Oui mais faut penser aussi à tous les plugins qui ont repris le fonctionnement actuel de spip.
Donc ça ne me parait pas envisageable.

Hello,
Désolé si je m’immisce et je ne sais pas si ça va influencer la discussion mais j’ai ça en RTL:
PrtScr capture

C’est un padding-right qui doit être left. Je fais un ticket ou j’attend de voir ce qu’on decide?

1 « J'aime »

hihi, un classique de chez SPIP :stuck_out_tongue:

J’ai soumis une PR : #195 - Amélioration de la zone de changement de statut - spip - SPIP on GIT

PR pourrie.
La seule bonne proposition est celle de touti, mais vous (spécialises de l’ergonomie, huhu, je me marre) n’avez visiblement pas l’ouverture d’esprit pour le reconnaitre.

J’ai mis la PR en WIP.

Sur le fond, pourquoi pas, effectivement, aborder le sujet mais par le bond bout, à la @touti :slight_smile:

Sur la forme, évitons les forcing avec, je cite, « du crade » à la veille d’une sortie de version stable.

1 « J'aime »

Effectivement la proposition de touti semble intéressante.

Ceci étant dit, je pense comme Eric qu’il faudrait idéalement aller vers une définition en Workflow. Ça structurerait bien plus l’extensibilité et le code.

2 « J'aime »

Je ne crois pas que quiconque se soit attribué la qualité de « spécialiste de l’ergonomie » au travers de ce fil.
Cette PR est de surcroît loin d’être terminée et ce n’est pas le forcing de @RealET qui va nous émouvoir, n’en faisons pas un débat stérile !

Oui la proposition de @touti a du sens et ses remarques sont pertinentes.
Mais pour moi, la proposition ne va pas au bout pour deux raisons principales:

Le choix d’un statut
Je ne pense pas que l’on doit choisir un statut mais plutôt faire une action qui va résulter en un nouveau statut. L’action n’est pas je change de statut x pour y mais je publie, je refuse ou je propose un article. Franchement peut-on prétendre qu’un utilisateur ou qu’une utilisatrice peut vraiment voir la différence entre un article refusé et mis à la poubelle surtout que pour les deux on peut revenir à n’importe quel autre statut ?

L’action de refuser une publication devrait renvoyer l’article en état prepa pour le revoir avec un commentaire du pourquoi, l’état refusé n’a aucune sémantique sauf mémorielle.
De même quel est la sémantique du statut poubelle quand des articles dont on ne sait pas si ils ont été publiés s’entassent dans une poubelle pour l’éternité ?
Et je ne parle pas du statut archivé qui n’existe pas ou de l’action dépublier pour laquelle la sémantique resterait à définir.

Des transitions sémantiques
Toutes les actions ne sont pas nécessaires depuis tous les statuts, ça n’a aucun sens quoi qu’en dise certains. De fait, si on réfléchissait en workflow on verrait bien qu’on n’a pas besoin de plus de deux ou trois actions par état, et encore, ce qui simplifierait beaucoup la solution.

En reprenant ces idées, voilà un workflow qui me parait définir complètement le cycle de vie d’un article :
workflow-article
Les icones commentaires pourraient être une amélioration du processus actuel mais ne sont pas indispensables dans un premier temps si on utilise les commentaires de l’article.
J’ai laissé une dépublication pour « je ne sais quoi » par convenance mais je ne suis pas sur qu’on en ait vraiment besoin si ce n’est en cas d’erreur…

Moi aussi, je trouve la proposition de @touti très intéressante.

Sur le statut « Poubelle », c’est si tu as le plugin Corbeille que le vidage au bout de 24h ne se fait plus automatiquement.

Sur la notion de workflow, ce que j’explique en formation, c’est que le gros avantage de SPIP sur d’autres solutions de publications (M$ SharePoint par exemple), c’est justement qu’il n’impose pas de workflow, et que c’est à l’équipe d’adopter le workflow qu’ils veulent, avec la possibilité de faire des exceptions en cas d’urgence.

Ceci dit, une fois qu’un article est publié, il manque d’un point de vue SEO/ergonomie de l’internaute côté public une notion de : « qu’afficher à l’internaute en cas de visite d’une url dépubliée ?».
Avec comme réponses souhaitées :

  • comme actuellement, une 404 : c’est la pire des solutions
  • page en maintenance : dans le cas d’une dépublication pour modifications
  • redirection temporaire pour donner quand même une information le temps d’une republication
  • redirection permanente

Et un autre serpent de mer : la possibilité de laisser l’article publié dans sa version actuelle pendant qu’on en crée une version modifiée.

Ça paraît pas mal, mais est-ce qu’on peut supprimer un article parfois, ou même tout le temps ?

Pour compléter mon message voilà ce que le workflow proposé donnerait en visuel :

statut2