A couple of days ago, Scoble paid a visit to the OSAF office in San Francisco and did a video interview with Mimi Yin, the product designer for Chandler, and Katie Parlante, the General Manger of OSAF (and my boss). Of course, I heard about how the interview went, but I was curious to see how the interview would go. Robert and I have talked briefly about Chandler over the years, but not in any detail, and I wanted to know what he thought about what we have done so far. When someone says “I want it”, that’s generally a good indicator, and I was glad to hear that phrase pop out of Robert’s mouth. Also, he asked almost all the questions that I could have wanted him to ask, so if you watch the interview, you’ll get a pretty good idea about some of the most important ideas in Chandler. It should be no surprise that I want to expand/clarify some of the things in the interview, so here goes:

Where’s my Outlook?
If you watch the video, it’s clear that Chandler Desktop today is not very much like Outlook, in the sense that it is not an e-mail centric application. If you believed the Wired-induced hype about Chandler being an Outlook killer, you’re probably disappointed. How did this happen? When we sat down and looked at what people were using PIM’s for, how they worked, and what they needed the most support for, we discovered that there was a big need for supporting groups of people working together as opposed to individuals just managing their own information. That’s why you see an emphasis on sharing and collaborating. A bunch of the infrastructure that we built early on for supporting customized personal information is supporting what you see, so there’s still the capability for doing individual personal information management, but we haven’t focused on those capabilities. Developers take note.

Web-based Chandler
This came across unevenly in different parts of the interview, so I want to make this clear. Chandler Server/Cosmo, which powers our free Chandler Hub service, is a web based version of Chandler. It doesn’t yet have all the features of the desktop version, but we are getting there, and we plan to get all the way there. Not only that, the back end of Chandler Server can provide you with data in a variety of formats/protocols. We want to make sure that you can get data into and out of Chandler Server as easily as possible.

Edit-Update / Sharing (or turning e-mail into a Wiki)
In the interview, Robert latched onto the edit/update features of Chandler. These are still in a primitive state, but you can see the value of them already. He had a great summary of how it works – “you turn e-mail into a wiki”. Exactly. You can create and share a collection with any number of people, and they can all edit/update items in that collection and see each other’s changes, without groveling through endless e-mail reply chains. At one point in the interview, Mimi said something about e-mail being the hub of people’s usage. Truth of the matter is that e-mail is more like the glue that holds batches of information together. Collections of items with edit/update is a different kind of glue.

Plugins/APIs
Robert asked about a Chandler that could slurp data out of Facebook/Twitter/blogs/blog searches and manage all that stuff via the dashboard (the triaging workspace) and Chandler collections. This is a topic near and dear to my heart, and solving that problem is actually the biggest reason that I came to OSAF to work on Chandler. Personal Information Management is no longer about the tiny set of data types that Outlook typically manages. Today, most of my personal information (by volume) lives in the cloud, so any system that is going to manage that information must be integrated with the cloud.

If you look at the Plugins menu of Chandler Desktop, you will see hints at being able to do what Robert asked for. There are demo quality (read: proof of concept) plugins to yank data out of Amazon.com wishlists, EVDB/eventful.com calendars, RSS feeds, and Flickr. We had a plugin for grabbing your del.icio.us bookmarks, but it got way out of sync, but it wouldn’t be too much work to put it back. All these parcels turn their data into Chandler items, which can then be stuck into collections or managed via the dashboard.

On the server, we’re a bit further behind on data type extensibility. It’s possible (I mean it’s code, right?) but it’s going to be a bit more difficult to do because of the server environment. The server does provide good access to calendar data via a number of calendar protocols, including webcal, CalDAV, and Atom feeds. In addition, the AJAXY web UI talks to the rest of the server using Atom feeds and AtomPub, so in theory you could implement a different client by using those feeds and AtomPub. I am quite sure that we will be doing more work on data access API’s for Chandler Server in the months ahead. If you have ideas, suggestions, or code, come by the cosmo-dev mailing list or the cosmo IRC channel.

What’s Left to do?
If you watched the interview, you’ll know that there are a bunch of things that Robert asked about which are not there yet. This is not the 1.0 release of Chandler, and there’s plenty to do. At the same time, the desktop and server are done enough that people can use them and developers can get an idea of what we are trying to do and where we are trying to go. In the server project we’ve already had some good contributions from people outside of the OSAF staff (the hibernate based storage engine, and the minicalendar in the web UI). We’d (the desktop and server projects) love to see even more people get involved.

To keep up on Chandler happenings, visit the Chandler Project blog.