Hierarchical Folders

Status Gathering open issues and design challenges around hierarchical folders in the sidebar

See also BrowserDesign

Organizing the sidebar v. Organizing collections

• Proposal
• Separate the notion of organizing the sidebar from the more complex problem of organizing collections of information. One is a relatively shallow user need. The other is library science problem.
• Users can organize sidebar collections into trays, which are not themselves collections.
• Items cannot be directly added to trays.
• Clicking on a tray does not display any items in the summary view.
• Trays do not show up in the Label or See also section of an item's detail view.

• Questions
• Do we need Trays to make users feel at home in Chandler's new world (a cheap way to simulate hierarchy without getting into the data model complications of implementing real hierarchy)?
• Or will we decide after the design review that we can remove Trays altogether because we've come up with a better solution to sidebar management?
• Do we need multiple levels of trays?

• trays.gif:
  

Separating the UI Affordance from the user need

• Hierarchical folders v. Need to organize my items v. Need to organize my collections

1. Do users need to organize their collections? aka create a taxonomy?
2. Are users trying to tame out-of-control sidebars?
3. Are there other, better ways to tame the sidebar?

• Questions Will users be willing to abandon a familiar, but clunky UI affordance for organizing for new affordances we believe will be more intuitive and easier to use.

The problem and a proposed solution in a nutshell

We're left somewhat shorthanded wrt Organize (a la David Allen) UI affordances, primarily because we've had to cut the

1. Collections Manager and
2. the Attribute-based Item Browser.

By removing the collections manager and item browser from Kibble, the assumption was that the sidebar needed to be a comprehensive list of all named collections. However, if we challenge and remove this assumption, we may achieve a better design.

So, perhaps some of our organizational needs can be met by

1. Treating the sidebar as a shortcuts bar AND
2. Sorting in the summary table view

What if we return to the idea that the sidebar contained only the OOTB collections and the user-defined collections you've explicitly chosen to add to the sidebar?

All user-defined collections exist as labels on their member items, but only a few select, highly used collections are hand chosen by the user to live in the sidebar.

For example, you might have a single mailing list collection in the sidebar.

Within the mailing list collection summary table view, you can sort all of your mailing list items by a "collections" column that lists all of the collections that each mailing list item is a member of...(ie. devlist, designlist, etc)

Assumption: Sidebar as we know it today is broken AND How do people use their sidebar?

All along, we've assumed that sidebar organization as it stands today is unsatisfactory, confusing to many users and actually slows people down in their efforts to organize their information.

There seem to be two main reasons why people file items into the sidebar

1. To organize their items into pre-filtered sets in order to make it easier to retrieve items in the future
2. To have easy 1-click access to a commonly viewed collection of items

The resulting conundrum of course is that the number of type 1 collections is virtually infinite and sidebars more often than not, get so overloaded with type 1 folders that they leave no room for type 2 folders.

Type 2, easy to access, 1-click folders don't exist in today's PIM sidebars. A more accurate description might be: "hunt - scan - and - carefully - click" folders.

Furthermore, DnD filing itself becomes a motor coordination challenge, even for the most skilled mouse users and especially as sidebars get longer and more complex.

Choosing the right metaphor for our data model

1 item in "n" places...

Sidebar hierarchy is further complicated by our unique data model which allows for a single item to appear in multiple collections or "locations". The Chandler data model is better expressed as a web or semi-lattice than as a fixed hierarchical tree. This was the original motivation behind implementing more of an iTunes-like attribute-based item browser where the user can "walk" the web, one tree at a time.

1. Is a fixed tree hierarchy an actively misleading way to represent the way Chandler items are organized?
2. Do we need a more radically different design (ie. no hierarchy a la iTunes) to communicate to users that items are NOT defined by their location in Chandler, to re-frame and reset user expectations and assumptions about the laws of physics in Chandler?
3. Do we need to bring back the attribute-based item browser to compensate for the lack of a hierarchical folders?

Tree v. Semi-lattice

• The semi-lattice is a more accurate representation of our data model
• Implementing a tree raises other issues such as...
  • Can collections live in more than one collection as well?
  • If I have two collections called Tasks for Jed in the Chrome project and the Detail view project, is that the same collection? or is Tasks for Jed orthogonal to Detail View project and Chrome project?
• If an item is added to a sub-collection (ie. 2004), is also automatically added to the sub-collection's parent collection(s) (ie. Foo and Bar)?
• tree_versus_web.gif:
  
• collections_in_collections.gif:
  
• collections_hierarchy.gif:
  

The dream of attribute-based collections and an infinitely flexible tree Is this still a goal of Chandler in the future?

Which brings us back to...

With these issues in mind, we come back to the Simplified Kibble Proposal...

1. Treat the sidebar as a shortcuts bar aka reserve it only for type 2, I-need-one-click-access-all-the-time, collections
2. Sort by a "collections" column in the summary table view

Improving on the Foldering and Labeling workflow: Treating collections as keywords.

Various PIMs have primarily 2 ways to organize items into groups:

1. Users can create explicit collections via DnD
2. Users can attach a category or label attribute to an item via pulldown

• Neither are satisfactory*
• Method 1 entails too much motor coordination and makes it hard to file one item into multiple collections
• Method 2 requires the user to troll through a long list of collections in order to pick out a label and also makes it hard to file one item into multiple collections (although a checkbox pulldown might make this easier)
• Both methods require the user to stop what their doing and embark on a separate workflow if the grouping they want doesn't exist yet

• sample_sidebar.gif:
  

• categories.gif:
  

• • Method 1:
  • Create a new folder in the sidebar
  • Find untitled folder in the sidebar
  • Name untitled folder
  • Re-find the item you were filing
  • Re-find new folder
  • DnD item into the new folder
  • Method 2:
  • Select "Edit categories" from the Category pulldown
  • Dialog pops up with a list of all categories
  • Click add a new category
  • Name the new category
  • Click Okay
  • Click the Category pulldown again
  • Find the correct category
  • Select category.
• Both methods discourage users from creating new groupings because: "Is it really worth adding yet another folder or label to my sidebar if I only have one item in it?"
• Both methods leave "unfiled" items, backlogged in the Inbox, for no other reason than: I don't really know where to put this, and even if I did, I don't have the energy to do it.
• Both methods make it hard to add one item to multiple collections. Both methods come from a world where items live in one place.

• Proposal: A new data model deserves a new and better way to organize
• User apply labels to items by typing into a text field featuring auto-complete (just like email addresses in Apple Mail)
• User can apply multiple labels at once
• User can create new labels on the fly without having to switch to a different workflow
• User can set a preference to either
  • Automatically add all new collection labels to the sidebar (OR)
  • Only add explicitly designated collections to the sidebar
• Sidenote This is actually treating collections as if they were keywords in some sense. Conflating the two to mean the same thing.

• label_detail.gif:
  

How we got to this point and How should we proceed?

Looking back over the last year of design...

We came up with a number of ideas on

1. How to improve on sidebar organization in a way that...
2. Accurately represents the way items are organized in the Chandler data model

We've decided that we can't implement all of these design ideas for Kibble.

That being said, the following questions remain:

1. Without the Collections Manager and Attribute-based Item Browser, do we need to have trays in the sidebar so that users can get by until we have a fully functional framework in place for Organizing?
2. Trays, as merely a visual UI means of organizing collections can address the need to organize collections and yet avoid the structural issues with nested collections.
3. But, do we even need trays in Kibble? Or should we test the simplest UI for Kibble first before deciding to add trays?

-- MimiYin - 02 Nov 2004