Ergonomie, Rails et Architecture de l'information web (2.0)

Je suis tombé récemment sur deux chiffres extrêmement intéressants concernant l’utilisation des tags dans les outils de publication sur le web, et sur les pratiques afférentes.

Le premier a été publié par Yahoo lors du WWW2008 de Pékin et concerne son service de bookmarking social Delicious, où 90% des utilisateurs et 95% des bookmarks sont rassemblés sous moins de 2000 tags, ce qui fait à la fois beaucoup et très peu.

Le second vient d’une présentation faite par Garrick Schmitt à l’IA Summit 2008 et concerne l’utilisation de la navigation par tags par les visiteurs de sites web : 87,8% d’entre eux n’ont jamais navigué à l’aide d’un nuage de tags ou ne le font jamais, et seuls 12.2% d’entre eux les utilisent régulièrement.

Offrir une recherche sélective à vos utilisateurs de manière simple et utilisables relève bien souvent de la gageure. Quand on ne tombe pas sur des horreurs peu intuitives, voire inutilisables, c’est pour se retrouver face à des formulaires de recherche avancée incompréhensibles dont la seule évocation parvient à faire fuir 95% des utilisateurs. Des solutions élégantes existe pourtant. Bien qu’elles ne s’adaptent pas à tous les cas de figure, elles ont pourtant l’avantage d’être efficaces, simples d’emploi et souvent peu coûteuses à mettre en place.

Après avoir fait le tour des avantages et inconvénients posés par le très populaire et web 2.0 ”live search”, nous passerons cette fois au crible ce système puissant à bien des égards qu’est la recherche prédictive.

Pour la majorité d’entre-nous, un formulaire de recherche se résume d’un coté à une simple zone de saisie texte associée à un bouton de validation, et de l’autre à usine à gaz permettant de trouver la perle rare à partir d’un très grand nombre de critères le plus souvent obscures. Évidemment, les choses ne sont pas aussi tranchées, et il existe un grand nombre de formulaires de recherche, aussi bien par leur présentation que par leur comportement.

Dans ce premier volet d’une série de 5 billets consacrés à l’anatomie des formulaires de recherche, je vous propose de nous intéresser au live search, un mode de recherche directement hérité de l’émergence d’AJAX et symptomatique du web 2.0 aussi bien dans ses avantages que ses inconvénients.

C’est du moins ce que dit Jeremy Schoemaker quand il explique pourquoi il n’aime pas 95% des spécialistes en SEO, avant d’expliquer pourquoi.

Je viens de tomber sur Users Behavior, un intéressant article de Ian Holsman (qui en plus a le bon goût de tourner sous Typo) sur la difficulté de faire changer des habitudes bien établies, même pour une démarche qui devrait sembler normale, ou tout au moins pleine de bon sens.

À cause de gros problèmes de stabilité, je viens de repasser des nightly builds de Flock, version 0.7.99 vers la dernière version stable 0.7.10. Le moteur par défaut de Flock est Yahoo, contre lequel je n’ai rien, mais auquel je préfère largement Google.

Pour une raison que j’ignore, l’onglet de choix de la recherche est absent du panneau de configuration de la version stable, alors qu’il est présent dans la version de développement, et, de mémoire, qu’il l’était dans la précédente stable, du moins la dernière fois que je l’ai testée.

Si vous souhaitez modifier le moteur de recherche par défaut, il va vous falloir choisir les options de configuration à la main. Dans la barre d’URL, saisissez about:config, puis remplacez les champs browser.search.defaultenginename et browser.search.selectedEngine par Google. Puis, remplacez la valeur de browser.search.defaulturl par http://google.fr/.

Voilà, c’est fait, vous pouvez chercher en paix.

Il se passe de drôles de choses depuis quelques jours : certes, j’ai regagné un Page Rank décent, mais en contrepartie, j’ai totalement disparu de Google.

Prenons mon nom de famille, par exemple : Villamil. Je suis passé de la première à la huitième page. Et c’est comme ça sur tous les mots clés sur lesquels j’avais un positionnement correct, voire plus que correct. Une idée quelqu’un ?

Après la dernière refonte de ce site, j’ai reçu un mail passablement remonté d’une personne m’annonçant que, puisque je l’avais rayée de ma blogoliste, elle allait faire de même avec moi. Cette personne s’imaginait probablement que la réciprocité du lien entrant était un principe sacro-saint du web, ou tout au moins de la blogosphère. Sa missive a au moins eu le mérite de m’offrir une cure de jouvence à peu de frais en me ramenant une dizaine d’années en arrière.

Il ne s’agissait pas de sanctionner cette personne , que ce soit à titre personnel ou pour la baisse de qualité de son contenu. Le fait est que j’avais tout simplement supprimé ma blogoliste.

Pourquoi ?

Il y a 4 ans, lorsque les blogs étaient peu répandus, surtout en France, afficher sa blogoliste était un acte d’affirmation sociale : cela signifiait “je suis un blogueur, et voilà ceux que je reconnais comme mes pairs”. L’utilisation des agrégateurs RSS était loin d’être généralisée, et posséder une blogoliste était un moyen d’envoyer les visiteurs vers des blogs que l’on considérait de qualité.

Sauf qu’aujourd’hui, les choses ont changé.

“Socialement”, les blogs sont devenus une denrée courante sur le web, et on ne peut plus vraiment parler de niche. S’afficher blogueur ne représente plus un acte d’affirmation de soi.

Mais c’est surtout techniquement que les choses ont changé.

L’utilisation du flux RSS comme principale manière de consulter ses sites favoris a rendu relativement caduque l’envoi sur les sites “amis”, puisque la page d’index n’est plus la page d’accès privilégiée à un blog. Le temps de navigation gagné permet de lire beaucoup plus de sites, beaucoup plus simplement, en filtrant les billets à partir de leur titre. La généralisation des liens permanents de type /articles/titre-de-l-article en lieu et place de /index.php?id=4242 assure une véritable identité aux contenus publiés.

Mais surtout, avec la croissance exponentielle du nombre de blogs, le ratio contenu intéressant / contenu à faible intérêt pour un site donné est devenu très faible, bien que certaines personnes soient plus régulières que d’autres, dans la médiocrité aussi d’ailleurs. Ceci ajouté à la généralisation croissante des gestionnaires de favoris en ligne fait qu’il vaut mieux aujourd’hui lier des billets ou des contenus précis que des sites.

Pourquoi cela ?

• Vous envoyez directement le lecteur vers des contenus pertinents, et réduisez ainsi le rapport signal / bruit.
• Vous aidez les personnes que vous liez à équilibrer la cible de leurs liens entrants. En termes de référencement, cela permet à leurs billets pertinents d’être mieux placés (merci Sébastien Billard).
• Vous sortez de cette habitude idiote héritée des pages perso des années 90 “tu me link, je te link”.
• Vous réduisez la taille de votre sidebar, donc la pollution visuelle qui pourrait détourner le lecteur de votre contenu.

Oui mais si je veux partager ma liste de lectures à mes lecteurs ? Eh bien pourquoi ne pas être 2.0 jusqu’au bout et ne pas leur mettre à disposition tout ou partie de votre fichier OPML ?

Question : comment fait Google pour tester ses nouveaux algorithmes d’indexation et ses fonctionnalités à venir en grandeur réelle sans pour autant rendre son service inutilisable à deux ou trois milliards d’utilisateurs ?

Réponse : en lançant un moteur de recherche alternatif : SearchMash.

Searchmash reprend la simplicité et l’austérité de l’interface de son grand frêre en y ajoutant des fonctionnalités intéressantes. Outre la recherche sur les blogs et les images déjà existantes, il y ajoute une recherche sur les vidéos et l’encyclopédie libre Wikipédia, ce qui accroît encore un peu la légitimité du site collaboratif. Les recherches “alternatives” sont disponibles sur la page principale et sont affichées à la demande avec un bout d’AJAX.

Un menu “hide details” permet de cacher les détails des résultats pour ne laisser que le titre de la page retournée. Pas très lisible pour l’instant, mais intéressant quand on choisit d’afficher plusieurs dizaines résultats sur une recherche.

Cependant, la principale nouveauté réside dans le retour utilisateur sur l’opportunité des résultats retournés dans chacune des catégories. Reste à savoir dans quelle mesure il est pris en compte par Searchmash.

Crowdsourcing, AJAX, média alternatifs – je me demande s’ils utilisent le microformat rel=”tag” pour les indexer – Wikipédia… ce Google en devenir répand en tout cas de belles effluves de web 2.0, il ne lui manque que le bêta ;-).

Les liens hypertextes sont au coeur du web. Sans eux, rien n’existerait, et nous avons pourtant tendance à les négliger. Bien employés, ils ajoutent de la valeur aux contenus publiés ; bâclés, ils peuvent aller jusqu’à leur retirer tout intérêt. Raison de plus pour s’y intéresser et en prendre grand soin.

Combien de fois êtes vous passés à côté de documents passionnants pour cause de liens invisibles, introuvables, incompréhensibles, illisibles ou inaccessibles par bête négligence ? Ce genre de choses ne doit plus arriver, et ce billet se propose justement de vous aider à les éviter en passant en revue les erreurs les plus fréquemment rencontrées et les optimisations trop souvent méconnues. Parce qu’il n’y a que sous UNIX que les liens sont symboliques.