Mind / Matter
things that count
DN Logo

Click here to send an email. DN

What's Old with Chandler?

Chandler is Mitch Kapor's new PIM. Most of it seems to be rather a rehash of old ideas.

What is Chandler? Chandler is a Personal Information Manager. This is a piece of software that deals with a number of problems that relate to the management of personal information on computers.
"What's new with Chandler?" This is the way that the question is usually formulated and presented. But the succinct true answer to this question---particularly if you consider things like Spring(tm), Six Degrees(tm), Zoot(tm), and several other past and current software packages---is `Nothing', and that doesn't make for a very interesting discussion. So maybe if we spend some time considering why it is such old hat we will be able to learn something useful.
Open Source The one thing that truly seems to be new here is that this is one of the first PIM-oriented projects that is attempting to accomplish its objectives by using the process that has come to be known as Open Source.
Advantages: Open Source has a couple of advantages. First, it allows us to `see' what the code actually does. Second, we need not worry about someone else `being in control' of our code. We can always decide to manage it ourselves. The principal downside is that for any complex piece of code, it simply isn't practical to actually make much use of the fact that we have the code. Simply understanding it is a daunting task.
PIMs as Software PIMs manage personal information. The most common examples of this kind of information are such things as phone numbers and calendars of events. In particular situations, of coure, this can become somewhat more complex, and things like `contacts' and `to-do' lists might be in the domain of the software. One could even imagine situations where some financial information was kept in a PIM, although I don't know of any so far that has really attempted to do this.
What is `The Problem'? The `problem' associated with dealing with this kind of information is not necessarily easy to define.
Kapor's History Kapor has a historical record with respect to PIMs of Chandler's type. He spent some of the money he made with Lotus(tm) on developing Agenda(tm) a DOS-based piece of software that could loosely be called idea management---basically a PIM. It eventually lapsed into unsupported state, but still has a active, if small, community of users---most of whom claim that no more recent product has any superior characteristics.
The Group vs. The Individual It is worth distinguishing group and individual use. In general they are quite different. For example, individuals keep track of appointments in wildly different ways. Some people love to carry a fat Filofax(tm), brimming with forthcoming appointments. Others like a single little card representing each day. Some adore their Palm-Pilots, others love their WinCE machines, and hordes of others don't want to have anything to do with recording their appointments in some electronic medium. So predicting what individuals want is dangerous at best.

Added to this, organizations feel differently about the sanctitity of the appointment book. In some organizations, information about appointments is widely shared. In others, it is treated with more sanctity than state secrets. There's no right or wrong to these extremes. They just represent the wide differences between people, and are often the result of historical accident.

Individual Preceeds Group Kapor chooses to treat the `group' problem with high importance. I regard this as a mistake. My analysis would suggest that no group is likely to make much effective use of any particular technology unless that technology passes the test of being acceptable to a large number of the individuals that make up the group. Thus, I'd test any proposed scheme first for acceptability by individuals. And only put it into wider use if it first passes the test of acceptability for individual needs.
Implications of Individual Testing If this is correct, it has substantial implications. For example, there's little reason to worry about organizational deployment, sharing information on servers, etc. unless the technology is deemed to be acceptable by a large number of the members of the potential user community. We might still support a system even if it failed to gain wide acceptance, but it is unlikely that the volume of transactions that we would need to handle in such a case would tax any chosen form of delivery. This suggests that consideration of issues of information collection and dispersal at the outset of the project---before we have any firm evidence on any of these matters---is premature at best, and perhaps a smokescreen at worst.
Hiding the Data And regardless of the answers to the above, we have to consider the prospect that a fair number of the potential clients for a system might choose, for their own reasons, to hide data from the system rather than to turn it over for widespread use. Some people just don't like others knowing what they are doing, and want to keep tight control over the dispersal of information about their schedules. In some organizations, knowing something about someones schedule is an important measure of being `inside'. There are those who believe that the President's Chief of Staff may have more to do with what is actually accomplished in government than the President, largely because he controls the President's schedule.
The Data I am a little disappointed that so far I haven't seen any analysis from the Chandler people about the nature of the data that they are going to process. While I would expect the amount of data that it is necessary to process to vary quite widely from one organization to the next, nevertheless there ought to be some consistency and some notions of at least the order of magnitude of the information that we will be dealing with. Understanding orders of magnitude differences is an important part in getting a grip on a systems design problem, as solution methodologies may vary quite widely depending on whether the data is `substantial' or not.
Mumbo Jumbo In the published material about Chandler so far, there is some mumbo jumbo about `items' and `collections' etc. As far as I can see this is largely just `smoke' or hand waving, as so far not much detail has been developed---at least as far as printed material is concerned.
Volume Just to take one example, I seem to generate about a quarter of a million bytes of scheduling information each year. If I give myself weekends off, this reduces to just about 1000 bytes / workday. If it takes 50-100 bytes to describe a calendar `event', then this represents 10 - 20 events per day. That sounds like a fairly reasonable estimate to me.
Handling the Volume In the last department I ran, I had about 100 employees. If their schedules were anything like mine, I would expect to be able to handle all of the scheduling data for the department in a 25mb data file. While that is a substantial load, it is no serious amount that would require any `special methods' or elaborate handling. So at that volume, no particularly elaborate technology would be called for.
Storing the Data: Storing this magnitude of data presents no problem at all. At the current time bulk storage coses are approaching the $1 / Gigabyte level. This means that storing a substantial quantity of PIM data might cost a few pennies. Even in a large organization this doesn't amount to much.
Moving the Data: At these quantities moving data around also represents no problem. Passing a large quantity of information around in a net can be done with ease, so the small quantities represented by this kind of data present no problem at all.
Searching the Data: Similarly, at these magnitudes no special methods are necessary to search the data. The volume of data is small enough so that it can be searched by whatever means are most convenient for us. We don't need to devote any attention to the effeciency of storage or search structures because at these volumes costs are so inconsequential that they needn't concern us at all.
Summary: Handling the Volume The argument is straighforward. A small volume of information does not require any special handling. If we have huge quantities of data, then it may be very important to carefully consider how the information might be stored and manipulated. But at low volumes of information going to any such trouble would almost certainly cost us substantially more than any efficiency might make up.
Serving Data This argument extends to the question of how the data might be `served' to a community of users. Of course, given our discussion above, this requires two things. First, that the volume of information be signficicant enough that it matters. Second, it requires that we are going to establish some `group-wide' standards by which the information is going to be handled. So far we haven't found that either of these considerations obtain.
Selling the Project Kapor makes some effort to sell Chandler as an approach. Since he has more experience `selling' such software smoke than I do, it isn't worth my spending much time considering such strategic issues.
An Interface Problem? There is an assumption floating around that the reason that people have failed to use previous generations of PIM software must have something to do with the interface. As a result considerable effort now seems to be invested early in the project in trying to decide on the characteristics of an effective human interface. However, if what we are saying here is true, then this may well be largely a waste of time.
What's Wrong? That leaves us with the question of why previous generations of PIM software have failed to carve out an effective niche, and why we are pessimistic in this paper about them doing so with this iteration. There are many reasons, and we can start with what may be the most important, the cost effectiveness of this kind of software.
Little Gain Much Pain The core issue seems to me to be that there is very little to be gained by converting personal information into machine readable form. The principal gains seem to be that electronic form makes the information easily available at multiple sites, and that its storage costs are low. The principal losses are that our instincts about information in this form are not well honed, and this makes it easy for us to make bad mistakes about handling the information.

If we take these two aspects together we see that the prospects for gain are quite modest, while the prospects for loss may be substantial indeed.

Attractive Nusciance Another problem is that the kind of organization of data implicit in systems like Chandler can be an attractive nuiscance. When this is operating, we find that getting data into an organized system can easily become the goal, rather than a step on the path to the goal. We begin to develop an interest in keeping the data organized rather than with the salutary effects of doing so. We become a librarian interested in the neatness and tidiness of the books in the library rather than whether they are read or not.
No Real Problem We also suffer from the difficulty that no one is very clear about just what problem we expect to be solving with this technology. Most of the discussions just assume that there is a problem and then they proceed to develop some software that presumably somehow treats this unspecified problem.
Need more Time This illustrates a point. For most people the problem in their life is that they don't have enough time, not that they haven't organized the management of their time properly. It's easy to get confused about this. In many different domains we live with the illusion that substantial quantities of resource will be released if we only organize properly. While most of us can improve things a little with organization, unless you are doing things in some horribly ineffective manner, though, the amount of gain is likely to be quite modest.
The Sophisticated Phone Mitigating against the effectiveness of the PIM from the other side is the increasing capability of modern day phones. These days we rarely have to know phone numbers any longer. Our phone lists are effectively in our phones, and this means that we do not need to manage them much any more. So sophisticated phones are now doing things that we would formerly have had to handle through more sophisticated computer programs.
Structured Drives out Unstructured Another aspect of PIMs that is evidence of a problem comes to us from Herb Simon's observation that structured work drives out unstructured work. This perceptive observation comes from noticing that very often we invest our energy in unimportant structured tasks while we leave important, but unstructured, tasks undone. We are overly prone to work on converting what's in our In Basket into our Out Basket while much more difficult but important work waits undone.
People are Idiosyncratic Systems often fail to recognize just how different people can be.

© Copyright 2003 David Ness.
Last update: 2003-02-07 15:41:21 EST