Design Issues Meeting 3 Nov 2003

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

Chao opened with an overview of where he sees this series of meetings heading -- see DesignProgram.

Mitch drew a CoarseInformationItemSchema that there was consensus on.

Scenarios

Mimi walked through the first two sections from Workflows -- the spawning scenarios and the spawning workflows scenarios. Most of the discussion centered around inline editing.

Inline Editing

Comments: Mitch's experience with Agenda says that users have a hard time figuring out inline editing, so that must not be our only way to create items (or links). However, he feels strongly that in an email View you need to be able to see other types of items, and a View without editing is bad.

Conclusion: Mitch would like inline editing, but recognizes it is a design challenge to make it work well. Giving alternate creation/linking methods is a possible way around the problem of users getting confused.

Discussion: If, in inline editing mode, a user inserts a Task under an email message, is that new Task a subtask of the email message, or is it a strongly-linked task to the email message? Decision: the first Task created is a new Task, strongly linked. If the user wants to then make subtasks of that Task, then they can indent under that Task to create sub-tasks.

Projects

Do attributes assigned to an item carry through to things that are strongly linked? For example, if you create a Task, make a strong link to a Calendar Event, then assign the Task to the Bake Sale project, does the Calendar Event also get assigned to the "Bake Sale" project?

Instead of giving the Calendar Event the project of "Bake Sale", we could instead show the "nearest neighbors" for projects: because the Calendar Event is strongly linked to the Task, it would show up as well when a query for "Bake Sale" items was run.

Views

Consensus: What makes an X View an X View (where X is E, T, or C) is that all the clusters are headed by X items. In other words, in an E View, all the "header1's" in the outline structure will be Email messages.

[OI]: An item can be in two clusters. For example, an email message could be in an email thread and in a cluster with Tasks. How do you show both? Perhaps, since we can have a hierarchical display, both the thread and the thrask should be shown.

Detail Views

Some of this discussion is captured on the DetailedView page.

Mitch drew a form which looked somewhat similar, I will approximate here:

Description: Requestor: Requestee: Schedule:

Brian pointed out that in that view, we're encouraging people to think of it as one item, so why not have it be one item?

Mitch redrew his picture to have a dotted line between the "task" part and the "calendar" part

Description: Requestor: Requestee: Schedule:

Mitch allowed as how he might give in to Task and Calendar being one thing -- and attribute propagation (i.e. changing X on an item would also change X on item that was strongly-linked) if and only if he could be sure that this would only happen for strongly linked types.

Mitch reiterated that he feels that trying to solve the generalized case of item mutability is the wrong approach, that we should instead focus on the special cases and figure out what small number of cases should be strongly linked.

Chao wondered if we should let users decide if an item is strongly or weakly linked; Mitch was unequivocal in his desire for Chandler to determine strong/weak linking, not the user. I believe there was consensus on that point.

Clustering

This discussion is captured on the ClusteredView page.

Summary

Open issues

• Once you link an X to a Y, what can you then link to the Y?
• In what scenarios do you have strong linking?

Consensus

• To approach the design task in the rough order proposed DesignProgram (though with the caveat that we are unlikely to acheive or even strive for slavish adherence to that linear of a model).
• The hierarchy described in CoarseInformationItemSchema.
• (I think there was consensus, anyway.) FYI links being asymmetrical -- if you have a note "recipe for brownies" as part of five different bake sales (each with their own task), each bake sale task will include the recipe as an FYI, but the recipe doesn't FYI link to the bake sales.
• Users should not be allowed to determine whether an item is strongly or weakly typed.
• Tasks and Calendar Events frequently want to be displayed as one item. (I'm not sure we're actually all the way to consensus on them being one item, but we're close.)
• What makes an X View an X View (where X is E, T, or C) is that all the clusters are headed by X items. In other words, in an E View, all the "header1's" in the outline structure will be Email messages.
• (Somewhat tenuous and provisional consensus): Attribute propagation is appropriate if items are strongly linked.

Action items:

• Mimi to come up with specific scenarios for each of strongly linked pairs and a recommendation for what should happen in each case [with respect to whether a Project attribute propagates to the strongly-linked item?].
• Mimi to come up with a taxonomy of clusters and linking types. see ClusteredView and Relationships.
• Mimi to come up with a formal definition for Thrask. Covered in DesignIssuesMeeting20031104
• Mimi to reproduce Chao's diagram. , see DesignProgram
• Ducky to annotate Chao's diagram. , see DesignProgram
• (Implicit) Ducky to write up meeting notes. Awaiting feedback

-- DuckySherwood - 03 Nov 2003