After reading through your list of feature requests I’m not so sure I have a ton to add at the outset. But here are some things I’d like to see added “long term” (and may even take the time to help you with should I get a few free moments):

1. Export to vCard
You can setup a permalink per contact (an address card if you will) then just push the URL of said card to Technorati’s Contact Service (eg. my vCard).

2. Option to show and/or link to maps service.
Typically a link would be created to open the current address in Google/Yahoo! Maps or Mapquest. However now that Google Maps can be embedded easily I think it’d be a nice addition.

3. iPhone version
Perhaps this is in your plans with the ‘mobile version’ you mentioned. The iPhone could easily navigate the current layout (since it has a full version of mobile Safari running Webkit) – but creating a simple look up and entry point for this application for the iPhone would be killer. I could see companies or family sharing a contacts database this way.

4. hAtom for the hell of it?
The main reason I think it’d be cool to add hAtom is so that coworkers or family members could subscribe to changes found in the database. If someone’s number is changed and/or a new contact is added to the database by one of the applications users – all other users would be notified via a feed.

5. Data import / export / share.
Obviously having some way to import my current address book would be killer. Also, exporting for backup or moving to another platform (or just into my address book) would be killer too. Exporting into vCard per card is ok but if we could have one big vCard with all contacts that’d be neat). This could be done pretty easily with a large list of all contacts on a single sheet marked up with hCard. Though that probably wouldn’t scale too hot.

Sharing though – is something I think would be really neat. It’d be neat to create a community around this project and allow people to share their contact information through this system automatically importing anyone that shares their information into a new “company” called “shared contacts”. Quick and easy way to get in contact with other people that use this app. Just a thought.

6. AIM / Skype contact information
I suppose support for Yahoo!, MSN, Jabber, Gmail, etc would be a plus. But for me AIM and Skype information is crucial.

This isn’t all – I will have more. Now you have wanting to help you out!!

I’m leaving comments off on this post because all discussion surrounding this project should be done on his site.

Kyle is doubting the usefulness of Microformats, and is also saying that he thinks the learning curve is too hard because of the documentation making things “too hard”. First I’ll address his comments on the documentation being much too difficult to follow:

“Maybe it’s just me — but I feel like the microformats crew are actively trying to make this an elitest club. I’m not very stupid (I don’t think) but when I first started researching microformats it took me ages to really understand it. It turned out to be dead simple.

You can see the documentation (featured to the right) is quite brief for simple formats like hCard. Wait a second… are you serious? This page is reeee-diculously (and needlessly) long and really needs to be cleaned up. It’s like a giant newbie-scaring-machine. hCard is dead simple to implement; a couple of paragraphs should suffice with two or three examples.”

I could not agree more with Kyle on this. The documentation for Microformats, in reality, is all spec information. There is a definitive need for someone with any type of documentation experience to get on the Microformats Wiki and really make some “Microformats for Dummies” type of documentation.

Someone on Kyle’s comments suggested just getting Jeremy Keith to spear-head the effort. Well, Jeremy is already a microformats “evangelist”, but I can see their point. He has the ability to make things that seem difficult, dead simple. Perhaps he could take some time to edit the heck out of the wiki and/or just add a series of pages explaining each Microformat in human language.

Onto Kyle’s other gripe; the usefulness of Microformats. I disagree with Kyle on this point. Microformats can be, will be, and already are extremely useful. I feel a little weird saying this since I have yet to really take full advantage of Microformats on my site here – but it is definitely in my plans. Kyle didn’t really expound on his reasons why he thinks Microformats are not useful until one of the very last comments that he wrote (he doesn’t have permalinks on his comments so I will copy it here):

“But… again, you seem to have proved my own point with “We haven’t figure out how exactly that will help us” — that’s my entire point. I’ve been following microformats since Tantek was talking about them years ago. An yeah, Tantek is a cool dude… but is it enough of a reason to use them?

I honestly haven’t found it.

I use web standards because it helps me work faster produce more maintainable code and standardize my practices. I can’t say the same for microformats. The best I could say is: “I use microformats so that the extreme minority of my browsers, who have an extension installed, who are looking for specific metadata, who have scripts installed to interact with their other data management applications can more easily add me to their address book.”

Oh, and for those pushing hAtom… the last thing we need in this world is more syndication formats ”

His argument here is really way off. When he says “we haven’t found ways” he really means himself. I think if you ask the folks at Technorati, and the people that have invested millions of dollars into them, they’d disagree with Kyle too. Microformats is just really starting to take off (if people do not use them, they are indeed useless but as more people use them, companies like Technorati can really build useful tools). There is no one definite useage for each Microformat, however each have their own implementation. The biggest advantage I see? One content delivery system for almost any type of data. I don’t need to create a vCard for my about page, I just need to add a few classes to the information that is already there. This brings me to his second point that falls short.

His argument that “…and for those pushing hAtom… the last thing we need in this world is more syndication formats”. Perhaps he hasn’t delved into hAtom much, but it isn’t another syndication format, it literally takes the place of Atom (which is becoming increasingly popular and is starting to become the syndication format of choice of some of the larger companies that have tons of data to syndicate [ see Nail Kennedy's article about feed syndication formats and their usage]). Also something to remember is the hAtom is currently in draft format, but imagine if if you had a blog and you didn’t need to serve an HTML version, RSS 0.92, RSS 2, and Atom version of your site. You could just serve the HTML version and all of the data you wish to syndicate – to different applications and services, could be parsed from that single delivery system. This is the biggest advantage of Microformats in my opinion.

The documentation does need a serious look, and update, to make it a much less steep learning curve. Broader usage will come of that, and in turn more uses will reveal themselves from a growing user base. I suppose Kyle’s post really cuts right down to the root of the Microformats problem – explain them better, and they’ll be used.

[tags]microformats, kyle neath, tantek Çelik, jeremy keith, hcard, hatom, rss, atom, feeds, syndication, technorati, html[/tags]
[slug]re-microformats-useful[/slug]

Today, we’re going to be learning how to format our comments, for WordPress, to work within the hCard spec. If you are unaware what microformats are, what hCard is, or why you might consider doing this on your site, please take a few minutes to read the microformats site.

As a side note: Even if you do not see yourself trying to directly benefit from using hCard in your comments, others will. Adding hCard syntax to your existing comments on WordPress is painless, and should not effect your layout at all. So do it anyway!

Current WordPress comment markup

Obviously, this markup depends on the theme you are using, but I’m going to show you the most common example, and you can hopefully adapt it to your current theme.

The following is the markup found in Michael Heilemann and Chris J. Davis’Kubrick, which comes pre-installed with every copy of WordPress and is, by default, chosen as your theme. This theme has been customized thousands of times, and so most of you out there should be familiar with this markup.

<li class="<?php echo $oddcomment; ?>" id="comment-<?php comment_ID() ?>">
	<cite><?php comment_author_link() ?></cite> Says:
	<?php if ($comment->comment_approved == '0') : ?>
	<em>Your comment is awaiting moderation.</em>
	<?php endif; ?>
	<br />

	<small class="commentmetadata">
		<a href="#comment-<?php comment_ID() ?>" title=""><?php comment_date('F jS, Y') ?> at <?php comment_time() ?></a> <?php edit_comment_link('e','',''); ?>
	</small>

	<?php comment_text() ?>

</li>

This markup is replicated, by WordPress, for every comment you have on each post. So, how do we make this hCard compatible?

There are a few essential elements to a hCard. The first, is marking up where the actual hCard is. In this case, we’re going to use the cite tag since that is where we have the commentor’s first name, last name, and url to their website. The second essential element would be the annotation of the commentor’s formatted name. To do this, we need to add 3 class names to your comments.

• vcard: This signifies the beginning of an hCard
• fn: This signifies the formatted name (or the way that the user would like their name shown).
• url: The home url for the commentor.

There has been some discussions in the world of microformats recently about being able to uniquely target single hCards on a page with multiple hCards, hence I am also going to add an ID to each hCard, so that if something takes off in this area, your comments will already be compatible. So, below is the code that you may use inside of Kubrick v1.5 for your commentor’s information to be marked up as hCards.

<li class="<?php echo $oddcomment; ?>" id="comment-<?php comment_ID() ?>">
			<cite id="vcard-<?php comment_ID() ?>" class="vcard"><a class="url fn" href="<?php comment_author_url(); ?>"><?php comment_author(); ?></a></cite> Says:
			<?php if ($comment->comment_approved == '0') : ?>
			<em>Your comment is awaiting moderation.</em>
			<?php endif; ?>
			<br />

			<small class="commentmetadata"><a href="#comment-<?php comment_ID() ?>" title=""><?php comment_date('F jS, Y') ?> at <?php comment_time() ?></a> <?php edit_comment_link('e','',''); ?></small>

			<?php comment_text() ?>

		</li>

It really is just that easy. Again, adding these few classes should not effect your layout, and can be installed painlessly into your site, for your benefit and ours.

Digg this article to help others find it.

[tags]wordpress, kubrick, microformats, hcard, xhtml, semantics[/tags]