To pave or not to pave the cowpaths

In Eric Meyer’s SXSW talk on Emergent Semantics (slides, notes) he referred disparagingly to the design adage, “Don’t pave the cowpaths.” He compared it to the useful practice of seeing where people walk and building sidewalks to match.

But there’s an important distinction between paving the cowpaths and paving the footpaths: people aren’t cows. The cowpath metaphor comes from the common urban history in which rural cowpaths evolved into city streets. As anyone who has ever driven in a city that developed that way knows, the result is picturesque but unusable. The problem is that cows don’t want to go where people want to go, cows don’t navigate the way people navigate, and furthermore cows don’t have the form factor of the vehicles that people want to drive in cities. Paving paths made by people for the use of people is a very different proposition from paving the paths made by cows for use by cars.

This is mostly a quibble about metaphors, but it does have some implications for Meyer’s subject of implementing microformats in XHTML in order to build a “lower-case semantic web” from the bottom up. Once microformats have caught on, will they get us somewhere we still want to go? And more pointedly, does the microformat concept scale up to a system that is coherent and usable once there are a zillion of them?

(By the way, paving real-world footpaths is an idea to be used with care. There are many places where foot traffic completely obliterates the landscape, and if you paved them all you’d have nothing but a parking lot. The solution is to carefully study the footpaths, pave some of them, and plant hedges to protect the grass. Whether that metaphor can be applied to online technologies is an exercise left to the reader.)

5 thoughts on “To pave or not to pave the cowpaths

  1. Prentiss, the creation of “microformats” reminds me of the evolution of the Internet standards process maybe 10-15 years ago. Back then it was “microprotocols” to use a new word for it, small self-contained little efforts to improve some use of the net or to build incrementally on existing formats. The IETF was a quarterly forum for protocol builders to get together on neutral turf and co-opt each others good ideas in the process of making competing products.

    What the community is missing is this kind of neutral ground for geeking about the protocols in some non-vendor specific way, you saw some success for that in how ATOM got built, but there’s more to it that needs to happen to get more eyes on things as they are designed and more folks thinking through bigger picture implications.

    I’d love to see RFCs for a lot of these microformats with the rigor in description that level of scrutiny brings.

  2. According to Eric Meyer and Tantek Çelik’s representation of it at SXSW, the microformat movement is an intentional reaction to the standards process. One of them — Eric? — said that the standards process has gotten too unwieldy as the Internet has grown in importance, with too many big players for anybody to get anything done in a reasonable amount of time.

    With microformats the idea is: don’t propose it, just do it.

    I’m torn. I like the idea of lightweight innovations simple enough for anyone to do them. But I fear that the process of spontaneously formed commmunities around microformats won’t scale. Right now there are quite a few people experimenting with a handful of microformats, and aggregators of various sorts popping up to use them — will the communities still form when there are hundreds of microformats, or thousands? And without the communities, will there be anything to aggregate?

    I also fear “semantic drift”: what happens when you build a service based on a certain meaning for a microformat, and then people start to use it in some other way?

    Funny, this is starting to sound like the folksonomy discussion. What would be a cutesy term to link the two ideas? Folksattribute?

  3. As an outsider, my question is — how can you form a community around something that is micro? By definition (so near as I can tell), it is small and ad-hoc. Large-scale adoption takes the small part away, so you’re left with ad-hoc. But large-scale adoption means it has work every time (or almost every time), which also ruins the ad-hoc-edness of it. Practically a Catch-22, to me.

    Edward’s comments about IETF are instructional. We presume to believe that the internet as it exists today can replcae the quarterly meetings, and the RFCs can be replaced by these wikis that sprout up. Perhaps it can, but I haven’t seen it work that way yet. When you don’t have to look a man in the eye and tell him why you’re not following his standard (microformat), it makes it so much easier NOT to.

    Consider, too, that the goals of IETF were different from what we see today in standards development. VASTLY different. So much so, that I can barely fit these concepts into my head. OK, then…

  4. Scott, maybe “small” is an overloaded term. In the case of microformats I think they intend “small” to mean “simple”, not to imply “not widely used”. Of course, once something is widely used with no means of enforcing a standard, it is likely to mutate or grow and no longer be simple, either, so effectively you may end up in the same place.

    An addendum about cow paths and sidewalks: a term for the paths made by users is desire lines, as described by Peter Merholz in his “Metadata for the Masses” piece a few months back and an earlier one about desire lines at Berkeley.

  5. If you’re looking for work being done on microformats, check out microformats.org. We have a good deal of work being done on our wiki and mailing list.

    Also, I wouldn’t classify the microformats movement as entirely “don’t propose it, do it.” There is great value in proposing a new format before implementing it so that you can get input from parties who are interested in using it.

    “I’d love to see RFCs for a lot of these microformats with the rigor in description that level of scrutiny brings.”

    I think you’ll see that at microformats.org. We have rather formal proposals which are still readable. Some examples – hcard, hcalendar and hreview.

Leave a Reply