Testing Out Microformats: hCard

Since I’ve been talking a big KISS-game recently, I thought I’d get my hands dirty with a couple microformats. Today I went for hCard, which is a XHTML version of vCard, which itself is just a way to markup your contact info. There are marking up your links and cites to other people. But, for now, I’m just interested in one person (me) declaring their contact info.

The Page

If you look at the sidebar of the main page for the blog, you’ll see:

Which is pretty much what it was before I started playing with it, sans the IM links and time zone. The point is: the visual rendering of the page and even the CSS didn’t need to change to use hCard. The microformat is unobtrusive, which is fancy-talk for “cheap to implement.”

The Code

Here’s what the “code” (to use the term loosely) looks like:

<address class="vcard">
	<div id="about">
		<h2>About</h2>

		<p class="pic" id="portrait">
			<a href="http://www.flickr.com/photos/cote/"
			   title="More photos">
			   <img src="http://static.flickr.com/31/101406173_5dad3bf43a_m.jpg"
			        width="160" height="240" alt="Coté" class="photo" /></a>
	  </p>

		<p>I'm <a class="url fn" href="http://www.peopleoverprocess.com">Coté</a>,
			a software <span class="title">Industry Analyst</span>
			with <a href="http://www.redmonk.com"><span class="org">RedMonk</span></a>.
			I cover a wide range of topics in the software and technology world.
			These opinions are my own, but whose else would they be?</p>
	</div>

	<div id="contact">
		<h2>Contact</h2>
		<span class="email">
			<span class="type">Email</span>:
			<a class="email" href="mailto:[email protected]">[email protected]</a>
		</span>
		<br/>
		Y!: <a class="url" href="ymsgr:sendIM?bushwald">bushwald</a>
		<br />
		AIM: <a class="url" href="aim:goim?screenname=bushwald">bushwald</a>
		<br/>
		<!-- didn't bother putting these in microformat -->
		GTalk: [email protected]<br />
		MSN: [email protected]<br />
		Skype: <a class="url" href="callto://bushwald">bushwald</a>
		<br/>
		<span class="tel">
			<span class="type">Work</span>:
			<span class="value">+1-512-206-2927</span>
		</span>
		<br />
		<span class="tel">
			<span class="type">Cell</span>:
			<span class="value">+1-512-663-7507</span>
		</span>
		<br />
		Time Zone: <abbr class="tz" title="-06:00">CST</abbr></span>
	</div>
</address>

That may seem like a lot of code, but the difference between what I had before adding in an hCard and after is slim.

The key point here is that the microformat of an hCard more layers on top of existing formats than rests on it’s own. A companion point is that the hCard microformat piggybacks on existing XHTML tags instead of making it’s own tags up.

The long existent address tag is used for the entire hCard, and it spans more than one “block” of data. You don’t have to use address, of course, the important things are the class attributes and the relationships implicit in the XHTML nesting.

Convention and Hierarchy

So, what we have here is formatting by convention (to steal a page from Rails) and hierarchy.

Format and convention are two words that don’t often go together, because convention implies messiness and parsing problems. But, convention, not validity, is what makes, and made, the web successful.

Hierarchy is a danger word for many coders as it’s a synonym for “bad performance” and “walking DOMs.” Both of those applied to the hilt until recently. But those problems have been steadily fixed in XML/XHTML land with a better understanding of XSLT, CSS paths, and the fact walking a DOM in a dynamic languages (e.g., JavaScript) can be much easier than in most static (e.g., Java) languages.

Rendering

Here’s what the data looks like in a third-party tool:

Not too hot because of two things: I have a funny character in my name (é) that no one nor no thing ever gets right. Bill probably has the same problem. Also, it seems to have conflated together two of my URLs. I’m not sure if that’s because I typed in something wrong, or a bug in the tester.

Why This Matters: Less Code & Config

Typical snafu’s aside, what’s amazing about this example is that with just 10-20 minutes of reading and typing, a static web page was used to provide structured data to a 3rd party tool. The time it took doesn’t matter so much, what does matter is that one view can be used by two different consumers. The URL PeopleOverProcess.com can be used by:

1. People who want to read the webpage.
2. Software that wants to get my contact info.

Normally, you would need two different URLs/files for that: one for each consumer. That is, microformats make screen-scrapping really easy. No more need to use regexes and script-hacks.

This simplistic example doesn’t mean much. But let’s expand it to something with even more data: free/busy calendars.

A constant problem for us at RedMonk is scheduling meetings. We each have different OS’s, but more importantly, 99% of our scheduling is with people outside of our organization. so you can imagine that the Exchange/Outlook approach doesn’t work too well.

Now, you can imagine that we could put a calendar on a web page that showed when we were free and busy: it might even say what we were doing at the time, contain links to relevant things (like follow-up blog posts)…you know, the Web 2.0 calendaring wet dream ;> Upcoming, eventful, and others are good initial cuts at a UI for a calendar (the next steps are integrating with more applications and services, like Exchange and iCal, or dodgeball.).

What gets tricky is if some application — say Outlook — wants to use that calendar web page to help someone schedule time with RedMonk. Good luck with that. At best you’d have to screen-scrape and someone hook up with Outlook.

Now, if that calendar web page was microformated — with hCalendar? — things would go much better for the program involved: parsing the well-formed XHTML of a microformat is do-able in a short amount of time (read: “cheap”).

You might be thinking, “but you could just have the programatic view of the calendar at another URL.” And, sure, you could, but why have more code?

Which highlights a key benefit of microformats in web pages is that you don’t need a protocol of discovery for the programatic content. For example, if I give you the URL http://www.peopleoverprocess.com, I might have to markup in that page that my programatic calander view is at http://www.peopleoverprocess.com/cal.xml. (Indeed, this is what’s done for RSS feeds with a link tag in the page’s head.) That’s where the whole “one view instead of two” idea comes in again. Once you’ve got the URL, you’ve “discovered” everything there is to know.

Using It

There are always going to be times when another view is better. On the other hand, when it comes to many types of data — contact, calendars, social net relationships, and other declarative statements in both consumer and enterprise software — coding a support another view for programatic access may be just time prohibitive enough to prevent you from providing programatic access. In those times, microformats are a good option. Meta-data is exciting stuff, and microformats are light-weight enough to actually be a viable approach to meta-data…as opposed to say, RDF, at least by programmer-lore.

The over-all simplicity of microformats makes them a good base-line for providing data access as well. Instead of starting out with a new view from the get go, It might be a good idea to start by using a microformat, and only expand out to a brand new view if needed.

Disclaimer: Microsoft is a client.