Encore une très grande nouvelle pour la communauté des microformats annoncée hier sur le blog officiel des microformats par Tantek. L’adoption par Facebook sur les pages événements du standard ouvert microformat hCalendar ouvre non seulement une facilité pour l’utilisateur de renseigner son agenda, mais laisse aussi présager de très riches potentiels pour les moteurs de recherche. Une réalisation de Paul Tarjan facilitée par Tantek avec un bug qui reste connu sur le fuseau horaire*. Tout ce qui suit n’est qu’une traduction du billet source et comme à l’habitude… seul le lien original fait référence.
Aujourd’hui, Facebook a marqué tous ses événements avec le microformat hCalendar en marquant aussi les lieux hCard. Selon une simple recherche sur Google, cela donne des millions d’événements publics publiés avec des microformats (si quelqu’un connaît un nombre plus précis pour la quantité totale du nombre d’événements Facebook, y compris les événements privés, ou combien d’événements sont créés par jour, faites-le nous savoir !).
Voici un exemple à venir : le Great British Booze-up durant SXSW 2011 (que je recommande vraiment si vous êtes impliqué dans le marquage de haute qualité, car un bon paquet d’entre nous seront là pour partager des verres et pour des conversations autour du panel du futur des microformats).
Visitez cette page dans un navigateur qui supporte les microformats (il existe à ce jour de nombreuses extensions pour Chrome, Firefox, Internet Explorer et Safari). Essayez par exemple Firefox 4 avec l’Extension Operator, et vous verrez s’afficher Évènements (1)” dans la barre d’outils. Un simple clic révèle “Great British Booze-up” que vous pourrez alors exporter dans votre agenda iCal, 30 Boxes, Google ou Yahoo.
Et si vous êtes un utilisateur, c’est tout. La capacité de copier des événements là où vous le désirez. Si vous publiez du hCalendar, Google les indexera et affichera des « rich snippets » pour vos événéments. C’est ce que les microformats vous « empuissancent » à produire.
Pour les auteurs/designers/dévéloppeurs web qui passeraient par là, jetons un œil sur le marquage de Facebook. Si vous regardez le code source de la page et cherchez “vevent”, vous voyez le code suivant :
<body class="vevent ...Ce qui indique que cette page est un événement. En cherchant plus loin dans la source, vous verrez que Facebook génère le reste à partir d’un script. Même si cela n’est pas idéal (en général, il est préférable d’avoir le marquage dans le marquage), il existe apparemment des raisons de performance pour le contenu généré par un script. Pas de problèmes, nous pouvons utiliser le menu de contexte de Firefox « Code source de la sélection » pour voir le marquage généré.
Je tiens à faire ressortir ici deux aspects spécifiques de l’implémentation Facebook. Sélectionnez la ligne complète de date et d’horaire : “Heure lundi 14 mars · 18:00 – 21:00” et faites un clic-droit/ctrl dessus et choisiissez “Code Source de la Sélection”. Voici ’ le marquage que vous verrez (espace-blanc ajouté pour la lisibilité).
<div>lundi 14 mars ·
<span class="dtstart">
<span class="value-title" title="2011-03-14T18:00:00-07:00"> </span>18:00</span> -
<span class="dtend">
<span class="value-title" title="2011-03-14T21:00:00-07:00"> </span>21:00</span>
</div>
Encoder des dates et des horaires qui fonctionnent tant pour les humains que pour les machines fût l’un des plus gros défis dans les microformats. Et ce que vous voyez ici est le résultat d’années d’itérations de communauté (techniques, feedback, recherche) appelé la technique ‘value-title’ du modèle de classe value. Pour faire court, en plaçant les dates et heures dans un format ISO lisibile par les machines dans l’attribut title d’un élément span vide innocent, adjacent à la date et l’horaire lisible pour l’humain, nous pouvons parvenir à un équilibre pragmatique entre l’expérience utilisateur, la fidélité du contenu en minimisant les effets consistant en fait à dupliquer la donnée (une violation du DRY, quelque chose que nous évitons du fait des incohérences potentielles à moins que ce ne soit absolument nécessaire pour un plus grand principe, tel que l’utilisabilité pour les humains).
C’est le déploiement le plus massif connu à ce jour de la technique ‘value-title’, et cela fonctionne merveilleusement avec le support du modèle de classe value dans Operator.
Jetons un oeil au lieu. Regardez le code source de la Sélection sur le bloc complet à partir de “Lieu Shakespeare’s Pub” jusqu’à “78701″ et vous verrez (de nouveau avec un ajout d’espaces blancs)
<div class="location vcard">
<span class="fn org">Shakespeare's Pub </span>
<div class="adr">
<div class="street-address">314 East 6th Street</div>
<div class="locality">Austin, TX 78701</div>
</div>
</div>
Ceci est un excellent exemple d’utilisation d’une hCard embarquée pour un lieu dans un événement hCalendar, à part une chose :
<div class="locality">Austin, TX 78701</div>
Qui devrait être plus marqué comme :
<span class="locality">Austin</span>,
<span class="region">TX</span>
<span class="postal-code">78701</span>
Je suppose que ce qui se passe ici est une interface grossière entre un système backend et frontend, ce qui revient à dire que pour la facilité, les développeurs peuvent retrouver la totalité de la ville, de l’état et du code postal à partir d’un backend sous une chaîne unique. Par conséquent, le mieux que puisse faire le front end est de marquer la chose en entière comme la ville (locality).
Même si ce n’est pas idéal, cela n’est pas horrible. Une fois de plus, en utilisant Operator, choisissez « Exporter le Contact »” pour Shakespeare’s Pub, et remarquez que ce qui s’affiche dans votre carnet d’adresses est tout simplement bien (même si les champs ne sont pas exactement aux bons endroits). Copier et coller cette adresse sur un site de cartographie fonctionne aussi. Le marquage n’est pas idéal, mais il est utilisable et utile. Et je suis heureux que Facebook ait fait le choix d’aller de l’avant et prennent cette décision pragmatique, tout en sachant qu’ils pourraient itérer et améliorer la fidélité des données dans une mise à jour à venir.
Le déploiement de hCalendar dans Facebook est simplement la dernière de leur série de support lent et régulier des standards ouverts et des microformats en particulier. Il y a deux ans Facebook avait ajouté le support de hCard à ses profils utilisateurs. L’année dernière, ils annonçaient le support de OAuth 2.0, tout comme l’ajout du support XFN rel-me aux profils utilisateurs, s’interconnectant ainsi avec le web social distribué. Ils ont fièrement documenté leur usage de HTML5. Et désormais, des millions d’événements hCalendar avec des lieux hCard. Impatient de voir ce qu’ils supporteront la prochaine fois.
Well done Facebook, and keep up the good work.
* Comme le faisait remarquer Andy Mabbett, il leur reste encore un peu de boulot afin d’être utilisable en Europe. En France, ce serait cool de localiser le fuseau horaire d’hiver à UTC/GMT+1 pour ne pas déraper de +9 heures dans l’espace-temps de nos agendas en ligne.
{ 1 Commentaire }
