It's not enough to just say that Chandler is a faceted system. Users tend to get lost in faceted systems. There's no grounding. No sense of "What are the most relevant facets" and "How do they relate to each other." Therefore, OOTB, Chandler must provide that sense of grounding in order to provide users with a coherent environment in which to organize their information.
(The following is a result of user research, interviews and sidebar data collected via OSAF dev list.)
There is a hierarchy of facets.
- Kind describes What a thing is
- Communications
- Tasks
- Calendar
- Resources
- Media
- Directories
- Project: is an area of responsibility generally centered around:
- A person or an entity: your manager or the people you manage, client
- A product area: IMAP
- A project phase: 0.6
- Status
- In the Chandler PIM world, status has to do with how Done you are with an item.
- In other contexts you might have different status attributes:
- Finance: Stock price ranges
- Weather forecoast: Time of day ranges
Why are Kind, Project and Status fundamentally different types of facets?
Kinds
Kind is what a thing
IS, not just another facet, aspect, characteristic of a thing.
Johannes is a human being is fundamentally different from Johannes has blue eyes or Johannes is German.
Another way to think about it is that Kind values are nouns, whereas values of all other attributes are adjectives. However, any attribute can have values expressed as a proper noun. Which means that any attribute can become a Kind.
Johannes is a German.
Cyan is a Blue.
As a result, you could elevate any attribute to become a Kind attribute.
Another difference between Kind attributes and all other attributes is that the Kind attribute value determines what other attributes an item may have. Otherwise known as the Kind schema.
A human being has height, weight, race, sex, age, hair color, eye color, birth date, favorite kind of cookie.
Therefore groupings of items based on the Kind attribute are also fundamentally different.
The question to answer is:
Why is Kind so important to people?
Content Kinds represent Modes of Actions to users
People
Do different kinds of things with different Kinds of items. Each Kind represents its own set of Actions. Traditionally, content types are associated with a particular application or software tool, which has a particular set of affordances and features. So users are used to making the connection between item Kind and a particular set of tools.
| Item Kind | Nature of item | Primary actions | Use cases |
| Personal communications | Generally items we author or that are addressed specifically to us. | Authoring | Too many to list |
| Tasks | Generally items we author or that are assigned specifically to us. Represent things we need to do. | Authoring, Organizing | Action items, Research, Chores, Errands |
| Calendar | Generally items we author or that are addressed specifically to us. | Authoring, Organizing (scheduling) | Reminders, Appointments, Meetings, Events |
| Resources | Generally items we author or (co-)authored by co-workers. More formal presentation of ideas and proposals. Longer than most communications and usually goes through multiple iterations. | Author, Store and Retrieval | Documents, Presentations, Specs |
| Media | Baked items that we don't really edit very much. They're not things that we author over a long period of time. They are not expressions of our thoughts and ideas. In that sense, they feel more "external" and we keep track of them as a list of references to outside things. | Organizing to either share with family and friends or to keep track of for yourself | Photos, Songs, Books, Movies |
| Directories | Information about people and organizations. Not edit very often. | Store and retrieval | Contacts, Restaurant directory, Inventories... |
Projects
- Projects are areas of responsibility.
- Generally speaking, when users create groupings of items (ie. email folders, calendars, file system folders) they're creating project-based groupings.
- Projects are usually defined by:
- A person or stakeholder: Your manager, or someone you're managing, client, etc...
- Product area: I'm using product in the widest sense possible: whatever it is you and/or your organization produces, creates, provides etc...
- Project phase
- Users need to be able to view Projects individually in order to Review, Assess and Plan.
- Projects can contain items across all 6 content Kinds: Communications, Tasks, Calendar, Resources, Media and Directory
- Projects need access to the affordances of all 6 content Kinds: Communicating, Doing things, Scheduling, Documentation and Presentations, Media resources and Reading lists, Contact information...
Status
- Status is a continuous spectrum that consists of a Beginning, Middle and End
- As a result, people should always be able to view items across all statuses in a single view, so they have access to the whole story.
- For example, when evaluating progress on a Project, users need to be able to see what's been Done, what's going on right Now and what's coming down the pipe Later.
- As a result, Status is a way of dividing up a grouping of items, but isn't a facet that defines a grouping.
The resulting design is:
- Project and Kind are orthogonal facets. Users can either start by selecting a Kind or viewing a Project
- Projects live in the sidebar and Kinds live in the toolbar simply because
- the vertical sidebar allows for more items
- the # of Kinds is fairly fixed and
- users are likely to have more projects than kinds
- Status is a way of dividing up any grouping of items, whether it's a Project-based grouping or a Kind-based grouping.
Use cases
A good way to think of the orthogonal relationship between Kinds and Projects is:
Each Project in the sidebar has a Mailbox, Tasklist, Calendar, File Cabinet, Media cabinet and Rolodex. However, sometimes you want to pick up all of your calendars across all of your projects to do some high level scheduling. Or maybe you want to just look at the tasklists across two projects that are tightly interdependent to do some strategic task management. The following use cases are broken down into 2 categories, the first are scenarios where the user has a particular thing they want to
Do, so they start out picking out a Kind or Action-mode. The second include scenarios where the user simply needs to deal with a certain area of their life, so they start out by focusing on a particular Project.
- 1. Starting out with Kind
- Schedule a single event or a series of events across several calendars (ie. planning a family vacation)
- Manage tasklists for two interdependent projects
- Put together a party photo album to send around to party guests
- Look up a contact or Create a mailing list group.
- 2. Starting out with a cross-kind collection aka lightweight project management
- Keeping on top of things minute-to-minute
- Planning a wedding
- Need to bring up all the stuff related to a particular person for a 1-on-1 meeting (Basically the people you meet with in regular 1-on-1s are probably important enough to you that you see them as a project in and of themselves.)