Amélioration de la zone de changement de statut

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

Expliquer en formation que c’est bien de ne pas avoir de workflow c’est ton problème, moi je considère que c’est une mauvaise pratique.
D’ailleurs ton problème c’est pas le workflow c’est plus la difficulté à le personnaliser.
Et justement, le fait d’aller vers des workflows même très simples, ça permet comme le dit @marcimat de facilement amener de la personnalisation.

Quand on regarde l’API objet, on configure les états mais il suffirait de configurer les transitions pour avoir de fait une logique de personnalisation des workflows.
Et on est pas obligé de faire compliqué par défaut.

Donc non, je ne trouve pas que ta remarque soit pertinente, mais c’est mon point de vue.

Ben je dirais qu’il faudrait se poser la question de la nécessité non ?
Mais si on le veut absolument je dirais que c’est une action générique, relativement dangereuse et je serais plutôt d’avis de la mettre à part et visuellement distincte.

La vrai question c’est pas tant l’action supprimer mais le besoin d’un état poubelle avant suppression totale ou pas suivant qu’on utilise corbeille.
Avec les autres états a-t-on vraiment besoin de passer dans un état intermédiaire de poubelle avant suppression physique.
C’est une question ouverte.

Le fait de faire des boutons d’actions direct, ne permet pas (quand on le souhaite, soit pour tel objet soit tel sous plugin qui l’ajouterait à d’autres objets) de complexifier au besoin, quand on veut obliger à remplir des champs supplémentaires pour tel ou tel changement de statut. Dans ce cas ça ne pourra se faire qu’après coup et donc sans obligation, ce qui ne va pas justement pour définir des workflows plus précis. J’ai déjà donné quelques exemples : obliger à mettre un commentaire quand on « refuse » un contenu, mais ça vaut pour « publier » aussi (= comme obliger à mettre un log de commit quoi, Wikipédia parfois oblige à ça), ou tout autre champ à remplir obligatoirement pour avoir le droit de passer à tel autre statut.

C’est extensible et possible quand on choisit un statut puis qu’on le valide (= par défaut ça ne fait que ça, mais si on veut on peut faire apparaitre des champs en plus), mais impossible si c’est une action immédiate.

Par ailleurs faut pas préjuger du nombre, là c’est « facile » en prenant que les statuts/transitions qu’on connait des articles mais 1) pour d’autres objets ça peut être bien plus et 2) même pour les articles, des sous-plugins peuvent décider d’en rajouter.

Mais c’est très bien tous ces brainstormings, ça dégrossit le terrain, et ouvre des pistes, merci.

1 « J'aime »

Je ne vois pas pourquoi.
La programmation avec un moteur de workflow est justement très souple et très personnalisable même si ça dépend de la performance du moteur.
Mais je pense que justement c’est bien plus pratique à coder et à personnaliser car cela s’appuie sur un déclaratif qui structure toute la démarche.

Et plus tu auras de statuts plus cela sera difficile de continuer à travailler en statut alors qu’en workflow on se promènera de statut en statut sans problème et avec les transitions pour guide.

Bonjour,
Je me permets moi aussi d’apporter un ressenti, car les derniers messages (sur l’orientation WorkFlow) m’interessent énormément : j’ai (très)souvent eu envie/besoin de changer/créer un workflow pour des objets SPIP, allant travailler sur Bonita ou ProcessMaker. Donc une telle ‹ systémisation › en API me paraitrait une superbe avancée.
Mais en relisant cette discussion, je crois identifier plusieurs points bien distincts (qui n’on tpeut-etre pas besoin d’etre tous résolus en meme temps, et pour la 4.0.0) :
0- une discussion sur les boutons d’actions directe (imposés par les mobiles ?),
ou à deux étapes
=> moi aussi j’oublie régulièrement de valider un changer en téléchargement, choix de rubrique ou…
sans aller jusqu’à la véritable discussion d’ergonomie, les divers SPIP 3 ont apporté AMHA une « certaine diversité » que je ressens parfois comme déstabilisante,mais cela devra attendre !
1- une suggestion d’amélioration de l’interface actuelle des statuts actuels
(corrrigée par Tcharlss, avec le bouton 'changer Inactif/Actif de Rasta )
=> j’achète dans l’immédiat
2- une discussion sur les actuels statuts et leur workflow actuel (avec/sans corbeille,ou d’autres plugins)
=> cela me parait etre un des derniers fondamentaux de SPIP (contournable avec {tout} )
qui n’est pas a changer sans réflexions, car cela pourrait re-mettre bcp en cause
3- l’idée de transformer l’implémentation du statut en généralisation
(commel’ont été :les autorisations, les liens, les mots, les API, les …)
=> BRAVO !
remplacer les ‹ statuts › par un ‹ moteur à statuts › élimine la discusion n°2
(car chacun pourra adapter facilement…) et ouvre un avenir…!

Alors, avec mon point de vue utilisateur je suggérerai bien sur le point initial n°1
un ‹ gogogo › sans attendre,
car l’accord semblait assez général avant l’ouverture esquissée par touti
ouverture très intéressante, mais qui dépasse largement la question initiale,
(trop) bien documentée et affinée dans cet échange…

Et donc ensuite, la question : je rejoins totalement Eric (son post 44) = envisager de
conceptualiser le passage du statut d’objet à un statut piloté par un moteur type workflow Petri
(bien évidemment personnalisable/dérivable par objet et par rubrique) !

Dans la conception des statuts de SPIP, tout objet qui vient d’être rédigé/créé n’est jamais publié sans une action supplémentaire.
Certains objets, comme les commandes, jamais publié, sera juste « en cours » ou « payée » via une API qui gère ce changement de statut.
Ailleurs (WP Joomla ou autre) on trouve deux boutons de validation lors de la rédaction d’un texte de page avec les notions d’action enregistrer en brouillon ou publier.
SPIP a été conçu pour un webzine avec de multiples autorisations suivants les statuts des « auteurs », l’article était ou non validé, refusé, mis à la poubelle etc non pas suivant un workflow prédonné mais suite à discussion., sujette, comme toute discussion à erreurs et retours en arrière (restons humains).
En introduisant dans le changement des stades de statut la notion de workflow, je trouve que cela complexie et réduit les capacités d’action de retour en arrière.
J’entends la notion de workflow mais je me demande si c’est à cet endroit que cela doit jouer.
En effet, dans l’exemple d’Eric, le workflow donné est imposé, le rajout du statut « archive » qui n’existe pas pose question pour celleux qui considèrent que ce n’est pas un statut (voir les discussions sur les listes SPIP et donc la question de comprendre la notion même de statut ). Le retour en arrière (erreur d’archivage par exmple) ne semble plus possible. Pourquoi ne plus pouvoir décider de passer mon article à la poubelle quand il est seulement « En cours de rédaction », alors que je viens de voir qu’un autre article parle du même sujet (exemple basic).
L’idée de Realet de requestionner l’affichage des changements de statuts est intéressante. J’ai tenté une réflexion plus conceptuelle et proposé un visuel qui ne perde pas ce que l’on connait déjà de SPIP et les fonctionnements de l’API de changement de statuts (qui n’inclut pas de workflow), une sorte de débroussaillage pour éclaircir les choses et les rendre compréhensibles.
Il serait de fait sans trop de modications tout à fait possible aux autres objets, sans changer leur code, de voir s’afficher proprement dans la boite de l’objet XX :
0/ Patate 23 : identifiant numérique et nom de l’objet
1/ Statut : label au lieu de la phrase tronquée sur le statut qui reprend le nom de l’objet
2/ publié : affichage du nom du statut sans le select coloré actuel mais avec la puce
3/ un bouton d’action qui ouvre la possibilité de changer le statut

Bref, amha il reste seulement à déterminer l’intitulé du ou des boutons à la validation du changement, that’s all. Et je propose que l’idée du workflow soit reporté à une branche ultérieure après discussion sur sa nécessité.

Voilou …
Capture d’écran 2021-06-03 à 13.01.14

Capture d’écran 2021-06-03 à 13.00.34

Non absolument pas, j’ai volontairement réduit le schéma à plus que le strict minimum pour étayer la discussion mais on peut rajouter les deux fameuses transitions supplémentaires comme illustré ci-après.
Maintenant, on introduit rien de nouveau, on a déjà un workflow, il est seulement non décrit et « plat de nouillesque » (5 états, 5x5 transitions). Dans le schéma il y a 4 états réels et 6 transitions auquel il faut rajouter l’action Supprimer: c’est quand même plus simple.

statut3

Mais la transition Supprimer n’est pas du même type que les autres. Qu’on passe l’article dans un statut poubelle c’est de la bidouille pour gérer une corbeille rien de plus ce n’est pas du cycle de vie.
Il me semble qu’il n’existe pas d’autre cas où on demande de passer un objet en poubelle, on propose une action Supprimer ou Mettre à la poubelle.
Pour moi elle est « hors workflow » et si on voulait voir encore ces articles il faudrait faire une action « Voir la poubelle ».

C’est possible oui :slight_smile: .
Mais je pense que cette piste de workflow est à creuser car elle s’avèrera à l’usage plus pérenne, plus personnalisable et plus ergonomique.
Un workflow bien pensé c’est didactique avant tout, pas restrictif.
C’est comme ça qu’il faut le concevoir pas à l’envers.

Et c’est aussi beaucoup plus personnalisable: aujourd’hui c’est très compliqué de modifier le comportement car les transitions sont implicites. J’ai conçu un plugin relecture pour introduire un workflow de relecture plus complexe et c’est très compliqué de s’intégrer dans l’existant.

Donc, on peut laisser le workflow à son stade de recherche pour le moment.

  • Il faudrait pouvoir redéfinir les statuts historiques de SPIP uniquement sur les articles, voire les renommer, en retirer ou en rajouter comme le statut archive, c’est aussi une autre et longue discussion, par exemple, une archive peut devoir rester publiée (ou pas) et ahma, archive n’est pas un statut. (Il faut aussi que le statut antérieur + la date de changement de statut soit accessible quelque part en plus que sur la page de révision.)
  • Que penser aussi de l’idée de déporter certains statuts dans le(s) bouton(s) d’enregistrement de l’objet comme dans les images WP que je présente plus haut et qui ne sont pas forcément explicites on s’y perd carrément et SPIP parait presque plus clair !
  • Peut-être revoir la nomenclature avec la notion de brouillon
  • questionne l’utilité de certains statuts, exemple de prop/prepa qui sont des faux statuts (dans l’idéal amha il n’y aurait que 2 statuts publié/non publié) prop/prepa/publie ne sont jamais qu’un mode d’accès au texte par
    rédacteurice-> administrateurices → internautes du site public.
  • des administrateurices me demandent pourquoi leur article à l’état « en cours de rédaction » ne sont pas visibles aux autres administrateurices, juste parce qu’ils ont oublié de changer le statut en « proposé à la publication » on a actuellement un gros bouton jaune orange pour pallier à ça mais ce n’est pas possible de poursuivre dans ce type d’UX de rattrapage.
  • donc là, ce n’est plus la petite boite de la colonne de l’objet mais on secoue tout et on revoit là où on révolutionne et là où on peut conserver.
    Bref, y’a de quoi alimenter les futures discussions :slight_smile:

Du coup … si on veut que cela avance
je vous propose de valider les différentes propales ci dessous et de nous concentrer sur l’intitulé du ou des boutons à la validation du changement.

  1. Patate 23 : identifiant numérique et nom de l’objet
  2. Statut : label au lieu de la phrase tronquée sur le statut qui reprend le nom de l’objet
  3. publié : affichage du nom du statut sans le select coloré actuel mais avec la puce
  4. un bouton d’action qui ouvre la possibilité de changer le statut

Voilà une PR liée à une branche de dev qui implémente la proposition de @touti, en essayant d’être accessible pas trop mal. J’ai bien précisé que c’était totalement en [WIP] :smiley: et j’ai expliqué en détail ce qu’il reste encore à faire.

Mais en tout cas fonctionnellement ça marche et cela pour tout objet, et je trouve déjà ça bien plus simple à comprendre pour le pékin moyen, merci touti :slight_smile:

Ben c’est dommage et frustrant de mon point de vue parce que l’ergonomie actuelle ne peut pas être fondamentalement améliorée si on reste sur la même approche. J’avais cru d’ailleurs que c’était un peu le sens de ta première intervention sur ce fil.

C’est là justement l’intérêt du workflow, son extensibilité.
Pour le statut Archive c’était un exemple, je ne pense pas que Archive tout comme Poubelle soient des statuts du cycle de vie de l’article mais plus des zones de rangements. C’est d’ailleurs ainsi que j’ai codé le plugin Archivage de contenus SPIP qui conserve le statut et permet une gestion de l’archivage sans modifier le statut.
Je vois les choses comme suit:
statut4

Ce qui fait que les statuts du cycle de vie sont toujours conservés quand on transfère un article d’une zone à l’autre et que la mise en poubelle ou en archive sont des mécanismes différents de instituer.
Je pense que cette logique serait préférable et donne la limite de ce qu’on appelle les statuts comparés aux mécanismes autonomes de suppression ou archivage.

Absolument pas, ce sont des vrais statuts : être en cours de rédaction, ou être en cours de revue d’un article ça a tout son sens. Par contre, refusé lui n’est pas un statut c’est clair. Si on refuse un article proposé à l’évaluation c’est qu’il n’est pas « fini » donc il revient à l’état en cours de rédaction.

C’est pas la faute du statut mais de l’absence de workflow guide pour comprendre comment vit un article.

Plus ou moins avec la liste des statuts mais continuer l’interface en ciblant des statuts ne peut en rien améliorer drastiquement l’UX ou UI de mon point de vue.

À noter que l’exemple de Wordpress avec des boutons avec des verbes, c’est justement ce que @eric_tonton appelle les transitions, dans les workflows (Enregistrer mon brouillon VS Publier). Et effectivement on pourrait très bien imaginer qu’en plus d’un bloc générique sur le côté contenant toutes les actions de workflows autorisées à un instant T, certaines actions puissent être déclarées aller aussi dans la barre de bouton d’enregistrement de l’édition du contenu, pour que certaines actions puissent être faites dès cette étape plutôt qu’en deux fois (d’abord enregistrer puis changer d’état). Mais c’est toute une grosse réflexion à avoir sur comment déclarer ces workflows, et les autorisations afférentes, etc. C’est un boulot intéressant cela dit :slight_smile:

1 « J'aime »