December 29, 2002
Making Design Decisions
[The text below is a draft of material to be included in the Chandler Community Wiki, which we hope to deploy next week. We're beginning to focus on the pragmatic aspects of the project. This is a taste.]
Making Design Decisions: Some Principles
This area [of the Wiki] is for discussing the principles which will guide decision-making about Chandler's design. This is not meant to be all-inclusive list, just a start. All of these principles are subject to comment, criticsm, and improvement. You may wish to propose and give reasons for your own.
The first set of principles have to do with making decisions about which features and capabilities need to get into earlier releases and why. It thus forms a partial rationale for scheduling the work to be done.
It's often easier to state a principle than to apply it, but you have to start somewhere.
1. Implementation must be sequenced
It's not a real project until commitments are made to defer some capabilities. Doing everything at once is not an option.
2. First, provide core functionality users expect
If a feature is in common use in today's PIM's, then it needs to have its equivalent in Chandler. In order for the product to be adopted, it must have the critical mass of features people expect.
3. Lead with Chandler as an application, not a platform
The Chandler project is intended first and foremost to deliver an application suitable for daily use to handle email, calendar, contacts, and tasks. We believe Chandler will embody components of great potential usefulness to many applications such as the repository and the view manager, so it is fair to think of Chandler as a platform also.
We are making a clear choice to lead with the application-oriented aspect of Chandler, rather than the platform-oriented aspect. We believe that application adoption will provide great leverage for the entire project
Moreover, we want to create an application we ourselves would like to use. No such application exists today and the felt need is urgent.
Understanding application requirements will help shape the platform to be more suitable. (I am indebted to Andy Hertzfeld for this observation.) An implication is that it would be useful for platform development to be working on a second application simultaneously.
We don't know if we will have the resources to work on a web client for Chandler at the same time as the PC version, but if we do it will help make Chandler a better platform.
We will do the best job we can to think through platform issues form the outset and embody them in our architecture, even if we have to defer implementation of some things necessary for Chandler as platform.
4. Begin with Chandler's PIM functions: email, calendar, contacts, tasks; add full knowledge management later
Accept for the moment, if you will, that email, calendar, contacts, and task management comprise the PIM aspect of Chandler. Then, think of Lotus Agenda and ECCO as examples of tools for ad hoc knowledge management with some PIM functionality.
We intend to develop the PIM aspect of Chandler first with sufficient fullness to enable it to be in daily use. Chandler as PIM will be built with the rich semantics and flexible views found in the ad hoc KM tools, and there will certainly be a base set of knowledge management features, but the full development of Chandler as ad hoc KM will come after Chandler as PIM.
PIM's are universal productivity tools, while KM's are not (though many of us wish they were). As in the principle of "Chandler as application first" the adoption of Chandler as PIM first will provide leverage that will benefit the entire project.
No doubt having to wait longer for the complete delivery of Agenda-like and ECCO-like functionality is going to be disappointing for many of the loyal and faithful.
5. A few killer features are needed from the outset to make adoption worthwhile
Chandler must do a few things radically better. Candidates include: sharing; robust, transparent security; agent architecture; Agenda-like flexibility; [add your favorite here]
Killer feature ideas must be sufficiently well-developed as ideas to be willing to place bets on them. This is a key priority.
Posted by email@example.com at December 29, 2002 10:23 AM
Here here on the app approach. I vote for a robust repository that others can use - as a feature request. I'm not sure if that's a contradiction - as it sounds like a platform feature request, but we'd prefer something stable and useful, to the long term, waiting game.
So now "when did you say it would be available?"
Posted by: Marc Canter at December 29, 2002 09:54 PM
The point about a "few killer features" is crucial - One - a free form database would be much appreciated by today's overloaded office worker and by folks who are constantly on the move. I don't know what the other killer features the Chandler designers have in mind.
Another important point is to get these killer features right the first time, esp. in terms of performance.Users of open source applications have grown a bit tired of applications with performance issues or bad user interfaces. I installed Redhat 8.0 earlier this week and Nautilus crashed within a couple of hours for no apparent reason.Mind you , the gnome developers have spent an enormous amount of time and resources,improving this application. The patience of even die hard open source fans is stretched to the limit at times. Open Source applications rarely seem to have the reputation ,that their server side cousins have ( for quality). Considering the fact that you are using some technologies like wxPython and ZODB, which may not have been tested on this scale for desktop applications. It's absolutely crucial that responsiveness and performance are good right from the first general release.
In this respect it might be useful to compare each Chandler release with Ximian Evolution.The design philosophy is different in that, Chandler does not intend to be an Outlook clone. But Evolutions is already ahead of Outlook in terms of the ability to classify information in a flexible manner and indexing mailboxes(gigabytes literally) at blinding speeds. Combined with the vfolders feature, a lightning fast indexing engine, MS Exchange support it has already become popular. Chandler has to offer some compelling new features that allow for easy organization of information and retrieving it.
Posted by: S.Ramaswamy at December 30, 2002 06:11 AM
I am very interested in how Chandler will be developed. Will the code in development be open to the world? And if yes how people could contribute? Mitch, can you address the issue?
Posted by: Alex R. at December 30, 2002 11:39 AM
I'd like to see in the "item wrapper" the small hexagonal database that journalists apply to news stories. The "5 W's and an H" would be 1. Who (Author, Person(s) involved); 2. What (Subject, General Area of Knowledge); 3. When (Time, Date, Year); 4. Where (Physical Location); 5. Why (Intention, Goal, "Destination"); and 6. How (Method, Means, "Journey"). It's interesting that GPS uses a time signal to determine location ... addresses #s 3 & 4 simultaneously. Online Computer Library Center (oclc.org), home of Dewey Decimal, is working in this area.
Posted by: Robert Maxwell Case at December 31, 2002 01:22 PM
Wow. The more that I read about Chandler, the more that I want to get my hands on it and use it on a daily basis. I realize that a release is a ways out, but I want to use it now. :)
Posted by: milbertus at January 1, 2003 07:58 PM
Mitch it sounds interesting..will interested in seeing the interplaty between Chandler , Semantic Web, and the rest of the new xml technology..
For those that are folowing the conversation..
I just started switching my weblog from Manila to Roller Webloggin..
The new Url is:
I find in my own caes the informaiton overload is getting worse and worse.. and we need to move forward with using such areas a semantic web and etc to manage the load more effectively rather than continue in the same inefficient work and information flows.
Given the move towards semantic web what do you see uesable in terms of rdf and other semantic web formats as far as enabling PIM data to be more manageable and searchable?
Posted by: Fred Grott at January 2, 2003 11:42 AM
I didn't realise till today but there are similarities between Chandler and our own 'MyWorkplace' application, developed as a web based PIM for NHS staff - http://www.myworkplace.nhs.uk (userid/password demo1) Ours uses SQL server + DHTML so it's not as robust as Chandler.
Posted by: Ben Toth at January 2, 2003 11:47 PM
The one thing which nearly all organizations miss in developing an organization and deploying I.T. is the lack of business processes in place, i.e. defined and communicated. You state: "Understanding application requirements will help shape the platform to be more suitable. (I am indebted to Andy Hertzfeld for this observation.)" May I make another one regarding father up the design chain: understanding business processes will help determine application requirements. While Chandler can not possibly know all of an organization's business processes, the more flexible Chandler is in adapting itself to such endeavors it will increase the adoptability by internal change agents.
Don Evans, CEO of OMI, Inc has stated that what allowed them to win the 2000 Baldrige after a 10 year pursuit was defining the business proceses first to take care of their customers and then assigning responsibilities of each step in each process. In fact, when you walk into their main board room you see a large wall graphic depicting all 160+ processese beginning and then ending with the customer. Too often, organizations hire people to fill spots without much thought of defining processes to deliver to the customer.
Based on the above comments, there are only two process states in an organization: static and dynamic (i.e. hopefully changed to improve the current static process). A significant factor in the dyamic part is scalablity, whether a company of one or 20,000. Hopefully Chandler will not only address a business process perspective but also the scalability of an organization's informational growth.
I am looking forward to where this is headed.
Board of Directors
Colorado Performance Excellence
Posted by: Kevin Cullis at January 4, 2003 09:20 PM
I think that Personal Information Managers need to be much more open. For example, I am a Groove and Sharepoint user. I maintain many different calendars and would prefer if there were only one, that interacted with all of my shared applications. Also,I want to post emails in my shared applications so others on my team can comment, sometimes these emails are from me, sometimes I have to copy others into the shared app, or change them into pdfs.
I have too many applications with the same functionality, I want to simplify my life. Items described by XML tags that can shared with other apps would be great. I hope that Chandler will make some of this functionality available.
Posted by: Ralph Poole at January 5, 2003 06:32 PM
killer features for me:
1. Simplicity. The main issue I have with existing applications is actually the sheer complexity and number of options. I'm fine, because i'm a geek, but the billions of hours lost each day, week, and year because users have to 'unchoose' features they don't need when performing everyday actions is a tragedy. the 80/20 rule applies here, except it's the 97/3 rule.
Have you considered doing some serious instrumentation and analysis of usage of the existing applications in this area? which mozilla mail features do a sample of 1000 people actually use?
Can you come up with a way of making features visibly available as required, instead of cluttering the menus and intimidating the user?
(I've seen lots of poor implementations of this)
How many non-engineers have you got involved?
doesn't offer any dcent solutions, but it does characterise the problem quite well.
2. You're going to need really good migration tools. I have 5 years invested in mozilla, and I guess most outlook users are the same. I'm not going to switch unless I can bring my life (90,000 emails) with me.
3. your comment elsewhere about being able to trade filtering for search is spot on. the best extension to my existing setup would be a fast, decent, freetext search over my archive.
Posted by: Stefan Magdalinski at January 8, 2003 04:25 PM
Ok, Nit-picking time here.
You say "Chandler must do a few things radically better...transparent security..."
No such critter. If people don't understand, don't see, and do not deliberately use the security features in a product--even if those security features are on and functional by default, there is no security.
This is not to say that automatic encryption of all outbound mail is a bad thing--it adds to the noise and makes those who *need* to use encryption stand out less (or not stand out at all), but lets not kid ourselves--if you aren't conscious of what you're doing, you're not secure.
Posted by: Billy Oblivion at January 15, 2003 11:59 AM
I mildly disagree with Billy Oblivion. Security *can* be a "set and forget" situation, especially if you can configure multiple levels of security. This allows it to be an UNCONCIOUS effort that occupies your peripheral attention without distracting you.
A prime example of this *concept* (the implementation leaves much to be desired) is the security zones in MicroSoft Internet Explorer. There are a handful of "zones". The interface makes it clear at all times which zone you are in, but you can ignore it most of the time. You can customize the settings for each zone, and they all come with defaults. To me, this concept is *perfect* for "transparent security".
I *do* agree with Billy that there ARE times, however, that security needs to be front and center in your attention (like when you are setting up your security zones). At these times, the user must have access to ALL the information needed to make their security decisions; wizards with deep help files (that are actually *helpful*, unlike those from MicroSoft) can step even the least technical user through the decision making process.
Posted by: James Damour at January 16, 2003 02:12 PM
*This is _not_ the right place for this, but since Mitch only gives his email address by phone ...*
You'll want to update the URL for Dan Gillmor's blog: http://weblog.siliconvalley.com/column/dangillmor/
Posted by: hfx_ben at January 17, 2003 10:22 AM
would like some help in setting up a weblog or a fourm any help will be grateful thank you
Posted by: Gina at March 1, 2003 11:46 PM
I was going to tell you Im working on setting up my site and to have a fourm or a weblog would be super.. Just so we can chat and keep in touch post Ideas etc... thanks again..
Posted by: Gina at March 1, 2003 11:49 PM
Know Chandler from lots of places. I would like to use it and see how it works
Posted by: Sam at March 31, 2003 01:12 PM
I use chandler it rules
Posted by: carfax at June 24, 2003 02:52 PM
what have been done since your post on december02?
Posted by: tom at September 28, 2003 05:17 AM