Complex in What Way?

This issue of complexity is a difficult one. It's often subjective and like most "concepts" can mean very different things to different people in different concepts.

Complexity in Chandler

One the one hand, I agree with you. Chandler's design is very complex. There is a consistent theme of complexity in that "things" in Chandler aren't static. They can morph and change shape, to the point where they are unrecognizable as the thing you started with.

First there's Stamping

1. Notes can become emails.
2. Emails can become Emailed Tasks.
3. Tasks can be put on the Calendar
4. Calendar items can be emailed.

And so on and so forth.

Then there's our Virtuality

1. Generic Tag values (ie. San Francisco) can be assigned semantics: Location=San Francisco.
2. Both Tags and Attributes can be put into the sidebar and treated as Collections.
3. Collections are themselves just Tags or Attributes on their member items.

Now there's this morphing Task-Project thing

1. An item can start out as a Task
2. As this Task starts to spawn sub-tasks, Chandler recognizes it as a Project.

Complexity was the Best Route to Simple

On the one hand, yes, this all feels really complicated. On the other hand, I would make the argument that it's the simplest design we could come up with.

We believe that it is this very flexibility, this very ability to morph and change that keeps the design simple. Because while we can't change the users' need for complexity:

There really is a need to differentiate between:

• Projects, Tasks and Areas of responsibility
• Emails, Events and Invitations
• Tags, Attributes, and Collections

We can at least simplify the modeling so that the App starts out with very simple basic elements (like Lego blocks) that the user can then take and shape, combine and permute to build-in their own complexity in the ways they see fit.

This is an approach that is orthogonal to the one that is traditionally taken in software: which is to make objects in the app as concrete and "like the real-world" as possible. (ie. Folder metaphor)

There used to be hardware-physical world limitations that necessitated strict adherence to real-world metaphors (ie. documents can't live in more than 1 folder, just like the real world). But as those limitations fall by the way-side, I think it's time to re-examine the virtue of our real-world metaphors and where we should and shouldn't be applying them.

Both Outlook and Entourage have taken this "make it concrete" approach. Instead of having tasks that can become Projects with sub-tasks...They have both a Task Application and a Project Center.

Instead of a generic notion of a container of items that can either be a Tag-based container, an Attribute-based container and/or a Container that lives in your sidebar...They have separate notions of Folders, Attribute-based views, Category labels and Project views.

Instead of a generic notion of a container of items that can contain items of any Kind...They have separate types of Containers for every combination and permutation: Email IMAP or MAPI folders, Email POP folders, Email local folders, Task views, Calendar views, Notes, views, Journal views, Cross-kind Project views, Kind-specific Custom views, Cross-Kind Custom views, etc, etc....

The consequences of building with concrete

The elements are concrete, they don't change. But the sheer number of them and the subtle distinctions between them puts a heavy burden on the user to learn and understand:

1. What all the widgets and gizmos
2. What they do and don't do
3. Which one best fits the needs of my data

BEFORE they can decide which gizmo to use. Should I just make an email folder for this one email I want to file? Or should I use a category? Or maybe I should define a search view, because I might get more stuff like this later. Or maybe this will turn into a Project, so I should really use the Project Center.

The problem is simple. The user is offered too many choices at the wrong time. Even if they bothered to figure out what all the options were, how they differed from each other and what they're relative merits and demerits were, they still wouldn't know what to choose because they can't predict how their data is going to change and evolve.

Most people just ignore all these extra choices and use what they already know. But once in a while, what you already know breaks down so badly that you're willing to try anything new in the hopes that it will be better, but as soon as you try, you're bombarded with such an enormous amount of technology that they throw their hands up in despair.

Is there anything better?

But there is a clear need for all of these features, users request them...that's why Microsoft has decided to put all these things in their PIMs.

What's not clear is that they have the modeling right...Do all these things really need to be concrete, immutable things.

What's not clear is that they really are all different things. It's possible (and we believe this is right way to think about it), that a lot of the elements in PIM apps are really "phases" in the life cycle of a single thing.

So instead, we would rather a very "simple" UI with 2 very simple basic elements: Items and Groupings of Items and let the user "dress up" those 2 simple elements in any way they choose as their data progresses through it's life cycle.

Where did we get these ideas? Users

In truth, we didn't come up with this idea ourselves. Users are already doing this and we're simply following suit.

Users already try to treat their sidebar folders like Attribute or Tag-based folders. Status folders. Project folders.

On the flip side, if you look at Tag-based systems like Delicious, users are already trying to apply semantics to their tags by doing things like tagging items as: Project=Foo, Location=San Francisco, For=Dave.

So what Chandler wants to do is to react dynamically to these user actions. We want the system to be smart enough to say: Oh, you want to apply semantics to this Tag. Why don't I stop being a dumb tag and start being a semantically meaningful attribute instead.

Similarly, when a user starts to type up a list of sub-tasks on a Task, we want Chandler to be smart enough to say: Oh, looks like this task is really a Project. Why don't I stop being a dumb task and mark myself as a Project.

And we want this "smart" process to happen seamlessly, almost without the user knowing. As in we don't want Clippie to pop-up.

Complexity is subjective

I've always believed that complexity and it's evil twin simplicity are more complex than meets the eye. Mozart's music is complex, yet deceptively simple to the ear compared to some atonal 20th century music which may actually be structurally simpler. This is due in part to the skill of the composer. But it is mostly an artifact of our cultural familiarity with Mozart. We grok Mozart, because we're used to Mozart.

You just have to look at the hierarchies people end up with in their file systems or even just their email clients. There is so much metadata crammed in there, but it's locked and arguably lost in a dumb system.

So the problem isn't complexity. The problem is that software is rarely if ever adaptive enough to grow in complexity with the user to match the complexity of the user's life.* The generic folder in your folder hierarchy is plain and simple in the beginning and it stays plain and simple and dumb all the way to the end. So while over time, you stuff more and more data into that hierarchy, the hierarchy ignores it, incapable of expanding to accommodate the new information you're putting into the system.

*After all, life is complex and our data systems are supposed to help us manage our complex lives.

The folder you're treating as a "Status: To reply to" folder doesn't know it's a Status folder and so you'll never be able to truly treat it as such (ie. The items in the Status folder don't know that they have a Status of "To reply to". If you move any of those items to another folder, they lose there "To reply to-ness").

The generic, a-semantic folder is always generic and a-semantic. You try to encode semantics into it like: This is a Status folder of "Status: To reply to". This is a Project folder of "Project: Write-up proposal". But it's like talking to a brick wall, the system is impervious to the subtleties and nuances of the information you put into it. So, when the data is presented back to you (ie. when you look at the big mess of folders you've created), you can't differentiate between Status folders and Project folders without individually parsing the alpha-numeric string that is the name of each folder.

And herein lies the cognitive speed-bump. The system starts to feel more complex over time if it FAILS to adapt to the complexity the user is adding to it. If it fails to respond with a capacity to capture and present back to the user the information they're putting into it.

Metaphors from the real world versus Metaphors from our Brain

Another way to put it is:

While it's true that this Chandler world of mutable, evolving items and collections is NOT the experience people are used in the physical world. (Desks don't turn into Oatmeal.) This IS exactly what happens with ideas and concepts in our brains. (Ice cube, Ice Cube, Ice queen.) And computers are supposed to be brains, not file cabinets.