Fixed Parent-Child relationships are bad for managing personal information [INSERT EXAMPLE]

• fixed-parent-child relationships
• 1 way to walk the tree

• We're not saying that all hierarchical data models are bad in all situations

• Using hierarchy to store semantic information is bad
• Things can't be in more than 1 place
• Hard to change the structure
• If you take the item out of the structure, you lose all the semantics

• Mail>>Todo>>i18n>>BrianK>>Review proposal
• Done>>Review proposal (loses semantics of where it was before)

• Differentiate between hierarchical data models v. hierarchical UI affordances

• Dewey Decimal System: 1 location per item

Facets good

• iPod
• gmail
• summary table view

Another way to look at it

• Gets around to 1 item in multiple locations
• 1 collection in multiple collections

But facets have this problem, where people get lost, don't know which way is up

• Items in a soup of attributes is overwhelming
• Successful faceted system (ie. iPod) ground the user in fixed faceted world, differentiating between the attributes users need to navigate and incidental attributes that are less important. ie. Artist, Album, Genre, Composer
• You need a clear ontology of facets. A meta-ontology.

Hierarchy of attribute values is bad, but hierarchy of attribute is good

• Small data set
• Eternal concepts

What are the important attributes in an information manager?

• Kind or content type generally defined by the purpose of the content. People do different things with different kinds of items. ie:
  • Email is for communicating, so are IM, IRC, phone calls, snail mail and talking
  • Events are for scheduling
  • Tasks are for doing
  • Documents are for documentation and presentation, so are slideshows, spreadsheets, interactive demos etc.
  • Photos are for fun, so are songs, books, and movies
  • Contacts are for keeping around profile information, so are restaurant directories, product catalogs, etc.

• Collection or Area of responsibility, which can be further refined to be defined as:
  • Person, Client, Organization, Stakeholder (some entity)
  • Project
  • Project phase
• Based on user sidebars via sidebar survey, user interviews, research papers

• Properties or characteristics of items
  • Who
  • What
  • When
  • Where
  • Status is the most important one in (PIMs)

How are these 3 things different from each other?

• Kind is What a thing is which is different from some characteristic of a thing. What a thing is determines what kinds of characteristics it has. ie. Humans have height, weight, age, eye color, hair color, etc... It's the difference between:
  • Johannes is German (attribute) v.
  • Johannes is a German (kind)
  • In Chandler, a thing can be multiple "thing-types" (aka Stamping)

• Collection to the user is a personal conceptual grouping that is hard to define and almost impossible to express as a straight up query. It is fundamentally different from a query. Instead, the query is a means to an end. And the end is a concept that is fuzzier than the original query. ie. User may start with the query: All things that are To: or From: June. But really they want to create a collection centered around the idea of June. There's a purpose to "things having to do with June", there's isn't really a purpose to the query "To: or From: June".

• Properties are characteristics of the thing, that the user often has no control over. They are perhaps facts as opposed to opinions. They just are. ie. Hair color. Eye color. Height. Weight. But only the user can decide if the model belongs in the "Clairol look" group.
• The line between collections and properties is really blurry and largely up to the user to determine in many cases.
• Status is the most important property for PIM items.

Why is it important for elements of the Information Architecture to be different from each other (for the user)

• Nouns, verbs, adjectives
• Implementation wise: Items are the same as collections. But a user needs to have these thing look and behave very differently.

• An item is a unit of content. Examples of items include: Email message, task, event, contact, document, song, movie, book.
• An attribute-attribute value pair is a characteristic of an item. Examples of attribute-attribute value pairs include: From: Jane, Age: 10, Mood: Ecstatic

• Items v. Attributes v. Attribute values
• Items v. Collections

How do you pick UI affordances for each of these things?

• Item: Row in the summary table. Detail view.
  • You want to be able to see each item as a separate entity and each attribute of the item enumerated
  • The detail view is purely a practical solution for complex items that have a lot of attributes and/or long attribute values

• Attribute: Column in the summary table. Fields in the Detail view.
  • In a faceted system, you want to be able to sort and group by different attributes
  • For us, the most important grouping is by Triage status. Grouping is the right affordance for triage status because you really want to see a continuous story from Now-through-Later-to-Done. It forms a coherent thread when you're:
    • Evaluating progress on a project
    • Managing a task list and moving items between Now and Later

• Kind: Application area aka Action-mode
  • Kind is an attribute of an item, it is a means of organizing and grouping items. In other words, Kind is a navigation affordance.
  • People need to be able to start out with a Kind because Kind represents Action-modes
  • In traditional systems, Kind represents what Application you fire up: Word, Thunderbird, iCal, Omni-outliner, iTunes, Address book, etc.
  • Once users are in that action-mode, they then need to be able to organize their items by collections.
  • Use cases
    • Esther scheduling a vacation for Mitch and Esther across their calendars and OSAF calendar.
    • Managing tasks across 2 closely interdependent projects
    • Pulling together a set of resources (ie. documents, presentations, spreadsheets) to do a write-up
    • Putting together a photo album
    • Looking up a contact

• Collection: Sidebar item
  • Collection too is an attribute of an item. It is also a means of organizing and grouping items. Collection is therefore, also a navigation affordance that is equally important as Kind.
  • Until now, most software treats Collections as 2nd-class citizens. Users must always first select a Kind (aka application) before they can look at a Collection
  • However, in a faceted system, there is no notion of a fixed hierarchy, therefore, users can start out with Collection and then narrow by Kind if they so choose.
  • If collections are areas of responsibility, you really want to be able to focus on just a single area of responsibility at a time. (ie. Home v. Work or Project Foo). This means mutually exclusive views
  • Once you're in a particular collection, you may want to work with only one aspect of the collection (ie. respond to email, manage tasks, schedule meetings, etc)
  • Use cases
    • Keeping on top of everything as it comes in, in your universal Inbox
    • Planning a wedding
    • Preparing for a one-on-one meeting with your manager

Back to the sidebar design

• Kind and Collection need to be arranged in such a way that users can:
  • First start with Kind and then narrow by Collection OR
  • First start with Collection and then narrow by Kind
• This means both Kinds and Collections need to be visible in the UI
• Since the user is likely to have more collections than Kinds, it makes more sense to array Collections vertically, and Kinds horizontally.

Introducing a 3rd facet into the sidebar: Spheres of Life

• Some users might want to segregate their information along a 3rd axis: Sphere of Life. Examples include:
  • Home v. Work
  • Personal v. Public information: San Francisco Performing Arts.
  • Esther might have Mitch as a separate sphere in her sidebar.
• Sphere is also useful for determing "from who's perspective" you want to view the data. For example, in Esther's Mitch sphere, she will want to see all of his calendar data from his perspective wrt Event status, etc.

• The Spheres are a facet, not a hierarchy. This means:
  • The collections in each sphere are intersections of the collection and the sphere
  • The collections themselves can exist in an "All" sphere which includes items across all spheres

• This brings us into a discussion about how these 3 orthogonal axes in the sidebar are best displayed.

• What's the likelihood that there will be items of multiple kinds in each Project? High That's why we don't want to represent it with a hierarchical layout. Too much repetition and can only start with Kind. Defeats the purpose of facets because you always have to start with Kind.
• What's the likelihood that there will be collections that span multiple spheres? Low That's why this would work better represented in a hierarchical layout. Not much repetition and people are okay with always starting with a Sphere because there aren't many cross-sphere collections.

Different things in the Information Architecture need to be represented by different things in the UI

• Visual design needs to reinforce structural design
• Stamping is a good example of why Kind needs to be in a different place than the Collection attribute.