[Dev] Re: [Design] Chandler in a Nutshell

[Lisa Dusseault]

I have been working on a presentation/tutorial on some of how  
collections and facets and tags fit together for WAC on Thursday.  It's  
intended as a tutorial to bring people to understand Mimi's designs and  
Mimi reviewed it, but my slant on that is kind of how I personally came  
to understand (slowly) some of the nuances of that.

http://wiki.osafoundation.org/bin/view/Journal/ 
WestwoodAdvisoryCouncilMeeting20050922Preparation
http://wiki.osafoundation.org/pub/Journal/ 
WestwoodAdvisoryCouncilMeeting20050922Preparation/Organizing- 
Information.ppt (warning -- large)

Lisa

On Sep 19, 2005, at 5:31 PM, Mimi Yin wrote:

> I've gotten some really great feedback and questions from people,  
> which I thought I would share with the group, as I'm sure more than  
> one person was confused by these points as well :o)
>
>
> Questions about Chandler Virtuality
>
> Q How do collections fit into slide 13, Chandler Virtuality? Facets  
> are attributes like from, to, status. I believe collections to be  
> items grouped together based upon tags and attributes into things we  
> might call projects. The slide talks about a faceted sidebar on the  
> left as well as a facet panel on the right. I'm sorry to be so dense,  
> but I seem to be missing something about how facets and collections  
> fit into the window. Do you see my dilemma?
>
>
>
> A Yes this is a hard concept to explain because we're sort of glossing  
> over all of the cognitive psychology and library science stuff about  
> how to best use hierarchies, faceted systems and tags...
>
>
> The slide is attempting to show that our system is a Hybrid that  
> brings in elements of all three systems. We're sort doing a high wire  
> act, trying to exploit hierarchies for the things they are good at.
>
> 	• 	Shallow hierarchies are great.
>
> 	• 	Hierarchies are great at organizing high-level concepts that are  
> static and unlikely to change over time.
>
>
> This is why we only have ever have 2 levels of hierarchies: Kinds and  
> Sub-kinds, Spheres and Collections in the Sidebar and Attribute groups  
> and Attributes.
>
>
> This is why we only use hierarchies to organize abstract concepts:
>
> 	• 	Attribute types: Who, What, When, Where, Status, # Values.
>
> 	• 	Kinds: Communications, Todos, Calendar, Resources, Media,  
> Directories.
>
>
> And why we don't use them to organize user data (ie. tags), which is  
> messy, heterogeneous and changes constantly.
>
>
>
> Faceted systems in Chandler
>
>
> Which brings us to facets. We've selected 2 facets out of the dozens  
> and potentially hundreds of attributes in the PIM domain and promoted  
> them to be first-class navigation tools in the sidebar: Kinds and  
> Collections...
>
>
> (One of our complaints about facets is that while the occupy the  
> balanced middle ground between over-structured hierarchies and  
> under-structured tagging systems, they are overwhelming to deal with  
> in their own right. Simply put, there are too many facets, so many in  
> fact that most users will have a hard time knowing where to start.)
>
>
> However, there are plans to create a more advanced, more generic  
> faceted browser (something like the iTunes Browser interface) which  
> would allow people to browse their data with a broader range of  
> attributes: including Projects and People.
>
>
> But out of the box, the 2-dimensional faceted sidebar is the most  
> basic UI for faceted browsing that all users will use.
>
>
>
> An elaboration on collections
>
>
> Collections fit into the sidebar in that they are the things that live  
> in the Sphere trays in the sidebar. (Keep in mind that a user starts  
> out with 0 trays out of the box, but can create and define their own  
> trays over time.)
>
>
> Collections are groupings of items, just like any Tag-based grouping  
> or Facet-based grouping. (ie. All "World cup" items or All "Date  
> received: Today" items).
>
>
> So it's not that Collections are Projects. It's more like, a grouping  
> of items based on the attribute "Project: Foo" can be promoted to the  
> sidebar to be a collection. Similarly, a grouping of items based on  
> the attribute "Date received: Today" could also be promoted to the  
> sidebar as a Collection.
>
>
> So in the end, what does it really mean to be a Collection grouping  
> versus a Facet or Tag-based grouping.
>
>
> Well, not much really. The difference is more cognitive than  
> functional.
>
>
> When people Tag or describe items in terms of facets or attributes  
> (ie. London, Foggy, Weather report OR Author: Mark Twain, Protagonist:  
> Tom Sawyer, Publisher: Harlequin), they are:
>
> 	• 	explicitly describing the item and as a result of that...
>
> 	• 	implicitly creating groupings of items based on the description
>
>
> It's what we're calling a bottom-up approach to grouping items.
>
>
> When people create and manage a collection, they are doing the  
> opposite:
>
> 	• 	grouping items explicitly and
>
> 	• 	describing items implicitly
>
>
> Ergo, collections are a top-down approach to grouping items.
>
>
> And generally speaking, we've identified the following characteristics  
> of top-down groupings:
>
> 	• 	You specifically want to see the grouping of items as a group. ie.  
> A shopping list, An itinerary, A project plan.
>
> 	• 	It's probably something you are actively monitoring: An active  
> project or task.
>
> 	• 	You want explicit control over membership through drag and drop:  
> In Chandler, once you've promoted an item grouping to be a collection  
> in the sidebar, you can do inclusions and exclusions that violate the  
> rule governing the collection (ie. I might have a collection based on  
> the attribute, Date received: Today and exclude one of the items  
> because it's not important to me.)
>
>
> Bottom-up groupings on the other hand:
>
> 	• 	You don't necessarily care to see all the member items in an  
> aggregated view together
>
> 	• 	You mostly use it as a way to narrow down searches
>
> 	• 	You don't need to manage manually with explicit inclusions and  
> exclusions
>
>
> Which is the long explanation for what a Collection is. In Chandler  
> there's really only one-notion of item grouping. What toppings the  
> user puts on that basic notion of an item grouping is really up to  
> them: They can leave it as a tag, add a facet to it or treat it like a  
> collection in the sidebar: whatever it is they need to organize their  
> data as it grows and changes.
>
>
> It's sort of the Grand Unified Theory of item groupings. There's a  
> base particle and all other "particle types" are just different  
> instantiations of the same base particle.
>
>
> This is "as opposed to" the way most other applications model item  
> groupings, which is more of an "either-or" experience: Either you  
> create a Folder or a Search Folder or a Category. And once you've  
> created it, that's what it will stay forever more.
>
>
> On Sep 16, 2005, at 2:59 PM, Mimi Yin wrote:
>
>> It's been a long time coming, but I've finally managed to pull  
>> together a Chandler In a Nutshell presentation that is relatively  
>> short and succinct (at least by my standards.)
>>
>> http://wiki.osafoundation.org/bin/view/Journal/ 
>> ChandlerInFifteenMinutes
>>
>> The wiki name is a bit ambitious, but a presentation in both PPT and  
>> PDF formats can be found on that page as well as a supporting  
>> write-up of use cases to ground some of the more abstract concepts in  
>> the slides. (Slide #s are referenced on the wiki write-up.)
>>
>> (Some of the slides have additional comments in the Notes section.)
>>
>> I'd be interested in feedback both on general comprehensibility and  
>> specific points. Please feel free to add comments to the page, either  
>> at the bottom or in-line. I expect this to be an initial round that  
>> will be iterated on over time.
>>
>> Thanks!
>>
>> Mimi
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> 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 --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 12713 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/dev/attachments/20050920/edf9a259/attachment.bin