[Design] Distinguishing a collection as a "user collection"
Mimi Yin
mimi at osafoundation.org
Sat Mar 4 17:08:47 PST 2006
Hi Philippe,
I think maybe I wasn't clear in my email to Alec, the proposal is:
> 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.
>
> As opposed to Label attributes, labels that users attach to items
> to help them organize their data (ie. Project: Foo, Status: Later)
In short, we need to define a set of "intrinsic" attributes that
don't get discarded if an item is dragged out of a collection. (ie.
Date received). All other attributes are.
Mimi
On Mar 3, 2006, at 10:29 PM, Philippe Bossut wrote:
> 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
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060304/0c183d32/attachment.htm
More information about the Design
mailing list