[Dev] Re: [Design] Chandler in a Nutshell
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
(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
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.)
> 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.
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev