My earlier post about the costs of microformats led to some interesting comments that I’d like to respond to at the top level here.

In this comment, André Luís brings up his personal experience with ease of publishing hAtom, and also points out that it may have just been my publishing platform which gave me difficulty. He also mentions that i’ve overlooked added value for power users.

Shira believes that many of the problems I listed will go away with maturity of the microformats project, and are present because of its work-in-progress status.

Yes, it’s true that there will be some cases where publishing microformats will be a technically straightforward matter (especially with say, hAtom or hCard). I don’t wish to say that it’s always technically difficult, but what I’d really love to get across is that there are not only potential technical landmines, but also policy and relationship complications that can result from such a move. In the case of my publishing platform, which was, in my case, in-house written code, there were extreme difficulties in attempting to contort our markup to something that would follow microformat structure expectations in hCalendar and hCard. Additionally, publishing microformats resulted in ongoing maintenance, policy, and backwards-compatibility costs that were not considered at the get-go. No matter what method you use to reach out to developers or power users, you will need to pay the price to keep those relationships healthy, and your data strong. Microformats don’t make your job any easier, because you’ve just intermingled the methods you use to serve your general user base and your developer base. Haphazardly publishing microformats while keeping your developer API users happy is going to cause grief for some users, and will likely be interpreted as sloppy behavior.

I certainly have avoided discussing any of the potential value of publishing microformats, as the title of my previous post may let on. I find that nearly all of the information available solely discusses the benefits without spending due time on the costs. Furthermore, the benefits of microformats (as well as the potentially reduced technical costs that Shira refers to) are, from a pragmatic standpoint, hypothetical. As a writer, it’s my hope that by spreading more complete information, people can make more educated decisions, and I feel that what’s missing in the hype about microformats is the discussion of costs. So, I apologize if I don’t spend much time on the benefits, but I really feel you can get more of that information elsewhere, as long as you remember that those benefits are typically projected onto a vision of the future where microformats are omnipresent. I’ll just say that I don’t see many benefits that aren’t already available to publishers who conform to the existing standards that microformats are based on.

So, what is the likelihood of a world in which microformats are an accepted standard in XHTML publishing? What are the chances that your real, tangible costs will eventually be paid back by real, tangible benefits? How would you begin to evaluate or consider that likelihood?

Typically, standards succeed when there is a massive market need that has not yet been met. However, there already exist viable, well-known methods of serving the needs of both browser users and developers, so I don’t see why these large publishers should invest in serving the “power users” market in between those two, when these power users needs are so close to that of developers. The power users are often served by the standard data formats underlying microformats anyway. Also, the developers often take developer platforms and build products specifically targeted towards power users! So, I don’t see a large, unmet need. To me, it just seems like an product aimed at serving a niche user base that is already being served pretty well.

Also, there is the fundamental matter of data quality that drives the growth of a standard. If your data is questionable, nobody will want it. Or, they’ll collect it and throw it away. If your data is valuable, consumers will go to great lengths to take in and use as much as your policy allows. This natural magnetism that high-value publishers have predates microformats, and explains well why there are dominant platform APIs that don’t seem to play by the rules of standardization. Sure, there is a high technical barrier to entry, but typically, these producers invest heavily on data quality, policy, AND their developer relationships. Relationships between publishers and consumers around valuable data is what drives your average successful Web 2.0 platform, not whether the publishing format is standardized. So, if you want to really predict adoption of microformats, pay attention to the data quality of published microformat data.

If you want to consider the potential of momentum to bring about a microformat-based future, you’ll pay attention to the spread of adoption of microformats, and the hype surrounding them. As mentioned above, I would encourage you to also frame your perspective according to the data quality of data made available via microformats, but that requires a lot of time and energy to really evaluate. The vision here is pretty blurry; I think that’s just the nature of hype. It’s easy to get excited about something before the costs come into the picture.

Essentially, by publishing microformats now, you are becoming an early adopter. These standards are not mature, which Shira is essentially pointing out. The costs may one day be lower, but by getting into the game now, you are not only placing a bet that many others will follow, but also they are subsidizing the costs of publishing for latecomers. I don’t think that the current tangible costs outweighs the current tangible benefits plus the hypothetical benefits multiplied by the likelihood of them coming to pass. But don’t take my word for it. I’d just encourage you to at least make an educated decision, and consider all of the costs I listed in my previous post before taking the plunge.