Voyez par exemple celui produit par extraction automatique de mes tags del.icio.us :

Et cet autre produit avec les tags de Gastero Prod [2] :

Mais ce que je n’ai vu personne signaler, c’est qu’à part produire une image, permettant certes de réaliser de beaux t-shirts ou autres gadgets, ces nuages de tags ne peuvent malheureusement pas être utilisés sur un site pour la navigation, puisque le résultat n’est pas du tout cliquable.

Ce qui n’est bien entendu pas le cas du nuage de tags de Gastero Prod, qui n’est pourtant pas si moche non plus, par rapport à ce qu’on peut voir ailleurs :

Mise à jour du 1er juillet 2008 : Encore plus de nuages possibles :

• * Wordle permet maintenant d’indiquer une URL de blog ou de flux RSS, mais il semble qu’il utilise le contenu plutôt que les tags, que je mets pour ma part dans les balises <category>
• * Il est aussi possible d’obtenir le texte correspondant à ses tags Flickr pour le copier dans Wordle

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.

Après plus d’un an d’attente, FeedLounge est ouvert au public.

Le moins qu’on puisse dire, c’est que l’interface est de toute beauté !

FeedLounge

Et heureusement, ce n’est pas que de l’habillage graphique, les fonctionnalités sont vraiment intéressantes :

• * ajout de flux par souscription individuelle ou import de fichier OPML
• * trois façons différentes d’agencer les panneaux de consultation
• * navigation intégrallement au clavier, à un tel point que la barre d’espace peut suffire !
• * gestion de tags sur les flux et sur les items individuels, ce qui permet notamment de classer un même flux dans plusieurs tags là où Bloglines ne permet qu’une catégorie par flux
• * Etc.

Parmi les quelques points à améliorer, on peut néanmoins noter :

• * les panneaux ne sont pas redimensionnables, mais c’est dans la todo
• * les tags sont uniquement en minuscules et sans espaces
• * il n’est pas possible de masquer les flux déjà intégralement lus, mais on en discute
• * je n’ai pas trouvé de notifier à la manière de celui de Bloglines, qui permette d’alerter en cas de nouveauté sans avoir à se connecter

Mais la seule chose qui pourrait vraiment retenir quelqu’un de s’inscrire, c’est que FeedLounge n’est pas un service gratuit, contrairement à ses principaux concurrents. Il faut en effet s’acquitter d’un règlement mensuel de 5 dollars par mois ou 49,95 dollars par an. Afin d’éviter un écroulement de la plateforme dès le début avec trop d’utilisateurs, FeedLounge a choisi de ne pas proposer pour l’instant de comptes gratuits limités. Si la qualité de service est à ce prix, je suis près à le payer, tout comme je paie déjà un abonnement à Flickr.

Courrez vite vous inscrire !

Et si vous êtes l’heureux utilisateur d’un navigateur moderne, vous pouvez utiliser des scripts Greasemonkey, dont celui que j’ai créé spécialement pour poster directement dans Blogmarks depuis FeedLounge !

A chaque fois que je poste un bookmark sur Blogmarks concernant des logiciels libres, par exemple, j’avais pris l’habitude de mettre un tag « open source », mais je me demande s’il ne serait pas plus intéressant de mettre deux tags, « open » et « source », et profiter de la recherche libre qui semble s’accomoder de multiples tags.

J’avoue hésiter encore, et l’impossibilité pour l’instant dans Blogmarks de renommer un tag unique en deux autres tags me pousse à bien réfléchir avant d’agir.

Qu’en dites-vous ?