Both hCard and hCalendar are based off of already existing standards (vCard – RFC#2426 and iCalelndar – RFC#2445 respectively). With some XSLT transformations or Javascript parsing, we can export the microformatted data in a webpage to other pages or into other data formats. For example, sites like upcoming.org mark up events with the hCalendar microformat. If we plan on attending these events, we can add it our Google Calendar, Yahoo Calendar, or 30Boxes to remind us about the event at a later date.

One of, if not the most popular microformat user-agent is the Firefox extension Operator by Michael Kaply. Currently, Michael is working on adding microformat functionality and javascript functions for microformats to Firefox 3. This means we’ll be seeing a lot of these features in the next version of Firefox. Operator supports a wide range of microformats, but as previously mentioned we’re only going to stick to hCard, hCalendar and we’re going to talk a bit about rel-tag. The premise of operator is simple: if it detects any microformatted data, it allows you to take some sort of action. If you find a person or place marked up with hCard, you can export it as a vCard or add to yahoo contacts. Exporting an hCard as a vCard will allow you to save a contact to programs like Address Book, Outlook or any program that supports the vCard standard.

I’ve already mentioned what you can do with information marked up with hCalendar, so let’s look at rel-tag. Rel-tag is simply marking up up the “rel” property of a hyperlink with the value “tag.” Once Operator knows that the link is a tag, it can then look for that same tag at sites like flickr, technorati, and del.icio.us. A common use for tags is looking up additional information about something you’re reading. Blog posts for example are usually tagged, so people can find pictures on flickr, related blog posts on technorati, or related sites on del.icio.us.

Let’s take a moment to recap and see why we like microformats and operator. For one we don’t have to input data ourselves. Since the data is already online we’re simply copying it to our application of choice. With this comes the advantage of actions becoming point and click. If you want to add an event to your Google Calendar, you point and click on the add to Google Calendar option. Pretty simple.

One area that can benefit from microformats is the cell phone market. I’ve already written about the iPhone as a microformat killer-app, but I wanted to expand this idea to include both cellular phones and internet-enabled PDAs. Cell phones and PDAs both have notoriously horrible input interfaces. Don’t you dread typing out a long text message, let alone trying to search for something on a cell phone browser? What about trying to write something out in Graffiti? What if these devices had the point and click ease of use that operator has? With REAL browsers coming to next-gen cell phones such as the iPhone, I see no reason why microformats shouldn’t be a part of this market. Imagine adding a person’s contact information into your cell phone via their hCard. You have all of the information you need about them ready to and be entered into your cell phone at the tap of a stylus. The same can be said about events and adding it to your calendar application on your cell phone or PDA.

With these smaller devices, ease of input usually suffers. In this case microformats make a great alternative to user input and can help overcome these shortcomings. It really can be just as easy as point and click.

I think I might be going about this idea of consolidating your online identity with the OpenID simple registration extension and microformats wrong. I found this microformat library for PHP; It works by by retrieving the microformatted data (in this case hCard) by simply feeding it a URL and it then saves the hCard data for future manipulation. I’m starting to realize this same practice may be another way to consolidate your online identity with OpenID.

Before we get ahead of ourselves, let’s see how the applicable portion of the OpenID protocol works. The first step is to supply our OpenID URL to the consumer site and hit “submit.” For example, I would enter “nickpeters.net” as my OpenID URL to the consumer site ma.gnolia. What is a consumer site exactly? According to the OpenID Specification, the consumer is:

A web service that wants proof that the End User owns the Claimed Identifier.

Pretty much it means a site that wants to find out whether or not we are who we say we are by first asking for our OpenID URL.

After we hit the “Submit” button, an internal script on the consumer site will redirect itself to the given URL and look for two link tags in the head of the given HTML document. For the sake of simplicity, we’re only going to discuss the one of them: rel=”openid.server.” The href value of this link tag is going to be the script that actually authenticates you by asking you for the username and password you use on all OpenID-enabled sites. This practice is useful because you can offload the authentication process to a site like Vox or livejournal instead of setting up a server on your own server. This means I can enter the URL for the livejournal authentication script or a script hosted on my site. It also means your username and password isn’t sent to the consumer site and is only sent to the specified script.

That should be enough information for now, so let’s see how hCards can fit into this. Let’s say we log in to our OpenID consumer site (ma.gnolia) and go through the login process as normal. While the consumer site looks for the and OpenID.server URL in the head of our page, it would also look for some sort of clue as to the location of your hCard information. Perhaps this “clue” could follow in the steps of the existing OpenID protocol and also be a link tag, such as rel=”hcard” in the head of the document. From there, the consumer-site script can retrieve the hCard location by looking at the href value, properly redirect itself, and retrieve your information (Perhaps even using the hKit library).

The pros of this is that you can add as much or as little information as you want about yourself in your hCard. The simple registration data fields are very limited and there maybe some information in there that you don’t want to be shared (such as email address).

The cons is that it requires more administrative overhead. You’ll have to edit the header information of your site. You may not even be able to do this on all OpenID identifiers (such as ones on livejournal) because you don’t have permission to edit the header information.

Right now there are discussions going on in the microformat community about authoritative hCards that could possibly guide this idea in the right direction. I will continue to think about this and would appreciate any ideas from others.

The problem is that some sites on the internet that implement hCards may contain inconsistent data. This proposed solution will allow sites to retrieve your information from one source. If someone wants to find your personal information, they can go to any site that has your hCard instead of having to find your authoritative hCard (this will be a topic of another blog post I’m sure).

Let’s take the OpenID-enabled site ma.gnolia for example. You can sign-in with OpenID and upon successful login, ma.gnolia can retrieve your personal information from your OpenID identity provider. From there it can turn the resulting information into an hCard microformat. Of course there would have to be some sort of control panel to determine which information gets displayed and which information to hide (such as email).

Now, essentially all I am doing is applying an existing protocol, but I wanted to bring awareness to the idea of using OpenID with the hCard microformat. I also wanted to bring attention to the idea of using OpenID as a way to centralize your personal identity so you have consistent personal information among sites.

The first step I took was to actually learn the entire OpenID protocol. I ended up not learning all of the protocol because I felt the documentation was insufficient. This brings up another project idea: document the OpenID protocol in plain English. It was fun learning as much as I did and learning how to implement it myself in PHP. It also gave a chance to learn/use the cURL library in PHP. Perhaps after I learn the protocol, I’ll use a library to make further development easier.

I spent the rest of my time socializing and meeting new people and talking to people met at previous DevHouses. Highlights include talking to Konstantin Koll about his OS that implements a WinFS-like file system, Jesse Andrews of Flock about the next big release of flock (which I eagerly await!), and Chris Moak about his new sleeping schedule and duct tape accessories.

The night was ended by going out to Dennys where we discussed what made this DevHouse a success and what can be done to improve it for next time.

Pictures can be found at: http://www.flickr.com/photos/tags/shdh15

After absorbing all of this, I started to think about how microformats fit into the picture. Now that we are able to retrieve a full XHTML webpage with Safari on a mobile device, we are also able to retrieve microformatted data. What does this mean in terms of how we add contacts to our address book, add events to our calendar or find a location on a map? It sounds like the processes can be streamlined. With hCard we can add a new contact (including a photo for quick recognition!) or find out the location of a business with Google Calendar. With hCalendar we can add an event to our calendar (assuming the calendar supports adding new events). All of this can be possible without typing anything or syncing data from our Mac/PC. Of course all of this is theoretical, but imagine how easy organization will be. It will be exciting to see if microformats ever make it to consumer devices for purposes such as this.

It was already demonstrated that the iPhone already has the ability to dial numbers from locations found on Google Maps. It seems that Google uses their own closed standards/algorithms to parse the information from websites and somehow sends the extracted information to the iPhone. What about the rest of the sites out there that have just as good information to offer? If the move to an open standard like microformats is made, similar functionality can be had on any website that implements the appropriate microformat.

Oh also, I bought an Apple TV today as an impulse buy. It ships out on March 2nd!

• Performance Improvements – I’ve done a few things here. The main thing is that I was going through the document’s DOM one time for each microformat. I’ve reduced that to one time for all microformats, and I also cache the list of microformats as best I can (there’s more work to be done here. I’ve also modified it so that I don’t build any menus until the icons are actually clicked. In addition, I removed the code that did a reverse lookup on geos to get the address. This was causing a MAJOR performance problem on pages with geo tags. I think this is a deficiency in the geo spec – I wish they had a way to specify a name for the geo on the geo tag.
• User Interface – I’ve added both a toolbar button and a status bar icon that contain all the Operator functionality.
• Handlers – I’ve made it so that handlers can indicate that they require data in a microformat. If that data is not there, the handler won’t appear. In addition I’ve added basic support for 30 Boxes. If any 30 Boxes developers are out there, please feel free to contact me so we can discuss why I can’t make 30 Boxes work as good as Yahoo or Google Calendar. I’ve also added support for Yedda.
• Microformats – I’ve added support for hResume. It’s not there by default, so if you want to see it, you’ll have to add it using the Microformats tab in Options.
• Debug – I’ve modified the debug dialogs so that they now display in a readonly text area that can be copied to the clipboard. They are also formatted better.
• Tags – I’ve improved the parsing to be more compliant with the spec for valid/invalid tags. You’ll notice the tags on my blog don’t display because they are invalid. (Thanks blogger!)
• Browsers – I’ve verified that Operator works on Flock and modified the install.rdf to support Flock
• hCard – I’ve added support for the “hCard reference via object.”

Before I give any of my opinions I would like to try it out for a few days to really get to know the differences. Anyways, I suggest you check it out and give Michael feedback as well.

Test it here:
If it works you should see two buttons below the bookmark.

This
hCalendar event brought to you by the
hCalendar Creator.