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

Après quelques années d’immobilisme quasi complet, Bloglines nous revient avec une toute nouvelle version bêta qui pourrait bien permettre à ce dinosaure des agrégateurs en ligne de sortir l’oubli dans lequel Google Reader et Netvibes l’ont fait plonger. Je passerai rapidement sur le design joli mais sans grande originalité, les abus d’AJAX et de Scriptaculous dès la page de login et le trop plein de web 2.0itude pour me concentrer sur l’ergonomie et l’utilisabilité de la chose. Et là, on va tout de suite faire tomber le suspens, cela fait quelques années que je n’avais pas fait de bonds partout dans mon salon en découvrant une application web.

Finis les onglets feed, blog, clipping, playlist, forum et search, ainsi que l’ennuyeuse et inutile landing page de la version actuelle, l’utilisateur arrive directement sur la page de ses flux. À la première visite, il se voit proposer de drag and dropper ses flux favoris au centre de la page afin de les visualiser par défaut à son arrivée sur le service à la façon des pages personnelles. Une manière plutôt sympa d’occuper l’espace inoccupé de la page.

Google Map ne cesse de me surprendre de jour en jours, aussi bien par sa richesse fonctionnelle que par la rapidité de ses algorithmes qu’une gigantesque ferme de calcul ne suffit pas à expliquer.

Dernière fonctionnalité de malade en date, le “click and drag” proposé sur leur outil de calcul des itinéraires.

Mettons que je veuille me rendre de Lisieux à Hermival les Vaux…

Mais que je m’aperçoive soudain que j’ai oublié d’acheter un pot de beurre au supermarché de Glatigny (et puis la route de Glatigny est bien meilleure pour remonter à Hermival). Il me suffit de cliquer sur un point de la route et de déplacer celui-ci à Glatigny pour que mon itinéraire soit automatiquement recalculé en temps réel.

Cette vidéo est d’ailleurs beaucoup plus parlante que ces captures d’écran.

Au delà de la prouesse technique qui n’est pas sans me rappeler le jeu Click and Play de l’éditeur Maxis (Sim City) en son temps, je me demande si, malgré son extrême simplicité – je clique, je déplace et ça marche – ce genre d’interface super intuitive est aujourd’hui réellement à la portée d’utilisateurs grand public habitués à des outils beaucoup plus austères, complexes et directifs.
Aujourd’hui, l’ensemble des applications de calcul d’itinéraires existantes nécessitent un nombre important d’étapes bien délimitées : adresse, code postal, ville, pays de départ, d’arrivée et pour chaque étape. Ces dernières sont à préciser en amont de la recherche, et ne peuvent pas être changées sans effectuer une nouvelle recherche, là où Google Map demande simplement une ligne de départ, une d’arrivée, et suggère des alternatives quand il ne trouve pas directement ce qu’il cherche.

Comme rien ne vaut les retours d’expériences, je viens de faire essayer le service de calculs d’itinéraires de Google à une habituée de Mappy. Elle devait se rendre de Rouffiac (17) à Saint Sauveur d’Aunis (17) en passant par Parançay (17). Sa première réaction fut : “c’est nul, on ne peut pas indiquer par où on veut passer”.

Le changement d’usages est là évident : à une habitude consistant à indiquer par où l’on souhaite transiter en amont de la recherche vient se substituer le calcul d’un itinéraire idéal (se prendre les embouteillages à Tonnay-Charente n’est clairement pas ce que j’appelle un itinéraire idéal) que l’utilisateur peut altérer de manière visuelle, simple et avec le calcul du nouvel itinéraire en temps réel, en fonction de ses goûts ou de ses besoins. Sauf qu’aujourd’hui, l’utilisateur ne le sait pas encore, et qu’il n’est pas forcément prêt à une telle mutation.

Et vous, qu’en pensez-vous ? Croyez-vous que ces nouveaux usages pourront facilement convertir une masse d’utilisateurs non geeks, ou sont-ils destinés pour un temps au moins à une communauté d’early adopters ?

Via Ogle Earth et Nicolas

Le 31 mai prochain, Google organise une journée d’ateliers et de conférences autour de ses nombreuses API à destination des développeurs du monde entier. L’étape française se déroulera à Paris, dans un lieu tenu secret, de 13 à 21 heures. Cette journée représente une excellente opportunité de rencontrer les ingénieurs qui réalisent ces applications que nous utilisons au quotidien et pour vous familiariser avec l’énorme potentiel de ces outils.

Une API est un protocole permettant à une application de communiquer avec une application tierce. Les API ont joué un très grand rôle dans l’essor du web 2.0, créant notamment la vague des mashups, des applications utilisant de nombreuses API pour un résultat parfois étonnant.

Je m’y rendrai certainement, car je suis particulièrement motivé par les API Google Mobile, Google Map, et Google Aps.

Les inscriptions sont gratuites, et les premiers arrivés seront les premiers servis.

À 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 ?

Afin de lutter contre le spam, Wikipedia vient d’ajouter l’attribut rel="nofollow" sur tous ses liens externes. C’est du moins ce qu’annonce Google Blogoscoped, et un simple coup d’oeil sur une page de l’encyclopédie communautaire permet de s’en assurer.

rel=”nofollow” ?

La croissance des blogs depuis 2002 a entraîné une nouvelle pratique dont nombre d’entre vous ont certainement été victimes : le spam de commentaires. Des robots viennent déposer un commentaire contenant des mots clés précis et pointant vers leur URL sur votre blog afin de faire monter leur page rank Google.

La situation est très rapidement devenue incontrôlable, et les causes en sont multiples :

• Le peu d’outils de blogging différents, qui permet de créer peu de versions des scripts de spam.
• La quantité de blogs et de wiki sur lesquels il est possible de publier des commentaires et des pages sans authentification (et même avec, ça ne change pas grand chose, particulièrement sur les wiki).
• L’absence – à l’époque – de solutions de lutte contre le spam efficaces.

Il a donc fallu rapidement trouver une solution, sous peine de voir tout le système du pagerank s’écrouler sur lui-même. C’est le microformat rel="nofollow". La présence de l’attribut “nofollow” dans un lien indique aux outils de recherche que ceux-ci ne doivent en aucun cas suivre le lien donné dans leur récolte. Ce lien externe n’est dont pas pris en compte dans l’indexation de la cible, et les spammeurs en sont pour leurs frais.

La mort du page rank ?

Le pagerank d’un site se base non seulement sur la quantité de liens externes pointant vers lui, mais également sur le pagerank des pages liant ce site. Il y a donc un certain principe de réciprocité : un site fortement lié agira fortement sur le pagerank des sites qu’il met en lien.

En appliquant l’attribut rel="nofollow", Wikipedia vient de casser ce principe de manière inquiétante : l’encyclopédie en ligne possède en effet un très fort pagerank, et chacune de ses pages (23 millions selon Google) est également très bien cotée au point d’apparaître dans les 10 premiers résultats d’à peu près n’importe quelle recherche sensée (je précise pour les petits plaisantins qui chercheraient des choses absurdes ou n’existant pas dans le seul but de me contredire). Elle récupère donc tout le bénéfice de ses liens entrants, sans toutefois rendre la pareille à ceux qui la lient. Et vue l’importance du site, on est en droits de craindre

• Que ce genre de pratique devienne systématique sur toutes les grosses publications.
• Que le page rank finisse par perdre complètement sa valeur suite à la sortie de la boucle des sites les mieux cotés.

À la fin de l’année dernière, j’ai commencé à m’intéresser au positionnement de ce site sur les moteurs de recherche. J’ai alors contacté Sébastien Billard qui tient l’excellent blog Référencement, Design et Compagnie afin qu’il me fasse profiter de ses lumières. Suite à ses réponses, j’ai commencé une refonte structurelle – et ergonomique – qui a amené à la version actuelle. Un mois plus tard, retour sur les améliorations effectuées et sur les résultats obtenus.

Conseils Structurels

• Remplir le champ <title> à l’aide du titre du billet suivie de la mention “Frédéric de Villamil.com”. Cela permet aux outils de référencement de bien distinguer les pages les unes des autres.
• Dans la structure du code, mettre le contenu de chaque billet avant la navigation, de telle sorte qu’il se retrouve à la première place. Là aussi, il s’agit d’éviter que les moteurs de recherche ne considèrent les contenus comme semblables d’une page à l’autre. Techniquement, cela se fait en jouant sur la position des éléments : le contenu, placé avant dans le code, est placé dans un float: right;, tandis qu’on laisse la navigation dans le flot de la page.
• Supprimer le lien sur le titre du billet en mode lecture puisqu’il pointe de toute manière vers la page en cours. Cela rajoute en plus un bon point pour l’accessibilité.
• Mettre le message “Répondre à ce billet” dans une balise <h3> et non une balise <h2>, cette dernière étant déjà utilisée par le titre du billet, hiérarchiquement supérieur au formulaire de réponse dans la structure de la page.

Conseils éditoriaux

• Ajouter une tagline reprenant les principaux mots clé du site. Sébastien m’avait suggéré “Ergonomie, web design, métiers du web : le blog de Frédéric de Villamil”, mais ma préférence est finalement allée à “Webdesign, Ergonomie et Métiers du Web (2.0)”. Côté sémantique structurelle, le titre du blog se trouve dans une balise <h1> et l’accroche juste en dessous dans une balise <h2>.
• Supprimer le paragraphe de présentation placé en haut de chaque page. Relativement long, celui-ci leurrait les outils de recherche en leur faisant croire que toutes les pages étaient semblables. Le résultat était catastrophique, puisque Google ne recensait que 4 pages différentes, et plus de 1500 doublons. Le paragraphe de présentation a finalement rejoint la navigation, en bas de page.
• Faire figurer les catégories sur l’ensemble des pages, et particulièrement sur celles des billets. Seul problème, je ne voulais plus de sidebar sur ce blog. J’ai finalement décidé de déroger en ce qui concerne les catégories, pour des raisons purement ergonomiques : ce système permet au lecteur d’embrasser le contenu du dernier billet et les thématiques du site d’un seul coup d’oeil, sans retomber dans la pollution visuelle entraînée par une sidebar “fourre tout”.
• Soumettre le site à des annuaires afin de varier la provenance de mes liens entrants, principalement des blogs à ce jour.

Les résultats

Source : google.com, les chiffres de google.fr peuvent être différentes.

Je referai le point sur ces mots clé dans 6 mois, afin de constater les évolutions à venir, en faisant une vérification sur ces mots clé chaque premier du mois, et en les comparant à mes statistiques en entrée. Je remercie Sébastien pour ces conseils qui ne m’ont absolument rien coûté, puisque la bière promise n’a pas encore été commandée. J’espère que vous pourrez à votre tour en profiter pour accroître la visibilité de votre site.

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

• Samedi, atelier Google Map.
• Jeudi, séminaire sur le Web Mobile
• Vendredi, conférence Paris on Rails

Le week-end commençant, ne vous étonnez donc pas de me voir arriver lundi avec une killer app en Rails utilisant la Google Map API à destination des PDA et téléphones mobiles.

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.