testimonials

From Microformats Wiki
Revision as of 21:25, 5 November 2008 by CmontRpase (talk | contribs) (calmonb)
Jump to navigation Jump to search

licavar

Testimonals

These are stories from the micformats-discuss mailing list, where users characterize why exactly they find microformats so useful and compelling.

Scott Rozic

I'm jazzed about microformats, and right now i just made an ultra-micro posting system with it, I've created a new blog that's deeply microformatted, and will be rolling microformats into 5 or so new applications by the end of this year! Still in the experimentation phase but lots can be done here to standardize the cross-web, cross-app experience for users and make life easier for app and site builders.

Liz Dunn

I wrote a little essay on my personal blog about why I like, nay, LOVE, microformats. The goal of this essay was to get my friends, who aren't super extra into web formats, excited about the possibilities of microformats. I'm not sure it worked, since one friend commented that she didn't think she was the audience for my blog anymore. But I'm not going to stop writing about microformats!

Kevin Lawver

My personal interest in microformats stems from my general laziness and love of conformity. I don't want to have to think about how to mark something up all the time. I think Microformats can go a long way towards standardizing how we mark up particular pieces of data... I work at a company that has a huge collection of developers spread all over the world. If I can tell all of them, "Hey, you should mark a review or search result or list of blog posts this way, and heres' the documentation," they'll be more likely to do that, and we'll have an easier time maintaining and "discovering" that content.

Ernest Prabhakar

Organization web page

I'm responsible for the website for an informal group at work. The HTML I inherited was a horrible mess, and painful to maintain. I realized that it was pretty much just a list of events, people, and resources. So, just to avoid having to think about HTML design, I turned the whole thing into a bunch of XOXO, hCards, and hEvents. Then, in order to make it look the way I wanted, I just added (or often, stole:-) appropriate style declarations.

Could I have done this without microformats? Actually, no. You might, but I couldn't. Microformat was the crutch to help me think intelligently about CSS. As a bonus, I can now use all these funky tools to extract vCards -- and show the entire site as a presentation. Cool!

Custom application format

One of my side projects is working on a program to display lyrics for sing-a-longs (i.e., church worship services). I was experimenting with a bunch of different XML schemas, but a) I wasn't sure I had it right, and b) there was no way I could imagine getting a lot of people to adopt it.

Then I discovered S5. I suddenly realized that XOXO was the perfect format for encoding lyrics (stanzas, lines, etc.). It is so obviously *right* that it is trivial to evangelize, rather than arguing over every last tag. It is flexible, so people can add their own metadata if needed, and socialize them informally rather than having to push them through a central standard (which I'd have to maintain, ugh). It is also non-intimidating, so people who know HTML but not XML (believe me, there's a lot of them) are comfortable adopting it.

Not bad. But wait, there's more! This also means:

  1. There's a trivial way to view every file (browser), even without my app
  2. Design can be done using CSS, meanings trivial to customize -- I don't need to provide a tool
  3. I can reuse the existing HTML viewing tools on my platform

At this point, I literally cannot imagine tackling any web site or application format problem withOUT leveraging existing microformats. It is the shortest route to success for the kinds of things *I* care about. Where getting an 80% solution out - now- is the most important thing. If you slice the 80/20 correctly, it is actually only the top 5% of customers who ever actually run into the tough edge cases. The long tail rarely cares -- certainly not enough to pay the added cost.

Its kinda like optimizing source code. Its better to write it first then optimize the hotspots, than try to pre-optimized what you *think* the problems will be.