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

Alec Flett alecf at osafoundation.org
Thu Mar 2 11:56:03 PST 2006


Ok, I think I'm starting to understand some of this...comments inline..

Mimi Yin wrote:
> The design proposal for 0.7 is to replace the Appears in: field with a 
> generic Label field. Labels that are also collections in the sidebar 
> will be delineated with something simple *for now*m ie. (*) or (C).
ah, ok I think this does help clear up some things. So in some sense, 
we're completing the "merge" between labelling and collections in 0.7? I 
like that.

The crux of what I'm trying to ask, I guess, is "what is the 
significance of the collections in the sidebar?"

In particular...see below
>
>> * Later, if there is a UI to present a list of collections to the 
>> user (i.e. maybe some sharing UI, or a parcel writer wants to let the 
>> user choose a collection in a dialog box or something) - how do they 
>> choose which collections to display?
>
> I'm not sure I understand this question. To display in the summary pane?
Lets say some new parcel wants to display a list of "user collections" - 
i.e. maybe it has a UI that says "choose the collections you wish to 
export to MyApp" or "Choose the collections to search" or "choose the 
collections that make you sad" - the point is, how do we distinguish 
specific, user-facing collections from the set of all collections in use 
in chandler? I think that "Appears In"/"Label" is only one case of this.

I guess maybe another open issue is:

* Say a user marks something with the label "Kitchen" or "Project: 
Kitchen" and that label never existed before - does the new 'collection' 
that now exists automatically appear in the sidebar? If it does not, how 
do we distinguish that collection from another collection like "Project: 
Birthday" which /does /appear in the sidebar? Is its membership in the 
sidebar enough, or is there some lower level semantic that we should use?

> Except as a Section as well? 
>
I'm not sure I understand this completely - I think of sections as a way 
of rendering a particular collection, technically grouping it into "Sub 
collections" which are of course collections in their own right. I 
understand the way "All items with triage status 'now'" is a means of 
defining a collection, but is this a kind of "first class" collection? 
Maybe it doesn't matter? i.e. does it appear in Label? (seems like it 
should not)

Here's an interesting case: Say a user drags "triage status: done" from 
the detail view and into the sidebar.
1) what is this new collection? is it an inclusion/exclusion-style 
collection? (seems like not in this case, but it could vary based on the 
attribute?)
2) does that collection now appear in the "Labe"l field? (I assume not?)

>
> 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?


Alec
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060302/43769ffd/attachment.html


More information about the Design mailing list