Sharing revisited

Status Quick write-up of what we have thus far.

Motivation

• Discuss and decide on the basic (dog food) sharing scenarios, use cases and workflows
• Discuss and begin a list of the important basic features for sharing
• Discuss sharing network architecture in relationship to these workflows.
  • Get alignment on the most important pros and cons of each architecture approach in relation to these workflows.
  • We note that conflict resolution is the biggest issue in the peer-to-peer architecture. I want to explore this issue in finer-grain detail in relation to these workflows
  • See if this sheds light for finer-grain sequencing of the bigger network architecture decisions

See Also

• CanogaSharingDesign20040419
• SharingNetworkArchitectures
• SharingConflictResolution

Use cases

	Sharing Scenarios
	2-Person Calendar Sharing	Workgroup Calendaring	Share an invitation for 2 other people	Share an invitation with 20 people
Examples	Mitch's calendar managed by Esther & Mitch	OSAF events calendar managed by Esther	Chao organizes design team meeting	Blue and OSAF Xmas Party
Privileges	RWA	RWA	RWA	RWA?
Use Cases
a	Schedule appointments	Schedule or edit events (mostly Esther)	Schedule or edit appointment (Chao)	Schedule or edit event(Blue)
b	Move appointment times around	Sign up on an event as a participant	Enter participants (Chao)	Enter participants
c	Add / remove participants	Edit attendance attributes	Edit attendance attributes	Edit attendance attributes
d	Schedule meeting rooms (Mostly Esther)	Write what you're bringing for the potluck picnic in the Notes field	Schedule meeting room (Chao)	Reserve/change venue (Blue)
e	Write up agendas / meeting notes (Mostly Mitch)	Write comments on Meeting notes of a meeting you didn't attend (wiki)	Edit agenda (Mostly Chao)	Write-up directions (Blue)
f			Write meeting notes (Mostly Chao)	Write-up itinerarya (Blue)
Workflow Stages
Sharing initiation	Enter list of sharees
	Push invitation to share to subscribers
Accepting the share	Click invitation link to pull collection	Click to pull collection	Click to subscribe to auto-updates	Click to subscribe to auto-updates
	Opens up in a different window	Opens up in a different window
	Click to subscribe and cache collection	Click to subscribe and cache collection
		DnD specific items into your own collections to subscribe to individual items OR Add yourself as a sharee on a particular item
Editing attributes	a,b	a	a	a,d
Editing body text	e	d,e	e,f	e,f
Editing ACL	c, d?	b,c	c,d?	b,c
Item Conversations can potentially solve conflicts for...	a,b,c,d	a,b,c,d	a,c,d	a,c,d,e,f
Sharing termination
Turn off sharing	Turn off sharing while you do major renovations. Sharees retain last known version of shared items in their repository
Remove sharee from ACL (i.e. disinvite someone)	For discussion: Item / collection is rescinded and removed from sharee's repository. [OI?] Is this always what the user wants to do? Sharer may want to rescind the Share. Sharee may want an archive of work done in the past even if I'm no l longer an active collaborator?
Delete item / collection	For discussion: Item(s) and links to shared item(s) removed from sharee's repository. [OI?] What if a Sharee deletes an item simply to indicate that they are not attending the event.

Other sharing scenarios to consider:

• Sharing contacts (2 and 20 person)
• Sharing tasks (2 other people)

Observations by Chao:

• Above scenarios really involve 1 or 2 writers, and optionally many more readers
• Sharing initiation will have to involve linking to WebDAV server if we adoption Network Arch. #1 (see below). Otherwise, sharing initiation is similar in all 4 scenarios
• Privilege granularity is not that critical to DogFood^? release. Restricting item sharing to select people is the more important security feature
• For above scenarios, I think actual problematic conflicts are rare (see below for discussion on conflicts). Would the Item Conversation affordance be sufficient to mitigate conflicts in the above scenarios? We should validate this with a good P2P expert through more concrete and in depth look into these use cases.
• Do we want to treat body text editing differently from attribute editing?
• We have some sharing termination choices to make but any decision we make does not fundamentally affect network architecture choice (or vice versa) and we can easily unmake sharing termination choices.

Sharing initiation workflow storyboard

Sharers initiate
1. Go to collection detail view via:

• Rt-click sidebar collection
• Menu item
• Clicking on the "share" toolbar button (change since 8/18/04, toolbar needs updating too)

2. Add subscribers:

• What happens automatically:
• Mark-up bar changes visually to reflect that the collection is being shared
• ACL default setting is W(rite) for everyone
• 3rd column displays each subscriber's share status (ie. whether the collection has been viewed, subscribed to, still waiting for a response from fellow subscribers)
• Preview of the collection is placed below the notes field
• Item conversation (aka Comments) live below the preview
• At the end of the editing session (basically when the user stops interacting with the collection detail view), newly added subscribers are automatically capital "N" notified of this new share

• What the user can do:
• Change default ACL settings (ie. Read or Off, which temporarily suspends subscriber's sharing privileges -- does not delete item from subscriber's repository)
• Add a note
• Add a comment

3. Explicitly click "Notify"

• OR Stealth mode (not in .4): If user doesn't explicitly click "Notify", Chandler auto-sends (at the end of the edit session) a small-n notification that appears in the sharees' notifications log.

Sharees accept
1. Subscribers receive Notification of share as an item in their Dashboard view. The detail view of this Notification is IDENTICAL to the collection detail view described above EXCEPT: the "Notify" button has been replaced with a "View live collection" button.

• What subscribers can do in response to the Notification:
• Ignore it, which will be reflected in the detail view of the collection as: Subscriber share status = Waiting
• 2. Click View live collection, which pulls the live collection from the Host's WebDAV server and is reflected in the detail view of the collection as: Subscriber share status = Viewed
• A temporary (there will be a visual cue) collection appears in the sidebar (just for .4)
• Chandler auto-selects this new collection. The detail view of the collection is IDENTICAL to the detail view of the Notification item except: the "View live collection" button has been replaced with a "Subscribe" button.
• 3. User can click on "Subscribe" button to add collection permanently to their repository, which will be reflected in the detail view of the collection as: Subscriber share status = Subscribed

• Share_Collection_Workflow.gif:
  

• Collection_Detail-view_200.gif:
  

Sharing Termination

1. Subscriber deletes an item. What happens in the other subscribers' repositories?
   • Motivation
     • Mistake
     • Cancelled event / task
     • Junk
     • No longer relevant (ie. Contact for a restaurant that closed down. Out-dated research on a digital cameras.)
   • Proposal:
     • Delete item [specifics to be dealt with under the "deletion semantics" topic]

1. Subscriber removes fellow subscriber from ACL.
   • Motivation
     • Removee is no longer working on the project
     • Changed job roles
     • No longer on the team
     • Left the company
   • Proposal:
     • Collection exists with a flag indicating that it is no longer a "live collection"
2. Subscriber suspends sharing by setting AC privileges to Off
   • Motivation
     • Subscriber (A) wants to work "offline" for a while, but doesn't care if other subscribers continue to update and share: A sets their own AC privilege to Off. (This is the same as A literally going offline for a few days, so it shouldn't affect other subscribers at all.)
     • Subscriber (A) wants to continue to work with subscriber B but suspend sharing with subscriber C: A sets C's AC privilege to Off
     • Suscriber wants to rescind the share. (A shared a collection of embarassing photos of her friend and she made her promise to take them offline.): ??
     • Subscriber deletes collection.
   • Proposal:
     • Collection exists with a flag indicating that it is no longer a "live collection" and that sharing has been suspended
     • [OI^?] If one of many subscribers suspends sharing, does that suspend sharing for everyone? What if the person who suspends sharing is the owner of the WebDAV account hosting the collection? Can everyone else still share except that the owner of the collection neither shares nor sees changes made by other subscribers.

Observations
It seems like there are essentially two roads to travel down.

• Delete the item / collection
• More nuanced solution
  • Disconnect the item / collection
  • Flag it as such
  • Explain the action that was committed (ie. You have been removed from the ACL OR This item has been deleted by Mary)
  • Give subscribers the option to either delete or save for archiving purposes
  • We must be mindful in this approach that a disconnected item, may still be shared or later be shared in yet another collection. The disconnected item then needs to be brought up to date.

Proposed solution

• Removed and Deleted items will be "flagged" put in a special collection (like the Trash can) with an explanation of why it has been put in this special collection:
  • Item has been deleted by a subscriber
  • Item has been removed by a subscriber
  • You have been removed from the ACL...
• Subscriber can then choose to "D"elete it or save it
• [OI^?] If A shares an item via a shared collection, does that item exist in both A's Dashboard view AND the shared collection? Does the item still exist in A's Dashboard view even if it's been "removed" from the shared collection?

Resharing

Resharing is a general term we have used to describe the need to share an item or collection of items with other people in addition to the original group of sharer and sharees. I break this general issue down to 3 different resharing scenarios to more concretely address the issue. [Put in this context, resharing is probably not the right term?]

• Assumption: Sharees of a collection have the same privileges to all items in the collection except for the ones marked private (CanogaSharingDesign20040419 #21 & #22)

• 1. Resharing a Collection
  • Example: Esther and Mitch share a calendar. Esther goes on vacation and wants to add Greg as a sharee to the calendar
  • Proposal: We will not allow the collection to be shared by separate groups of people in a disparate fashion. i.e. there is only one AccessControlList for any one shared collection. All sharer and sharees appear on the same addressing fields in the detail view of the shared collection. So, you don't really "reshare" a collection.

• 2. Resharing an Item (simple case)
  • Example: Heikki adds Aparna to a standing meeting for the QA/Release Mgmt working group
  • Proposal: Same as "resharing a collection". There is only one AccessControlList for any one shared item. All sharer and sharees appear on the same addressing fields in the detail view of the shared item.
    • Sharee's to a collection(s) containing this item should still have access to this item, but they are considered distinct from sharee's of this item itself and do not appear on the addressing fields in the detail view of the shared item.

• 3. Resharing an item because two separate shared collections contain the same item (complicated case)
  • Example: Mitch and Esther share a calendar containing an event: "Sharing Workflow meeting", of which Mitch and Mimi and attendees. This event is also contained in the "Project Sharing" collection that is shared by the Design working group.
  • Proposal: This is the most complicated scenario. Proposals in scenario#2 should still hold. In addition, changes made to this reshared item is propagated to all sharees in all shared collections of this item e.g. If Esther makes a change to "Sharing Workflow meeting", Chao gets to see it in the Design working group calendar.
  • resharingItem.gif:
    

.4 target

• Basic functionality to support entire collection sharing workflow
• WebDAV account set up
• Collection detail view:
  • Subscriber list with error checking to make sure:
    • Sharees have an account on Sharer's WebDAV server
    • Contact on subscriber list contains both sharee WebDAV account and email address
  • Headline
  • Notes
• First-time "N"otification to initiate Share
• Sharees can view invitation and "View live collection"
• Sharees can "Subscribe" to collection (True Sharing)
• Auto-polling and updating of subscribed collection (without notifications)
• Sharee stops sharing (receiving updates) when removed from subscriber list

• Nice to haves
• Subsequent "N"otifications
• Sharee sharing status
• Preview

Workflow

1. Bring up detail view of collection by:
   • Click Share button in Toolbar
   • Rt-click item and select Share from the context menu
   • Collection menu item: Share
2. Add subscribers with email addresses
3. Chandler validates email addresses against WebDAV userids. Status: Validating, Validated, Invalid userid
4. [optional] Change ACLs: Viewer, Editor, Off
5. [optional] Write note
6. Click Send

• Sharing status information
  • Sharer: Uploaded, Error
  • Sharee: Pending, Error (either sending out the invitation or downloading the collection), Viewed
• Sidebar collection sharing status information: Uploaded (out arrow), Downloaded (in arrow), Not online, Error (like Apple Mail)

• Sharing_detail_while_enteri.gif:
  

• Sharing_detail_after_enteri.gif:
  

Comments

Sharing rule-based collections
StuartParmenter 28 Jun 2004: Scenario: When you share a collection with a rule, do you share the collections as an explicit list of items? or do you share the rule?

MimiYin 28 Jun 2004: Initially, we will simply share the collection as an explicit list of items. In the future, we want to be able the share the rule as well.

• [OI^?] Is the rule specific to the sharer's repository or is it generic to all subscribers' repositories?
• Checkbox option: Apply this rule to my repository as well.
• Dogfood version: No sharing of rules

ChaoLam 07 Jul 2004: In 0.4, we only share the explicit list of items not the rule. Rule-sharing is fraught with issues and we will revisit it later.

Representing major and minor versions to the users Capital N v. small n versions

• Do we even need minor versions?
• If we have minor versions, can we combine them into a single ad-hoc collection with major versions.
• Proposal: View all major versions of item X (all capital N notifications) in the context of it's discussion thread with a separate link to "See all version" of this item will expand the thread to include minor versions as well.

[Insert] Sketch

Information Design
How do we represent the hierarchy of versioning? Especially when there's a deep network split between two competing versions of an item. (ie. Each version has had multiple revisions)

Hybrid Proposal

• Implement proposal 1
• Implement proposal 2 for collections where owner is the only one with one with write priveleges (except for item conversations)
• Implement proposal 3 just for 1-time send
  • [OI^?] Is proposal 3 implemented through XMPP or Email?
  • What about IMAP / Chandler integration issues with deleting items?
  • When you delete an item, are you deleting the item? or deleting a version? How do we differentiate?
    
    

Scenarios to consider if we do 1-time send sharing for items and WebDAV for collections

1. What write privileges mean in Collection sharing.
   • Esther and Mitch are sharing Mitch's work calendar. Both have RW access. The calendar lives in Mitch's WebDAV account.
   • Mitch sends out an invitation to Chao and Lisa re: .4 planning meeting for Tuesday at 4PM.
   • Later on, Esther reminds Mitch that he should probably leave an hour to get to his speaking engagement in Berkeley at 5PM on Tuesday.
   • Mitch asks Esther verbally to please change the time of his meeting with Chao and Lisa to 3PM.
   • This assumes:
     1. Esther can hit Send on items in Mitch's calendar even if she neither organizer nor participant.
     2. Esther has Chao and Lisa's email addresses (as static text) even though she may not be sharing Chao and Lisa contacts with Mitch.

1. Additive access privileges
   • Esther and Mitch are sharing Mitch's home calendar. Mitch has RW access. Esther only has R access. The calendar lives in Mitch's WebDAV account.
   • Mitch sends out an invitation to a July 4th party to friends, acquaintances and KKIE folks. Amongst the KKIE folks is Esther.
   • Dilemma: As a subscriber to Mitch's home calendar, Esther has only R access. However, as a participant in a specific event on Mitch's home calendar, Esther should have the same (1-time send) W privileges of any other event participant.
   • Proposed rule of thumb: When a sharee has conflicting access privileges as a result of being both a subscriber to a collection and a participant in a particular item in the collection, they're privileges should be additive.

(Collection: RW) + (Item: 1-time send RW) = All changes are automatically sent out to fellow collection subscribers AND changes can be 1-time sent to all participants of the item.

(Collection: R) + (Item: 1-time send RW) = Changes are NOT automatically sent out to fellow collections subscribers BUT changes can be 1-time sent to all participants of the item. Fellow subscribers receive changes via Mitch's WebDAV server account.

• • If Esther is not a participant in an item, she cannot edit it.

1. Notifying ghost subscribers on an item
   • Esther and Mitch share a calendar
   • Mitch asks Esther to schedule a meeting room for a meeting and to Notify him when she has done so
   • Esther schedules the room and edits the event item
   • Esther clicks Notify to notify Mitch, even though no one is specified in the Participants field
   • [OI^?] What if there are participants specified?
   • [OI^?] What if this item is shared in multiple collections with different subscribers?
   • Possible solution: No "N"otify for collection sharing at all
   • Possible solution: IRC like: type "N"otification's recipients name into comments to PING them
   • Possible soloution: Click and hold "N"otify to select specific people to "N"otify
     • [OI^?] Can we "See all subscribers" on this item?

ChaoLam 07 Jul 2004: Finegrain individualized notification will have to wait post-Canoga

[OI^?] What issues will come up as a result of the mental model shift we're making wrt server-centric sharing?

• Mental_model_shift.gif:
  

MimiYin 23 Aug 2004: Feedback for sharing

Feedback for the various stages of sharing will probably be one of the hardest things to get right in the workflow and should probably be high on the priority list for .5.

• When does the share start? When I send out the invitation? Or when people accept and download for the first time?
• Do we need to show people the status of the sharees? Who's seen the invitation? Who's accepted? Who's successfully synced up?
• Do we need to show time status? Last sync for both the user and the sharees?
• Do we need to show who made the last change to the share and when they made it? * How is this going to help us with conflict resolution?

MimiYin 23 Aug 2004: Filtered shares See FilteredShares.

• WebDAVaccountsetup^?.gif:
  

3 Proposals for Modeling Collection sharing

No kind filters. Special my mail, calendar and task collections with owners (ie. My calendar v. Jamie's calendar)

• Sample sidebar: Esther
• No kind filters
• Triage
• In
• Out
• My home calendar
• My work calendar
• Mitch's calendar
• Karl's calendar
• My tasks
• My home tasks
• Junk
• Trash
• Labels
  • Home
  • Work
  • Fun
• Pros
• Clear way to manage my items v. someone else's items
• No need to understand kind filters
• Assumes user will be working in a sharing environment
• Cons
• Cannot filter Label collections by Kind
• Need to explicitly label items as my items from the GET GO
• Will users need to create multiple categories of my stuff (ie. My home calendar)
• How will these categories interact with generic label categories? (ie. My home calendar v. Home label)
• Can you share labels?
• Do we keep track of ownership of shared labels as well? (ie. My home v. Jaime's home)
• [OI^?] How likely is this use case?

Kind filters, create separate collections to share

• Sample sidebar: Esther
• Kind filters
• Triage
• In
• Out
• Junk
• Trash
• Labels * Home * Work * Mitch's calendar
• Pros
• Can filter all collections by Kind
• Labels = the ways users create multiple "my calendar / taks* category collections
• Baby steps: Let's provide a generic way for users to share collections and see what they do with the feature before modeling "templates"
• Cons
• Need to create separate my calendar collection when you share it with someone else
• Users still need to explicitly label events as mine, however, they only need to do this if they're sharing someone else's calendar
• Harder for users to distinguish and manage mine v. yours
• Mitch will need 2 clicks to see his calendar (the one managed by Esther)

Filtered shares

• Sample sidebar: Esther
• Kind filters
• Triage
• In
• Out
• Junk
• Trash
• Labels * Home * Work * Mitch's calendar
• Pros
• No need to create and manage a separate my calendar collection to share
• No need to explicitly label new events as my calendar events in order to share them in the right collection
• Cons
• Potentially more complex
• Doesn't really differentiate between mine and yours
• 4 possible configurations
  • Sharee defines filter parameters (sharees cannot change)
  • Sharees can change filter parameters for everyone
  • Sharees can define their own filter parameters
  • Share and Sharees can define their own filter parameters per sharee