Microformats Recycle

As Tantek and I were working the other night at Maxfields, we came up with an an analogy for descibing the microformats principles.

Just to review, here are the principles we use for developing microformats:

  • solve a specific problem
  • start as simple as possible
  • design for humans first, machines second
  • reuse building blocks from widely adopted standards
  • modularity / embeddability
  • enable and encourage decentralized and distributed development, content, services

We noticed that the principles tend to follow the .

Here’s a possible breakdown we came up with:

  • Reduce

    • solve a specific problem
    • start as simple as possible

  • Reuse

    • design for humans first, machines second
    • reuse building blocks from widely adopted standards

  • Recycle

    • modularity / embeddability
    • enable and encourage decentralized and distributed development, content, services

When reducing, we try to attack a specific problem, make it as simple as possible and simplify the format until it seems too simple.

When reusing, we try to model solutions on existing human behaviors and reuse existing widely deploy standards, names and approaches.

When we’re recycling, we try to salvage portions of other standards and make use of implicit schemas (ie, patterns which have yet to be formalized).

So, it seems that Microformats are really a conservation movement- conserving time, effort, and intellectual capital.

Tags

8 Responses to “Microformats Recycle”

  1. scott :

    Can you expand on this notion of designing for humans first? Which humans are you referring too? It is not clear to me why anyone but developers would care about the design of microformats. How do you go about deriving usability tests for these designs to verify that they are appropriate for human consumption?

    September 23rd, 2005 at 10:46 am

  2. Joe Reger :

    Hi Ryan! Thanks for putting this up. I’ve made some comments on my blog where I try to compare reger.com’s microcontent meritocracy to the concepts you have here:
    http://www.joereger.com/entry-logid7-eventid4548.log

    Please don’t hesitate to let me know if I’m off base.

    Best,

    Joe

    September 27th, 2005 at 11:07 am

  3. Ryan :

    scott-

    Can you expand on this notion of designing for humans first? Which humans are you referring too?

    Humans who have to grok the formats- designers, programmers and writers- people who, for the most part already understand HTML.

    It is not clear to me why anyone but developers would care about the design of microformats.

    I think you’re poking at something important here- you’re right, its likely that only developers will care about the design of microformats. But, you have to remember that these people are critical path to getting microformats published.

    A target audience for us are web designers. They tend to be targeted for several reasons- (1) they understand the process of semantic XHTML, (2) we can ease their workload by providing preexisting semantics, (3) they are often critical path to getting adoption.

    How do you go about deriving usability tests for these designs to verify that they are appropriate for human consumption?

    Before I answer your question, I have an adide to make- we’re actually optimizing for publishers, not consumers. So, our “usablity tests” would be for publishers/designers, not consumers.

    When trying to judge how usable a microformat is, our approach is generally pretty informal- we disuss it with domain experts, designers, markup-geeks and we also try to pitch the ideas to people we think would be hard to convince (ie, very opinionated and picky :D). In this process, we can usually come up with a good idea of how the microformat will be accepted.

    Also, we explicitly try to model microformats off of patterns we see emerging in the wild, so, in a way, we’re doing usablity that way.

    Thanks for the good questions, Scott. Let me know if there’s anything else (see this for all our discussion channels).

    September 27th, 2005 at 12:35 pm

  4. scott :

    Ryan-

    Humans who have to grok the formats- designers, programmers and writers- people who, for the most part already understand HTML.

    I’ll call this person a content engineer because I know some and this is what they call themselves. I don’t see designers or writers falling into this category though. A content engineer is responsible for implementing the UI design and supporting the content requirements using HTML/XHTML, CSS, DOM, Javascript and tools like XSLT. And they gotta know all the different browser incompatibilities and deal with those. Just when things were starting to get simpler, maybe even manageable, here comes AJAX which needs to be stirred into the mix. I am rooting for AJAX but I do understand that nothing comes for free.

    I think you’re poking at something important here- you’re right, its likely that only developers will care about the design of microformats. But, you have to remember that these people are critical path to getting microformats published.

    I view content engineers as developers. I think any approach should take into consideration the benefit of reusable design patterns and how tools can best take advantage of such patterns. Content engineers should know this better than anyone. I take it that the designers and writers are responsible for defining the semantics. I would ask the designers and writers what kind of tools they would like and what minimal functionality they need to accomplish this task. Let these answers be your guide to the data structures that need to be built. I also am concerned that your suggested approach could easily drift towards anarchy or get hijacked by the powers that be.
    Common infrastructure is important. As are production processes. Otherwise, you cannot hope to impose a ceiling on complexity. As it is, I see your adoption strategy favoring the shallowest learning curve on a case by case basis. I would tend to think that such a trend would increase the complexity requirements of the other software components that interact with these disparate formats, resulting in a net loss.
    I am convinced that the increased complexity related to Web 2.0 enhancements to web applications, even simple ones that support personalization, will lead to a divide and conquer approach for their development. I don’t think Widgets or Gadgets will suffice. I am betting on Portlets and see alot of synchronicity between them and microformats so I will go ahead and add myself to your discussion channels. Thanks for your response.

    September 27th, 2005 at 6:22 pm

  5. Ryan :

    I’ll call this person a content engineer because I know some and this is what they call themselves.

    I wouldn’t call someone who doesn’t actively use math an ‘engineer.’

    September 29th, 2005 at 4:08 pm

  6. scott :

    Ryan-

    I wouldn’t call someone who doesn’t actively use math an ‘engineer.’

    You appear to have a very narrow view of what engineering is. I hope that is not indicative of a biased attitude or worse, ignorance. I call myself a software engineer and I don’t actively use math.

    September 30th, 2005 at 1:39 pm

  7. Ryan :

    Scott-
    My previous comment was a bit of hyperbole, but I hope you still see my point.

    September 30th, 2005 at 4:57 pm

  8. Meriblog: Meri Williams’ Weblog » Links VII :

    […] Reduce, Reuse, Recycle is a GREAT framework for explaining the microformats principles. I’ll definitely use it when next trying to explain the concept! […]

    November 21st, 2005 at 2:50 am