[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