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 ,
- oui, bien sûr on peut discuter, et c’est très intéressant en plus
- 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:
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 
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 
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 :
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…
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 :
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) !