Tuesday, November 07, 2006

We launched!

This blog will not be updated anymore. For our TimeBridge blog go to http://www.timebridge.com/blog

See you there!

Friday, September 15, 2006

Bridging the gap

One of the basic premises behind TimeBridge is the ability to optimize activities, scheduling and calendaring while letting our users continue to work from their own familiar environment. Given that our target users are busy professionals, we have integrated our services into Outlook (other platforms will follow). In this light, our Outlook extensions are much more than a simple plug-in - as a whole they create a seamless bridge between Outlook’s desktop and the world of web services. As Jeremy Zawodny said a couple of months ago “Nobody has made it easy to bridge that gap” - I agree - turns out that this level of integration is one of the most daunting technical challenges we face today.

As we believe this is critical, we have spent a lot of engineering time working with and around the Outlook application which is fraught with pitfalls and limitations. Microsoft doesn’t help much, and I wonder if they’re missing a trick or playing one?

Friday, July 21, 2006

Federated Free/Busy

I just got back from the Open Group Conference in Miami, where I demo’d some of the things we’re working on here at TimeBridge. The demo was in response to the Open Group’s Federated Free/Busy Challenge, which was initiated by Boeing.

Boeing, like many companies, has a network of external partners which work closely with the Boeing employees. Each partner is on a different calendaring system, which makes scheduling a big pain since there is currently no easy way to see each others’ free/busy time. Not only is this a frustrating experience for employees, but it adds up to lots of wasted time.

For our part, TimeBridge put together a public free/busy server that allows users to publish their free/busy data, making accessible to other systems. In our demo, we used the TimeBridge Toolbar for Outlook to pull the free/busy time of users across organizations while scheduling a meeting. Using our service, it will be super easy to publish your free/busy data to a public server, where it will be available to the people you trust.

At TimeBridge, we believe that federated free/busy information is an important first step. It provides an initial rough cut at a possible meeting times. On its own, it is incomplete, but it becomes really powerful when combined with a system that allows organizers to propose multiple times, quickly collect preferences from attendees, and close on a time that works for everyone.

These are the kinds of things we’re working on at TimeBridge. If you’d like to see this in action, we’re currently looking for select beta testers to try out the latest version of our service. If you are interested, just email us at beta@timebridge.com.

Update: The press release is now live.

Director of Product Management

Tuesday, June 20, 2006

Impressions from CTC2006 / Boston

I am at the Collaborative Technology Conference (CTC 2006) in Boston (where the temprature is now ) – pretty interesting crowd in here. I was speaking on a panel organized by Michael Sampson previously one of the best collaboration bloggers out there www.shared-spaces.com [rip] and now with Foldera [good luck, Michael!])- and moderated by Larry Cannell from Ford titled “Calendaring: Time for an Update”.

Below are some of the main points made by the panelists, who, as a group, mostly focused on free/busy and other type of calendar sharing and organization.

Larry Cannell started by making the point that calendars manage our most important resource – time, and went on to argue that scheduling is still an art.

Next, I argued, in a slightly contrarian way, that free/busy as a scheduling tool is inherently flawed, because whether I am “free” or “busy” is, interestingly enough, probably the least important bit of information to my decision process. Instead, it is information contained in the proposal itself (who is asking? what is it about?) and the group dynamics (who else is going to be there?) that dominates a participant’s decision-making.

My main points were:
1. Calendars are not natural scheduling tool, because:
- The Propose/Accept/Reject model is flawed
- Free/busy access is inherently broken, in most situations
2. Any solution must:
- Start with the way people communicate (email, be polite, etc.)
- Capture group dynamics & support good citizenship
- Be easy & efficient

Consistent with my view that TimeBridge is a new way to interact with existing calendars, and there is no new need for “YAC” (“Yet Another Calendar” – as Fran from Airena said, if my notes are correct).

Later, Nathaniel Borenstein from IBM agreed that calendaring is a very hard problem, and suggested we start by asking the most basic questions:
- What is time? How can we structure it?
- How can one control the experience? With what tools?

Later, Nathaniel made the point that having standards, while very complex, will go a long way towards solving the problem, and pleaded the relevant organizations to take action. He made the point that IBM heard that the #1 (and 2, 3, 4 & 5) priority in terms of calendaring in large corporations is free/busy sharing.

Following that, John Robb of Zimbra described the commonly held view that calendars are disconnected islands of data. No sharing of free/busy of information, no ability to mesh-up, most are not shareable and lack universal access (such as from mobile devices). He basically argued (against IBM & Microsoft, I guess) that since the current off-line calendars were invented there were "few" advances in standards and technology. e.g. the World Wide Web emerged, XML was defined, Web 2.0 came into existence, search is omnipresent, Macs made a come back and open source is a respected way to get IT projects done.
What is coming? He mentioned initiating conference calls straight out of the calendars, integration with travel sites, overlay calendars with web analytics etc.

Gary Schwartz, representing Calconnect, provided an entertaining and candid overview of the history of standards and the current efforts underway.

The session ended with Fran Rabuck from Airena suggesting “if time is money, then your calendar is your wallet”.

I later added – if your calendar is your wallet, then TimeBridge is PayPal ;-)

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.

Wednesday, March 08, 2006

What Do You Think About Scheduling Tools?

I need to get my work done. I need to meet, and so I send out an email.
Stuff accumulates in my Inbox, but worse than that - stuff accumulates in my head. I become stressed and inefficient.
Here is how it works: I open my calendar. I search for available times. I start to type into my email "I can meet on thursday march 20th at 3 pm, or friday march 21st at 1 pm, or .....". Sometimes I'll block out these times in my calendar - but then forget to remove the proposed times after a final time is confirmed, and end up with zombies in my calendar. On other occasions, after all the responses are in, I am not available anymore. Back to square one.
Meanwhile, more stuff to think about, to worry about, to manage.

This is the current state of scheduling, and more essentially, of driving business forward. Modern electronic calendars are great and useful, but while good at calendaring (i.e. graphically representing temporal information), how useful are they as *scheduling* tools?