Of course, there’s a limit to how many light-up indicators we can cram into browser chrome as well. Maybe 2 years down the line we’ll have all kinds of useful embedded artefacts through µf that would cause my location bar UI to overflow and clutter up. But by the same note, not every µf would be rightly highlighted like that: hResume would be out of place there.

There’re a lot of challenge, and I think implementers should be ready and willing to evolve quickly but right now cruder kind of discover that draws attention to the possibilities might well help the µf is terms of recognition, as well as helping users realise the potential of what they can do in their browser.

There is a tendency to associate Microformats and RSS/Atom because they both let you extract information from a page (and they are both trendy new technologies) but I’d make the important distinction that feed information is entirely meta. Most of the Microformats I have seen are visible elements in a web page. The first thing that alerts a user that there is useful information on the page is probably going to be reading it on the page; not a discovery icon so why not provide functionality via the context menu? In Firefox you can right click on an image and ‘Set as Desktop Background’. In effect the user is taking a visible page element, extracting it and using it elsewhere, just as they would be if they wanted to add an (hCal) date to their diary. I wouldn’t get rid of the icons in the address bar because it’s nice to have a dialog(s) where a user can centrally see all of the meta information in a page but it would be great to be able quickly access functionality from the context menu too.

Tails. Hmm. Very useful as a developer tool certainly and does allow auto-discovery of Microformats. That’s fabulous. But it’s the wrong tool for taking Microformats to the masses. People don’t ‘Open an HTML Document’, they browse a web site. In the same way, people aren’t going to ‘aggregate Microformats’ they’re going to ‘View contacts’ or ‘show calendar events’.

I don’t want to diss Tails, because it’s a really useful tool for people like us and I’ve a lot of respect and thanks for the guys who wrote it (and the Tails Export version that followed), but they took Tails in the direction of being a ‘Microformats’ extension rather than a ‘Contacts and Events’ extension. It’s the latter that I want and that will be useful to non-technical users.

A simpler answer is just that Tails Export doesn’t work on OSX.

It puts an icon in the bottom right, click it and a sidebar shows you the microformats on the page.

The icons are already covered by the hCard microformat. If you view the source for my sidebar you’ll see that my icon is marked up with <img class="logo" src="&#8230;" alt=""/>. The logo property is used as the icon (NB I’ve also used the class avatar on that image, but that is for my own use, not part of hCard).

As I said in my reply to Jon, you could also use the photo property of hCard as an image source. My point in the original post about gravatar and favicons is that they could be used as fall back in the event that a discovered hCard didn’t have a logo or photo property.

Should gravatar be the source of the picons, or should there be a more standard approach?
should there be a:
link rel=”avatar” href=”/avatar.gif” type=”image/gif” /
like the:
link rel=”icon” href=”/favicon.ico” type=”image/x-icon” /

?
Using µformats, of course!

Colin: In the interim – which basically translates as ‘before auto-discovery gets implemented’ then Dashboard widgets, or perhaps more suitably bookmarklets, could be implemented to provide UI like this, certainly.

There’s probably potential to implement the whole lot with GreaseMonkey/UserScript and provide the UI in an overlay ala Lightbox or Flickr’s ‘add contact’ UI, rather than opening a new Window. It would fall short on the drag and drop to other apps, though.

Instead of icons next to the names, shouldn’t it look for the ‘photo’ property?