Internet fraud costs victims millions of dollars each year. Protect yourself with Escrow.com!

Mon petit doigt me dit que cette entreprise va avoir un peu de mal à développer son activité sur les marchés francophones… Pourtant, elle a des atouts indéniables :

Il reste comme un malaise, non ?

Cela fait un certain temps que je suis avec beaucoup d’intérêt les travaux du MIT (Massachusetts Institute of Technology) autour de Simile (Semantic Interoperability of Metadata and Information in unLike Environments). Ses intervenants défrichent le terrain du web sémantique avec beaucoup de talent et sans oublier de passer de la théorie à la pratique.

Le projet le plus connu est sans doute Timeline qui se veut le « Google Maps du temps ». J’avoue que le résultat est plutôt à la hauteur de la comparaison, d’autant que l’intégration de Timeline dans un site web est triviale !

Par contre, je suis un peu moins enthousiaste avec Exhibit. Ce framework permet de publier des données structurées et de les manipuler dans une interface web avec une déconcertante facilité. Le concept est génial mais je trouve certains choix techniques très discutables.

Pourquoi avoir créé des attributs HTML spécifiques à Exhibit ? Par exemple, pour réaliser un filtre à facettes, il faut écrire le code suivant :

<div id="exhibit-browse-panel" ex:facets=".discipline, .relationship, .shared, .deceased"></div>

Résultat, le code source n’est pas conforme et la page n’est pas accessible (au sens ergonomique). Des inconvénients qui vont à l’encontre du web sémantique ! Pourquoi ne pas avoir développé une syntaxe particulière pour les valeurs des attributs HTML officiels ? C’est le principe de diffusion adopté par les microformats.

Quant aux données, elles proviennent d’un objet Javascript (plus précisément d’un objet JSON). Adopter JSON est une excellente idée… sauf pour le référencement de la page web. En effet, pour un robot d’indexation, une page Exhibit est vide ! Il y a bien quelques pistes pour résoudre le problème, mais je suis loin d’être convaincu. Il me semblerait plus judicieux d’intégrer les données par défaut dans le code source HTML et de les manipuler via des méthodes non intrusives (unobstrusive Javascript) par le DOM du navigateur.

Et de votre côté, utilisez-vous Exhibit dans vos projets ? Avez-vous trouvé des réponses à ces contraintes ?

Exhibit a un tel potentiel que je ne voudrais pas être bloqué par ces deux défauts majeurs. Surtout qu’un autre projet va en décupler l’intérêt : Potluck (merci Christian pour cette découverte !).

Les acteurs du web n’ont pas attendu la vague du « web 2.0″ (à quand le ressac ?) pour créer des communautés ou des applications en ligne (on remarquera au passage que les web applications sont devenues des SaaS, softwares as a service, c’est plus « tendance »).

Et que dire du contenu généré par les utilisateurs (le fameux User Generated Content si cher au « web 2.0″) ? N’est-ce pas la fonction première du web que de permettre la diffusion rapide, massive et économique de contenu ? Depuis 1990 (et la première page web), les utilisateurs mettent en ligne du contenu.

J’ai eu la chance de concevoir des services « à la sauce web 2.0″ dès 1998 : sites communautaires, applications en ligne, outils de travail collaboratif… Et je n’étais pas le seul ! Mais il faut bien avouer que deux choses ont freiné leur expansion : les connexions bas débit et l’inviolabilité de la sphère privée.

Tout le monde peut comprendre qu’avec un modem RTC qui charge une page web en 55 secondes, il est impossible d’avoir des services tels que YouTube. Quant à la sphère privée, il a fallu une bonne dizaine d’années pour que l’internaute s’habitue à publier (donc rendre public) quelques bribes de sa vie personnelle (avec les excès que l’on connait aujourd’hui…).

Finalement, pour moi, le « web 2.0″, c’est :

• un coup marketing de maître !
• la généralisation du haut débit
• l’ouverture de la sphère privée

C’est tout. Enfin presque… J’ai oublié le seul point réellement nouveau dans le « web 2.0″ : Ajax (Asynchronous JavaScript and XML), rendu possible grâce à l’implémentation de XMLHttpRequest dans Internet Explorer (merci Microsoft !).

Ajax change tout, à commencer par la notion de page web. Comme le fait très souvent remarquer Frédéric Cavazza, peut-on encore utiliser le terme de page web, alors que le contenu et la forme évoluent par petites touches au sein d’une seule page ? Netvibes en est un bon exemple.

Nous en sommes à l’ère des single page applications (SPA). Ses effets révolutionnent notre manière de voir et de concevoir le web. Les ergonomes sont obligés de revoir toutes leurs préconisations. Ajax change nos méthodes de production, les éditeurs de code HTML (comme Dreamweaver) ont disparu et font place à des environnements de développement lourd. Ajax bouscule les habitudes chèrement acquises des internautes (on ne touche plus au bouton « Page précédente » du navigateur pourtant si pratique !). Ajax perturbe l’économie du web en faussant la mesure d’audience.

Ajax finira peut-être par tuer le web, en imitant toujours mieux le comportement des applications classiques. Il rendra inutile le navigateur web et favorisera l’émergence des RIA (Rich Internet Applications), puis des RDA (Rich Desktop Applications). Finalement, Ajax entraînera un retour aux sources de l’informatique grand public : un système d’exploitation, des applications locales, des interfaces riches.

A la différence que tous leurs éléments intrinsèques seront connectés à internet et dépendront de lui : WebOS, RDA, Widgets, SaaS. Le web sera, quelques temps encore, un protocole d’échanges de données entre machines, avant de disparaître…

Je n’ai pas trop l’habitude de présenter le « tout dernier service web qui va révolutionner la planète », d’autres le font bien mieux que moi et vous savez peut-être ce que j’en pense.

Je fais une exception avec CrazyEgg parce que je trouve l’idée simple et utile, le genre de truc qui facilite la vie. CrazyEgg analyse le comportement des visiteurs de votre site web. Vous me direz, le marché de l’analyse d’audience est loin d’être nouveau. Oui, mais ici, les résultats sautent aux yeux ! Ils permettent vraiment de travailler l’ergonomie de votre interface.

Là où les autres outils se contentent de dresser une vue globale des comportements (pages vues, pages populaires, pages d’entrée et de sortie, chemins de visites, etc.), CrazyEgg vous en donne le détail. La démonstration parle d’elle-même.

Dans la « top list » des petits trucs qui agacent : l’obligation d’entrer « www. » dans la barre d’adresse du navigateur pour accéder à un site. Quatre caractères qui n’apportent aucune information particulière, sauf celle de définir un site web (ce que l’on sait déjà puisqu’on utilise le protocole HTTP). Heureusement, la plupart des sites propose un accès via leur domaine seul (exemple.com) ou avec l’adresse complète (www.exemple.com).

Cependant, aux yeux des moteurs d’indexation, il s’agit de deux sites différents. Votre contenu sera donc diluer dans les index des moteurs de recherche. De même, les liens vers votre site ou son clone diminueront le « poids » de vos pages web (le fameux « page rank » de Google, par exemple).

Pour conserver l’avantage d’une adresse courte et éviter le double référencement, il suffit de placer ces lignes dans le fichier .htaccess situé à la racine du site :

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.exemple\.com [NC]
RewriteRule (.*) http://www.exemple.com/$1 [QSA,R=301,L]

Cette règle de réécriture permettra au serveur de rediriger les visiteurs (et les moteurs d’indexation) vers l’adresse complète (www.exemple.com).

Pourquoi ne pas en profiter pour faire l’inverse, à savoir simplifier l’adresse en redirigeant vers le domaine seul ? Parce que la norme impose de garder « www » comme adresse principale d’un site web. Internet et les noms de domaines existaient bien avant le web (les premiers domaines en « .com » ont été achetés en 1985, cinq ans avant la naissance du web) et servent à d’autres services internet (messagerie, transferts de fichiers, surveillance réseau).

Google, Yahoo et Microsoft, frères ennemis ? Pas toujours ! Ils savent aussi travailler ensemble quand cela favorise leurs intérêts respectifs. Un exemple : le protocole Sitemap, initié par Google, fait maintenant l’objet d’un site dédié (sitemaps.org) et d’une licence Creative Commons pour favoriser son adoption. Autant dire de suite que Sitemap sera LE standard d’indexation du contenu des sites web.

Avec Sitemap, le webmaster reprend la main sur l’indexation de son site : il peut en décrire la hiérarchie, favoriser l’importance d’une page ou indiquer la régularité des mises à jour. Ces données sont stockées dans un ou plusieurs fichiers XML soumis directement aux moteurs d’indexation.

C’est toujours mieux que le simple fichier robots.txt, mais ce n’est pas encore la panacée. Sitemap est parfait quand la structure du site évolue peu. Par contre, lorsqu’à l’occasion d’une refonte, des contenus changent de rubriques, sont fusionnés ou éclatés, changent de domaine, Sitemap ne sait pas décrire ces changements. Certes, les codes de statut HTTP peuvent y remédier, notamment les 301, 302, 303 et 307, mais ils sont souvent mal exploités (quand ils le sont…) par les systèmes de gestion de contenu et sont plutôt destinés aux navigateurs web qu’aux moteurs d’indexation.

La bonne idée serait donc d’ajouter quelques balises dans les fichiers XML Sitemap pour indiquer les changements de structuration du contenu (suppression, déplacement, fusion, éclatement, pages liées, etc.). On pourrait alors se passer du fichiers robots.txt et de quelques balises META dans le code HTML de chaque page. On pourrait même imaginer se passer des codes de statut HTTP si le navigateur web savait exploiter les fichiers XML Sitemap. Il me reste à contacter les frères ennemis pour mettre tout cela en place !