- reuse building blocks from widely adopted standards
Recycle
- modularity / embeddability
- enable and encourage decentralized and distributed development, content, services
So I decided to use this to check Reger.com's approach to microformats. In a nutshell, we enable users to create their own microformats (we call them Log Types) via a simple drag-and-drop user interface and then we facilitate a marketplace of those microformats. A new user looking to track their jogging data, for example, may find twenty different jogging microformats to choose from. They choose the one that works best for them, or they create their own. It's very democratic, open and merit-based. The best microformats survive and thrive... the rest are happily used by their owners in obscurity, filling their needs exactly.
Ok, so this approach has been slapped around a bit by those in the microformat space. How does it stack up to the guiding principles of microformats? Let's take the principles one-by-one:
microformat principle: solve a specific problem
By giving users the freedom to create and customize their microformats we virtually guarantee that they solve a specific problem. Users aren't forced to use a microformat that doesn't quite do what they need. Because the barrier to microformat creation is low people only use formats that do what they need them to do.
microformat principle: start as simple as possible
Drag a few fields into your format. Log stuff for a while. Find new stuff you want to log, add it. No need to adopt a standards-body-approved format. Create one that does exactly what you need. Another concept that fulfills this "start as simple as possible" goal is the notion of microformat expansion that I haven't touched on much. One user owns a microformat. Others can use it (if the owner chooses to make it public). Those that use it can then extend the base fields with their own. They can add fields to track just that "little extra" that they need. Now, that "little extra" isn't involved in the social networking side of the microformat, but it allows them to track it. The key here is that they started simple with another users' format.
microformat principle: design for humans first, machines second
We first built the UI that allows users to drag-and-drop to create microformats. Users don't have to know about XML-this or Schema-that. Once we had that built we added the ability for users to upload an XML Schema file to create a microformat. Humans first, machines second. I think we pass.
microformat principle: reuse building blocks from widely adopted standards
We're somewhat agnostic on this one, but keep reading. You see, users can choose to reuse pieces from other widely-adopted standards, but we don't require it. We're the pen and paper... they're the authors. That said, we do allow the notion of starting with a popular microformat and then tweaking it for your own good. And on the publishing side we certainly use widely adopted standards. When a user creates a custom microformat we embed that in the widely-adopted RSS 2.0. We also publish it in the widely-adopted structured blogging (they have a ton going on despite a not-so-updated site). But, as you should note, there's a difference between the microformat itself and the publishing mechanism. We're moving more and more to a full XML Schema concept so we feel that we'll be more able to support any standard out there. I give us a passing but not perfect grade here.
microformat principle: modularity / embeddability
We've got some work to do on the modularity side of things. We'd like a user to be able to create a supermicroformat by combining many smaller microformats (one-click in a UI, of course). We'd also like to see more data portability between microformats. For example, move your Swimming Log data and Running Log data (now separate) into a single Triathlon Log format. Doing so requires some smart thinking on data transformation. Can you say XSLT? Our challenge is to do this and still adhere to the "humans first" ideal.
microformat principle: enable and encourage decentralized and distributed development, content, services
Boom! This is where we shine! Microformat power to the people. Everybody has their own take on what needs to be tracked in a particular vertical. Within each vertical are sub-groups: take the case of joggers. There are those who run marathons... they want to track things like endurance nutrition and heat avoidance. There are those who run 10K's... they want to track muscular strangth and VO2Max workouts. There are those who run to lose weight... they want to track run distance vs. weight loss. There are thousands of hobbies out there. And hundreds of sub-hobbies. There's simply no way to service all of these groups with a top-down approach. The people must be able to create their own formats and morph them, share them, publish them.
Once a user creates a microformat we then automatically create quantifiable search, rss embedding, graphs and apis for them. These common things that we do across all microformats enables the distributed services to prosper.
I'm glad Ryan put this idea up there. In fact, it encouraged me to continue comparing reger.com's microformat meroticracy to another page where they discuss what microformats are and are not:
a set of simple open data format standards that many are actively developing and implementing for more/better structured blogging and web microcontent publishing in general.
Ok. I'll accept that. In our concept a microformat is a type of data to log... a Log Type.
microformats are: design principles for formats
Ok.
microformats are: adapted to current behaviors and usage patterns
Bam! Exactly! People already have a behavior of blogging... logging in, creating content and publishing. We add the notion of adding extended data to track and publish. But it's still the same flow. And on the publish side we also open the doors to analysis, mining and integration.
microformats are: highly correlated with semantic XHTML, AKA the real world semantics, AKA lowercase semantic web, AKA lossless XHTML
Agree. Some of the distribution mechanisms.
microformats are: a set of simple open data format standards that many are actively developing and implementing for more/better structured blogging and web microcontent publishing in general.
We're open... when a user uses the UI to drag-and-drop create a microformat we publish that format via XML Schema. We nail the concept of "many actively developing" although we could do better to facilitate cooperation on a single Log Type.
microformats are: an evolutionary revolution
By giving people the ability to create their own microformats we model birth. By creating a marketplace for microformats we model the forces of survival-of-the-fittest.
Ok, now on to what microformats are not, from the same page:
microformats are not:
a new language
infinitely extensible and open-ended
an attempt to get everyone to change their behavior and rewrite their tools
a whole new approach that throws away what already works today
a panacea for all taxonomies, ontologies, and other such abstractions
defining the whole world, or even just boiling the ocean
any of the above
And let's take these one-by-one:
microformats are not: a new language
Agreed. People don't need to know any programming to create a microformat with reger.com. They simply need to be able to drag and drop.
microformats are not: infinitely extensible and open-ended
I agree at the single format level but disagree at the "whole system" level. Each microformat is set by the owner. They set the fields, constraints, etc. This is important so that others can build services on top of them. But one person's microformat is never the end of the story. In the "whole system" view people can be completely open-ended... they can extend until their drag-and-drop fingers get blisters. A few reasons why some don't want microformats to be infinitely extensible and open-ended: first, it allows discussions of microformats to get too far-reaching and nebulous... nothing gets accomplished. Second, it's hard to envision a Web 2.0 of intereconnected services when microformats are always changing. This is one of the big pushbacks to reger.com's microformat meritocracy approach. My answer is this: yes, if you're the Adidas shoe company you'll be staring down the barrell of 200 different jogging microformats. And you won't own any of them. But once there is a user base worthy of investment in value-add services there will also be a long tail phenomenon. One, two, maybe a handful of those 200 jogging microformats will cover the vast majority of log entries. You'll choose to support those top microformats. In doing so you'll encourage others to come on board to those microformats, strengthening them. This is no different than investing years in a jogging log microformat standards body... except that your customers are the ones that created the format... it's already been vetted and debugged in the community. Your investment in a meritocracy-built microformat is on more stable ground. Let me say that again: your investment in a meritocracy-built microformat is on more stable ground.
microformats are not: an attempt to get everyone to change their behavior and rewrite their tools
Well, this seems to be some public relations work. An attempt to assuage those who fear change. I don't know... if a better system comes along you're likely going to have to change your tool. I agree that the goal of microformats is not to force tool change, but it may cause such an effect.
microformats are not: a whole new approach that throws away what already works today
I agree on the tech level and on the human level. On the tech level we're talking about using rss, xhtml, xml, xsl, etc. These things work and do their job well. And on the human level people are already tracking data... we just need to give them tools that allow them to easily track that data. We're not trying to get anybody to change what they want to track.
microformats are not: a panacea for all taxonomies, ontologies, and other such abstractions
Again, I think the goal here is to help focus the discussion of microformats so that it doesn't get unweildy. If you're caught in a mindset that you have to have prior agreement on each microformat then this is a valid concern. But if you create an evolutionary meritocracy where microformats can evolve, then you don't care much whether people try to go big or keep it small. That said, I do agree that even with the reger.com-proposed microcontent meritocracy which encourages thousands upon thousands of microcontent formats we still don't completely solve the issue of taxonomies and ontologies. Much work needs to be done to create relationships between microformats. Maybe that's microformat meritocracy 3.0. Lots of tough issues here and format creation is not the whole solution.
microformats are not: defining the whole world, or even just boiling the ocean
Well, this is where I'll poke a bit. People, when given the right tools, can add structure to the whole world. Look at the World Wide Web. With simple publishing there is content related to almost anything on earth. With a robust Web 2.0 publishing tool like Reger.com at their disposal, I suspect that the people of planet earth will add structure to most of it. We can make this claim by focusing on enabling microformat creation, not on actually creating microformats ourselves. Microformat power to the people!
As always, I've likely missed a number of key points. Slap me around a bit! Post comments, blog it or email me... I truly enjoy and value your input!
CK from ck-blog.com Writes About dNeero