[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.

In the past few weeks we've been engaged in the necessary but unglamorous process of building a development organization which fires on all cylinders. I'm excerpting an email I sent to our development group. It will come as no surprise to anyone who's been directly involved with a large-scale development project. Individual brilliance pales without an effective group dynamic. We have some catching up to do and are settings ourselves to that task

Folks,

In the past couple of weeks several of you have come to me with concerns and suggestions about improving our overall effectiveness as a development organization. I want to thank you for taking a risk and speaking up. I welcome your initiative and I'm learning from all of you.

One decision we've reached is to hire a development manager for the group. In the interim, we mustn't be waiting for a knight to ride in on a white horse. There are a number of things we can and should be doing now.

First, we should make sure everyone in the group is up to speed on what decisions have been reached so far . As Mitchell [Baker] has said, it's not a decision if it's not written down and communicated. We have some catching up to do.

In addition to working on an initial release of code, we need to be developing an overall architecture for Chandler we can all agree on, in order to enable subsequent work to be done in parallel, with designated individuals taking responsibility for specifics aspects of the architecture. This is appropriate given that we are already too large to work using the "Vulcan mind-meld" methodology. There needs to be a sequence of group sessions and periods of individual work to work on the architecture as a whole.

There may be other things we should have as top-level priorities as well and if so they need to be identified quickly.

I need your help to meet these goals. With your help, I'll sign up to direct the process.

The first thing I'd like to do is to get the group together to help formulate a more detailed and actionable plan. Everyone is welcome to come, or participate by phone if you can't come in person. I'm hoping we can have a critical mass of people this Monday... Please let me know your availability.

Mitch

Kevin Altis put it better than I could re: Outlook and Chandler in his weblog reprinted with permisision here.

What's New About Chandler?

Mitch Kapor made a post to try and better describe Chandler, partly in response to a lame WIRED article. My post below is in response to what Mitch had to say, but even more so to a point Ari Pernick makes in the comments section. So go read that stuff before continuing.

Ari makes a good point. Perhaps it might be more accurate to say that the object model and the way Outlook exposes its data seems cumbersome at best for the types of information management and sharing envisioned in Chandler. Despite its size, there are actually a lot of things you simply can't control or change with the Outlook object model. Not to mention that it is Windows OS centric. Even though my primary platform is Windows 2000, I want data formats, languages, tools, and standards that work on other platforms.

In addition, like most of the Office apps, Outlook has defaults that seem broken to a lot of people, designing new views, writing scripts to manipulate data, etc. is just not easy enough. Perhaps, because the default language to do scripting is VBA.

How many people have ever selected the Tools->Forms->Design a Form menu item? Chandler is probably going to have to duplicate that functionality, but Outlook users don't even know it exists or why they might care. Fewer people still have probably seen the Outlook object model docs or a book about the subject. There is a reason MS sells a pro version of Office and that people can make a living at building "enterprise apps" on top of Outlook/Office.

But the biggest problem with comparisons between Outlook and Chandler might be that Chandler is embracing a much larger set of goals. It will support data and document types that Outlook considers outside its scope. From the start Chandler is supposed to support group interactions which Outlook only has minor support for, unless of course, you have an Exchange server.

It may also be accurate to say that if you only want the out-of-the-box, single user, single machine, basic email, contacts, calendar, and tasks of Outlook or a similar app and that you are already happy with that app, then Chandler might have nothing to add because you would never use the extra features.

Of course Chandler is a platform, not just an app, so that too will take time for people to digest and accurately compare to Outlook/Office as a platform. Hopefully, people won't curse Mitch and the OSAF when they use Chandler the way they sometimes (okay, maybe often) curse Bill, Clippy, and MS if they use Outlook.

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.

I've made two edits to yesterday's entry. First, I've put a pointer to the actual Wired article on Chandler at the top of the entry. Second, I've inserted a note with the actual headline text, which was slightly different than what I recalled.

I also failed to mention yesterday the overall title of the piece is "The Outlook Killer?", which firmly bracketed the article in the David vs. Goliath trope I got agreement would not be used.

I've heard from Chris Anderson, the Editor of Wired, asking me to clarify my concern. He wants to know whether I object to the headline or to the fact that my list of Outlook complaints was used. The fact is, in my interview I chose my words carefully and did not speak in terms of complaints about Outlook.

As I remember my telephone interview with Joseph Portera, what I actually offered was a set of ways in which Chandler was going to be different, not only compared to Outlook but also on its own. So, rather than put Outlook down in terms of its negatives, I spoke strictly in terms of positives about Chandler. I can only imagine that the writer basically put words in my mouth to achieve the desired effect. I remember him saying, "OK, so tell me what it is about Chandler which is going to be new and different?"

That is, I said we were going to strive to have a straight-forward interface, wouldn't require a server, would be available on all PC platforms, would add many features to aid in the organization of email and other types of information, would have built-in security, would be easy to share information, etc.

Journalistic misrepresentation like this is fairly common. CNET also got it wrong, something I wrote about early on in this weblog. I used to get really angry when this happened. Lately, I feel more half-irritated, half-amused by life's foibles. Journalists taking the easy way out is a fact of life I'm not going to have much impact on.

In hindsight, I think it was naive of me to believe in the assurances I was given. . I'll bear it in mind in the future and pick my interview spots more carefully.

Finally, it's fortunate that a weblog is a wonderful, alternate, and complementary forum in which to speak directly, thus by-passing the intermediation of formal media.

See the article I'm making a fuss about here

Mr. Kapor,

Chris Anderson, our editor-in-chief, has asked me to contact you
regarding a short piece we'd like to run for next month about your
open-source Outlook killer.

We would like to know ten things you dislike about Outlook. This can include
anything (like the GUI, the complexity, lack of usability, etc).

[snip]

-Joseph Portera

Joseph,

I appreciate your interest in the offer of coverage. Candidly, I don't want to play into the meme that Chandler is an Outlook killer.

I especially don't want to be positioned as attacking Microsoft. It makes for good copy, but bad business. Sorry.

I would do something about 10 reasons why what we're doing is new, cool, and different. If that's of interest, please let me know.

Mitch

Mitch,

I understand your concerns. I didn't mean to paint it that way -- what we'd like is your take on what's why Chandler has the potential to be a better program/platform. How would it be better than Outlook?

How about ten ways/reasons Chandler is going to be different from Outlook?

[snip]

-Joseph

[As my email to Chris Anderson, editor of Wired, indicates, the piece didn't turn out to be quite what I expected.]

Chris,

...I raised a concern of great importance to me and received reassurance that Wired's coverage of the Chandler project wouldn't take an explicit anti-Microsoft slant. Imagine my surprise to see a headline title like "10 Things I Hate about Outlook" in the current issue [The actual title is "10 Things That Bug Kapor About Outlook" -MK.

I responded in good faith to your inquiry and could not have been clearer about ground rules, which were treat with total disrespect. This completely wrecks your credibility in my eyes, something I will keep in mind with regard to future coverage.

Mitch

I'm back, and I've pulled myself out of the pit of writer's block -- an occupational hazard of those who would weblog.

The OSAF staff has grown considerably in the past weeks. We now number eight paid and four volunteer staffers. We're about to update the people page on the web site, so see it for details. Welcome Chao Lam, Chandler Product Manager and serial entrepreneur; Lou Montulli, founding member of the Netscape engineering team and inventor of the browser cookie; and Aleks Totic, also a Netscape founding engineer.

One of the principal tasks has been to gain momentum in the development process itself. It's been a bit of a struggle, but our noses are to the grindstone to get initial code on the web site for developers to begin to look at. We're not going to make the self-imposed original Dec. 31, but we will make January. Not a great precedent to slip our first scheduling milestone. We'll have to do better.

Mitchell Baker and Chao Lin have made some big strides in getting our act together on community collaboration tools. Expect to see something rolled out in the coming week. We've also made considerable progress in the overall architecture. John Anderson will be posting architecture diagrams in the days and weeks to come.

Personally, I'm excited and chastened. We're no longer just talking about how great it's gonna be, but actually trying to make it be great. It's the meaty part -- I worry about biting off more than we can chew.