Friday, April 28, 2006

EventMesh: An echo in time

I've worked in a variety of places, including NASA, various consulting firms, and three startups.

One constant element of my working experience is that the basic 'stuff' of business -- coordinating activities with other people -- is a phenomenal pain. It's like an overall frictional force on business execution. Kind of like swimming in syrup rather than water (although it seems that that particular metaphor is now busted; see the April 2004 article in Nature).

Since I never metaphor I didn't like, how about this one: scheduling activities, meetings, etc., involves an asymmetrical energy event. It's like poking an elephant with a pin. Small amount of energy out, a large amount of energy back. An example: I send a single email message to seven people, trying to schedule a product design review meeting. Three days and 47 email messages later, we've finally settled on a time to meet. A small amount of energy out, and a complete emailstrom of well-intended but largely ineffectual communication back.

In 1997, I built a Perl-based prototype of a web-based group scheduling service. I called this "EventMesh", thinking that if the Internet was about linking computers, and if the Web was about linking documents, then this new group scheduling thing I'd built was about linking events. An event, I figured, could be represented and exist even if it didn't have a precise start time.

In fact, the underlying idea in EventMesh was that it would be best if each event could collect constraints on when various people considered themselves available for it. This way, for some specific event, I could say that I'm available any afternoon next week, you could say that you're not available Monday or Friday, and this leaves us with the open window of the afternoons of Tuesday, Wednesday, and Thursday. Using such a process, we narrow down to an acceptable start time, rather than playing a calendar-based version of battleship: I ask, "How about Friday next week, at 2PM?", and you answer "Hah hah! No! Try again!". Unless you're desperate for a strange form of entertainment, calendrical battleship really isn't much fun.

This idea of per-event constraint collection and manipulation came from looking at the profound limitations of existing group scheduling systems. After building the EventMesh prototype, I wrote a short whitepaper on the problems that I saw with existing systems. If there's any interest, I'll take that old whitepaper and make it available via this blog.

So EventMesh was an implementation of the per-event constraint-collection idea. It sent SMTP-based email to people to request their per-event availability information, and used HTML over HTTP to display and collect it. The idea worked pretty well, and after demos to both Institutional Venture Partners and Mayfield, I managed to raise a Series A venture investment, and to create a core team. The company that we founded became known (and loved by many!) as Timedance. Timedance grew to the point where (according to independent evaluator PC Data), it was supporting over 1M monthly visitors.

When I next get a few minutes to add to this blog, I'll explain some of the lessons that I learned at Timedance, what worked and what didn't work in terms of user experience, and some general principles that I've discovered that apply when one tries to add "computational value" to communication flows that are inherently very personal and loosely structured.