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

Mimi Yin mimi at osafoundation.org
Thu Mar 2 14:06:10 PST 2006


See inline :o)

On Mar 2, 2006, at 11:56 AM, Alec Flett wrote:

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

Oh I see. Well I could see that you would want to either select from  
user collections and/or just search on any given attribute. I think  
the best way to present stuff like this is to the user would be to be  
really literal:

+ What do you want to Add from your Sidebar?
+ What sections do you want to add?

Then there's just importing data, perhaps not in containers:
+ Search on an attribute and add the results

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

No, the collection would only appear in the sidebar if:
+ User drags label from detail view to sidebar
+ User right-clicks on attribute in detail view and selects: Add to  
sidebar
+ User searches on Project: Kitchen and then saves the search as a  
collection in the sidebar
+ User defines a new collection in the sidebar as Project: Kitchen
>
>> 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)

I think for automatically created Sections and Partitions, we  
wouldn't need to treat them as 1st-class collections. But if we had  
say user-defined collections where you section a view from scratch,  
then I would say yes, we should treat them as first-class collections.

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

I'm not sure about that. If you remove an item from the TS: Done  
collection, what's the TS now? You haven't defined an alternative. I  
could imagine that you want to have a collections that's Most of my  
TS: Done stuff.

The thing in the sidebar: is your hand-crafted view of data, rather  
than a straight-up "persistent short-cut" to a search result (aka  
Search Folders).

In the future you could imagine more sophisticated UI that shows you  
a list of in/exclusions and allows you to "reset the collection" or  
"get rid of certain in/exclusions"

> 2) does that collection now appear in the "Labe"l field? (I assume  
> not?)

This redundancy is exactly what we want to avoid. The Triage Status:  
Done attribute in the detail view displays visual feedback that it's  
been added to the sidebar as a collection.

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

>
>
> Alec
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/20060302/5376049c/attachment.htm


More information about the Design mailing list