[spip-dev] r15001 - spip/squelettes-dist/formulaires

* cedric.morin@yterium.com tapuscrivait, le 24/01/2010 23:46:

Je ne sais pas si cela est satisfaisant.
Le libellé du bouton 'Modifier cet article' est effectivement erroné car le rédacteur n'a pas le droit de modifier l'article, mais le bouton sert en fait à aller sur l'article, dans l'espace privé, pas à le modifier.
En supprimant le bouton, on supprime le moyen de navigation privé-public, ce qui est très gênant.
Il faudrait sans doute plutot renommer le bouton de façon plus correct. Ou utiliser le libellé "Interface privé", en envoyant sur l'article tout de même (ce serait donc un bouton contextuel vers l'interface privée).

Pour ma part, ça fait des années que j'ai renommé ces boutons "modifier" en "gérer".
Et pour les formations, ça me facilité grandement la vie :
- gérer cet article passe du public au privé
- modifier cet article passe du privé à la modification du contenu.

Autrement, c'est "compliqué" d'expliquer de quel bouton "modifier" on parle (celui du public, ou celui du privé).

Mes 2 sous.

RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 24/01/2010 23:46:

Je ne sais pas si cela est satisfaisant.
Le libellé du bouton 'Modifier cet article' est effectivement erroné
car le rédacteur n'a pas le droit de modifier l'article, mais le
bouton sert en fait à aller sur l'article, dans l'espace privé, pas à
le modifier.
En supprimant le bouton, on supprime le moyen de navigation
privé-public, ce qui est très gênant.
Il faudrait sans doute plutot renommer le bouton de façon plus
correct. Ou utiliser le libellé "Interface privé", en envoyant sur
l'article tout de même (ce serait donc un bouton contextuel vers
l'interface privée).

Pour ma part, ça fait des années que j'ai renommé ces boutons
"modifier" en "gérer".
Et pour les formations, ça me facilité grandement la vie :
- gérer cet article passe du public au privé
- modifier cet article passe du privé à la modification du contenu.

Autrement, c'est "compliqué" d'expliquer de quel bouton "modifier" on
parle (celui du public, ou celui du privé).

Mes 2 sous.

Bonjour,

Au passage, ne serait-il pas possible de permettre quand-même aux
rédacteurs de proposer des modifications des articles, mais qui seraient
seulement proposées à la publication dans l'interface privée ?
...alors ça nécessiterait un nouveau statut d'article qui serait
"proposé à la modification" n'opposant pas pour autant à sa qualité
"publié" ?
Dans cette logique et en relation aux derniers échanges, il me semble
que ce qui manque à spip en natif pour les sites collaboratifs c'est
aussi une gestion des groupes d'intervenants, rendant plus souples la
distributions des permissions, et qui permettrait notamment d'assigner
des permissions hétérogènes suivant les personnes et les sections des
sites (par exemple permettre aux visiteurs mais seulement dans certaines
rubrique, de proposer des modifications).
Personnellement un de mes regrets c'est qu'en natif spip ne propose pas
de fonctions de publication ouverte, ce qui serait peut-être logiquement
le point de départ de la distribution des permissions d'un CMS à
vocation collaborative.

@+

PM

exact et c'est aussi le terme (avec "accéder à") auquel je pensais à défaut de trouver encore mieux. Le changement de version est une occasion d'améliorer l'ergonomie de ce cas
Claude

bonjour

RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 24/01/2010 23:46:

Je ne sais pas si cela est satisfaisant.
Le libellé du bouton 'Modifier cet article' est effectivement erroné
car le rédacteur n'a pas le droit de modifier l'article, mais le
bouton sert en fait à aller sur l'article, dans l'espace privé, pas à
le modifier.
En supprimant le bouton, on supprime le moyen de navigation
privé-public, ce qui est très gênant.
Il faudrait sans doute plutot renommer le bouton de façon plus
correct. Ou utiliser le libellé "Interface privé", en envoyant sur
l'article tout de même (ce serait donc un bouton contextuel vers
l'interface privée).

Pour ma part, ça fait des années que j'ai renommé ces boutons
"modifier" en "gérer".
Et pour les formations, ça me facilité grandement la vie :
- gérer cet article passe du public au privé
- modifier cet article passe du privé à la modification du contenu.

Autrement, c'est "compliqué" d'expliquer de quel bouton "modifier" on
parle (celui du public, ou celui du privé).

Mes 2 sous.

Bonjour,

Au passage, ne serait-il pas possible de permettre quand-même aux
rédacteurs de proposer des modifications des articles, mais qui seraient
seulement proposées à la publication dans l'interface privée ?
...alors ça nécessiterait un nouveau statut d'article qui serait
"proposé à la modification" n'opposant pas pour autant à sa qualité
"publié" ?

en fait tu proposes que le forum privé des articles soit accessible y compris pour les articles publiés

Dans cette logique et en relation aux derniers échanges, il me semble
que ce qui manque à spip en natif pour les sites collaboratifs c'est
aussi une gestion des groupes d'intervenants, rendant plus souples la
distributions des permissions, et qui permettrait notamment d'assigner
des permissions hétérogènes suivant les personnes et les sections des
sites (par exemple permettre aux visiteurs mais seulement dans certaines
rubrique, de proposer des modifications).

ce que j'ai fait pour un site, c'est de proposer des commentaires, des "remarques", non publiés pour me signaler les erreurs et corriger mais effectivement c'est ça OU les forums publics (modérés ou non). Si tu veux les deux il faut créer ses propres formulaires. Regarde aussi du côté du pluging "autorité"

Claude

bonjour

RealET a écrit :

* cedric.morin@yterium.com tapuscrivait, le 24/01/2010 23:46:

Je ne sais pas si cela est satisfaisant.
Le libellé du bouton 'Modifier cet article' est effectivement erroné
car le rédacteur n'a pas le droit de modifier l'article, mais le
bouton sert en fait à aller sur l'article, dans l'espace privé, pas à
le modifier.
En supprimant le bouton, on supprime le moyen de navigation
privé-public, ce qui est très gênant.
Il faudrait sans doute plutot renommer le bouton de façon plus
correct. Ou utiliser le libellé "Interface privé", en envoyant sur
l'article tout de même (ce serait donc un bouton contextuel vers
l'interface privée).

Pour ma part, ça fait des années que j'ai renommé ces boutons
"modifier" en "gérer".
Et pour les formations, ça me facilité grandement la vie :
- gérer cet article passe du public au privé
- modifier cet article passe du privé à la modification du contenu.

Autrement, c'est "compliqué" d'expliquer de quel bouton "modifier" on
parle (celui du public, ou celui du privé).

Mes 2 sous.

Bonjour,

Au passage, ne serait-il pas possible de permettre quand-même aux
rédacteurs de proposer des modifications des articles, mais qui seraient
seulement proposées à la publication dans l'interface privée ?
...alors ça nécessiterait un nouveau statut d'article qui serait
"proposé à la modification" n'opposant pas pour autant à sa qualité
"publié" ?

en fait tu proposes que le forum privé des articles soit accessible y compris pour les articles publiés

bon, j'ai regardé sur le mauvais site : les forums existent aussi lorsque l'article (le site, la brève) est publié

dlatr a écrit :

en fait tu proposes que le forum privé des articles soit accessible y
compris pour les articles publiés

Non, pas dutout : je propose que les articles en eux-mêmes puissent
évoluer suivant un mode multi-rédacteurs en versions successives
validables au fur et à mesure.
En gros, que se formalise une méthode rédaction en elle-même collaborative.

C'est encore juste une idée, qui supposerait qu'un article "publié"
puisse à son tour passer suivant un nouveau statut "archivé", en tant
que version, dès lors qu'une des ses copies "soumise à la rédaction" se
trouverait "validée", et donc remplace l'article initial dans
l'interface publique.

Par pure hypothèse cela signifierait peut-être :

- un distinguo entre articles traditionnels et articles collaboratifs
- des brouillons (propositions)
- des épreuves (propositions en cours de validation)
- des archives (copies des versions antérieurement validées)
- des équipes de rédaction (mais là je parle plus d'équipes de
'modération' - j'y reviens plus loin)
- les types de validation (unanime, majoritaires, par délégations, etc.)

Je reviens au concept de modération qui n' à ce jour aucune place
directe dans spip, parce que si j'ai fort apprécié l'évolution vers la
possibilité d'administrer par secteur, je l'ai un peu comprise comme une
évolution vers un système allant dans ce sens.
J'ignore ce qu'il en est à ce stade des développements, mais j'ai
l'impression que le rôle de modérateur a pleinement sa place dans spip
en natif, car dans le cadre de projets éditoriaux on peut imaginer que
les membres de l'équipe de rédaction d'un secteur puissent avoir leur
mot à dire concernant le contenu sur le fond d'articles d'une autre
rubrique que la leur ; on peut concevoir aussi cette séparation afin de
rendre possible la publication automatique d'un contenu dès lors qu'une
forme de majorité d'utilisateurs-modérateurs ait agréé à celle-ci sans
déléguer cette prérogative à une personne ou à groupe spécifique. On
peut aussi concevoir que dans certaines organisations le fait d'être
l'auteur même d'un article puisse interdire et non autoriser
automatiquement la publication en ligne de celui-ci...

En un certain sens il s'agirait d'émanciper la partie constitution de
contenus / décision rédactionnelle de SPIP de sa partie administrative
informatique, afin de rendre les premières moins "hiérarchiques" et plus
souples et "démocratiques", dans la mesure du possible. Ce que j'ai pu
constater c'est que les prérogatives d'administrateur se révélaient
souvent un encouragement à l'autocratie qui pouvait même contrarier les
processus collaboratifs, à vrai dire. Je met ça en relation au fait
qu'en l'état, le statut de rédacteur reste pour le moins frustrant
puisque ne permettant pas l'auto-publication voire la publication de
l'article d'un tiers, ce qui souvent serait souhaitable, sans pour
autant requérir la permission de modifier en structure les rubriques.

Si je résume ce qui concerne l'évolution des types d'utilisateurs je
crois qu'un manque est certainement de ne pas pouvoir combiner les rôles
: rédacteur par là, modérateur ailleurs, par groupe ou individuellement.

PM

Bonjour

Le tout est deja plus ou moins présent à l'heure actuelle.
Il faut voir si on peut determiner un statut de publication à un
article et à une révision donnée, à partir de là ça repondrait à vos
question si je ne m'abuse.

L'espace privé permet d'assurer déjà un suivi des version des
rédactions en affichant soit la différence entre 2 version soit le
contenu exacte d'une version donnée.
Vous avez les pipeline pre_boucle et post_boucle de présent qui
devrait permettre la surcharge du comportement par défaut coté
publique.

A l'heure actuelle l'ensemble des éléments requis semble etre présent,
il manque un bon cuistot pour faire monter la mayonnaise

Km

Non, ce ne sont « que » des révisions, pas des versions.

Pouvoir préparer de nouvelles versions de contenus déjà publiés, sans avoir à retirer ce qui est publié ni dupliquer le contenu (et perdre les id donc les URL), ce serait top !

-Nicolas

Bah c'est assez facile, suffit de faire comme dans spip-agora non ? :stuck_out_tongue:

Troll mis à part, c'est une fonctionnalité assez simple maintenant à
intégrer, tous les problèmes sous jacents (liens avec les documents)
ont été évacués :

- "Creer une copie de travail" --> copie de l'article et de ses liens
avec les documents, auteurs, mots clés etc ..., ajout d'un flag
"copie_de"=id_article, et statut=redac

Aucun problème particulier pour l'edition de cette version de travail,
qui est versionnee normalement.

- "Publier cette copie à la place de l'article d'origine" -> Echange
des contenus et liens des 2 versions, pour que la versions publiées
soit mise à jour. La copie de travail devient une version
archivée/refusée/poubelle, au choix.
Là il y a un choix à faire sur le traitement des révisions. Est-ce
qu'on veut conserver les révisions de l'article d'origine et y commit
la nouvelle version en un coup ? Est-ce qu'on que l'article modifié
hérite des révisions des deux articles ? Est-ce qu'on ne garde que les
révisions depuis le passage en mode 'copie de travail' ?

Il n'y a donc techniquement aucune restriction depuis que les
documents peuvent être proprement associés à plusieurs articles.
Cédric

Le tout est deja plus ou moins présent à l'heure actuelle.
Il faut voir si on peut determiner un statut de publication à un
article et à une révision donnée, à partir de là ça repondrait à vos
question si je ne m'abuse.

L'espace privé permet d'assurer déjà un suivi des version des
rédactions en affichant soit la différence entre 2 version soit le
contenu exacte d'une version donnée.

Non, ce ne sont « que » des révisions, pas des versions.

Pouvoir préparer de nouvelles versions de contenus déjà publiés, sans avoir à retirer ce qui > est publié ni dupliquer le contenu (et perdre les id donc les URL), ce serait top !

Bah c'est assez facile, suffit de faire comme dans spip-agora non ? :stuck_out_tongue:

Cette fonctionnalité était très appréciée, effectivement... :wink:

Troll mis à part, c'est une fonctionnalité assez simple maintenant à
intégrer, tous les problèmes sous jacents (liens avec les documents)
ont été évacués :

- "Creer une copie de travail" --> copie de l'article et de ses liens
avec les documents, auteurs, mots clés etc ..., ajout d'un flag
"copie_de"=id_article, et statut=redac

Aucun problème particulier pour l'edition de cette version de travail,
qui est versionnee normalement.

- "Publier cette copie à la place de l'article d'origine" -> Echange
des contenus et liens des 2 versions, pour que la versions publiées
soit mise à jour. La copie de travail devient une version
archivée/refusée/poubelle, au choix.
Là il y a un choix à faire sur le traitement des révisions. Est-ce
qu'on veut conserver les révisions de l'article d'origine et y commit
la nouvelle version en un coup ? Est-ce qu'on que l'article modifié
hérite des révisions des deux articles ? Est-ce qu'on ne garde que les
révisions depuis le passage en mode 'copie de travail' ?

Je dirais que les révisions du nouvel article devraient d'ajouter à celles de l'article d'origine, mais si on fait des modifs dans l'article d'origine après avoir créé la copie, ça va pas être simple, donc le mieux est peut-être de tout « simplement » échanger les deux id, et mettre un statut "archive" à l'ancien article.

-Nicolas

Ah, suis-je bête. La solution simple est de copier l'article original
ET ses revisions au moment de la creation de la copie de travail, ce
qui fait que celle-ci hérite de tout l'historique, et qu'on garde tout
bien quand à la fin on échange les deux ID.

Voila donc le problème principale de résolu, il n'y a plus qu'a
aligner les quelques lignes de code qui vont bien, et l'interface.

Cédric

On perd quand même les modifs faites sur l'original après copie, mais cela me semble de toute façon difficile de l'éviter, tout comme on a du mal à suivre les modifs entre traductions...

-Nicolas

Salut,

Après quelques échanges sur IRC on a retenu le verbe "Consulter" pour remplacer "Modifier" dans le bouton d'admin affiché pour un rédacteur qui n'est pas autorisé à modifier l'article. Je trouve que le verbe "Gérer" est un peu trop vague et en plus on ne peut rien "gérer" si on est auteur et que l'article est publié...

Des objections ? D'autres propositions ?

Salut,

Après quelques échanges sur IRC on a retenu le verbe "Consulter" pour remplacer "Modifier" dans le bouton d'admin affiché pour un rédacteur qui n'est pas autorisé à modifier l'article. Je trouve que le verbe "Gérer" est un peu trop vague et en plus on ne peut rien "gérer" si on est auteur et que l'article est publié...

Des objections ?

non, c'est bien
mais tu écris pour les rédacteurs, pas pour les admins ? si quand même
claude

Après quelques échanges sur IRC on a retenu le verbe "Consulter" pour
remplacer "Modifier" dans le bouton d'admin affiché pour un rédacteur qui

"Consulter" un article que tu consultes déjà est un peu trompeur... je
n'aime pas non plus le fait d'avoir deux boutons.

-- Fil

Nicolas Hoizey a écrit :

Bah c'est assez facile, suffit de faire comme dans spip-agora non ? :p
    

Cette fonctionnalité était très appréciée, effectivement... ;-)
  

Je dirais même que c’est la raison principale pour laquelle certains sites tournent encore dessus, maintenant que polyhiérarchie existe.

Un tel système intégré en natif serait fortement bénéfique à spip dans des contexte « sérieux ».
De même qu’une gestion plus poussée et plus fine des droits d’utilisateurs comme ça a été mentionné (groupes, paramétrage fin des groupes de mots-clés pour distinguer ceux réservés aux webmestres / admins / admins restreints / rédacteurs…).

C’est, avec la facilité de création d’un nouvel objet sur mesure, ce qui a (malheureusement) orienté certains développements de sites que je connais vers drupal alors qu’ils étaient précédemment en spip.

A bientôt
Simon

Fil proposait sur IRC :

[Article 12] vs [Espace privé]

Donc ça donnerait :

- je suis autorisé à modifier l'article => [Article 12]
- je ne suis pas autorisé à modifier l'article => [Espace privé]

Avec les deux boutons qui pointent sur exec=articles et on vire le bouton qui pointe sur directement sur exac=articles_edit.

On a un bon compromis avec ça ?

Je vois pas l'intérêt de changer le libellé du bouton.
Le premier "Article 12" convient pour tout le monde.
C'est ce que proposait tetue hier au soir déjà :stuck_out_tongue:

Cédric

Fil proposait sur IRC :

[Article 12] vs [Espace privé]

Donc ça donnerait :

- je suis autorisé à modifier l'article => [Article 12]

Pourquoi dans ce cas n'aurais-je plus le bouton permettant d'accéder au « tableau de bord » de mon site, l'accueil de l'espace privé ?

- je ne suis pas autorisé à modifier l'article => [Espace privé]

Avec les deux boutons qui pointent sur exec=articles et on vire le bouton qui pointe sur directement sur exac=articles_edit.

On a un bon compromis avec ça ?

++
b_b

Après quelques échanges sur IRC on a retenu le verbe "Consulter" pour
remplacer "Modifier" dans le bouton d'admin affiché pour un rédacteur qui

"Consulter" un article que tu consultes déjà est un peu trompeur... je
n'aime pas non plus le fait d'avoir deux boutons.

-- Fil

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip

-Nicolas

* Bruno Bergot tapuscrivait, le 26/01/2010 13:03:

Fil proposait sur IRC :

[Article 12] vs [Espace privé]

Donc ça donnerait :

- je suis autorisé à modifier l'article => [Article 12]
- je ne suis pas autorisé à modifier l'article => [Espace privé]

Avec les deux boutons qui pointent sur exec=articles et on vire le
bouton qui pointe sur directement sur exac=articles_edit.

On a un bon compromis avec ça ?

Non, on perd une fonctionnalité que je donne parfois en formation : puisqu'on peut faire des liens vers des articles, c'est pratique de pouvoir voir dans l'espace public l'identifiant de l'article via le bouton d'admin (surtout dans un site où la navigation publique ne correspond pas forcément au classement dans l'espace privé).
Donc, [Article 12] dans tous les cas me semble préférable.