Pluxml - son intérêt et ses curiosités
delagomme
Member
Habitué des CMS plus lourds, je ne peux qu'être séduit pas l'efficacité de pluxml. Question rapidité, c'est une vraie Ferrari au milieu des grosses cylindrées poussives que sont les CMS qui sont sur le devant de la scène.
Il y a pourtant quelques curiosités qui me laissent sur ma faim :
- les auteurs ne peuvent créer qu'un type de document (l'article de blog) : la page de contenu serait la bienvenue.
- l'administrateur peut créer des documents en le signant de l'auteur de son choix : jamais je ne n'oserais proposer une pareille fonctionnalité (hormis pour des tests).
- un auteur choisit la date de publication de son document : pourquoi ne pas avoir laissé le système géré cela ? Cela peut créer des confusions.
- la gestion des images gagnerait à être séparée de la rédaction des articles : des auteurs lambdas doivent pouvoir uploader des images pour un article sans obligatoirement être confrontés au gestionnaire d'images.
Je vous ai livré en vrac mes quelques impressions sans vouloir remettre en cause les travail effectué (j'imagine le paquet d'heures passées pour y parvenir) ni la qualité du produit qui me semble très prometteur notamment pour tous les utilisateurs qui souhaitent mettre en place des blogs et des pages de contenus chez leur FAI. Ces derniers sont incapables de gérer convenablement les CMS avec base de données (j'ai testé Wordpress et Drupal sur SFR et Free... C'est une calamité). Par contre Pluxml me semble le produit idéal pour ce faire.
Amicalement.
Il y a pourtant quelques curiosités qui me laissent sur ma faim :
- les auteurs ne peuvent créer qu'un type de document (l'article de blog) : la page de contenu serait la bienvenue.
- l'administrateur peut créer des documents en le signant de l'auteur de son choix : jamais je ne n'oserais proposer une pareille fonctionnalité (hormis pour des tests).
- un auteur choisit la date de publication de son document : pourquoi ne pas avoir laissé le système géré cela ? Cela peut créer des confusions.
- la gestion des images gagnerait à être séparée de la rédaction des articles : des auteurs lambdas doivent pouvoir uploader des images pour un article sans obligatoirement être confrontés au gestionnaire d'images.
Je vous ai livré en vrac mes quelques impressions sans vouloir remettre en cause les travail effectué (j'imagine le paquet d'heures passées pour y parvenir) ni la qualité du produit qui me semble très prometteur notamment pour tous les utilisateurs qui souhaitent mettre en place des blogs et des pages de contenus chez leur FAI. Ces derniers sont incapables de gérer convenablement les CMS avec base de données (j'ai testé Wordpress et Drupal sur SFR et Free... C'est une calamité). Par contre Pluxml me semble le produit idéal pour ce faire.
Amicalement.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J’avoue ne pas avoir trouvé l'utilité à ça, mais de la à créer des confusions ?
il est vrai que cela peut être amélioré.
Merci de nous faire part de tes remarques.
Je vais apporter quelques éléments à tes questions:
- Si par "page de contenu" tu entends "page statique", ce choix a été fait car dans les pages statiques on peut ajouter du code (php, javascript, etc...) et donc nous le réservons aux admins et rédacteurs avancés. De plus les pages statiques ont un contenu statique, qui normalement doit peu changer. Les auteurs ont donc uniquement accès aux contenus dynamiques c'est à dire les articles, ce qui va dans le sens d'un CMS.
- L'administrateur administre un site. Il doit donc avoir la main sur le paramétrage et également pouvoir modifier, corriger, rectifier tout le contenu du site. On lui laisse donc la possibilité de modifier l'auteur d'un article.
- Le système propose par défaut la date de publication d'un article. Si on peut modifier la date c'est pour pouvoir programmer la publication d'un article à une date future. Fonction indispensable. Tout les bloggeurs te le diront.
- 2 façons des gérer les images. Par le menu Medias dans la barre des menus ou par l'icone "image" de la plxToobar associée au chapo ou au contenu de l'article. C'est uniquement avec cette icone que l'on peut ajouter une image dans les articles.
Voilà
Et bienvenue dans le monde de PluXml
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
- De la même façon, les dates de publication peuvent être très utile. Il pourrait d'ailleurs être intéressant de les intégrer dans un calendrier. Toutefois, il me semble qu'il y ait confusion entre date de création et date de publication. Si une anomalie survient sur un document produit à une date qui n'est pas celle de la création, comment l'administrateur peut-il diagnostiquer un dysfonctionnement (lié à une mise à jour par exemple) ? Les deux dates devraient à mon avis apparaître dans le formulaire de façon à savoir quand l'anomalie a pu se produire.
- Quant à dire que l'administrateur a tous les droits, c'est un propos qui me paraît erroné. Pour avoir administré plusieurs bases documentaires et autres systèmes de travail collaboratif, il me semble qu'il a surtout beaucoup de devoirs (là le discours est un peu politique) à commencer par celui d'être le garant des informations produites pas les auteurs. Sauf à gérer un système de révision documentaire avec historique des modifications, il me paraît dangereux d'offrir une pareille fonctionnalité (c'est pourquoi je pensais initialement qu'il s'agissait d'une fonctionnalité de test).
- Enfin, concernant la gestion des images évoquées, je me plaçais du côté du rédacteur de base en pensant au formulaire "Article" que propose Drupal soit un nombre limité de champs :
- titre,
- contenu,
- image à charger à l'intérieur du document (sans box, bref très dépouillé),
- tags
- et enfin catégorie (que l'on peut assimiler au "menu link" si celle-ci est intégrée dans une barre de menu comme je l'ai vu sur certains sites).
Au final, un formulaire aussi simple qu'efficace pour les auteurs de base qui ne souhaitent pas avoir un système trop complexe sous les yeux.
Amicalement.
Le gestionnaire de medias de Pluxml a évolué, depuis sa création, justement par l'apport des demandes des utilisateurs de base (création de dossiers, miniatures, etc...).
Rien n'est parfait, évidemment, mais il me semble que le système Pluxml est un des moins complexes (pour l'utilisateur) parmi ceux que j'ai eu à tester.
à plus,
Gzyg
Je ne partage pas votre avis. L'administrateur a tous les droits (sinon qui les a ^^) Son role est de garantir le bon fonctionnement des outils mis à disposition des utilisateurs. Il peut ensuite effectivement porter une autre casquette, celle de garant des données, role qu'on assimile plus souvent à un modérateur ou par exemple au rédacteur avancé dans PluXml. Mais son role 1er n'est pas ou ne devrait pas etre de gérer un contenu editorial. Il me semble plus approprié d'avoir une hierarchie des roles moins simplistes avec des fonctions mieux bornées. Un administrateur gère le site (config, paramètrage, droits, etc), des modérateurs qui gèrent le contenu du site, des rédacteurs qui alimentent le contenu du site. Apres certains roles peuvent porter plusieurs casquettes: un admin peut modérer et etre rédacteur. Il faut bien garder à l'esprit ces bases reprises dans beaucoup de systemes informatiques et sur lesquelles se repose également PluXml.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Que diable ! Personne ne doit avoir des droits pareils. Comme tu le signales, la division fonctionnelle entre Administrateur et Modérateur (je ne parle pas de l'ingénieur système ou réseau) peut assurer une juste répartition des pouvoirs. Quant à la question des droits et devoirs, elle est inscrite dans la charte du site qui, comme dans la vie courante, encadre les actions possibles. En ce qui me concerne, je ne pourrais y écrire que l'Administrateur et/ou le modérateur se réservent le droit de prendre l'identité d'un auteur en s'appropriant un contenu ou en signant un nouveau document de leur nom (intentionnellement ou malencontreusement d'ailleurs), c'est pourquoi cette liste déroulante des auteurs me paraît dangereuse.
Amicalement
Quand un ouvrier est malade, le Patron (Admin) n'est pas en droits de choisir un remplaçant pour faire le boulot à la place de ce dit malade ?
Bref tu le souligne aussi , l'administrateur/Modérateur doit intervenir dans les propos posté dans les articles et doit faire face aux imprévus (rédacteur non dispo a l'heure par exemple).
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Un administrateur/modérateur (sérieux) est le premier à ne pas se tirer une balle dans le pied en faisant n'importe quoi...
Les arguments du remplacement au pied levé sont de plus très judicieux.
à plus,
Gzyg
A quel moment et dans quelles circonstances est-il nécessaire de substituer au nom d'un auteur celui d'un autre ?
Moi je n'ai pas de réponse.
Amicalement.
Je suis rédacteur mais j'ai aussi un profil de rédacteur avancé (donc modérateur). Je peux relire les écrits d'un rédacteur et participer à la rédaction. Au final en commun accord nous décidons de ne pas rendre nominatif l'auteur de l'article mais de l'attribuer à un profil générique au nom de l'équipe.
Ces exemples ne sont pas pris au hasard.
Autre cas. PluXml peut etre un outil familial. J'aide mamie ou le petit frère à rédiger leur article. J'ai mon propre compte, mais au final l'article est à publier avec leur nom.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Je te remercie pour cette réponse.
Dans le cas de PluXml qui se limite à 3 niveaux de hiérarchie, il faut s'accorder certaines libertés si on ne veut pas s'enfermer au risque de ne pas pouvoir faire certaines actions.
En plus je trouve incohérent d'interdire le changement de nom du rédacteur d'un article à un admin, quand cette meme personne à la possibilité de supprimer et/ou modifier le contenu des articles (fonctions suppression/edition dues à son role d'admin).
C'est sur ça que j'ai surtout réagit car ce fil de discussion me semblait intéressant, pas uniquement sur le simple fait d'interdire ou non le changement de rédacteur, qui est lié à des choix de conception dans PluXml, mais à ce qui en découle, les responsabilités humaines liées à des fonctions, à savoir ce qu'on interdit ou autorise de faire, sous quelles conditions et quelles limites (sécurité, confidentialité, etc...)
Mais je comprends mieux que tu aies lancé ce sujet si tu travailles avec des systemes plus complexes où il faut se poser beaucoup plus de questions sur qui fait quoi et comment.
Consultant PluXml
Ancien responsable et développeur de PluXml (2010 à 2018)
Pour en revenir au débat, pluxml est peut-être "trop" laxiste sur l'aspect édition par autrui d'un contenu rédigé par un premier auteur. On pourrait pour lever toute ambiguïté mettre un champs "rédacteur" non modifiable (readonly="on") une fois l'article sorti des brouillons, et un champs "correcteur" où apparaîtrait le nom du dernier correcteur/éditeur, champs accessible par une fonction permettant de l'afficher en frontend.
A voir, mais débat très intéressant.
On peux même à la limite ajouter en bas de page de l'article par exemple:
Dernière modification le 27/10/2010 par Tartenpion.
- il y a le client
- il y a "nous"
- et entre les deux, il y a une société dite "de création de contenus".
Ces dernières sont souvent l'intermédiaire ; elles créer le contenu pour le client (car un article, ça se prépare, ça ne se pond pas comme ça, et que c'est vraiment toute la communication via le web de la société cliente qui est en jeu)
Ensuite, elles intègrent elles même le contenus, sauf les premiers contenus présent à la livraison du site ;
Dans la mesure où c'est la société intermédiaire qui à créer le contenu pour le nom d'une société (et éventuellement pour le nom de telle ou telle responsable de la société, ou tel responsable du service x ou y), et dans la mesure où c'est "nous" qui intégrons le contenu, il va de soit qu'on soit OBLIGE de pouvoir choisir l'auteur du contenu, quel qu'il soit
Sur tout CMS, l'administrateur (les) doivent pouvoir publier au nom de quelqu'un ; c'est impossible autrement ^^
Un supérieur hiérarchique qui s'approprie le travail d'un autre, c'est presque le quotidien de très nombreux employés. Moi-même, j'ai été cadre et malgré mes responsabilités, à de nombreuses reprises, il m'est arrivé de bosser dur sur un dossier pour m'apercevoir que mon patron s'est contenté de le lire et d'y ajouter sa signature au bas de la première page. Surpris, oui la première fois...
De même, ceux qui espèrent faire carrière en tant que professeur d'université le savent bien. Pendant leur thèse, ils rédigent un paquet d'articles pour leur responsable qui s'appropriera leur travail et récoltera la gloire. Ensuite, ayant "honoré" leur chef tout-puissant, ils pourront voler de leurs propres ailes. Beaucoup de mes amis l'ont vécu, c'est presque une règle tacite dans les doctorats.
Deux exemples pour illustrer qu'un administrateur, s'il est au sommet de la pyramide, est -malheureusement - libre de faire pratiquement tout ce qui lui plaît.
Mais en cas de problème, il devra assumer et en payer le prix.