Organized by design: The structure of Chandler collections

Status Putting page together as of 19 Aug 2004

In NaturalWorkflowDesign we talked about encouraging users to make easy, coarse-grain processing decisions first and making it easy for users to iternatively process their information over multiple passes, refining piles and grouping, transitioning from processing to organizing.

Here, we will attempt to come up with the best way to organize processed items in a way that is both intuitive to users coming from a silo-based, foldering PIM world without undermining our own efforts to help users shift away from such a strict and hierarchical mental model.

The OOTB collections are primarily concerned with Processing. They are a way to Organize the Processing process.

• Dashboard, where Collection and Processing happen
• Inbox and Outbox
• Archive
• Junk
• Trash

On the way to organizing, there is an intermediate step: Orgcessing, which is mostly concerned with assigning Kind-ness to items and organizing items into Kind-based groupings.

The Processing aspect of Orgcessing is Stamping. See StampingWorkflow.

The Organizing aspect of Orgcessing is the Kind filter bar in the Sidebar. See SidebarSpec.

Once users have decided whether to get something out of their face (Deferred until, Done, Archive, Junk, Delete) or keep it in my face (Processing) they can come back to an item on a second pass and pin down what Kind of item it is.

• Is this something I have to do? (Add to Taskpad)
• Is this something I have to do at a particular time? (Add to Calendar)

Users can answer these questions by Stamping their items. Adding an item to the Taskpad makes it a Task. Putting it on a calendar makes it either an Event or a scheduled Task.

Once users have done this, they can go see their items organized by Kind using the Kind filter.

Advanced users will want even finer-grain organization of their data and they will proceed to create their own topic taxonomy with Chandler collections. See BrowserDesign.

• Organize_Levels_of_Use.gif:
  

Hierarchical folders v. Orthogonal attributes

• Old Paradigm Hierarchical folders
• 1 folder per 1 item
• 1 folder per 1 sub-folder
• Fixed hierarchy
• Folders know about member items
• Items don't know about folders

• Chandler Paradigm Orthogonal attributes
• Many collections per 1 item
• Flexible "hierarchy"
• Collections and items know about each other

XYZ Chandler Canoga 1.0 will have 3 main orthogonal dimensions for basic personal information management. As the product grows to solve more complex task and project management use cases, the number of dimensions will probably expand.

• Kind: n. destination, physical object (ie. Mailbox, Taskpad, Calendar, Notepad)
• OOTB Triage status collections: adv. status of item (ie. Processing, Deferred, Done, Archive, Junk, Trash, In, Out)
• Collections: adj. topic taxonomy, category (ie. Projects, Spheres of Life, Subject matter)
  • When Chandler is more of a General Information Manager, collections might be refined with types of collections so that users will have more orthogonal axes with which to describe items

The result of modeling these different "groupings" of items as orthogonal attributes of an item is that users can think of their information as being organized in any of 6 the following virtual hierarchies.

• Kind
  • Status
    • Collection

• Kind
  • Collection
    • Status

• Status
  • Collection
    • Kind

• Status
  • Kind
    • Collection

• Collection
  • Kind
    • Status

• Collection
  • Status
    • Kind

Not all Organizations are created Equal

In this confusing array of possibilities, there are some good reasons for presenting each of these orthogonal axes to the user in a different way to help them understand how best to organize their data.

First and foremost, users should be spending most of their time in the Dashboard collection Processing and Doing. They should be using the other OOTB Triage workflow collections to manage this process.

Periodically (a few times a day) users will want to review their information based on Kind.

• View their Calendar to check their schedule
• View their taskpad to get a sense of their workload
• They may also want to look at their Mailbox or Notepad to find a particular item

Every once in a while (a few times a week) users may click on a collection to retrieve an item or if they are using collections as a way to track and manage projects, to review the status of a project. However, because topic taxonomies are particularly hard to construct and maintain and should really be an advanced user feature, we hope that most users will find it sufficient to simply Orgcess by Triage status and Kind.

How do we arrange these three orthogonal ways to group intems in a way that encourages users to work this way?

Why we want to model these 3 organizational methods orthogonally: Use cases

Outlook has all 3 methods of organization in 1 sidebar.

• Kind-based folders
• Cross-kind categories
• Cross-kind, cross-category status

The result is

• Redundancy (ie. Home account Inboxes and Home calendars and cross-kind Home categories)
• Long, confusing toolbar that is hard to navigate
• Kind, category and status are three very different ways to organize information. By treating all three equally in the sidebar
  • PIMs aren't providing users with the UI affordances tailored to specific use cases.
  • Instead, it's a one size fits all approach that renders all but the most basic organizational tools (ie. Inbox, Send, Trash) useless.

• sample_sidebar.gif:
  

We would like to custom tailor UI affordances to specific use cases for viewing items wrt Kind, Category and Status.

• Examples
• Kinds: Mail, Tasks, Calendar, Notes
• Triage status: Processing, Deferred, Done, Archive, Junk, Trash
• Collections: Spheres of Life, Categories, Topics, Projects (ie. Home, Work, Hawaii vacation, Mailing list, Accounting)

UI Options

• Mode: Switch contexts. Changes sidebar. Possibly changes main toolbar. Changes main content area.
• View: Changes main content area.
• Section of a view: Open and closable sections of a single view. Visual dividers.

• Mode_View_Section.gif:
  

Viewing things by Kind

Kind filters are permanent destinations. When an item is stamped as a Kind, it is unlikely to be unstamped. In some cases, it is literally not possible to unstamp (ie. Sent, Received messages).

• Users can either think of Chandler as being primarily organized by Kind-based modes: Mailbox, Taskpad, Calendar, Notepad and each mode has it's own set of sub-mailboxes, sub-taskpads, sub-calendars and sub-notepads. OR...
• Users can think of Chandler as being primarily organized by Collections and each collection has it's own mailbox, taskpad, calendar and notepad.
• Either way, Kind-based groupings are physical destinations.

Most prevalent use cases for viewing items by Kind:

• Calendar: What does my schedule look like
• Taskpad: What's my workload

Mailbox and Notepad are used more when looking for a particular piece of information.

Unlike Triage status, Kinds are additive, not mutually exlusive.

From the Calendar and Taskpad users will want to view their items by Collection: Home, Work, Soccer, Vacation as separate entities.

Users will have different sets of collections for each Kind filter.

Users will want to view each Taskpad sectioned by Triage status.

Calendar is the most compelling use case for persistent selection. Unlike the other Kind destinations users will want selections to overlay collections, one on top of another rather than to switch collections. Users will also generally want to have the same collections selected between visits to the Calendar.

Calendar and maybe Taskpad: Users will want to share a filtered set. (ie. Share just Home calendar, or Marketing Taskpad) See FilteredShares.

The sense of physical permanence, the clearly defined mindset of the user, the need to browse user-defined collections as a sub-structure of Kind destinations make browsing by Kind a modal user experience. Users are in a scheduling mode when they go to their calendar, a task management mode when they go to their Taskpad.

Viewing things by Triage status

Cross-kind Items See what's going on Gauge what stuff I have deferred Quick search of all my important stuff

Triage status, unlike kind describes a state of being, a stage in the lifecycle of an item. It is conceptual, a virtual grouping of items. The closest real world example of Triage status would be some kind of assembly line process (ie. trays of chemicals for developing photographs) or mail room processing piles.

Triage status describes the stage of an item as it goes through its lifecycle from birth through multiple iterations of Processing, Deferring, and Doing until it's Done. Sometime later, items may be semi-permanently retired to the Archive collection or killed altogether in the Trash.

Member ship in any one triage status group is ephemeral. Even items from the Archive collection could come out of retirement. As a result, triage status group membership is in a state of constant flux.

This also means that users will end up with a shifting constellation of collections for each Triage status as Projects ramp up, wrap up and start up again.

Triage status stages are mutually exclusive. Items cannot be both Processing and Done.

Why triage status groupings should be modeled as sections of a single view

2 modes

• Items I want easy access to: Processing, Deferred, Done items
• Items I want in the attic or basement or taken out with the trash altogether. It's there if I go look for it, but it doesn't clutter up my day-to-day existence.

For items I want easy access to, users will want to be able to see all of these items in one view. Users will want to have easy access to search all of their important to me on a day-to-day basis items.

Within the group of items I want easy access to items, we can draw even finer distinctions between items I want in my face right now and items I want easy access to, but don't need to look at all the time by sectioning items I want easy access to into three open and closeable sections: Done, Processing and Deferred where Processing is the section users will most likely keep open.

It is also important that the directional flow of the triage status groupings is presented to the user. If the triage status collections are simply listed in the sidebar like all other collections, there is no sense of order or flow. As a result, we arrange the Triage sections in conceptual time order: Past: Present: Future :: Done: Processing: Deferred.

Viewing things by Collection

• Cross-kind: Users won't care what Kind an item is
• Review status of a Project by Triage status
• Find an item starting with a pre-organized set of items

Organize Structure

• As you can see, Kind groupings have the most use cases for sub-structure. Users viewing items by Kind will want to see items organized by Collection and by Triage status.
• When users view items by Triage status on the other hand there is practically no use cases for sub-structure with the possible exception that they might want to sort their items within a Triage status by Collection.
• Again, when viewing items by Collection, users will want a status update and may sort by Triage status, but Kind-based distinctions are not really important.
• Organize_Structure.gif
  

Proposal

Based on the way people use Kind, Triage status and Collections to organize their items, we propose to organize:

• Section the main Dashboard by Triage status
• List collections in the Sidebar and provide affordances so users can both
  • Select to view collections one at a time AND
  • Persistently select to overlay collections one on top of another
• Organize the Sidebar navigation area by toggling Kind filters that change the list of available collections based on Kind

Dominant hierarchy in our flexible hierarchy orthogonal organization is:

• Kind
  • Collection
    • Triage status

• Organize_Hierarchy.gif:
  

-- MimiYin - 19 Aug 2004