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

[Mimi Yin]

Hi Philippe,

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.

Mimi

On Mar 3, 2006, at 2:25 PM, Philippe Bossut wrote:

> 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
> http://lists.osafoundation.org/mailman/listinfo/design