Ben Ward

Microformats in Web Browsers

. Updated: .

There’s a well established saying and it goes something like this: ‘Don’t keep an idea to yourself because you can guarantee that someone else has also thought of it’.

This weekend at @media I finally got to show off to Tantek some UI design I’d been doing for putting user-focused microformats discovery into web browsers. I’ve been sitting on the sketches for about six weeks due to time commitments at uni and general blogging laziness. For a while I was going to try implementing it myself. Excuses aside, I didn’t post it. This morning, Jon Hicks pretty much did. Oh how I laughedcried.

To my relief there are some quite important differences between my interpretation of this idea and Jon’s, so really it’s all worked out well as a motivating factor to finally get this posted! I recommend reading Jon’s post too.

So, this is a concept for putting Microformats ‘auto-discovery’ user interface in a web browser. Any web browser (although the sketches were original conceived as a Firefox extension). Most importantly, this UI is focused on providing functionality to users with no knowledge of a Microformat, nor any need to understand the underlying formats. By which I mean almost everyone who uses the Internet.

I’ve released the design rather than build it as I have no knowledge of writing Firefox extensions and it’s likely too complex to use as a first ‘teach-myself-XUL’ project. Plus, I’d never actually get around to doing it.

Presenting Microformats in Web Browsers

This design is intended to focus on the user interacting with the information: Moving events or contact information from the page into a Calendar or Address Book.

This is all based on the hCard and hCalendar microformats.

Discovery

hCard and hCalendar discovery should be automatic and consistent with the Web Browser’s existing auto-discovery behaviour for feeds.

The presence of hCalendar data is indicated with a calendar icon in the location bar, and hCard with a ‘contact card’ icon (similar to that used by address book applications on Windows and Mac OSX).

Note that we’re being consistent with feed discovery (which could of course be extended to treat hAtom as a first-class feed citizen too). Users are already being trained to look at the location bar for for additional page content.

Again, with this being designed for my Dad to use, the terminology used is ‘Calendar’ and ‘Contact’ not ‘microformat’.

Clicking the Calendar or Contact icon will invoke the corresponding interface (below).

Events

Events are listed in a simple window similar to the Download Manager interfaces of Firefox or Safari. They should be sorted by start date.

Events are summarised with three lines of information, in some order of importance: The event title, location and date are all displayed where available. In cases where some of that information is missing then a less important field could be displayed instead (such as the URL for the event, although the event title could equally double as a hyperlink to the event URL).

To the right of each event listing are three buttons. Working right-to-left, as the outermost button is the most important:

Ideally the interface should also support drag and drop of each event’s icon onto the desktop or into other applications to create an iCal event file.

In the status bar of the Events window is a “Subscribe to Calendar” button, which should pass the current page to Technorati’s hCalendar pipe to create a subscribable iCalendar.

On the Mac this should open the Technorati URL with a webcal:// prefix, rather than http://. On other platforms it might be preferable just to present the iCalendar URL to allow copy and paste into the user’s calendar application (depending on what Windows Vista’s iCal clone expects).

hCalendar doesn’t facilitate logos for events, so a generic ‘Calendar Event’ icon is displayed. This should ideally be the system icon for .ics files. Potentially, a logo icon could be extracted from a location hCard (suboptimal) or perhaps from the favicon of the event website.

People & Places

As for Events, hCard Contacts are listed in a simple ‘download manager-esque’ window. Contacts should be sorted by name (the illustration isn’t sorted, err, whoops).

A special exception to this sorting is the hCard of the page author (contained in or containing ADDRESS elements), which is bumped to the top. It seems reasonable to predict that users will be most interested in the author’s hCard, rather than that of blog comment contributions or blogroll entries.

As for Event listings, buttons on the right hand side offer functionality to open a vCard with the default address book and open a map for the hCard’s street address (where present).

It could be useful to provide other buttons for contacts. hCards can embed information about telephone numbers and IM screen names which could be used to invoke other applications such as diallers, Skype or AIM. However, whilst I’d love to see that functionality I’m reluctant to clutter the example illustrations.

Icons next to contact names should use the logo property of the hCard (I think), but if that is absent a fallback method could load the user’s Gravatar or the favicon found at their URL.

And that is my idea for microformats in web browsers. Consider the lesson about publishing on time well and truly learned. Ahem.

This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 England & Wales License. In the event that you want to implement this and can’t meet the Share Alike requirement for commercial reasons, contact me. Lets see how far sharing can go for now though.

Updates

Comments

Previously, I hosted responses and commentary from readers directly on this site, but have decided not to any more. All previous comments and pingbacks are included here, but to post further responses, please refer me to a post on your own blog or other network. See instructions and recommendations of ways to do this.

  1. Jon Hicks

    I may have beaten you to publish ideas, but you’ve thought it all through a whole lot more. I like the idea of seeing a download-style window.

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

  2. Colin D. Devroe

    In the interim that something like this happens, what about a Dashboard widget that looks at the current location in Safari and parses the code and spits out something like this?

  3. Ben

    Jon: I think Photo could be used, although the both Tantek and I are using logo in our hCards (mine smoothly integrated in the sidebar blurb). Neither field has any kind of dimensions specification (unlike Atom 1.0, which cleverly recommends an image size for feed logos), but I imagine either logo or photo could be used. Perhaps the browser could check against both graphics and choose one based on which is smallest, or squarest?

    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.

  4. luxuryluke

    Wow. This is a great idea. Would it be an extension for most of the advanced browsers to adopt, or part of the actual app, as needed?

    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!

  5. Ben

    Luke: IMHO this should be core browser functionality. It’s enabling you to do things with really basic data and I think the number of people who could make use of it is sufficiently huge – especially after Windows Vista comes out and the number of people with access to an iCalendar application increases massively.

    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="…" 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.

  6. Ben O'Neill

    Have a look at Tails Export:
    https://addons.mozilla.org/firefox/2240/

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

  7. Ben

    Ben: In the first draft of this piece I had a paragraph of why I’d designed this from scratch rather than based on Tails existing work. I cut it because it seemed to drift off the point, but hadn’t noticed that I’d removed all reference to Tails altogether, that was an error.

    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.

  8. Duncan

    You’re definitely right that the biggest problem with the current Microformats extensions is that they are focused on the technology rather than the utility. Yours is the first extension that I have seen that does not use the Microformats logo.

    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.

  10. Ben

    Duncan: I certainly think there’s something to be said more subtle µf integration as well. Context menus are a useful way of placing ‘save contact’, ‘subscribe to event’ type actions. The problem is, how do you know it’s there? One of my favourite features of µf is that you can slip them neatly into flowing text, but should someone right click on a paragraph? Should some contact or calendar icon pop up when you hover on it? At what point does placing chrome within page content become obtrusive to the page designers? Even if something is indicated on hover, not everyone uses the mouse to track as they’re reading…

    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.

You can file issues or provide corrections: View Source on Github. Contributor credits.