Again, Phillip Eby has been asking some good questions about why Chandler item collections behave the way they do...specifically:

• Why do we risk carrying out long lists of inclusions and exclusions
• Why don't we distinguish between rule-based collections and explicitly defined collections
• Why don't we distinguish between "saved search" collections (where the collection is defined by the rule) and "mail filter" collections (where the collection is simply populated by a rule, but if an item changes and no longer meets the parameters of the rule, it does not get automatically removed from the collection).

Here are some answers below...

One of the things we trying to avoid was having to differentiate between explicit collections and rule-based collections. (ie. Search folders v. Folders, Smart playlists v. Playlists) Instead, like many other things in Chandler, collections are what they are, based on how users interact with them. If they explicitly drag and drop items in and out of the collection, the collection behaves like an explicitly defined collection. If they add rules to the collection, the collection takes on the properties of a rule-based collection.

That being said, the issues you bring up are relevant and don't go away easily.

We have yet to begin design-engineering meetings wrt rule builder. I think this is where some of your issues might be best addressed.

For example:

1. Probably not in the 1st iteration, but future iterations of the rule builder will show users what has been explicitly included and excluded from a collection
2. Users can either specify that a rule they've created can act like a "mail filter" or like a "saved search" by checking a box that says: "Automatically remove items that fail to meet any parameter of the rule"
3. Users can specify whether they want the collection to "impose the rule" on explicitly added and removed items. (ie. The status=done collection will automatically set all items the user drags to the collection as done.)

The main goal...I guess the idea is that rather than provide users with 2 or 3 different ways of grouping items (explicit v. rule-defined v. rule-populated collections) and having them try and figure out based on what these different kinds of collections do, which would be the best one for me to try and use...We're giving users a single option (a collection) and providing them with incremental ways for them to control and fine-tune how they want the collection to behave. That's really all I care about. If there's a more efficient, less risky way to reach that end goal, I'm all for changing the way collections work.

Generally speaking users who build rules are pretty advanced and we're hoping that with a rich and clear UI for rule-building, users will understand how and why items appear and disappear in their collection.

As for performance, it's a serious issue, but I think we'd like to see how users use exclusions first before deciding whether or not we need to change them. My personal feeling is that exclusions and inclusions will be relatively rare. But that could be drastically off-base.

---

Back to the issue of AttributeValuesAsCollections A related though tangential thought is that I've been playing around with the idea of erasing the distinction between collections and attribute values (for select attributes). In Chandler, collections themselves are already attribute values as well. Which creates a confusing environment for the user when it comes to creating rule-based collections.

For example, what does it mean for the Collection: Done to have a rule on it that says: Status=Done? Shouldn't Status: Done be the collection itself? Why do users need to create these circular rules?

After all of the work done to keep track of different kinds of attributes (ie. These items all belong together because they share the same Status. These items all belong together because they share the same Creator, etc...) why do we mush them all together when it finally comes time for users to view their items in collection groupings? It's a shame to lose the semantics of "All things where Status: Done" by saying that the only way users can see "All things where Status: Done" is to put them into the semantically meaningless Collection: Done. (When I say semantically meaningless I am referring to the fact that Collections as an attribute name simply tells you THAT a group of items are related, but does not tell you WHY the items are related, in the way that the attribute name Status does.)

What's missing from this proposal of course is the ability for users to define new attributes, primarily because there is not necessarily a 1:1 mapping of attribute values to rule-based groupings. In other words, sometimes, I want to group items based on more than 1 attribute value. For example, if I want to create a complex-rule (ie. All items before April 2, 1984, Email from Jess and George, Done items for Carey from Yesterday) with which to populate or define a collection, I should be able to either define it as a generic collection...or I can create a new attribute called Date range: or People: or Keep on top of: or Subject matter:.