http://wordpress.org/development/2008/03/wordpress-25-brecker/

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.

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.

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 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.

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 !

Au delà, un système de validation structurelle (comme avec DotClear) ou orthographique est appréciable.

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 :)