Jeffrey Veen a fait le tour des CMS open-source, il en tire une liste de points sur lesquels ces solutions posent le plus de problème et sur lesquels les développeurs devraient travailler un peu… mes commentaires suivent chaque citation.

Une installation simple permet une meilleure adoption de ces outils.

Cet argument est interessant mais souvent une installation même simplifiée implique de connaître quelques paramètres barbares notamment tout ce qui concerne la gestion de la base de données.

Une prise en main facile en mettant l’utilisateur en situation rapide de réalisation et en augmenter la difficulté petit à petit

Cette idée est extrèmement intéressante mais requiert des scénaris adaptés aux différent profils d’utilisateurs amenés à utiliser un CMS. Un utilisateur peut être amené à faire de la configuration système, un autre à rédiger des contenus, à valider ces contenus, à s’assurer de la cohérence éditoriale ou encore à réaliser des modèles graphiques. Ce sont des profils utilisateurs totalement différents et donc des manières d’apprendre complètement différentes qui en plus ne prend pas en compte le niveau propre de l’utilisateur, son niveau d’expérience face à l’outil informatique par exemple. Beaucoup ne savent pas encore utiliser leur navigateur, alors une application de publication en ligne dans ce même navigateur… Le CMS pose essentiellement problème à ce niveau d’ailleurs, que fait-on des utilisateurs qui ont peur à l’idée d’approcher une souris et un clavier ?

Une documentation basée sur l’utilisation et non sur les fonctionnalités, la plupart des systèmes ont une documentation basée sur les capacités de leur produits et non sur la manière d’utiliser les outils mis à disposition

On pourrait penser que le problème vient surtout des solutions payantes qui pourraient répéter leur litanie marketing dans leur documentation, mais non… Ces produits sont par des « geeks » pour des « geeks », ce n’est pas complètement faux. Mais je pense que la documentation d’un projet devrait être séparée en plusieurs partie, un patie dédiée à l’utilisation quotidienne, pragmatique du produit et une autre à la documentation des diverses fonctionnalités, objets, fonctions que le CMS propose, plus destinée à des utilisateurs (très) avancés. L’aide contextuelle peut être aussi un moyen de bien séparer ces informations et pourrait même faire partie du scénario de formation.

Séparer la partie administration de la partie édition et gestion de contenu, la plupart des utilisateurs ne faisant pas de la configuration système mais de la gestion de contenu

Cette manière de séparer les modes de gestions permet en plus de simplifier l’utilisation et la compréhension de chaque intervenant de ce CMS.

La partie publique du site ne devrait permettre à un utilisateur de s’identifier, presque tous les CMS mèlent l’interface publique à l’interface d’administration

Évidemment… pas de discussion sauf pour des CMS destinés à des extra, intra-net.

Arrêtez avec le jargon, je ne sais pas ce qu’est une « portlet », une « snippet »…, ces mots existent-ils afin de s’identifier sur le marché ?

Je dirais plutôt un certain jargon, effectivement les termes comme portlet ne sont pas évident à comprendre. Mais certains concepts du CMS ne peuvent parfois se résumer autrement, il faut cependant trouver des termes moins « sauvages ». Si une telle terminologie technique doit être utilisée elle est obligatoirement explicitée à chacune de ses utilisations (avec des bulles d’aide, des sous-titres explicatifs…).

Pourquoi les sites webs devraient-ils être tous basés sur une mise en page en colonne ? Je voudrais pouvoir dire je veux mettre le contenu dans cet ordre et en faire la mise en forme avec des CSS

Les CMS ont commencé à voir le jour bien avant l’engouement actuel pour les standards et sans même l’idée que des designers voudrait y mettre le nez. Beaucoup ne comprennent pas encore ce que l’utilisation des ces mêmes standards peut bien leur apporter. Enfin la plupart des entreprises amenés à intégrer ce genre de produit ne se soucient que très peu de l’aspect visuel ou qualitatif du code rendu (SSII ou autre…).

Souvent dans les commentaires dit qu’une solution permet de résoudre tout ces points, j’en ajouterais une… Dotclear (qui se veut un blogware, mais permet tout de même d’aller au-delà).