Chandler In A Nutshell

• ChandlerInANutshell.pdf:
• ChandlerInANutshell.ppt:

The write-up below supports the presentation above.

"More Natural" Iterative Workflows in Chandler

Slides 4-8: The lowercase "p"-project you figure out over time

Motivation Because we realized that we don't live in a binary world where items are either Done or Not Done, emails are either Read or Not read, we've endeavored to design our workflows around the more cyclical, iterative way in which we handle information.

• You receive an email. Something about Privacy policy.
• Just from the subject line, you realize it's going to be a doozy, but you don't really have time to deal with it right now.

• So you Defer it to you "Later" pile with a "Tickler" on it to drop back into your "Now" pile at the "End of the Day" during your 15 minute "End of the Day Review". (The Tickler function essentially allows you to control when you receive requests for your attention. If someone sends you an email at a bad time, you can Tickle it to come back to you when you're ready to give it your time.)

• When you spend 15 seconds glancing over the body of the email at the "End of the Day" you realize that this is going to be a pretty significant multi-step task. But you're not yet ready to articulate what's needed, you just Stamp it as a Task so it will show up on your Task list. You Defer it again and Tickle it to come back into your "Now" pile first thing "Next Monday morning".

• This time, you have more like 5-10 minutes to really read and reflect on the email. You annotate the Subject line to more accurately the describe the task at hand and you annotate the Body of the email with some thoughts and a "Note to self: Write up a brief plan for dealing with this after talking to Marie." You leave it in your "Now" pile because you're meeting with Marie later in the day.

• During your meeting with Marie, the two of you come up with a short list of 3-5 tasks that need to be done in order deal with this Privacy matter.

Slides 9-13: The capital "P"-Project that sneaks up on you

Motivation Because we realized that most people's information doesn't need to be filed and organized... Because we realized that most people's information is heterogeneous (with varied organizational needs) unpredictable and changes over time... We want to provide users with right tools for the right organizational needs and give users the flexibility to change their mind about how to organize their information over time.

• You first start getting a few emails about some minor network problem.
• You don't really have a specific place for it in your existing hierarchy of folders.
• You don't want to create a whole new folder just to store these 1-2 emails.
• So you just throw it into your general "Network issues" folder, which has thousands of emails in it.

• Over time, you realize this "minor" problem isn't going to go away and you should really keep track of it separately from the general morass of Network issues. But the original few you received are already lost in the massive pile of emails in your "Network issues" folder.

How would this scenario be different if you had Tagging or Gmail style Labeling instead?

• You could have happily Labeled those initial few mails "Minor Network Problem" and "Network Issues" without the fear that you're adding unnecessary clutter to your sidebar. (Chandler, unlike Gmail and other tagging systems will NOT automatically newly created labels to your sidebar.)
• Later on, when you realize that this "Minor Network Problem" is really a persistent "Minor Network Problem", you can apply the "Project" Facet or Attribute, thereby grouping it with all of your other Projects.
• Now when you do a search for all of your Projects, or ask to sort any of your views of data by the Project attribute, "Minor Network Problem" will come up on your radar.
• Over time, "Minor Network Problem" really becomes a "Major Network Problem" and you realize that you need to track it extremely closely, so you promote it to appear in your Sidebar as a collection that you can 1) explicitly manage by dragging and dropping items in and out of it and 2) have easy access to all the time.
• All items you Drag into that collection automatically get Labeled as "Project: Major Network Problem".

How is this fundamentally different from other mail client experiences?

1. Outlook, Eudora and other traditional mail clients don't really have a notion of tagging, so "organizing" newly arriving mail always means finding a place for it in your existing hierarchy. The result is that "newly emerging categories" like "Minor Network Problem" are hard to accommodate.
2. Tag and Label Paradigm mail clients like Gmail don't really distinguish between Tags and Facets and Collections in the sidebar. Tagging may be easier than filing into folders, but your sidebar is arguably even more cluttered and hard to navigate than a hierarchy because Gmail dumps every single Tag you create into your sidebar.
3. Chandler has decided that we like the "lighter cognitive burden" Tagging imposes on users trying to organize large sets of homogeneous, constantly changing data (ie. their email). But we also see the need to allow users to evolve their Tags over time, to add structure where structure is needed and to have selective control over what goes in their sidebar versus what they can call up through search and column sorting.

Slide 13: Search and Aggregating Views of Data: Benefits of a Faceted system over a Hierarchy

• Say you have a large Security Project that spans multiple departments and involves many people.

• You often have meetings about this Security Project, so you really want to be able to see documents, emails, meeting notes and tasks related to that Project in one view.

• You also have weekly one-on-one meetings with the heads of these various departments, so you really want to be able to see documents, emails, meetings notes and tasks related to each person, regardless of which Project they're for.

This kind of flexible reorganization of data views is impossible in hierarchies, but incredibly simple and easy in Faceted systems.

• By Project>>By Person
• By Person>>By Project

Slides 14-17: Making sure your top-down plan jives with your bottom-up reality

Slide: 16

Q Why should you care about Chandler as a Platform for information management? What�s the value-add of aggregating data into a central repository?

A Once you have all of your data in a single system you can juxtapose and slice and dice that information to find relationships and dependendies you couldn�t possibly see when things were segregated.

• Are there tasks or bugs that are associated with the �Now� part of the plan that have been Deferred?
• Are there tasks or bugs that are associated with the �Later� part of the plan that are being dealt with Now?
• Are all of the issues associated with the �Doing Now� part of the plan dealt with?
• Are there still bugs or issues for parts of the Plan that are deemed �Done�?
• Does the �Later� part of the plan look big because there�s lots to do? Or because there�s one huge thing to do? How can that huge thing be broken down further to untangle dependencies, so the success of the project doesn�t rely on this one huge task.
• Are there any big issues still to be resolved? Should those be dealt with now? Even though they�re not technically part of the �Now� part of the plan since they will take some time to deal with?

The ability to juxtapose, overlay and relate disparate, homogeneous sets of information is fundamental to how human beings take raw data and synthesize it into something more useful called knowledge. Chandler aspires to be software that breaks down the �artificial� technological barriers that are holding all of us back from making more use of our information. The end result we hope will be a fundamental shift in people�s relationship to their data, a shift towards more informed and objective decision-making and planning.

Some current day examples of interesting juxtapositions and overlays of information:

• Google News, aggregates news from around the world gives a more interesting, if not clearer picture of differing perspectives
• Craigslist housing listings and Google Maps

Slide 17

By aggregating all of your data in a single system, you can create a feedback loops between top-down Project Planning and the bottom-up minute-to-minute triage you perform in your Dashboard view.

• Your Dashboard view contains all of your items, across all of your projects, organized by Triage status.
• Each individual Project view contains all of your items for that single Project, also organized by Triage status.
• Any Triage decisions you make in the Dashboard view will be reflected in the individual Project views as well and vice versa.
• For example, if you Defer a Task for the Security Project in the Dashboard because 10 new emergency items came in all of a sudden, that Task will also be Deferred in the Security Project view.
• Conversely, if you add 5 new items to the Now pile in the Security Project, that will be reflected in you Dashboard view. If you do that in too many projects, you will quickly realize you've overloaded yourself once you go back to the Dashboard view and see 50 new items piled up in Now.

Comments

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.

Q I'm sorry, but it's still unclear to me what facets are and how they differ from tags. Also, can you give a quick illustration of how "promoting labels to facets" would work? -- DavorCubranic - 21 Sep 2005 See answer below

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.

One take on why it's important that Chandler is a platform

Q In general in the Slides 13-17 section and in the associated slides, you have used tasks, bugs and issues. Would it be appropriate to change these to something else? I think it may be harder for someone that is not a developer to see the ideas in the slides and the text.

A Okay, maybe just Shared Documents and Shared Project manager? I wanted something that tracked fairly low-level things. I guess it's one of my own pet theories about High-level managers, is that they don't have very good visibility into bottom-up realities (ie. bugs). If there was a way for people up the chain to get real-time overviews of low-level things like bugs, it would give the executive summaries they're used to a little more depth and nuance.

Re: A While high level people should be more concerned about low level items, it may not be possible for them given they have to be aware of so many different projects. They are only human after all. Often the issue is too many levels of management between the top person in the hierarchy and the people doing stuff. That's my experience at least. I think for a CIO, they are probably tracking their own tasks, and project from their various managers. They may have one or two projects that are currently the hot items for them, ones that they are getting pressure from the Chancellor, state government officials, or faculty.

Re: Re: A Re: slides 14-17...A caveat on what I said earlier, I wouldn't expect a CIO to be tracking progress on individual bugs. The idea is more that by pulling together information from disparate sources, Chandler allows them to easily review the overall status of ALL bugs in relation to different project areas.

The assumption is that a lot is lost when bottom-up status is dumbed down and encapsulated into a written executive summary. But what if Chandler could pull together bottom-up, data-driven high-level summaries that were higher resolution, yet easily digestible?

What if higher-level managers could use high-level views of low-level issues as a supplement to their executive summaries and status overviews?

ie. You know Project Part A is due in 3 weeks, it would be nice to see that you actually have 4 weeks of bugs still open for Part A.

You know Project Part B is going to have a long release cycle, but looking at the bug list, there is really 1 huge bug that everything else is dependent on. How can you decouple dependencies such that the success of Part B isn't bottlenecked by that single bug? etc...

Such views don't really exist today, so I can understand how this might be too difficult to convey in a short presentation.

Here's an example that might help: http://www-personal.umich.edu/~mejn/election/ How do these illustrations (especially the ones lower down in the page) better represent election results than the following written executive summary: Bush won with 28 states and 254 electoral votes. Kerry lost with 20 states for 252 electoral votes.

Are you familiar with Edward R. Tufte's analysis of the Columbia Shuttle powerpoint presentation given to higher-ups at NASA before the launch. His thesis is that the powerpoint format actively made it harder for people to understand the seriousness of the problems being described.

More specifically, the text-based, summary-based, linear structure of powerpoint presentations makes it almost impossible to overlay related issues. As a result, individual problems that seemed "not-so-bad" when presented in isolation turned out to be "critically dangerous" when taken in sum. But the structure of the presentation itself made it hard for both the presenters and the reviewers to see the causal relationships, the very chain reaction that ultimately did the Columbia in.

http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB&topic_id=1&topic=Ask+E%2eT%2e

This is my personal bias wrt why people should care that Chandler is a platform. It's not just that outside developers will be able to customize Chandler to meet particular personal and organizational needs, but that the aggregation of the community's efforts will result in:

1. a powerful way to juxtapose and overlay heterogeneous data from disparate sources
2. so that we can begin to understand how the various pieces of information we currently interact with and manage serially, across various silos, fit together to form a larger picture. (The process of turning data into knowledge.)

Now I will step down from my soap box :o)

Tags versus Facets

Q I'm sorry, but it's still unclear to me what facets are and how they differ from tags. Also, can you give a quick illustration of how "promoting labels to facets" would work? -- DavorCubranic - 21 Sep 2005

A Hi Davor,

I just saw your question about facets. The relationship between Tags and Facets is subtle and hard to explain and even harder to understand, so I'm glad you brought it up.

In a way, you can think of Tags as an example of a Facet: The Tag Facet. So when you look at an individual item, you see a list of Attributes like this:

From: Mimi Yin
To: Davor Cubranic
CC: OSAF Development, Chandler Design list
BCC:
Subject: Re: [Design] Chandler in a Nutshell
Body: Hi Davor,...
Tag: Facets, Questions, Nutshell Presentation

So when in Chandler you promote a Tag value: (ie. Questions) to a Facet, what you're doing is applying a different Facet (ie. Issue type: Questions) to the Questions Tag.

So now the attribute value: Questions, is no longer a value of the "Tag" facet. It's a value of the "Issue type" facet.

In more goal-oriented terms, Tags are the most "generic" way to describe items. But as a result of their generic nature, Tags are also hard to manage because you can easily get way too many Tags and no way to differentiate them.

So, a system that allows you to define new Facets (or Attributes) and promote existing Tag values to become values of the newly defined Facet (ie. Tag: Questions --> Issue type: Questions), is essentially a system that allows you to better "organize" your Tags.

Some UI for this might be:

Dragging a Tag out of the "Tag: " field onto the detail view, thereby creating a new field with an "Untitled" field label. So back to the previous example:

From: Mimi Yin
To: Davor Cubranic
CC: OSAF Development, Chandler Design list
BCC:
Subject: Re: [Design] Chandler in a Nutshell
Body: Hi Davor,...
Untitled: Questions
Tag: Facets, Nutshell Presentation

You could also imagine right-clicking on the Questions tag and finding an option that somehow gets across the idea that you can: Apply a different Attribute name to this Attribute value.

If you've previously defined Questions to be a value of the "Issue type:" facet, you could pop up a suggestion below the Tag field when the user types in Questions as a Tag value.

Tag: Facets, Ques...

---

Issue type: Questions

Clicking on Issue type: Questions would apply the Facet to the Questions Tag value.

---

I'm copying here from my email to the design list my comments on making the presentation clearer. -- DavorCubranic - 23 Sep 2005

Would it be possible to explain the Tag-Facet difference in such concrete terms fairly early in your "fifteen minute Chandler" presentation? I think it may be a bit too abstract right now, and when facets appear in slide 10, I felt like I must have missed an important lecture and don't have a clue what's going on.

One possible way to deal with this in a very simple way is to be more consistent in terminology. For example, the illustration on slide 11 talks about "grouping labels". This is basically promoting tags/labels to facets, correct? If it is, how about mentioning facets on that slide? I think it would really pull together many of the slides.

Another presentation issue: I had a similar lost feeling when I came across the "bi-level hierarchy" in slide 13 -- it kind of appeared out of nowhere and disappeared just as fast, leaving me wondering if I'd just missed something really important.

One last thing: I was reading user docs for Piggy Bank today (thanks to a mention I found in this list's archive), and the flexible reorganization that you mention at the end of the notes for slides 9-13 ("by project>by person") made a lot more sense. But will your audience know what you mean here? I certainly didn't when I was reading it yesterday, FWIW.