Design Issues Meeting 4 November 2003

Attending: MitchKapor, MimiYin, ChaoLam, BrianDouglasSkinner, DuckySherwood

Taxonomy of Clusters

Mimi went over her taxonomy of clusters (see ClusteredView).

Mitch is not comfortable with the rigidity of the thread-like category being homogeneous (e.g. only E items in an E thread).

Navigation between Views

Mimi showed three different ways to present the summary view of clusters, and a few other ideas came up. I've added all of them to Jungle.ClusteredView.

These cases concerned strongly-linked items. Mitch has the strong intuition that there are only a very few cases where users will see strong linking, and that we ought to treat those on a case-by-case basis.

Mitch also thinks that assuming that items will be silo'd into separate homogeneous views might be a poor assumption. It might not be bad, but it just might not fit the data set of what people need to do.

In particular, there was a discussion of whether a thread was homogeneous or heterogenous. Mitch made a ConferenceOrganizerScenario case for heterogenous threads. That case has a sequence of items being created in this chronological order: E1, E2, T1, E3, C1, E4, T2, E5. IIRC, Mitch felt that this heterogenous collection was a thrask.

There was also discussion how a thrask should be redisplayed if the summary view switched from being X-centric to Y-centric. For example, if a user creates three sub-tasks to an email message while in the email view, then switches to to a Task view, what does the new view look like?

Option A	Option B
E: speak at conference? T: research conference T: check schedule T: talk to Bob	T: research conference E: speak at conference? T: check schedule E: speak at conference? T: talk to Bob E: speak at conference?

Mimi was concerned that the users would be confused at the data shifting around from how it looked when they entered it. Mitch was very certain that users would want the data to redisplay based on the View. He drew a picture of how Agenda showed two different views of children's blocks would look -- sorted by shape or by color -- depending upon whether you were in the "shape" view or the "color" view. He said that the data rearrangement was precisely what people loved about Agenda.

Mimi felt that the rearrangement was slightly different here in the case shown in the table above because the email message was acting as the title [supertask?] of the subtasks.

Mitch said that if it confused users we should do something else; that it was a visual design problem.

Relatedness

Mitch presented an idea for showing linked items where + and - buttons allow the user to show more or fewer items. The "relatedness" of two items would be how many links away. For example, suppose E1, E2, E3, and E4 are in a thread, and a T is linked to E1. If your focus is on E2 and E1 are one unit away. E4 and T1 are two units away.

There was some discussion of whether an item is linked to another item or to an entire thread. Mitch felt that if a Y item was attached to a thread of X's, then the Y was a distance of two away from all of the Xs.

Mitch's intuition about tasks

Chao asked Mitch to give a braindump of his intuition about how users will use Tasks. Mitch thinks:

• People will associate Tasks with Projects much more than they will associate any other types of items to Projects.
• People will create Tasks from anywhere, but the Task organization will happen in the Task View.

Summary

Consensus items (for people in room)

• The nesting/stacking view shown in Jungle.ClusteredView is too complex and confusing.
• To be successful, Chandler must
  • make it easy for users to link objects to each other
  • do a great job showing relationships
• The email capplet is more important than the calendar capplet or the task capplet.
• We do not have good intuition about how people would use a Task tool because there are no task management tools that lie between "toy" applications and full-blown, heavyweight project management software.

Things which might be consensus

• An item can be in multiple thrasks.
• Thrasks and projects might be the same thing (or implemented in the same way), but if a thrask is not explicitly named, then nothing appears in its "Project" column. Naming a thrask doesn't add anything to the schema.

Open issues

• [OI] Are thread-like objects homogeneous? For example, can you have a T in an email thread?
• [OI] What are the specific use cases where you'd have strongly-linked items?
• [OI] If an X is linked to a Y that is in a thread, is the X linked to that specific Y or to the entire thread of Ys? What do use cases suggest?
• [OI] Can you have groupings of thrasks? Can one thrask be inside another thrask?
• [OI] If an item can be in multiple thrasks, and you expand a thrask, how are the two thrasks it's associated with shown?

Action items

• [AI] Mitch to come up with a prioritized list of use cases Chandler should support (as starting point for discussion)
• [AI] Mitch to present workflow for task management (not ready Thursday)
• [AI] Mitch and Mimi to check in at 3:30 PM Wednesday
• [AI] Mitch and Mimi to meet Thursday at 10 AM to compare use case lists
• [AI] (implicit) Mimi to explore strategies for displaying clusters
• [AI] (implicit) Ducky to write up and send out meeting notes Awaiting feedback

-- DuckySherwood - 05 Nov 2003