These are exactly the issues we wrestled with 2 years ago when we first designed Item Collections. We decided not to confuse the user with too many distinctions between List collections and Search collections.
Basically, the user is not equipped at the time they create the collection to know whether they want it to be a "search" collection or a "list" collection.
And you may want elements of both. Give me all Bob Marley songs, including all new Bob Marley songs I add...except for this one Bob Marley song I hate. So you don't want the query to be forgotten, but you do want the collection to remember certain exclusions.
As a result, we decided to follow a more adaptive model. The collection would do whatever you told it to do and you didn't have to "type" it a priori, before you've even had a chance to put stuff into it and try using it for a while.
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
