[Design] Distinguishing a collection as a "user collection"

[Philippe Bossut]

Hi,

Mimi Yin wrote:
> On Mar 2, 2006, at 11:56 AM, Alec Flett wrote:
>>> If I create a collection *From: Jane* and then drag 1 item out of it 
>>> that is technically *From: Jane*, but I don't want it in the 
>>> collection, the item still displays *From: Jane*, but loses the (*) 
>>> designation that shows you that it belongs to the *From: Jane* 
>>> collection. 
>>>
>>> Presumably, this is only true for a certain set of attributes, 
>>> attributes we've been calling "intrinsic attributes". Things like 
>>> Date received, Date created, Body text, etc. Attributes that make up 
>>> the intrinsic characteristics of an item. 
>>>
>> Yeah, I think this is an extremely important point - because it seems 
>> like in some cases you want to change an attribute when an item gets 
>> added to a collection, and in other cases, you want to keep the 
>> attribute and consider the addition an "inclusion" - and 
>> understanding this is really going to help us make our 
>> InclusionExclusionCollection implementation do the "right thing" 
>>
>> So how do we decide which attributes are 'intrinsic' in this way? Is 
>> it a well-known list of attributes that we just decide on, or is 
>> there some rules that govern if an attribute is intrinsic or not?
>
> I think we can probably start out with a best guess list and be open 
> to changing it as new use cases come up. It should also be something 
> developers and potentially  can control as they define new attributes 
> and data types for Chandler.
This is one problem I mulled over after a collection meeting we had 
during 0.6: if a collection is the result of a query, should moving an 
item to the collection:
(a) modify the item attributes so that it will appear in the collection 
as a result of the query
 - or -
(b) be added to the collection as a specific inclusion

(there's a symmetric problem with moving an item out of the collection)

One can argue for both (a) and (b) and find numerous examples and 
scenarios better served by one or the other. One could of course "ask 
the user" each time but I'm afraid that having a prompt for each DnD 
action is a no-no.

So, what about having a choice at the *creation* of a collection (I'm 
talking solely about collections created by the user using a query, not 
free form user defined collections or OOTB collections):
(a) the collection will be purely query based
-or-
(b) the collection will be built and enumerated the first time the 
collection is created, IOW, data are gathered once and the query is 
forgotten

To make things clear, we need to give a name to these categories of 
collections and have special behaviors for them:
(a)
- "Search Collection"
- query based only : S = { x | prop(x) == True}
- new items coming in the repository will show up or not based on 
evaluation of prop(x)
- editing items in the repository may make them appear/disappear from 
the collection (if you change attributes that change prop(x))
- DnD (addition/substraction) of  items will modify the properties of 
the moved items (if the query correspond to one unique simple attribute 
like a tag, user defined label or intrinsic attribute) or may be 
forbidden (if the query is complex, though we have no plan to provide a 
UI to build complex queries in 0.7)
(b)
- name : "List Collection"
- explicit list of items gathered using the query prop(x) at create 
time, so it's like a "normal" user collection except that data are 
gathered automatically at create time instead of manually
- new items coming in the repository will not show up based on 
evaluation of prop(x) (note: eventually (0.8?), Chandler will have 
filters so the user can create a filter that add explicitly items to the 
collection if prop(x) is true, note that this is actually different from 
a search based collection)
- editing items in the repository will not add/substract anything from 
the collection
- DnD always allowed

(a) corresponds to scenarios where the user wants a constantly updated 
collection based on a criteria
(b) corresponds to data gathering scenarios and classical "filter and 
move" scenarios as seen in email clients today

I personally would use (a) for tags and label based collections, and (b) 
(associated with a filter on incoming items) for everything else.

One could argue that the new "tag/label collection" feature slated for 
0.7 should always create a "Search Collection". Same for triage status 
sections (as seen in the Dashboard). So the "user prompt" will not have 
to be shown before we have a UI for creating complex queries (not 
planned for 0.7). I'm not sure then we need to visually distinguish the 
2 types of Collections for the user on 0.7.

Cheers,
- Philippe