Grand Unified Theory of Collections

In Chandler, there are three kinds of collections

1. Search results
2. Collections
3. Clusters

Search results

• Search results are ephemeral collections of content items brought together temporarily by a general text search or attribute based browse.
• Search results can be saved as Collections. Otherwise, they go away as soon as the user navigates to a different collection.

Collections

• Collections are persistent groupings of items. Collections and their member items are bound together by bi-directional references.
• Collections must have a name.
• 2 or more collections can have the same name.
• Collections cannot contain collections.
• Collections can be populated via explicit DnD or by a user-defined rule.

Collections and Rules
In the current world of folders, there are two ways for users to populate a folder with a rule. The first is the saved search. The second are user programmable actions most commonly used to filter mailing lists and Junk mail.

[SKETCH]

• SS: Attached to the folder.
• PA: Floats above the folder hierarchy moving items hither and thither.

• SS: Does not allow explicit DnD to add, remove, or delete items
• PA: Allow explicit DnD to add, remove, and delete items

• SS: Does not allow items that violate the rule to be members of the collection
• PA: Allows items that violate the rule to be members of the collection

The crucial difference between Saved Searches and Program Actions
Saved Searches, the search parameters function as the gate keeper of the folder, controlling all items that enter and leave the folder. The search parameters aren't just populating the folder, they are the folder. Hence the term, Saved Search.

Program Actions on the other hand are simply a way for users automate explicit DnD actions. They populate folders and do not have the final word on what may go in and what may come out of a folder.

Looking at these two paradigms, we thought to ourselves, why bother? Why not just have one kind of collections (one that can have rules) and if the user wants to DnD items in a way that violates the rule, let them, they know what they're doing.

[CHANDLER SKETCH]

True statements about Chandler collections with Rules

• Collections can have rules.
• Users can choose to allow items to be explicitly added, removed, or deleted from the collection in addition to the rule.
• Users can choose to have items that are explicitly added to a collection automatically labeled to satisfy the rule. (This only applies to label attributes such as Collection membership, Mark-up bar attributes, etc. It does not apply to intrinsic attributes such as Date created.)

• OOTB Collections
• Dashboard (the All view)
• Archive (optional)
• Trash
• Inbox
• Outbox

• Items cannot be removed from the Dashboard collection, only deleted.
• Items that have been Archived, Junked or Trashed cannot exist in other collections and do not show up in Search results unless the user is explicitly searching the Archive, Junk or Trash collections.
• However, Archived, Junked or Trashed items can be restored to their former collections if they are removed from Archive, Junk or Trash.
• Inbox is a record of all incoming items, regardless of transport protocal (Email, IM, record of verbal communication), where the user is listed in the To, CC, or BCC field.
• Outbox is a record of all outgoing items, regardless of transport, where the user is listed in the From or Sent by field.
• Some items will appear twice in both the Inbox and Outbox if the user sent the item to themselves.

Clusters (Proposal for name change from Ad-hoc collections)

• Clusters are a lightweight version of collections.
• Clusters are designed to address the need for item-to-item relationships
• Clusters are designed to allow people to relate items quickly without having to name or describe the relationship
• Clusters cannot be populated via a rule
• Clusters open up in place in the summary table view
• An item can be a member of more than one cluster
• Clusters and their member items are bound with bi-directional references

Decisions history
Clusters are primarily designed to replace the need for item-to-item relationships. Oftentimes, we want to relate items to each other:

• for reasons we can't or don't have the time to articulate.
• the relationships are oftentimes ephemeral
• we don't want the mental overhead of creating a collection, naming it and then forever beholden to its existence, we are always worried that it isn't complete. Every new collection, every new node in a user's organizational taxonomy brings with it enormous mental management burdens.

Clusters are a way to group items so that users can have their cake and eat it to:

• Group items together so that it is easy to navigate to an item from related items
• Make the groupings lightweight so that users don't feel like they have to maintain them

• Examples of clusters
• Communications threads
• Event series
• On the way home tonight tasks
• Recipes of John's favorite foods + John's contact info
• List of movies + List of snacks to buy at the supermarket + List of books to bring over to Debbie + Calendar event for Movie Night

These are all examples of relationships that we would never want to maintain as full-blown collections. (Can you imagine if there was a collection for every conversation thread?)

Why we're not modeling these relationships as item-to-item links
Type the word jaguar into Google and the first return will be Jaguar the car. The second will be a link to Mac OS 10.2. At the bottom of the page is a reference to a computational chemistry software company, Shrodinger that sells a products Jaguar, which was designed to increase the speed of ab initio calculations.

In essence, if we can agree to call search terms and search returns in Google, items, all search returns have an item-to-item relationship with the search term. When you search for jaguar, 10 pages of returns gather around in an undifferentiated soup of information. Hence, the concept of clustering search results. Clustering is hard for computers to do, but easy for users. By forcing users to cluster their items, rather than encouraging to create item-to-item relationships, we hope users will end up with more meaningful webs of information.

• Items related to "Pick up milk" via item-to-item relationships
• Pick up milk
• Pick up dry-cleaning
• Eggs, sugar, flour, baking chocolate
• Recipe for Devil bars
• Print out driving directions to Simon's
• Things to return to Simon
• Cook-off at Simon's
• Brand's of milk Kate hates

• Items related to "Pick up milk" via item-to-cluster relationships

• Things to do before coming home
• Pick up milk
• Brands of milk Kate hates
• Pick up dry-cleaning
• Print out driving directions to Simon's

• Stuff for Devil bars
• Recipe for Devil bars
• Pick up milk
• Eggs, sugar, flour, baking chocolate

• Stuff for going over to cook at Simon's
• Cook-off at Simon's
• Recipe for Devil bars
• Pick up milk
• Eggs, sugar, flour, baking chocolate
• Print out driving directions to Simon's
• Things to return to Simon

What clustering allows us to do is rest our brains. Instead of trying to untangle 7 individual relationships, we start with 3 and the rest become perfectly clear.

-- MimiYin - 29 Jul 2004