Qu'attendez-vous d'un CMS ?
Plop,
Le sujet est surrané mais il vaut quand même le coup d'être lancé, en tous cas en ce qui concerne Pluxml. Aujourd'hui, avec la sortie de la version blog, on arrive à un premier palier, une sorte de première pause après la tempête et le rush des betas.
En passant, cette version blog est sans nul doute née grace à vous.
C'est donc à vous tous qu'elle est dédiée
Bref, aujourd'hui, si vous faisiez un petit bilan de votre expérience sous pluxml qu'en retiendriez-vous ? Et plus largement, qu'attendez-vous d'un script de gestion de contenu ?
Le sujet est surrané mais il vaut quand même le coup d'être lancé, en tous cas en ce qui concerne Pluxml. Aujourd'hui, avec la sortie de la version blog, on arrive à un premier palier, une sorte de première pause après la tempête et le rush des betas.
En passant, cette version blog est sans nul doute née grace à vous.
C'est donc à vous tous qu'elle est dédiée
Bref, aujourd'hui, si vous faisiez un petit bilan de votre expérience sous pluxml qu'en retiendriez-vous ? Et plus largement, qu'attendez-vous d'un script de gestion de contenu ?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Je suis heureux d'être le premier à poster sur ce topic
Pour moi, un CMS doit être tout d'abord léger et bien configuré par défaut (car c'est ce qui m'a fait reculer devant Xoops, GuppY et bien d'autres).
Il doit être beau et agréable à voir.
Il doit être extensible, pour qu'il puisse être polyvalent.
Il doit être libre.
Il doit aussi être polyvalent, et donc personnalisable.
En fait, il doit être tellement de choses que je peux pas m'en rappeler comme ça! Donc j'ai déjà marqué l'essentiel, et le reste je le rajouterais avec des edits
Salut!
donc Gratuit
Des billets
Des commentaires
La gestion des billet et des commentaire
La validité
La personalisation " facile "
Que même les débutant peuventy arriver
Et que j'aime.
Ensuite, pour moi, pour être le meilleur, il doit aussi être conforme aux normes d'accesibilité, facilement customisable et rapide à prendre en main, ce qui est à peu près le cas de pluxml aujourd'hui, à peu près, parce que pluxml est léger, conforme aux normes, facilement customisable graphiquement, mais il lui manque encore un peu de maturité (et c'est normal à ce stade) pour disposer d'une communauté suffisante qui permettra la création de plugins qui répondront aux divers besoins et demandes des utilisateurs finaux au niveau fonctionnalités, afin d'être accessible lui aussi à un plus grand nombre d'utilisateurs, car il faut bien le reconnaître, à l'heure actuelle, un utilisateur lambda ne peut pas faire ce qu'il veut de pluxml (je le répète, ce n'est pas une critique, c'est normal, mais je réponds à la question sur ce qu'est pour moi un CMS et je vais un peu plus loin en comparant le pluxml d'aujourd'hui à cette réponse), car cela requiert un minimum de connaissance en php (que moi même je n'ai pas, n'est-ce pas skyline ? j'espère au passage que tu ne m'en veut pas pour mon dernier message sur le topic où je demande un peu d'aide en php
Certains diront, pluxml veut rester léger, pas devenir une usine à gaz avec des tonnes de fonctionnalités, je répondrais d'accord, mais le fait d'avoir de multiples fonctionnalités que l'on peut ajouter au noyau de base par plugin ne signifie pas transformer forcément pluxml en machine de guerre excessivement lourde, j'entends par là que tous les utilisateurs n'ont pas les même besoins et ce n'est pas parce qu'on peut ajouter 50 plugins à un logiciel qu'on ajoute les 50, on ajoute ceux dont on a besoin, et pouvoir ajouter deux ou trois fonctionnalités dont on a besoin facilement tout en restant très léger, ce sera là à mon avis la force de pluxml par rapport aux autres cms, très lourds et chargeés en fonctionnalités inutiles par défaut.
Voilà kloobik, en éspérant que ma réponse ne parraisse pas dénuée de sens et inutile, qu'elle ne soit pas mal interprétée, car un des gros problème et je m'en rend de plus en plus compte (je me répète, ce n'est pas une critique à quelqu'un en particulier) de la communication indirecte, par écrans interposés est qu'il est difficile d'être honnête et sincère sur internet sans risquer de blesser quelqu'un, mais je suis quelqu'un de sincère (là des gens doivent se dire il est reloud ou parano, en vrai je suis un peu bourré après un bon gevrey chambertin et un bon crémant de bourgogne avec des amis ...
PS: une partie du message est Hors sujet, j'en suis désolé kloobik, mais je n'aime pas que ce que je dis soit mal interprété, surtout par des gens que j'estime, alors je prends des précautions, et je m'explique avant que ça ne risque de l'être
Ce que j'attends d'un CMS, c'est qu'il fasse CMS : que je n'aie pas à aller sur mon FTP pour créer de nouvelles pages (y compris des scripts spécialisés, autrement dit créer des pages connexes et créer des pages en se servant de PHP est ce qui me sert le plus).
Pluxml m'a réconcilié avec les CMS, de plus c'est sa simplicité que j'aime beaucoup : je n'ai jamais essayé Guppy, je ne doute pas qu'il soit très bien, mais Pluxml fait juste le nécessaire.
Libre, donc Gratuit
Libre (c'est-à-dire OpenSource), OK ! Gratuit ... les développeurs sont ... libres !
La définition originale est « free as freedom ».
Ensuite, j'attends d'un CMS deux choses :
1. en tant que rédacteur, la simplicité du code de base ;
2. en tant que visiteur, la lisibilité (que la "technologie" s'efface devant le contenu ...).
Et c'est pour ça que j'aime Pluxml : un rédacteur (même débutant) ne perds pas des semaines à comprendre toutes les"fonctionnalités" et leurs imbrications et peut rapidement mettre en ligne un site privilégiant le contenu !
Et, à en juger par la "skinmania"
à plus,
Gzyg
s'il manque encore deux trois features, je pense que la base solide est la.
A partir de la,
si je devais orienter le développement du CMS pour la suite,
je pense que je m'attellerais a la rendre accessible et conviviale,
1-je pense par exemple de devoir passer par un client ftp pour charger
des fichiers ou de baliser a la main pour la mise en page des articles.
Je pense qu'il serait temps de s'intéresser aux utilisateurs qui n'ont pas
de connaissances techniques ou de compétences web.
Vous allez me dire : "ça s'apprend"
oui, bien sur, mais je n'ai qu'a voir ma femme qui s'affole des que je lui dis
qu'il faut utiliser son client ftp pour charger une vidéo
par en cacahuètes car elle a oubliée de fermer une balise. :P
Accessible.
2- pour moi, actuellement, plum est le script "parfait", une tres bonne base,
je verrais plutôt les ajouts futur sous forme de plugs.
Je n'ajouterais personnellement plus aucune de fonction au système mais développerais
un systeme de "supermarché" de la fonction et l'utilisateur pourrait venir ici sur le site
ou le forum choisir les fonctions qu'il désire et les ajouter lui même, ca permettrais
de se centrer sur ce qu'on veut et éviterais l'avenir "usine a gaz" du script.
Un exemple:
je pense a la fonction menu de choix de skin qui m'intéresse et intéresse visiblement
d'autre utilisateur un petit module a telecharger ici et a ajouter serait probablement
une bonne solution, ceux uqi desirent la fonciton en disposeraient et ceux que ca
n'interresse pas ne verraient pas leur cms alourdit par ue fonction "inutile".
convivial donc.
Au vu de ma petite experience dans les CMS (dont Guppy pour lequel je fais partie de la Team Design), je noterai simplement qu'il faut penser à l'avenir des les fondations, car plus le projet prend de l'importance, plus il est difficile de restructurer le tout.
Ce que j'attend d'un CMS comme pluXML
1 : Accessibilité : codage en Xhtml Strict et validation AAA
2 : Multilanguages : cela va de paire aussi avec le strict
3 : Usabilité : acces rapide au contenu et à l'edition pour tous avec l'integration d'un editeur qui valide et wysiwyg (le plus dur)
4 : une structure plus facilement sauvegardable; et non pas un repertoire XML et XMLrep qui serait plus simple d'imbriquer dans un meme dossier datas.
5 : Securité: renforcement de la securité par index de dossier et mis en place de htaccess (apache)
6 : possibilité d'integré des scripts annexes (plugins)
voilà, en esperant avoir pus apporté de l'eau à mettre dans votre moulin pour l'evolutivité de votre projet que j'aime bien et suis de pres.
Amicalement,
- pas de base de données, léger, compact, compatible, respectueux des normes, facile à déménager et à installer.
- peu de fichiers scripts, lisibles et simples à modifier pour rajouter un bout de code maison. Les templates servent à ça : rajouter un lecteur de flux RSS en home par exemple (je ne suis pas développeur, j'ai bricolé un bout de code qui me donne partiellement satisfaction : l'idée était d'afficher deux fils, l'un distant, l'autre, celui des titres des news du plumxl. Ça marche, mais ce n'est pas propre).
- un module d'administration simple et robuste, un module d'édition qui permette d'insérer les balises html ou css que j'utilise le plus souvent (j'ai rajouté un truc comme ça, non wysiwyg surtout !).
- la possibilité d'envisager des extensions ou plug-ins, des ajouts et des modifications simplement (cf. le module mp3 qui est un un parfait exemple)
Ce que j'en attends également :
- un formulaire de contact avec un capchka ou un truc comme ça
- un mode prévisualisation avant publication des billets
- la possibilité d'appeler un article distant depuis un autre site pluxml
- une extension XPI firefox pour saisir à la volée un billet à tout moment. Ça existe pour d'autres CMS, pourquoi pas pour pluxml ?
- lire et publier des fichiers ics (calendrier)
Amicalement.
Je découvre PlumXML qui semble très prometteur. Alors bravo!
J'utilise Joomla! depuis plusieur années et mes commentaires en sont donc inspirés. Le succès de ce CMS réside dans certaines particularités qui facilitent aussi bien son utilisation que les développements de fonctionnalités supplémentaire.
Voici donc quelque souhaits qui, à mon sens, feraient prendre la mayonnaise:
1. un système d'installation des templates dans l'admin
2. moins de code dans les templates. Le système de gestion des templates est proche de celui de Joomla! et ce serait bien d'avoir certaines fonctions accessibles par des objets offerts par le noyau. Ex: liste des articles. D'ailleurs, l'adaptation de templates Joomla! (des centaines!) semble assez simple et il n'est pas impossible que je m'y intéresse d'ici quelques temps.
3. un système de plugins pour ajouter des fonctionnalités ou des "bridges" (galleries, forums...).
4. une doc de l'API du noyau pour développer ces futurs plugins
5. une gestion poussée des droits des utilisateurs
6. un éditeur WYSIWYG serait le bienvenu (FCKeditor ou autre)
7. Une rediredtion automatique vers le script d'install lors du premier lancement serait bien pratique
Une autre chose qui pourrait plaire aux utilisateurs sont les effets proposé par une librairie comme MooFx ou son successeur MooTools(Ajax).
Attention aussi à la sécurité. Le succès attire les hackers et une réputation est vite faite...
D'autre part, le choix d'XML plutôt que MySQL pour stocker les articles est original mais ce serait bien de le proposer aussi
Je suis conscient de lancer tout ça comme un pavé dans la marre, d'autant qui je n'ai peut-être pas encore assez fouiné sur le site ni étudié les docs existantes.
Quoi qu'il en soit, bravo pour la simplicité et les performance!
Mmmm .... le choix de l'xml est justement pour ne pas utiliser Mysql. Il existe des tas de scripts qui utilisent Mysql
Je n'ai pas encore installé la version blog, j'attends (patiemment) que notre cher créateur nous fabrique une table des matières pour retrouver facilement des articles même anciens ;-)
Je passe régulièrement voir les nouvelles :-)
Merci encore pour ce cms qui est vraiment ce que j'attendais.
( Ce qui de plus... Est légèrement moin beau :P )
Secondo, tout ce que j'attend d'un CMS je le retrouve dans pluxml :
Simplicité, Confort, Rapidité...
Quoi demander de mieux !?
En tant que président dune association et gérant dune petite PME, je me retrouve souvent à utiliser des CMS. Jai donc eu pour test du Dotclear, Mambo, Joomla, Xoops, PunBB et enfin PluXML.
Aucune de ces CMS ne ma plut sauf PluXML, vous verrez pourquoi plus tard.
Un point noir des CMS est la difficulté dêtre skinnable, donc une société sans budget internet ce retrouve vite à contracter les services dun designer. Avec PluXML je peux skinner moi même mon site web, ce qui est très enrichissant pour le développement de ses connaissances.
Un autre point important est la taille du CMS, quand certain CMS utilise plus de 59mo de mon serveur je trouve ca énorme. Avec PluXML plus de problème.
Mon serveur de 90mo ne sera pas surchargé :-) !
Donc en résumé ce que jattends dun CMS :
Facilité de skinner, légèreté.
PluXML à tous ces avantages. Bravo à lui.
Je remercie Skyline pour son chef-duvre,
Thomas
Et je n'ai jamais trouver se que je souhaitais réelement, bon pluxml n'est pas parfait, mais il s'en raproche, il manque (a mon gout) que quelque fonctionnalité "gadjet"
et se que j'attend d'un cms ?
La S.I.M.P.L.I.C.I.T.E. !
Ciao
Pour moi un bon CMS est donc facilement et le plus possible configurable : je dois pouvoir faire ce que je veux de la mise en page, l'apparence, la langue (et l'encodage) du contenu. En ce sens le fait que Pluxml soit seulement en iso-8859-1 est un handicap, adieu chinois, phonétique ou typographie...
Pour être facilement "adaptable", un bon CMS doit être simple : là Pluxml est parfait
Être simple et configurable, ça sous-entend de ne pas faire les choix pour l'utilisateur, de laisser l'utilisateur faire ce qu'il veut (pas de syntaxe wiki intégrée, de lecteur MP3/OGG en Flash qui fait sondage en même temps...), et ça j'adore
Et tout le monde aime un peu de confort. Si on doit tous apprendre le PHP pour coder soi-même ce qu'on veut dans Pluxml, c'est comme un canapé sans coussins : ça fait vite mal au c**
J'ajouterai qu'un CMS léger qui ne s'accapare qu'un minimum de ressources matérielles et logicielles est un gros avantage. Ne pas vouloir trop en faire, ne pas essayer de convenir à tous les utilisateurs car ça donne des gros pavés indigestes issus de trop de compromis et de hacks pas très propres. C'est aussi parce que Pluxml ne convient pas à tous les cas de figures que ce qu'il fait, il le fait bien
Au final, c'est bien Skyline qui modulera son script selon sa propre vision mais s'il tiens compte de ton intervention alors il aura comblé une niche sur la toile...
un CMS blog comme est partie pluxml et je trouve que c'est une bonne voie vue l'étantdue des autres CMS webblog qui existe. Le soucis c'est que la plupart sont en anglais et peu traduit en francais. Dotclear qui est une license francais et maintenant pluxml ? alors je dis foncons
La ou se demarque pluxml c'est qui doit rester leger donc rapide d'installation et dépourvu de fioriture.
les CSS sont plus simple et c'est bien.
Voici ce que j'attends d'un cms comme celui ci :
- CSS aussi simple faut rester la dessus
- legerté et facilité d'installation
- facilité de modification
- Mods directement implanté dedans comme un toolbar bbcode équivalente à celle que l'on peut utiliser dans les forums
- des mods simple à ajoutter
- un cms sans fioriture
- un mod de sondage directement placé à l'interieur du pack car c'est très souvant utilisé, et que l'on pourrait désactiver simplement
- un mod de formulaire automatique pour joindre l'admin
- un bbCode avec éditeur pour tous les textarea
- gestion des nl2br (parce que la j'ai du le rajouter
- gestion de pages auxiliaires a volonté avec éditeur WYSIWIG/bbCode (au choix)
- une bien meilleur convivialité, exemple on arrive sur l'index au premier lancement "lancez install.php" le néophyte il lit deux fois, il cherche pas a comprendre, il remballe. Je sais que plus c'est simple pour l'utilisateur, plus c'est chiant pour le codeur, mais c'est le prix du succès.
- une personnalisation plus avancée du menu, par la création de modules, de liens, d'images, de tout ce qu'on veut (donc la ca implique plugins...)
Mais sinon c'est une très bonne base, pour ma part j'ai juste bidouillé les templates, quelques classes pour avoir par exemple le saut de ligne dans les articles, mais pas dans l'édition en administration, et d'autres détails. Pourtant je suis une bille en POO xD
Mais si tout ca pouvait etre des la base ce serait super
Super boulot ce script.
Si code il y a, oui, si on reste à l'XHTML (ou alors qu'il y a un mode XHTML) alors non : les <p> sont là pour ça
WYSIWYG, non, à mon avis ce sera bein trop lourd et ça ne colle pas à la philoophie de PluXML. Pour le BBCode voir ci-dessus.
PluXML est pour l'instant reservé aux webmasters avertis donc ça pose pas de réel problème. Cependant dans le cas dont tu parles, il suffit de remplacer l'echo par un header('Location: install.php') à priori (faut tester si ca marche, surtout niveau de l'URL relative je sais aps ce que ça donnera)
C'est prévu, mais faut faire ça sans surcharger PluXML
Avez-vous, pour ceux qui sont sur Linux, déjà essayé l'éditeur Vim ? C'est un des deux plus puissants logiciel de codage au monde, l'inconvénient est qu'il a une syntaxe propre. Si on remplaçait Vim par un éditeur simple avec menu, toute sa puissance en serait anéantie.
BBCode : non.
Nl2br : non, j'en ai jamais eu besoin.
Page auxiliaires : oui, avec WYSIWYG : non.
Convivialité : non. le visiteur ne va rien comprendre s'il arrive sur une page d'installation, au pire il va contrôler tout le blog.
Personnalisation menu : on ne ferait que se restreindre à une interface d'administration, alors qu'il est tellement plus puissant d'éditer template.php...
@shadow :
Sondage : non, inutile.
Formulaire automatique : non, personne n'en a l'utilité (ceux qui en voieraient une auraient déjà installé la modification « formulaire de contact » présent sur ce forum, et y'en a pas des masses.
Si oui alors il faudrait évidemment mettre les nl2br. Si on garde l'XHTML évidemment que non (faut rester logique 5 secondes).
Concernant l'installation je vois aps pourquoi il comprendrai rien oO
Ya marqué "Installation de PluXML" en gros (ou un truc du style) et ça me parait assez logique qu'il fasse l'installer pour le faire marcher
Donc AMHA l'utilisateur ne sera pas déboussolé. Donc bonne idée potentielle.
Concernant l'administration je pense qu'ajouter des fonctions basiques peut être bien : ou alors on se dirige vers presque pas d'administration et totu via des fichiers. Je suis aps contre, les Linuxiens font bien ça presque tout le temps. Ou alors on se dirige vers une interface user-friendly et dans ce cas là on n'exige pas de l'utilisateur de connaître le PHP/HTML...
Bref également une idée à méditer sachant que beaucoup la reclament.
Je viens de répondre, sur le MP dédié au bêta-test, qu'il serait bien pour Pluxml que le XHTML soit supporté.
Non. Je n'aime pas ce dénigrement des néophytes. On est tous passés par là. Un néophyte n'est pas bête : soit il/elle ne veut pas apprendre et prend un blog hébergé (Blogger, Gandiblog...), soit il/elle veut apprendre et se débrouille pour installer son blog, et tous les Dotclear, Wordpress et autres sont bien plus difficiles de ce point de vue que Pluxml. Ne me dis pas que taper install.php dans la barre d'adresse (surtout que c'est indiqué !) est difficile. D'autres systèmes "conviviaux" demandent les accès MySQL, la racine exacte du site sur le serveur, et n'indiquent que dans la doc officielle sur quelle page pointer pour installer.
Pour illustrer le "piège" de trop vouloir simplifier il y a cet article, en anglais mais pas mal, de Kristian Van Der Vliet, LE dev de Syllable : http://www.liqwyd.com/soapbox4.shtml
Au lieu de demander de taper install.php dans la barre d'adresse, pourquoi on ne met pas un lien ou une redirection vers install.php ?
Peut etre que c'est un test de QI. Si tu ne sais pas ce que c'est une barre d'adresse, tu ne peux pas lancer l'installation.
L'idée est plus une idée de confort que d'un paliatif a un QI deficient
GC
C'est quand la fête à Blogmouassa parce que pour lui ! sa chauffe ...
Et comme je dis toujours:
[blocokotte] Au final c'est Skyline qui fera son choix mais vue qu'il a dans le colimateur de proposer un script "léger", il n'y a pas beaucoup de chance pour que les souhaits de notre ami soient exaucés[/blocokotte]
Le zCode a l'avantage :
- d'être un langage XML
- d'être compréhensible par n'importe qui
(Le nCode c'est juste du zCode en anglais, ça nous intéresse pas pour la version française).
Donc à mon avis c'est le Code à privilegier, si on en privilégie un. L'XHTML c'est de l'anglais, avec des nom de tag bizarres, incompréhensibles pour un newb. Si l'XHTML avait "suffit" alors tous les langages dont tu parles n'aurai jamais existé ^^
Au besoin peut-etre prevoir dans le css quelques classes specifiques pour y ajouté un peu de mise en forme. (flottant , alignement du texte , gras , quelques couleurs ) En proposant encore une fois un minimum .
Le preview "selon" skyline peut deja donne un aperçu du rendu ,
Je garde pour cela mon option de preview, popup, theme en cours et sans publication ou enregistrement de l'article ... assit sur du js de base .
Je prefere personellement le preview en popup pour les raisons suivantes :il me permet de visualiser mon article dans mon theme , et si mon theme est codées en transitionnal ou html 4.01 , l'aperçu reste fidele sans devoir se cantonner à l'aspect "eclaircie/naturel" de la page edition en xhtml 1.0 strict.Je n'ai pas besoin de sauvegardé l'article , ni de le publié , les script js (comme lightbox par exemple , tailles des polices ) ajouté au theme sont aussi pris en compte , etc ....
J'ai essayer sans editeur (comme tout le monde) , avec les propositions d'integration d'editeur que l'on retrouve sur d'autres cms et avec mon insertion au click de la balise voulu ... mes choix :
le preview me semble indispensable (et sans sauvegarde prealable)
l'editeur genre Tinymce ou autre sont un peu lourd et je n'ai pas l'habitude d'en faire usages , je n'ai pas conservé.
Mon mini-editeur qui s'etale sur 2 lignes (avec le bouton "preview" ),au dessus du textarea d'edition de l'article me suffit , même si j'ai tendance a taper au clavier mes balises par habitude du bloc-notes.
A part le preview (quelque soit la forme) , je crois que le reste doit etre du "plugin" au choix de l'utilisateur.
GC