Tinker to Evers to Chance, Tripit to Dopplr to Facebook

A few months back I observed:

Tripit, meet Dopplr. Dopplr, Tripit. You two should really get to know one another.

Richard Akerman replied:

You can feed TripIt’s ical output into Dopplr, I hear (I haven’t tried it)

That remark should have rung a loud bell for me, but somehow it didn’t. Then, yesterday, in conversation with James Senior, the bell rang. We were talking about how many services publish and/or subscribe to iCalendar feeds, how few people know that, and how much latent capability is being left on the table. Paraphrasing James:

I’ll give you a perfect example. I use Tripit, it’s a wonderful service. You email it your travel itinerary, and it organizes all your information for you. But I’ve been frustrated not to be able to share that information with my friends on Facebook. I also use Dopplr, and Dopplr talks to Facebook, but Tripit doesn’t. Then I realized that Tripit publishes an iCalendar feed, and that Dopplr can subscribe to iCalendar feeds. So I made that connection, and now my Tripit events are showing up in Facebook.

Brilliant. Look:

How did I miss that? Me, of all people, Mr. Splice-Everything-To-Everything, Mr. Find-Unintended-Uses-Of-Software, Mr. Cosmic-Significance-Of-Pub-Sub, Mr. Champion-Of-The-Underutilized-iCalendar-Standard, Mr. Computational-Thinking?

Because wiring the web is still too abstract, too convoluted, and too non-obvious — even, sometimes, for me.

The phrase wiring the web comes from Ray Ozzie, by the way. At ETech in 2006, demoed a concept called Live Clipboard. From my InfoWorld writeup:

Subscribing to an RSS feed, for example, has never conformed to any familiar user-interface pattern. Soon copying and pasting RSS feeds will feel natural to everyone, and Ozzie hopes the copy/paste metaphor will also make advanced capabilities more accessible. Consider my LibraryLookup bookmarklet. Dragging it onto the browser’s toolbar isn’t something easily understood or explained. Using the clipboard as the wiring junction will make a lot more sense to most people.

The same metaphor can accommodate what I’ve called lightweight service composition and what Ozzie calls “wiring the Web.” He showed how RSS feeds acting as service end points can be pasted into apps to create dynamically updating views. Virtually anyone can master this Tinkertoy approach to self-serve mashups.

This was, and remains, a crucial insight. From now on, we are all going to be wiring the web in one way or another. And we’re going to need a conceptual frame in which to do that — ideally, a user-interface metaphor that’s already familiar. Maybe it’s as simple as copy/paste. Maybe it’s more like Yahoo! Pipes or Popfly blocks. Whatever it turns out to be, we need to invent and deploy a universal junction box for wiring the web.

13 Comments

    1. Yes that did sound interesting. I remember the announcement. Unfortunately I now get login needed pages or blank pages for the most of the links. That does not help promote it. It dampens my curiosity.

  1. i love this wiring the web idea, but i’m getting concerned about where the wires themselves are stored.

    what if your dopplr or tripit or yahoo pipes or whatever you are using goes away unexpectedly? this could break a lot of stuff you have built.

    it might take forever to restore things to a working state, particularly if you relied heavily on one service.

    here’s what i think might solve this problem:
    you log in to yahoo pipes and design a filter that takes feed A and creates feed B.

    rather than the filter being stored at yahoo, the pipes create a small object that you can add to your website (or wherever) that performs that functionality. all that is needed now is for feed A to continue to exist.

    now, yahoo pipes suddenly disappears, to be replaced by google hoses. you still have that one piece of functionality you created with the pipes, which still works since you didn’t store it at yahoo.

    this would give you time to switch to google hoses for new filters, while old filters continued to work (and might even be able to be imported into google hoses for future editing)

    so the filters get stored with your data — after all, you spent time creating them, so they are sort of a type of meta-data, right?

  2. d_2,
    Interesting point. People often compare the now defunct Microsoft Popfly to Yahoo Pipes but to me they were complimentary rather than comparable because of one fundamental difference – with Yahoo Pipes the “processing” happened in a Yahoo datacenter, with Popfly it happened on your client as an AJAX application.

    Now, even though Popfly has disappeared (or will do), anyone that built a Popfly mashup and “installed” it will continue to be able to use that mashup. This fits with your scenario of Yahoo Pipes disappearing.

    Of course, there were other problems that caused Popfly to fail but at its core it was an interesting idea which was wholly decentralised and that is an important facet. Shame really.

    -Jamie

  3. Consider Google Wave …

    In a wave you bring together a problem and some people. They can write about solutions and they can add gadgets and robots that help.

    A gadget is any useful snippet of the web.
    A robot is any useful software function.

    Specific sets of gadgets plus robots solve the problem and are then useful elsewhere, as parts and whole.

    Standards for wiring will emerge from hacks in the ecosystem of these component parts. The strategic move is shift to a standard frame for making modules.

    The web architecture we know is underconstrained. The solution is not interchange standards, but such an architectural shift.

  4. Some time ago I tried to get my CalConnect friends interested in developing a standardized icon for .ics files meaning ‘you can add this item/collection of items to your calendar’. They had a lot of more important work to do at the time. Now, it sounds like in addition to that idea, a standard icon is needed to show that there’s a calendar feed at a particular location _and_ possibly that there ought to be an easy-to-guess URL for a site’s main calendar feed (for example, http://timswebsite.com/calfeed.xml ?)

  5. > The web architecture we know is
    > underconstrained.
    > The solution is not interchange standards,
    > but such an architectural shift.

    I haven’t tried Google Wave yet. But I wonder if the way I’m using FriendFeed here — http://friendfeed.com/elmcity — points toward the architectural shift you envision.

    I’m working with people, namely curators for my project, and resources, namely calendar (ICS) feeds. Because I’m also using delicious to curate the ICS feeds, and because I’ve subscribed to the curatorial accounts on delicious from the elmcity room, there’s a webhook-like alert mechanism. When a curator finds and adds a new ICS feed, the room hears about it via an RSS feed.

    The relevant constraint here is: “produces, and/or consumes, feeds”.

    The “gadgets” are services that obey that constraint.

    The “robots” are services that aggregate/slice/recombine “gadgets”.

  6. > _and_ possibly that there ought
    > to be an easy-to-guess URL for a site’s
    > main calendar feed (for example,
    > http://timswebsite.com/calfeed.xml ?)

    Or, better, a discoverability hook analogous to:

    <link rel=”alternate” type=”application/rss+xml” title=”RSS 2.0″ href=”https://blog.jonudell.net/feed/” />

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s