Design Issues Meeting 18 November 2003

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

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

The purpose of this meeting was to discuss sharing issues, record working decisions, and hence make the issue more tractable. Brian prepared a list of SharingDesignIssues before the meeting, and we went most of that list. (Editorial note: Brian has since annotated the SharingDesignIssues, with icons and red text denoting decisions made. I will try not to duplicate his effort too much, but there are some points which are probably worth expanding upon somewhat.)

(Editorial note: For today, Mitch felt more comfortable using the term "group" instead of "cluster". He's nervous about having to explain the term "cluster" to people. It isn't clear which term we'll use in the future, so I'll use "group" here -- but that might end up being "cluster" in the future.)

What can I share?

Mitch gave a central idea that sharing is all done by sharing a CPIA View -- that you couldn't share things in isolation, only when they were associated with a View. (This didn't mean sharing the presentation aspects of the View, only the data in a View.) This implies a fundamental affordance for creating named groups within a View.

For example, Mitch's assistant could keep an "Esther Calendar" and a "Mitch Calendar", each with its own set of access permissions -- who it's accessible to and on what terms. Esther's calendar could be private, while the "Mitch Calendar" could be read/write for Mitch and read-only for Mitch's wife. (These access permissions would apply to any group of Content Items, not just Calendars.) This also means that if I have an ad-hoc named group (like REI shopping list), I can easily create a View to share that.

Brian asked whether you could share Items on a sub-group by sub-group basis. For example, if you had a View that had your Home Calendar and your Work Calendar overlaid, could you share just the Work Calendar from that View? Mitch felt no -- that you'd share all or nothing of a View.

Mitch felt that you wouldn't be able to share an arbitrary, plugged-in Capplet (e.g. "MyMP3Player") because there wouldn't be a View for it. Andy pointed out that we might have a View at some point to manage Capplets, and Mitch pointed out that such a View would not be ready by the Canoga release.

For query results, Mitch said that you get one group "for free" -- whatever is in the view, just share it, boom, you're done.

Mitch opined that the Calendar MonthView was slightly different: if you're showing "December", you're not really only showing events that happen in December, you're showing a sliding window onto your calendar. In that case, sharing the View should share all the Calendar Events (including November, January, 1954, etc). If you really only wanted to share December, you could always go fabricate a crippled calendar that only showed December.

For email threads, Mitch suggested that we could decide you share whatever's in the view as a whole, so to show just a thread, you would need to create a view that showed just that thread.

In the discussion of queries, Mitch said that he felt it was okay to have either

• a view that consists entirely of one or more named groups OR
• a view that's based on a single query of arbitrary complexity with no subsets for sharing

but he was concerned that mixing those options would confuse users.

Mitch felt that fundamentally, we were interested in sharing Content Items as opposed to any form of Chandler Item.

There was quite a bit of discussion about whether to share any presentation elements. It was unclear how much -- if any -- of the presentation aspects of data should be shared, but Andy felt that we would need to at least have a mapping for which View the data should be viewed in.

Who can I share things with?

Mitch's basic principle for who I can share with is anybody for whom I have a Contact record with a unique string (like Jabber ID), a handshake (e.g. Jabber subscription), is someone I can share with.

There also needs to be a way to refer to a repository by something like a URL. There are lots of details to work out on that as well: machines might not have static IPs, people might have multiple machines, etc. If you could get at that repository in that fashion, the other person wouldn't necesssarily have to be on your roster.

MK when I first run Chandler, how do I get a list of other Chandler users? In general, you don't. While an autodiscovery feature like Rendezvous would be nice, it's potentially technically very difficult. We might have some facility where you could look in a known Chandler directory (e.g. a company directory) for addresses of people you could share with.

Terminology: if you subscribe to some shared information, you keep a local cached copy in your Chandler respository. (This is useful if either you or the data owner go off-line.) If you browse someone else's information, you do not keep a cached copy.

What can I share?

Mitch believes that to keep the problem tractable, the access controls need to be at the granularity of the ViewGroup^?.

Questions arose about whether or not you could make changes to an item that you had subscribed to while still being able to receive updates to that item. For example, if you subscribed to a calendar event which had a 15 minute reminder, and you wanted a 10 minute reminder, could you do that? There seemed to be two options:

• If you have write permission, you could change the reminder time to 10 minutes, but then everybody would have a reminder time of 10 minutes.
• You could make a local, private copy of the event that you edit, and edit it to your heart's content. However, if the owner changes his/her copy of the event (e.g. to change the meeting location), then you won't get updated with the change.

(Mitch had to leave the meeting at this point. We continued without him.)

We had a little bit of trouble with the notion that you share all of what you see. What happens if you have a detail view of Contacts that only shows business Contacts' name and work phone numbers, but not their street address? Do we use the model like for the Calendar where you're only seeing a limited view onto the Contacts but you share the entire contact? If so, how do you hide the note, "This guy has horrible table manners"?

Or do you only share what you see? If you only share what you see, does that mean you need to create a separate View that only shows free/busy in order to share that? Or a specialized View that doesn't show that note about the guy having lousy table manners? Mimi felt that sounded like pretty high-level customization.

Or do we have access control on a field-by-field basis, where some attributes are marked "never share this"?

Mimi continued to be concerned about links. She felt that perhaps users would need to say how many links deep from an Item should be shared.

What can we do with things that I see?

We discussed what you could do and what you couldn't do with data you could see. We decided that it made no sense to try to prevent anyone from doing anything that the could do with a simple copy-and-paste.

We continued to grapple with the question of wanting to allow annotating items that the user doesn't have write permission for, with no great success.

Push vs Pull

We talked about "pushing" items to other people via Chandler sharing. Clearly, you can always email either an item or a link, and we in agreement that email and IM were both quite reasonable transport mechanisms.

There seemed to be agreement that if Janice wanted to send an Item to Paul, she should attach it to an email message as a subscribed item. If Janice's repository was off-line when Paul got the message, Paul could use the copy in the message. If Janice's repository was on-line, Chandler would pull the Item directly from Janice's repository.

Mimi noted that this was a way to share at a per-item granularity instead of a per-view granularity. Would Janice need to construct a View that only has the one item in order to share it? The consensus was that that sounded yucky. Perhaps users only share views; single items are always sent as copies.

Andy did express the desire that if Janice and Paul are both online and in their Chandler Calendars, Janice ought to be able to generate an invitation, get it to Paul, have Paul accept, and receive Paul's confirmation, all without either of them having to leave their Calendars. (Editor's note: while I don't have notes to support it, I believe the consensus was that doing this outside of email was not a Canoga feature. @@@)

We agreed that both the sender and the reciever have to make decisions about whether something shared should be a copy or "live".

Links

The thorny linkage questions came back to forms of the annotation question: how does the user change metadata -- in this case, links and groupings -- when the user doesn't have write permission?

As an example, suppose that Janice has a Contact for her sister-in-law Wilma, and Wilma is in her "Family" group. She shares her Family group read/write with her best friend Paul, including Wilma's Contact record. Paul knows Wilma, so wants to put Wilma into his "Friends" group. To do that, presumably he'll need to put "Friends" into the group attribute of her Contact info. That should not get propagated back into Janice's repository. However, if Paul knows that Wilma got divorced, he could take Wilma out of the Janice's "Family" group, and that should get propagated. (Editor's note: this example assumes that Items know what Groups they belong to.)

We talked about strong links: suppose Betty receives an invitation to an event that she doesn't have write permissions on. Mimi interprets the email message and invitation as being strongly linked, but does Betty has the ability to make that strong link?

Summary

(See also SharingDesignIssues.)

Consensus

• Views can reference not only query results but also named clusters/groups, presumably as an additional query term. (Editorial note: Presumably this implies that Queries need to be able to return named groups.)
• For Canoga, there will be no discovery mechanism (like Rendezvous).
• To "push" Items to other people, users will need to use email or IM.
• Users should be able to attach multiple items to an email message.
• If a published Item (A) links to a private Item (B), then others who see A will not see B or even that A linked to something.

Open Issues

• View can have multiple blocks, each of which can is composed of a query. How do you share the multiple groups of data elements?
• Going forward, do we use the term "group" or the term "cluster"?
• Should we call "groups" instead, "independent attribute groups"?
• How does the user create Views?
• If we have a Repository View Capplet, then the user could potentially share any arbitrary Item, but allowing read/write permission on any Chandler Item could enable strange edge cases which we presumably wouldn't want to deal with for Canoga. Does this mean we disable the Repository Viewer?
• Is it appropriate to share some of the presentation elements of the View? Could we do that without making sharing way too complex?
• Can you refer to someone else's repository by something like a URL?
• How does delegation work?
• How can you restrict which attributes you share (e.g. only free/busy, "this guy has lousy table manners", etc)?
• What should Chandler do when an Item arrives by email?
• Sharing by email seems to be at a per-Item granularity, not a per-View granularity. Is that okay? Would someone have to create a View with one Item in it in order to email that item to someone?
• Does it make sense to have requestor/requestee attributes for Items that can't be shared?
• Can you make strong links to things in someone else's repository for which you do not have write privileges?
• Can you make FYI links to things in someone else's repository for which you do not have write privileges?
• Can you put a "remote" item into a one of your groups?
• If you make a link to something remote and then the remote Item is deleted, what do you see?

-- DuckySherwood - 18 Nov 2003