-11620

035753

Commentary: Mitch Kapor's `What's New About Chandler'

	Title	Kapor	Ness
	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.	This seems to beg the question of whether PIMs solve a problem worth solving. So far the historical record doesn't make one optimistic.
	Data Representation	One truly distinguishing aspect of Chandler is how the data is represented. I'll give a simplified, user's-eye view of it.	Data representation in a problem of this scale may not be very important. I'd guess that it is more important here to `find' the problem than it is to figure out how to do something effectively, but that remains to be seen.
	Repository	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.	Somewhat new names, hoary ideas. Anyway, so far this seems to say that we have the `usual objects', although what `every contact' means isn't completely clear: each person who is a contact, or every instance of contact between the author and someone.
	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.	Nothing new here. And so far the description is completely unclear about what the `attributes' are, for example are DNess@Comcast.Net and 72400.1116@Compuserve.Com the same sender?---They are both me, although nothing in the signatures indicate that.
	First-class Data	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.	I use an ASCII-oriented editor to find all PIM-like information in my systems. This is important not only for access reasons but also because it allows information to be sensibly archived.
	Attachments	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.	Again not much new here. In the Drupelets Project we store information in much this kind of way.
	Multi-Place	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?"	This feature has been around, at least since ECCO. And that died on the vine.
	Attributes	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.	This is one nice characteristic of objects. One can invent attributes on-the-fly, and adding them rarely makes like more difficult for things that have already been done.
	Sharing	Finally, Chandler permits the sharing of any item or set of items in an extremely simple way, forming the basis of any-time collaboration.	How? Inquiring minds want to know.
	Universal Tool	In short, it's intended to be a universal tool for managing personal information and collaborating with others.	As are other tools (Six Degrees and Spring) come immediately to mind. Comparisons and contrasts with them would be useful.
	The Future	In future entries, I'll continue with what's distinctive about Chandler.	I hope so. So far there's nothing new here.
	Comment	This probably makes clear that I am not optimistic about attempts to deal with this problem. We have been trying for more than 30 years, and have had no durable success so far. I believe this is because it is not a useful problem to solve rather than that we simply have chosen the wrong ways to solve it. But time will tell. I happen to think that the time-honored means of dealing with this problem (pens and pencils, paper, schedule books, ...) handle it well enough so as to not leave a great deal of room for improvement. When this fact is coupled with the notion that there are substantial opportunities to worsen the situation, it seems clear that the path to adoption may be slow indeed.