This is an idea for a Microformats user interface in web browsers, focused on users with no knowledge of a Microformat, nor any need to understand the underlying formats.

This was originally concieved as a Firefox extension, but could be implemented for any browser. I’ve released this design as I have no knowledge of writing Firefox extensions myself it’s likely too complex to use as in a personal teach-myself-XUL project. Plus, I’d never actually get around to doing it.

Additionally, following Chris Messina’s post to µf-discuss regarding awesome examples of Microformats, the time seemed right to publish this rather than sit on it.

The work is licensed under a Creative Commons Attribution-ShareAlike 2.0 England & Wales License.

Presenting Microformats in Web Browsers

Microformats are in an early stage of adoption and user interaction with the embedded data tends to occur using script-based Bookmarklets, Greasemonkey scripts or Firefox extensions.

Bookmarklets and Greasemonkey are strictly the domain of the tech-savvy whilst the Firefox extensions currently available (e.g. Tails) are focused on the Microformat, rather than on using the data. By which I mean no disrespect to the author of Tails, it’s excellent work, but Tails is currently a ‘Microformats Extension’ not a ‘Contacts and Events’ extension.

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 discover should be automatic and consistant with the Web Browser’s existing autodiscovery behaviour for feeds.

In the case of a Firefox implementation, the presence of hCalendar data is indicated with a calendar icon in the location bar, and hCard with a ‘contact card’ icon (as used by address book applications on Windows and Mac OSX).

Clicking either the calendar or contact icon will invoke the corresponding interface (below).

Events

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

Three lines of information are presented, in some order of important: The event title, location and date are all displayed where available. In the event that some of that information were 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 commonly used:

• Add Event to Calendar. This converts the hCalendar microformat into an ICS appointment file and opens it locally on the users machine, where an installed calendar application will handle it. This should probably be overridable to support Web-based calendars such as Google Calendar.
• Add Event Location to Address Book. Where the hCalendar location is represented by an hCard, the location can be converted into a vCard and openned on the local machine (again invoking the default application)
• View Map of Event Location. Invokes a mapping service (such as Google or Yahoo! Maps) using information from the location field. In Firefox, this could be customisable using the native installed Mycroft Search Providers.

Ideally the interface should also support drag and drop of the event icon onto the desktop 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 open a subscribeable iCalendar.

On Mac platforms this should open 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 Calendar application expects).

hCalendar doesn’t facilitate logos for events, so a generic ‘Calendar Event’ icon is displayed. This should ideally be 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, hCards are listed in a simple ‘download manageresque’ 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, which is bumped to the top. It seems reasonable to predict that users would be most interested in the author’s hCard, rather than that of blog commentors or Blogroll entries.

As for Events listings, buttons on the right hand side will save a vCard to the local computer and open with the default application and open a geographic map for the hCard’s street address.

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 an application. However, I’m reluctant to clutter these examples.

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