Design Issues Meeting 20 November 2003

Attending: MitchKapor, AndyHertzfeld, MimiYin, BrianDouglasSkinner, DuckySherwood

This meeting, by and large, was a continuation of the November 18 Design Issues meeting. Some of the decisions have been captured also in SharingDesignIssues.

(Editor's note: these notes are my best understanding of what we believed on 20 November 2003. There are few guarantees that this will be an accurate depiction of reality in the future.)

Mitch opened by retracting his prior opinion: he realized that a calendar would not be useable if everyone had the same reminder time, so now believes that alarms need to be settable on a per-user basis.

Mitch likes the "what you see is what you get" metaphor for sharing. Brian asked about two scenarios:

• navigating to your "November" calendar view and sharing it -- does that publish December or October events?
• closing a disclosure triangle in a shared View -- does what's 'under' the disclosure triangle cease being shared?

Mitch felt that in both cases, you should get all of the data even if it wasn't actually visible on the screen: December events, October events, and what's 'under' the disclosure triangle. Consensus was that we need to look at more case-by-case use cases to figure out what's appropriate when.

Mitch discussed Group behavior with this scenario:

• Mitch has Contacts 1, 2, 3, and 4.
• Mitch's group A contains Contacts 1, 2, and 3.
• Mitch's group B contains Contacts 1 and 2.
• He shares group B with Brian.
• To Brian, Contacts 1 and 2 belong to both group A and group B.

Brian asked if sharing a group shared the name of the group. This would be undesirable if the name of the group revealed feelings you wished to keep private, like "People I Hate" or "Arrogant Bastards". Mitch guessed that if you were trying to share the group, then the name would follow, but if you were doing something more ad-hoc, then the name wouldn't show up. (Editor's note: I think that means that in the above scenario, Brian would be able to see the name of Group B but not the name of Group A.)

Mitch feels that we don't have good intuition for how sharing ought to work because we have no example of sharing working well. Public folders work reasonably well, except they lack a notification scheme: users aren't alerted when something changes.

Mimi asked what the difference was between Groups and Projects. Mitch said that a group could be created simply by dragging Items into a View. From a user standpoint, a group could be either

• an explicit set of Items (i.e. ones that were dragged into a View)

or

• all Items satisfying a Query

Groups are like an iTunes playlist; queries are like a Smart Playlist.

Mimi asked which group an Item dragged into a View went into if that View had two groups in it already. Mitch figured that it was probably the Group that was "on top" (in the iCal "layers" metaphor).

Mitch tossed up a drawing (which he went to great pains to point out was not to be taken as a final representation, just as a sketch to illustrate one particular idea). The drawing had a calendar taking up most of the view, but two columns of checkboxes on the left. One column of checkboxes was labeled "Show" and the other was labeled "Share". Next to each of the checkboxes were names of Groups ("Home", "Work", "Other"). The idea was that if you wanted to see the Home calendar yourself, you'd click "Show". If you wanted to share your Home calendar, you'd click "Share". If you only shared the "Home" calendar, the other users wouldn't see "Work" or "Other" in their checkbox list.

Schema Evolution

Mitch expressed an interest in making sharing transitive across link boundaries; if you share A and A is linked to B, then B is shared.

Mitch feels that there should be a way to allow people to add attributes or attribute values even if they don't have write permission on the original item. Whether that should be allowed when browsing is unclear.

Suppose Mabel publishes a Contact read-only, and Wally subscribes to it and adds an attribute. If Mabel then adds an attribute, what happens? What happens if Wally, then Mabel, both create the attribute "Associates", but one is a String and one is a Group?

Mitch had the strong opinion that if groups of people were going to collaborate well, then it would be critical for them to have a shared vocabulary of project names, attribute names, group names, etc. The alternative would be to give power users a set of interesting tools for renaming, etc, but normal users wouldn't be capable of dealing with that level of complexity.

Mimi pointed out that if she needed to go through a formal negotiation to share an Item, she'd just always email Items instead. Brian pointed out that for most user, most cases, most times, sharing would just work because most users, most cases, most times won't be mucking with the schema. He also pointed out that attributes have UIDs as well as labels, so you could always disambiguate with UIDs.

Repositories

There was some discussion about where a replicated Item "lived" -- if there was one repository that was "cannonical", or if people subscribed to Items in the abstract. For example, suppose Henry has his repository on his laptop and replicated on a relay server under his department admin's desk. Jackie subscribes to Henry's SuperPizza Contact Item, but then Henry takes his laptop offline. Does Jackie treat the SuperPizza Contact Item on the relay server as being the same as the SuperPizza Contact in your repository? Mitch thinks that Items are subscribed to in the abstract, so yes.

Summary

Consensus

• Chandler must allow different people to set different alarm/reminder times on shared events.
• There is strong interest in being able to mark all of an Item "private".
• If Paul has subscribed to a Contact in Wilma's repository, and Wilma deletes it, then it should disappear from Paul's world as well.
• There should be a way to change/add attributes to an item that you have permission to see, even if you don't have permission to edit it.
• If you change the schema, there should be a way to mark particular attributes as private, but Canoga won't support having something be private for one person and public for another.
• Users subscribe to Items in the abstract, not tied to one particular repository.

Open Issues

• Can you put an item that you've subscribed to into one of your own groups?
• What is our taxonomy of link types? While we need to treat different link types differently in the UI, do we need differences in the data model?
• When you share an Item, what related information goes along with it? Group membership?
• If someone subscribes to Group A and to Group B, can they see when there is a link from one of the Items in Group A to one of the Items in Group B?
• Can you share/hide individual attributes of an Item?
• If Janice is running a later version of Chandler than Paul, and Paul edits something in Janice's repository, what happens?
• Should users be able to annotate (change/add attributes to) an item if they are browsing (not subscribing)?
• Access to a repository can only be done by an administrative user (who, by default, is the creator of the repository).
• A repository can have multiple administrators.
• For a local Chandler, you will need to have at least one account.

Action Items

• We need to look at individual use cases to figure out exactly how tightly to adhere to "what you see is what you share".
• Our documentation needs to be cleaned up to reflect that T and C are one Kind now.
• Ducky to write up meeting minutes.

-- DuckySherwood - 21 Nov 2003