Design Issues Meeting 13 November 2003

Attending: MitchKapor, AndyHertzfeld, MimiYin, ChaoLam, BrianDouglasSkinner, DuckySherwood

Relationships

There are two different types of relationships (as discussed in Relationships) which fall into two classes: clusters (what Mimi calls "item-based") and attribute-centric relationships. For example, "all the Email messages that have Status="Unread" would be an attribute-centric relationship, with "Status" being the attribute that all the messages are centered around. Clusters are groups of messages (discussed in more detail in DesignIssuesMeeting20031117).

Terminology: Mimi talked about how if a cluster is associated with an item, there is a difference between what she calls "linking to an item" and "linking something out ". If you drag and drop Item Y onto Item X's cluster, then you are linking Y "into" X's cluster. from Y's perspective, it's an "outgoing link". From X's cluster's perspective, its "an incoming link".

In traditional applications that show connections between items, other relationships between items in the set are not displayed. (See DickGoesToREI for an example of multiple relationships.) Typically, the user sees and undifferentiated list. For example, when you type "squash" into Google, you don't see pages about squash-as-a-food clumped together and squash-as-a-racquet-sport clumped together.

On the left of this drawing is a traditional view of the relatedness of items, and on the right is a depiction of items in context:

(Editor's note: Where it says "thrask" above, imagine "cluster". "Thrask" is a deprecated term.)

Workflow

Mimi pointed out that we have a tendency to group functionality by item-type silo: Email, Tasks, Notes, and Calendar Events. Instead, she suggested that we think in terms of work mode. She identified three modes:

• "Keeping track of your day" (AKA figuring out what to do next (including figuring out how to block out your day))
• Reviewing and organizing your "stuff"
• Monitoring for new activity -- where you're working in a completely different application (e.g. a word processor) but want to know if something important comes up.

(Editor's note: see also GrandUnifiedTheoryOfBasicCapplets.)

Mimi feels that Chandler's big strength is its ability to highlight different features in the "map" of your information world: forests, trees, villages, roads, mountains... and that which features need to be highlighted varies by which work mode you're in.

Mimi presented a sketch of an idea for processing mode (figuring out what to do next), where you see past, present, and future separated. (See GrandUnifiedTheoryOfBasicCapplets for a picture.) Items are organized chronologically: messages are located at when on your timeline they were sent. Calendar Events also show up on the timeline. Events and email messages colliding wouldn't be a big problem because email messages don't arrive in the future and you usually don't care as much about Calendar Events in the past.

(Editor's note: Yes, yes, we know that messages are sometimes forged to appear to be sent after they arrived, but in that case we'd use their Received timedate instead. Yes, yes, we will deal with timezones properly.)

When the user finishes with an Item, it moves into the "Past" section. They can also "snooze" an Item into the future. For example, if they want to reply to a message by 5 PM but not right now, they can snooze it so that a reminder is placed at the 5 PM spot. Or, if they want to snooze it until tomorrow, they can do that too, and it will move into the "Future" section.

Time passes. When it does, the timeline in the past can collapse (for space reasons), but the items will still appear so that you know you still need to handle them.

Andy raised an objection that when a message arrived wasn't generally important to him, and he really wanted a way to organize his messages semantically -- by priority. Mimi assured him that this was only one view, and did not preclude other views -- a supplement and not replacement. Andy reiterated that he didn't care when the message arrived but when he was going to deal with it. There was some discussion of how to roll over read/undone items into the next day.

Virtual Folders

Mimi then presented some ideas for virtual folders (VFs). She said that there were six levels of sophistication that we could support:

1. No virtual folders
2. A few default (built-in) VFs
3. 1 independent grouping (Editorial note: in this meeting, Mimi used the term "orthogonal buckets" for attribute-based groupings, but that has since been deprecated for "independent grouping".)
4. Wizard for creating independent groupings
5. User-customized independent groupings
6. Creating independent groupings from scratch

She showed a drawing of a "folder" view, where a summary view sat on top of a detail view, with a list of virtual folders spanning the rows on the left. The user can operate with multiple VFs in three different ways:

1. Switch
2. Intersect
3. Overlay

Finally, there are three different ways to group items in the summary view:

1. Clustering [OI]
2. Sorting
3. Clumping (like Outlook's "Group by" feature in email)
4. Color

There was some discussion where it was determined that a virtual folder was equivalent to a CPIA View. Mitch expressed some concern that normal users -- who won't even make folders for their email -- wouldn't be able to deal with the complexity of virtual folders. He expressed hope that we could provide users with a default set of independent groupings that would be useful to people.

One of the suggested groupings mentioned was "Sphere of Life". Ducky recapped a discussion she'd had with Mimi, where Ducky had suggested that if Projects were hierarchical, then "Sphere of Life" would be the top nodes in that tree, but that Mimi had had reservations about exposing users to too much hierarchy.

Mimi said that she now thought it might be okay to expose users to hierarchy, if we pre-populate with useful hierarchy. What we would hope that when users do create hierarchy, if they notice that they're creating the same sub-projects over and over again (e.g. design, implementation, and documentation sub-projects for every project), they would understand to create an independent group for each (e.g. a design group, an implementation group, and a documentation group) of those. If we can get that idea across to people, then the hierarchy shouldn't get nearly as complicated.

Summary

Consensus Items

• "Thrask" is an inappropriate word. We will use "cluster" instead.

Open Issues

• [OI] How would you migrate from a cluster-type relationship to an attribute-type relationship?
• [OI] In the "Do, Defer, or Delegate" model of task management, how do we do the "Delegate" tasks? (Sharing)
• [OI] How does the "keeping on top of your day" view work for week view and month view?
• [OI] In the "keeping on top of your day" view, where do you see untimed tasks?
• [OI] In the "keping on top of your day" view, how do "undone" things from one day roll over to the next day?
• [OI] In Eudora, you can alt/option-click to pull together related items in a View; what affordance will Chandler have (if any) for doing something similar?
• [OI] Which of Switch/Intersect/Overlay in the VF view do we want to support?
• [OI] Virtual Folders, as we talk about them, have some presentation elements, but "how much?" is undetermined.

Action Items

• Mimi to put together workflows on cluster vs. attribute grouping.
• Mimi to look to Brian for terminology. (Editorial note: we also discussed terminology in DesignIssuesMeeting20031117.)
• Mimi and Ducky to put together use cases with Items living in multiple clusters. (Mimi did this: see DickGoesToREI.)
• Mitch to present a current conceptual framework for sharing -- what the Mac got right and what the Mac got wrong (10-15 min).
• Chao to write up a "what we believe doc". (see DesignSummary.)
• Ducky to write up the meeting minutes.