A l’occasion du BarCamp Alsace, je lancerai une session d’échange sur le thème : « Développeur, intégrateur, webmaster : qu’attendez-vous d’un bon CMS ? ». C’est la première fois que je me lance dans une session Barcamp comme cela, un peu en « freestyle » donc je ne sais pas trop ce que ça va donner (je n’ai absolument rien préparé).
En fonction du succès de cette « non-conférence », je publierai sur ce blog un petit résumé des échanges et des idées qui en sont ressorties. En tout cas, j’espère vous y voir nombreux ;-) A demain ?
Abonnez-vous au flux RSS
Suivez-moi sur Twitter !
Contactez-moi !
10 commentaires pour ce billet
Hello Yoann,
Comme d’habitude, je pense que cela était réussi. Je regrette de n’avoir pu me joindre à vous, j’aurais fortement bien aimé venir ! Ce n’est que partie remise :)
C’est demain la session Lilian ;-) A Mulhouse au technopole !
Très déçu par l’éditeur de texte de WordPress, je souhaite surtout que le SGC ne formatte pas les contenus (et ses mises en forme) qu’on lui demande de gérer !
Au delà, un système de validation structurelle (comme avec DotClear) ou orthographique est appréciable.
Mathias, qu’est-ce qui t’as déçu exactement dans l’éditeur de texte de WordPress ? Il est assez simple et plutôt bien fait je trouve … non ?
Pour ce qui est de la validation orthographique, c’est clair que c’est une fonctionnalité qui a vraiment du sens dans un outil de gestion de contenu. Je n’ai pas encore fait de réelle recherche sur ce point, mais ce qui serait génial ce serait de pouvoir interroger une API type celle de Google pour faire cela. A creuser !
Ce que j’attends d’un bon CMS ?
Je sépare déjà dans ma réflexion en deux gros axes distincts les modules qui composent tout CMS qui se respecte, à savoir les modules, de l’éditeur plus ou moins wysiwyg pour les pages de contenu libre.
A| LES MODULES :
Il faut impérativement travailler chaque module comme de la dentelle ; le contexte d’utilisation de chaque module est différent. Et il faut en tenir compté ! Lister les entrées de tous les modules de la même manière est peut-être très facile à coder, mais aberrant pour un ergonome. Par exemple, sur le problématique de lister au mieux les entrées d’un module, choisir la meilleure selon l’utilisation finale : par 12 pour un listing d’entrées mensuelles pour avoir une année sous les yeux à chaque page, dans un ordre alphabétique pour un listing de noms, chronologique inversé pour des news, etc… Ca peut êtr con à dire, mais je l’ai très rarement vu dans les CMS que j’ai utilisé.
Il faut proposer les actions souris/clavier les plus simples et les plus intuitives (cliquer-glisser, cliquer-déposer, flèches du clavier, cochage/décochage à la volée), tout en conservant les bons vieux boutons classiques (faire remonter ou descendre une entrée, d’un cran, de tous, par 10…)
B| L’ÉDITEUR DE TEXTE
Là aussi, ceux qui marchent le mieux sont ceux qui basent toute leur conception sur l’expérience utilisateur et on reprendre basiquement le dernier wysiwyg open source super-complet-qui-fait-du-css-donc-je-suis-tranquille.
Proposer des gabarits statiques ou des modèles de mise en page avancés (photo gauche + commentaire + colonne texte à droite par ex., trombinoscope, listings statiques, etc…) et avoir au moins la largeur utile de la zone en fonction de celle du front.
Effectivement y proposer un maximum d’outils à la google : versionning (j’en entends déjà qui grincent des dents) ortho, grammaire, nettoyage ou remise à zéro des styles de texte etc…
Après tout dépend aussi de la philosophie de départ, en tenant compte des utilisateurs avancés (webmestres, intégrateurs) comme des néophytes (client-lambda-qui-connaît-word-et-outlook-express).
Le CMS-roi serait celui qui saurait s’adapter à toutes les situations, un genre de super tout-terrains, ou il ne montrerait sa puissance qu’en cas de besoin, tout en sachant supporter des demandes les plus complexes.
Merci pour ta contribution, je te rejoins sur pas mal de points, et notamment :
- actions clavier / souris intuitives
- affichage « intelligent » des listes
- l’éditeur de texte, qui doit servir uniquement pour la rédaction de texte, et pas pour la mise en page …
- … mise en page gérée par un système de blocs, dont on peut imaginer une bibliothèque de modèles
Un point qui me semble crucial, et qui est très peu souvent géré, c’est les préférences utilisateurs pour paramétrer des petits détails ergonomique de l’interface. Par exemple, quand on modifie un objet, certains préfèrent retourner à la liste après avoir validé, alors que d’autres préfèrent rester sur l’élément en question.
Enfin, par rapport au côté « super-tout-terrain », ça passe indéniablement par une modularité poussée à l’extreme, mais aussi par des performances un peu moindres. Il faut trouver le bon compromis.
Je suis irrité par la mise en forme de mon code par l’éditeur. (Je suis sous WP 2.2.2.)
Certaines balises ou attributs se retrouvent en majuscule, les paragraphes n’apparaissent pas clairement (les balises ne sont pas affichées même en mode code), ça me gonfle.
Plus de liberté, comme avec DotClear, serait appréciable. On verra comment sera la version 2.5.
Effectivement, à priori ils ont pas mal travaillé sur l’éditeur de texte, on verra ce que ça donne. Je suis aussi assez curieux de voir le résultat.
@matthias : « Certaines balises ou attributs se retrouvent en majuscule,[...] »
Euh d’accord pour le reste mais cela ne m’est jamais arrivé ?!? Parc ontre effectivement si wordpress est génial pour le reste par rapport à dotclear, son éditeur pèche un peu… Mais apparemment cela semble corrigé sur la 2.5 …. à voir.
Wordpress 2.5 viendrait de sortir en version finale, et c’est pas réglé pour le problème de l’éditeur : http://www.thierrypoinot.com/blog/2008/03/29/wordpress-25-a-toujours-du-mal-avec-les-balises-p/
http://wordpress.org/development/2008/03/wordpress-25-brecker/