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

[Philippe Bossut]

Hi,

The specific problem (raised initially by Alec) is that this adaptive 
model says nothing on what exactly should be done to an item added to a 
collection, namely:
a) should we modify the properties of the item so that the item shows up 
in the collection query? This is what I expect a collection based on 
triage status to do for instance.
-or-
b) should we add the item to an "inclusion" set ("exclusion" 
respectively when the item is dragged out)?

Your rebuttal still doesn't address this question.

Taking your Bob Marley example, I think it makes sense to use an 
exclusion set to take out the Bob Marley songs you hate (solution b). I 
do think however that would be a mistake to do this in the case of a 
triage status collection or you run the risk of having a complete lack 
of correlation between the triage attribute of items and the triage 
collection in which it appears (which would be horribly confusing).

So, what's your pick?

Cheers,
- Philippe


Mimi Yin wrote:
> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design