Je ne me suis attaché ici à comparer que les fonctionnalités natives de SPIP et DotClear, n’ayant plus trop le temps de chercher [2] pour chacun des plugins ou contributions pouvant apporter les fonctionnalités qui me manquent. Je me suis aussi surtout limité aux fonctionnalités de SPIP que j’utilise [3], et à celles de DotClear qui viennent en plus et m’apporteraient réellement un confort ou des fonctionnalités supplémentaires.

Installation

Même si c’est une opération qui ne fait pas partie du travail quotidien, l’installation est un bon moyen de voir si les développeurs pensent au confort de leurs utilisateurs.

Avec DotClear, cette installation est aussi simple qu’avec SPIP, c’est un pur bonheur, les néophites sont guidés pas à pas de manière très explicite.

De même, une interface publique par défaut est fournie en standard. Elle n’est malheureusement pas plus belle que celle de SPIP [4], mais à l’intérêt de montrer tout de suite que le produit ne pourra que difficilement servir à faire autre chose qu’un blog, là où SPIP montre par contre une plus grande richesse fonctionnelle.

Je n’ai pas regardé comment sont développés les templates [5], ce n’est pas un critère décisif pour moi, je suis prêt à m’investir si les fonctionnalités répondent à mes attentes.

Il faudrait aussi voir si les mises à jour sont aussi simples, mais je n’ai pas le temps pour l’instant...

Catégorisation des contenus

La possibilité dans SPIP d’affecter un article à une rubrique et à de multiples mots clefs ne trouve pas d’équivalent dans DotClear, ou un article ne peut malheureusement être rattaché qu’à une unique catégorie. C’est bien dommage, je ne vais pas pouvoir faire de tag cloud...

Rédaction d’articles

Côté syntaxe de rédaction, DotClear propose soit une syntaxe HTML libre, soit une syntaxe de type Wiki [6].

SPIP garde un sérieux avantage à ce niveau, intégrant notamment grâce à sa syntaxe spécifique la gestion des liens internes [7]. DotClear se rattrape avec la gestion des langues des ressources pointées, qui permet de générer l’attribut hreflang des liens hypertextes [8], ce que SPIP ne fait pas encore nativement [9].

Par contre, DotClear pêche côté notes de bas de page, qu’il a le mauvais goût de placer avant le contenu si elles sont dans le chapô, étrange comportement. Du coup, s’il y a des notes de bas de page tant dans le chapô que dans le contenu, les ancres ne sont pas bonnes !

DotClear a la bonne idée de gérer une galerie d’images partagée entre tous les contenus, mais ne permet pas de gérer des images spécifiques à un article donné, donc la galerie doit vite devenir difficile à gérer. Cette galerie ne permet en plus pas de gérer tous types de documents, ce qui est bien trop limitatif. Finalement, ma galerie de documents pour SPIP est beaucoup mieux, il faudrait que je la finalise...

DotClear n’intègre pas de correction orthographique, alors que celle de SPIP m’a permi déjà plusieurs fois d’éviter des petites horreurs. Le serveur d’orthographe de SPIP est générique, il faudrait voir comment le rendre exploitable par DotClear...

Interactivité

Du côté des commentaires, DotClear n’intègre malheureusement pas la possibilité de gérer des threads de discussion [10], tout restant désespérément à plat et sans possibilité simple de répondre de manière pertinente à un commentaire en particulier. Je n’ai pas vu beaucoup de blog utilisant — comme je le fais ici — cette notion de thread, alors que je la trouve plus intuitive et pratique dans les discussions puisque chaque message est bien dans son contexte [11].

Là où DotClear apporte un énorme plus à SPIP, et c’est LA raison qui m’a fait débuter cette étude, c’est dans la gestion des trackbacks et pingbacks. Ils sont le meilleurs moyen de relier les blogs entre eux, c’est à dire d’une part de savoir quand un autre blog parle de Gastero Prod, et d’autre part de signaler à d’autres blogs que je les site.

Bilan temporaire

Je laisse là cette étude commencée il y a plus d’un mois, faute de temps pour la boucler, et surtout parce que j’apprend que la première beta de DotClear 2.0 va enfin être mise à disposition demain !

Quoi qu’il en soit, je n’aurais pas jeté SPIP pour DotClear 1.

L’avenir dira si DotClear 2 me séduit plus...

Si ce n’est pas le cas, voici un exemple de tag cloud sur Flickr, qui représente les tags les plus utilisés depuis le lancement du service :

Sur Gastero Prod, j’ai mis en place ce mécanisme assez astucieux de listage des thèmes abordés, à la fois dans la colonne de navigation, et sur une page dédiée aux tags :

Sur cette page, je peux lister les tags par ordre alphabétique, ce qui est l’usage classique, mais aussi par ordre d’importance, c’est à dire selon le nombre d’articles auxquels ils sont associés, ce qui est plus pratique sans doute pour les utilisateurs de synthèses vocales ou autres outils non graphiques de navigation.

C’est que je m’interroge justement sur la façon optimale de rendre accessible ces fameux tag clouds.

La plupart des solutions implémentées ne sont à mon avis pas satisfaisantes de ce point de vue, pour différentes raisons :

Une liste, déjà, ce serait pas mal...

Certains n’utilisent tout simplement pas des éléments de type listes — <ul> ou <ol> [1] — pour lister les tags, mais se contentent de mettre les tags les uns après les autres.

La taille, c’est une information purement visuelle

Certains utilisent bien des listes, mais jouent sur l’importance relative des éléments en affectant directement une taille à chacun, via un attribut style en ligne, ce qui n’apporte aucune information sémantique — et donc plus accessible — d’importance relative.

Près du but

Certains autres, enfin, apportent un début de sémantisation du contenu en montrant l’importance relative de chaque élément avec des balises <em> imbriqués, mais je ne pense pas qu’une imbrication de plusieurs balises identiques ait un réel intérêt pour l’accessibilité.

Est-ce qu’une synthèse vocale fera la différence entre les deux éléments suivants :

• <em><em>tag1</em></em>
• <em><em><em>tag2</em></em></em>

Je n’en suis pas sûr...

L’unique solution ?

La meilleure solution que j’ai trouvée à ce jour, c’est d’exploiter le fait que la balise <strong> permet comme son nom l’indique de marquer une strong emphasis [2], alors que la balise <em> a pour objectif de marquer une emphase simple.

Il m’est donc possible de différencier trois niveaux d’importance relative des éléments de ma liste :

• Minimum : <li>tag</li>
• Moyen : <li><em>tag</em></li>
• Maximum : <li><strong>tag</strong></li>

C’est sûr, c’est moins joli que les solutions qui utilisent beaucoup plus de variantes de tailles, mais au moins c’est censé être plus accessible.

Une petite amélioration reste possible

Maintenant que le contenu est relativement accessible, rien n’empêche de rajouter de l’information en plus pour les heureux utilisateurs de navigateurs graphiques, en ajoutant par exemple des informations de taille aux éléments.

Cette information a bien un sens pour ceux qui peuvent l’exploiter, donc je ne pense pas que l’on puisse m’accuser de poluer le contenu avec de la présentation. Parfois, la présentation donne un sens.

Restent tout de même quelques questions

• Est-ce que tout ça est vraiment accessible, ou est-ce que je me prends la tête pour rien ?
• Est-ce que, si la solution est bonne, elle peut être améliorée en ajoutant un niveau utilisant l’imbrication <strong><em>tag</em></strong> [3] ?

Quoi qu’il en soit, voici une nouvelle preuve que la quête de l’accessibilité est loin d’être simple, et c’est toujours en tatonnant qu’on arrive à déterminer pragmatiquement les solutions les plus pertinentes.

Il m’a reconnu après avoir vu mon gravatar en divers endroits sur les forums ou commentaires de billets de blogs qui supportent ce système [2].

Sauf que manque de bol, ce n’était pas moi ! Je ne prends que très rarement le métro, et encore moins la ligne 13. En tout cas, je ne l’ai pas prise la semaine dernière, donc aucun doute n’est possible.

Stéphane a donc bien fait — dans l’absolu — de ne pas aborder cet autre que moi, même si bien sûr la discussion aurait pu être cocasse.

Sauf que cela montre bien l’énorme différence qu’il y a entre la facilité du dialogue online [3] — où notamment le tutoiement est naturel — et la difficulté de prise de contact dans le monde réel — où même un regard peu être mal interprété.

J’ai eu à peu près la même expérience lors du dernier forum Intégration, où j’étais pour animer une conférence sur les « critères de choix et positionnement des principaux outils d’EAI, ESB, ETL, EIP et autres solutions d’intégration ». En attendant le début de la conférence, j’ai passé un peu de temps dans le couloir en compagnie de quelques connaissances, et Laurent Jouanneau est arrivé, il devait participer à une table ronde sur l’avenir des clients riches.

Il n’y avait là aucun doute sur son identité, les forums ont l’avantage sur le métro d’étiqueter les personnes. Et bien je n’ai pas non plus eu le courage (l’audace ?) de l’interpeller sur un sujet dont nous aurions déjà discuté auparavant, dans les commentaires de son blog ou sur la liste des pompeurs [4].

Ai-je eu raison, l’aurais-je importuné en étalant ainsi dans la vraie vie une partie de sa vie virtuelle ?

Personnellement, j’avoue que je n’ai aucun besoin de cette page, qui présente uniquement des dates et un nombre de publications par mois, sans indication des contenus effectivement publiés.

Les pages affichant la liste des publications d’un mois particulier — septembre 2005 par exemple — n’a pas beaucoup plus d’utilité.

Si je veux rechercher sur un site un contenu que j’avais repéré précédemment, j’ai plutôt tendance à chercher sur des termes utilisés dans ce contenu plutôt que sur sa date de publication, qui m’a dans la plupart des cas de toute façon échappé.

Et vous ? Dois-je garder cette notion d’archives, ou — après la suppression de l’agenda — puis-je faire encore du ménage ?

Heureusement, ZeWoc va justement lancer son blog le 1er janvier 2006, de quoi repartir sur de bonnes bases ...

On vera si Gastero Prod est toujours là.