December 15, 2002
What's New About Chandler
There's already been a lot of discussion about what's new, different, and cool about Chandler in this weblog and elsewhere. But for the sake of new readers and convenience, here's another pass.
One truly distinguishing aspect of Chandler is how the data is represented. I'll give a simplified, user's-eye view of it.
The fundamental way data is stored in Chandler is as a collection of items, also known as a repository. Every individual email is represented by an item, as is every meeting on a calendar, and every contact. Not only that but every attachment, document, and annotation is also an item. In short, each piece of content is represented as an item.
An item contains a set of elements, which can be thought of as a collection of attributes and their values as well as relationships to other items along with a "payload". For example, attributes of an email item would include its sender, the date sent, the subject, and other information which is represented in the header lines of the email itself. The "payload" is the body of the email. Similarly, attributes of a meeting item include its start time, end time, location, participants, etc. An item may have a relationship to another item, as in two emails which constitute part of a thread.
By treating items as the first-class elements of data, it is then possible for the user to obtain an integrated view of all the information in her universe. One simple feature which takes advantage of this is that when you use Chandler you will never have to look in multiple places to find what you're looking for. In today's world, you use your PIM to look for information sent by email, and you use a file manager to locate information contained in a document stored as a file. You may have to use other tools to find other types of information.
Chandler can show views of attachments organized by date, subject, or other attributes as easily as it can show a view of your inbox. You can also just as easily see all of the items relating to a particular subject or project, including the emails, meetings, contact information, and documents.
Another key feature in Chandler is that an item of information can be stored in more than one place. You're not forced to file it in one folder or another. It can be in both with no additional effort. It solves the problem of "I know that email is here somewhere, but which folder did I put it in?"
I might also mention that any item can have user-defined attributes, as well as the ones which are standard for its type. Unlike conventional email clients, whose capability to permit user-defined attributes is limited to a fixed choice of labels or list of categories, Chandler allows an unlimited elaboration of user-originated ways of classification.
Finally, Chandler permits the sharing of any item or set of items in an extremely simple way, forming the basis of any-time collaboration.
In short, it's intended to be a universal tool for managing personal information and collaborating with others.
In future entries, I'll continue with what's distinctive about Chandler.
Posted by email@example.com at December 15, 2002 03:09 PM
re. the "truly distinguishing aspect", the RDF-backed PKM I'm working on (Ideagraph) also uses the 'item' as its key, and virtually all your description here could apply to Ideagraph. With one big exception - I'm not going to be looking at email functionality in the near future, so your "aspect" remains unassailed ;-)
Conceptually we're really in the same space - so thanks for some ideas for explaining this stuff on my cover pages!
Posted by: Danny Ayers at December 15, 2002 03:59 PM
Um... Your description of this is more of less exactly how outlook treats and exposes it's data. This becomes more apparent when you create custom views and forms. What you are seem to be adding to the table is the idea of pulling in other things from the file system and treating it the same, but then this is similar to what winfs in Longhorn should provide. Be carful building such a general facility into a single application (or application set), IMHO it's more usfully pushed towards the shell/os.
Posted by: Ari Pernick at December 16, 2002 11:54 AM
Ari - why do recommend care in regard to building what you describe into an application? I agree it would be much more natural appearing at the shell/OS level (the kind of thing you'd expect from Xerox Parc), but the OSes of most people's machines is pretty much out of reach. If the same functionality can be layered on top at application level, where do you see a problem?
Posted by: Danny Ayers at December 16, 2002 01:03 PM
The item-centric view is used almost exactly as described in Scalara Enterprise (scalara.com), which I find very amusing because I was largely inspired by Lotus Agenda when designing that product. :-)
Posted by: John Stanforth at December 16, 2002 01:07 PM
Why does an item have both a payload and a set of attributes? Isn't the payload just an attribute too?
This would make items similar to files in NTFS and the BeOS file system: Collections of arbitrary attributes, possibly with relationships between them.
Posted by: Chris Hanson at December 16, 2002 11:12 PM
The same idea with items (=snips), payload (=content) and attributes (=labels) is used in SnipSnap for some time now (and was inspired by Vanilla). SnipSnap is a weblog, wiki and knowledge management tool. For example see http://snipsnap.org/space/Label
So it's hard to see the "truly distinguishing aspect" (we could store mail but don't. Right now we only store dates via iCal and contacts via vCard)
Posted by: Stephan Schmidt at December 17, 2002 07:33 AM
I'm going to ask a stupid question, just to make sure that it gets asked. You wrote, 'an item of information can be stored in more than one place. You're not forced to file it in one folder or another. It can be in both with no additional effort. It solves the problem of "I know that email is here somewhere, but which folder did I put it in?"' Is that item the *same* item, just referenced/linked in two places, or is it two *copies* of an item? If the latter, you really need to look into some means of maintaining state, or versioning, or something. Otherwise, as often happens with documents in a file system, you wind up with diverging information, and eventual confusion.
Posted by: Peter Herndon at December 18, 2002 11:16 AM
What exactly differentiates Chandler "items" from Lotus Notes "notes" or, more commonly, "documents"
Posted by: Joerg Michael at December 18, 2002 05:25 PM
This description matches very well what one could (can?) do in BeOS with all the plethora of user attributes on any file/directory. Since BeMail was storiring your contacts and mails in filesystem as well, you could also do the same for all your contact/mail data. On top of that you could define flexible views based on a collection of attributes and save them just as a folder. Did not have to store data in more than one place -- it would all be handled by the database vi attribites.
Posted by: Andrei Popov at December 23, 2002 01:40 AM
Quite a number of programs, including ones cited here, have an item-centric view. This is one aspect where Chandler differs. So as not to be even more repetitious, a number of the other aspects of differentiation are described on our web site (www.osafoundation.org) and in earlier posts to this weblog.
Posted by: Mitch Kapor at December 23, 2002 11:34 AM
As one who has never ceased to use Agenda, there not having appeared anything remotely as good, I'm excitedly curious about Chandler. Can you make a few comments about what aspects of Agenda are and are not incorporated in Chandler (apart from, obviously, the item-centric aspect)? Will it render Agenda completely obsolete at long last?
Posted by: Chris Case at December 26, 2002 04:38 AM
Over time, Chandler is intended to be a complete replacement for Agenda. In order to produce something in as timely a way as possible, Chandler's first release will likely focus more on having a sufficiency of basic email and calendar features, though. I appreciate your patience.
Posted by: Mitch Kapor at December 27, 2002 01:46 PM
I might as well weigh in and say we too also developed an 'item-centric' product - which was a hybrid TV station/web portal authoring environment for NOW.com.
We look forward to working with Chandler and your repository.
Posted by: Marc Canter at December 29, 2002 09:51 PM
After reading about Chandler in Linux Magazine, 2003 issue, page 6, I decided to investigate. I read everything on the website and am pleased to see that this new project appears to be the answer to many of my desires. I can say after using Outlook for many years that it does not come close to what I have in mind for a useful PIM.
My most useful tool over the years was a product called "Info Select" from Micro Logic Corporation. After using this product for many years I moved on but never found anything I felt replaced certain functions of that product. I do now feel that your Chandler project will fill that void and do much more. Thank you for your efforts and I eagerly await that first useable product even if it is not complete.
Posted by: Niles at January 1, 2003 02:03 PM
RE: PIM functionality
If you are still gathering functionality concepts for Chandler I would suggest looking at an older version (mid 1990's) of a product called InfoCentral. I thought it was one of the neatest organizing tools around. (Corel bought it and they either killed it or buried it in their *Perfect suite.)
The hierarchial organization structure was truly awe inspiring to the anal retentives among us.
Posted by: David Gili at February 1, 2003 10:26 AM
I am so excited to see such enthusiasm over Lotus Agenda -- I spent 5 years (1987 - 1992) in the development of it, and I was the software architect and development manager of it at the end, when Lotus finally killed it after starving the poor thing for so long. Chris Case, thanks for the kind words.
David Gili, one of the great things about Lotus Agenda was how it unified a hierarchical organization of categories with a free-form bunch of items and a tabular presentation. I agree that a hierarchy is the right organization for many things, and Chandler will be lacking if it doesn't offer it.
I am really looking forward to seeing this project move forward. Best of luck!
Posted by: Steve Zagieboylo at February 10, 2003 07:44 AM
first heard about Chandler at TED conference
I have been a PIM user for 12 years, I started
with Pac Rat... then to ECCO, Commence, ACT, and now Outlook, Pac Rat continues to be the best that PIM i have ever used.....
It was the interational database and simplistic nature of Pac Rat.... all databases were searchable with a 6 key system..
Posted by: Jay Platt at March 2, 2003 11:33 PM
A note on Data structure:
Im not sure about how you are planning to implement the categorization/indexing of items, but I would like to plead for the directed graph. Rather than a system of folders (email, happy thoughts , appts, whatever) which index the items, allow any item to serve as a folder and index a set of items.
im sure this will make the memory footprint bigger, but it has some advantages. for example in ecco (im afraid i never tried going through the crazy agenda disk image procedrue) while you can have one item in many folders, so that the item magically updates itself in each, you cannot paste an item to many points within outlines and then have them update itself within each. There doesn't seem to be a reason to make a folder different from an item, since we should all have as much memory as necessary to index the hell out of everything.
Posted by: Joseph Coffey at March 11, 2003 02:47 PM
Thanks for your detailed explanation. Really helps me to understand Chandler.
Posted by: Sam at March 31, 2003 01:18 PM
I was a devoted fan/user of Agenda and have spent a decade trying to find a suitable replacement, without success. (The programs I ahve tried include PackRat, AskSam, Act!, ECCO, IBM's PIM (whose name I forget) and InfoSelect (which I currently use).)
I'd be very interested in becoming a beta tester of any version(s) of Chandler.
Posted by: Eric Weissler at April 7, 2003 03:44 PM