• 5 assumptions
• fallout of 5 assumptions

• Not all facets are created equal
• Different facet types map to different affordances

• Chandler as a system not just a tool
• 2 views of the same data: minute-to-minute decisions v. project planning

• Through our user research: we've identified 3 main facets: Kind, Project, Status
• The 3 facets of Kind, Project and Status need to be organized in the UI in such a way that users have the right affordances so that they
  • don't create extraneous sidebar collections just to see kind-specific views...and then when you schedul eyou have to pick through your long list of collections to just overlay calendars
  • how many people have an osaf folder in their email app?
  • how many people subsribe to osaf calendar?
  • how many people have home and work calendars?
  • how many people separate home and work emails accounts?
  • every project needs: mailbox, tasklist, calendar, resources and directories
  • we would probably use our calendars more if
    • it didn't all get munched up into 1 calender
    • it was so hard to get information into the calendar (stamping alleviatges this)
    • you had to double-file things to manage projects
  • workflow: you receive an email invitation to a meeting about project: foo
  • you tag it project: foo
  • now the email agenda is in your project foo folder and on your project foo calendar
  • you don't really want to manage 4 separate project: foo collections:
    • foo mail
    • foo tasks
    • foo calendar
  • users don't think of kind-based collections as collections

• • don't segregate your status-based collections so that you can't see a continuous story from done-through-now-to-later

• Kind and Project are the 2 most important facets for everyone
  • Kind is not just another facet
  • Project can be defined by many different attributes
  • Status / Timeframe needs to be the way to organize each project view
    • you need a continuous story
    • so you can see relative prioritization
    • assess overall progress on the project

Assumptions

1. We think it's important that users be able to put a single item into multiple collections
   • Ask for examples
2. We think it's important that users be able to see all the collections an item belongs to from the item (aka bi-directional references)
3. We want Chandler to look and feel like a standard PIM
4. We believe that users think in terms of projects, not applications or data types
5. Users should make decisions when they're ready to

What is the fallout of these assumptions?

• Assumption 1
• We think it's important that users be able to put a single collection into multiple collections
  • Ask for examples
  • Do Parent collections inherit all of the items in Children collections
  • Can collections be Children of multiple Parent collections?
  • If so, are the items in the Child collection also members of both Parent collections OR
  • Is the Child collection an intersection of the Parent collection and the Child collection?
• As a result, there's no such thing as a fixed hierarchy of collections
• Instead, Chandler is a faceted classification system
  • Digression: What is a faceted classification system?
  • Columns in your table view is a faceted system
  • iPod is a faceted system
  • Search is similar to a faceted system
  • You worry less about the structure of your organizational system. Instead you just describe your items and then find them later based on those descriptions.
  • Chandler provides a very loose organizational structure instead, just to ground you a little bit.

• Assumption 2
• Chandler collections are attribute-centric
• Attribute-centric collections need to have semantics: Why is this item a member of this group? Otherwise, you end up with a see of tags (ie. flickr or delicious)

• Assumption 3
• We need to have kind-based application areas: Mail client, Task manager, Calendar
• We need to have a sidebar where users can organize items into groups

• Assumption 4
• Sidebar groupings need to be cross-kind and therefore span all application areas

• Assumption 5
• Can't have 8 different flavors of collections: Local folders, IMAP folders, Public folders, Custom views, Kind-based views, Projects
• 10 different flavors of status: Read, Unread, Flagged, Different flavors of Flags, Done, Not Done, Past, Present, Future

Proposal

• Chander sidebar is comprised of 2 facets
  • Kind
  • Project

Why are Kind and Project the 2 most important facets?

An item can have an infinite number of facets (aka attributes). As a result, a set of items could be the result of a query with an infinite number of parameters. To create a pure faceted system whereby users can navigate the contents of their repository via any facet or combination of facets (ie. (from: jason X sent: yesterday) U (body: livewire X account: home X attachments: 4) would

1. take up a lot of screen real estate
2. be really confusing and overwhelming for most people who usually only navigate
   • 1 facet at a time (from: barb)
   • selecting from a relatively small pool of facets (ie. sidebar folders, from, to, subject, date, category)

Not all attributes are created equal...

There's actually a hierarchy of facets (oxymoronic as it may seem). The hope is that we can set up a relatively familiar-looking sidebar at the top level of the facet hierarchy, thereby reducing the number of facets the user needs to worry about from the get-go.

• Kind
• Projects or Areas of responsibility:
  • Who-based projects (ie. Someone you're managing)
  • Conceptual or Physical Area-based projects (ie. Accessibility)
  • Timeframe or Phase-based projects (ie. 0.6)

• Collections persist over a medium to long range of time
• The contents of the collection may increase over time, but rarely decreases

• This is why we don't consider status-based groupings to be collections (ie. Now, Done, Later), the contents of which change rather drastically over time and don't amount to an area of responsibility. Instead, they are a snapshot of time.
• Another way to evaluate whether something belongs in the sidebar or not as a Project is to ask whether it's useful for that collection to span across multiple Kinds. For example would someone ever keep a Now calendar v. a Later calendar? When you think about it, it makes no sense. You will traverse time on a single calendar, sometimes focusing on present events and other times looking into the future at Later events. However, Now and Later are two parts of a single calendar, not separate calendars altogether.

Why does it make the most sense to cross Kinds with Projects

• Most overlap with Kinds and Projects
• Each project needs a Mailbox for communications, Tasklist, Calendar, Resources, Media and Directory
• When users go into Actions modes, they want to be able to perform those actions across their projects

• Not all projects will have items of every Kind, but every project will have access to the same set of tools
• Not every project will be relevant to every Kind

Why are Kind-based groupings fundamentally different from other attribute-based Collections? After all, isn't Kind just another attribute of an item?

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 many attributes can become Kinds.

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. This is 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?

They represent Action modes:

• Communicating: I need to tell something to someone. I need to get information from someone.
• Task management
• Scheduling
• Resources: Sitting down to write a document or put together a presentation
• And then there is information that simply sits around for reference, which needs to be organized and catalogued: Media
• And information that is usually not organized very much, but is often searched in order to find a particular entry: Directories

Use cases

• Starting out with Kind aka action-mode
• 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
• Looking up a contact

• 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.)

---

Looking at alternatives

Why a traditional silo-based PIM doesn't meet our use cases

• Doesn't allow for cross-kind views
• If it does allow for cross-kind view (ie. Entourage's Project Center), it does it in a really clunky way by creating yet another silo to work in, maaking it very hard for users to add items from a particular silo (ie. Mail) to a cross-silo project.
• Disorienting because the sidebar and toolbar changes completely for each silo

Why a generic list of views doesn't meet our use cases

• If the thing in the sidebar is a view:
  • The semantics of the "things in the sidebar" are lost
  • What is a view? A project? application area? status?
• In a view-centric world, the contents of the view are simply another parameter of the view, equal to other parameters such asview layout, scrollbar position, item selection, etc.
• However, we believe that to the user, the semantically-rich "thing in the sidebar" is first and foremost the contents of the collection and that the view layout parameters are merely incidental settings that should be configured automatically by the application depending on the contents of the view.
• For example, if what I have in the sidebar is the Inbox, the Who column should display the From attribute, not the To attribute. This is not something users want to set manually for each "thing in the sidebar". These are settings the user will want Chandler to set automatically 90% of the time.

• If we don't give users clear semantics for what goes in the sidebar, we risk making things too generic and users won't understand how they should organize items into collections

Maxim: Simple and generic yet capable and specific enough to be useful

• If both Kind groups and Collections live in the sidebar, users will have to think about what they should put in the sidebar. Should they create a Kind group? or a cross-Kind collection?
• ie. Home calendar or just Home? Sometimes I just want to see the Home calendar, sometimes I want to manage all Home items together.
• How do we visualize the complex relationships between the Home collection and the Home calendar collection?
• Are kinds really a grouping? or are they just tools? ie. Imagine what they map to in the physical world: Notepad, Mailbox, Taskpad, Desktop calendar. A user has a home office and a work office. In both the home and work office, they have all 4 tools: Notepad, Mailbox, Taskpad and Desktop calendar. To the user Notepad isn't really a semantically meaningful grouping the way that Project Foo or Home and Work are.
  • Project: Foo answers the question: What is this item about?
  • Kind: Event answers the question: What is this item?
• Most applications conflate the two and present them as if they are the same thing. That's a legacy of the physical world where your Work Notepad and your Home Notepad are 2 physically discrete things and where it's not possible to separate Notepad-ness from the notions of Work and Home.
• However, in the virtual world, it IS possible to separate Kind-ness from Collection-ness and to treat them as orthogonal aspects of an item.

Sidebar and Stamping

• Because of stamping, a single item can belong to multiple Kind-collections. As a result, the faceted sidebar allows the same item to be added to a new Kind-collection while remaining in the same row-item in the sidebar.
• Otherwise, to look for the newly stamped item as a Task, the user would have to go to a different row item in the sidebar. The user doesn't think of stamping as the same thing as adding an item to a collection.