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

Mimi Yin mimi at osafoundation.org
Mon Sep 19 17:31:10 PDT 2005


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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20050919/ee9fe8ac/attachment.html


More information about the Dev mailing list