Summary

Items created on one person's computer can be viewed and modified by others, and their changes propagated back across all users sharing that item. The implementation for 0.4 is a simple scheme to share a set of items. A whole collection is shared with no control over granularity or temination. Sharing is done on an item collection level, synchronized through a server, initiated manually by users. Shared informaton is stored on a WebDAV server and notifications are done through specialized emails sent and received automatically behind the scenes. Conflict resolution is also handled behind the scenes and from ther user's perspective, the last update wins.

Overview

The primary goals for sharing in release 0.4 are limited to supporting some very basic workflows. This enables us to put together the underlying infrastructure for sharing and facilitate some level of conflict management to get a sense of how often conflicts occur, why and how to deal with them. Although it is expected that the functionality will support sharing workflows for any collection, the calendar collection will be the target use case for 0.4.

Terminology

• Sharer � Person who initiates publishing a shared collection to others.
• Sharee � Individual who receives an invitation to share.
• Invitees � individuals to whom we would like to send a sharing invitation (name in To: field)
• Synching - When a user synchs a shared collection, they are committing changes they have made to the webDAV server as well as receiving changes that others have made to the same share. In certain circumstances, a conflict can arise.

Feature List

• Sharing of any collection.
• Account dialog to setup Webdav server details.
• Invitation published to one or more users.
• Resending invitations.
• Sharee can accept or ignore the sharing invitation.
• One of more users can edit the same items of a collection.
• The user initiates synching of the collection, manually.
• Conflicts are handled by �last modification wins� scenario.

Assumptions

• 1. The WebDAV server information is setup separately using the account preferences dialog. This information is NOT pre-populated with the WebDAV server account detail.
• 2. Shares are supported only at a collection level, not at the individual item level.
• 3. The invitee is given read/write access by default and no privilege granularity is handled.
• 4. The sharer can publish a share to another person but there is no feedback loop to validate that the invitation was sent to a non-chandler user versus a chandler user or if the invitation was accepted or ignored.
• 5. The sharer can resend invitations which enables them to add additional sharers to the list of invitees or resend the invitation if an error occurred.
• 6. If the sharing invitation fails, the sharee is simply notified that an error occurred, they do not know if it succeeded for some people and failed for others.
• 7. The invitee does not receive the email invitation in their inbox. They will simply get a popup invitation that they can choose to accept or decline. An email is sent from the sharer to the invitee and deleted behind the scenes.
• 8. The sharee has only one opportunity to accept or decline the share from the popup dialog. Since the url for the collection is not received in an email, they cannot choose to ignore the invite and decide to accept later.
• 9. Once a share is published, there is no UI to terminate the share.
• 10. Only manual synching is supported, not automated polling.

Workflows

End to End Use Case

• Sheila wants to share a calendar collection with Lisa. Sheila runs Chandler and uses the File->Preferences->Accounts menu to setup the WebDAV server account information. She then selects her calendar collection in the sidebar and clicks on the Share Sheila Calendar item in the collections menu to bring up the detail view of the collection. In the To field, Sheila adds Lisa's email address to invite her to share this collection. Sheila then tabs out of the To field. If the email is not valid, a "?" sign will appear next to the name, otherwise Sheila will go ahead and click the Notify button on the bottom right corner of the detail view to send the invitation. The collection in the sidebar is now called Sheila Calendar (Shared). Lisa is currently using Chandler and a dialog pops up inviting her to share this collection. She clicks ok and the collection appears on her sidebar. Both Sheila and Lisa can then go on sharing and making edits to the collection as needed.

Use Case #1: Setup the Webdav account setup dialog

• Success Criteria:

• a. User selects Preferences->Accounts in the Chandler file menu to bring up the account dialog.
• b. The user selects the WebDAV account "WebDAV" from the account list, which will be setup as a default.
• c. The following fields will NOT be pre-populated. The values of the last 4 fields are ignored for 0.4.
  • i Description
  • ii Server
  • iii Path
  • iv Username
  • v Password
  • vi Port
  • vii useSSL
• d. The user specifies the server details (a,b,c only)
• e. Some error checking will be done on the WebDAV server account info when the user clicks ok.
• f. Non OSAF users can make a request to obtain a WebDAV account or they can use their own WebDAV server. Instructions will be put on the wiki in the form of 0.4 release notes for both of these scenarios.

Use Case #2: Ways to get to the detailed view for a collection.

• Success Criteria:

• a. Highlight the Calendar collection in the sidebar to display the summary view. Select the Share button on the toolbar to display the collection detail view. A single click will bring up the detail view, there is no �depressed� versus �up� state. The toolbar button displays "Share" as the mouseover text. The text is constant regardless of whether or not the collection is currently shared.
• b. Highlight the Calendar collection in the sidebar to display the summary view. For an UNSHARED collection, select the "share collection " menu item under the collections menu to display the collection detail view.
• c. Highlight the Calendar collection in the sidebar to display the summary view. For a SHARED collection, select the "manage collection " menu item under the collections menu to display the collection detail view.
• d. Highlight a different collection in the sidebar. The summary view will be updated appropriately. The detailed view is either blank, or the persisted version (if we have previously selected this collection and selected an item in the summary view) is displayed. Click either the toolbar button or select the menu item to update the detail view to the collection detail view.
• e. If the user does not have a WebDAV account setup, clicking on the share toolbar button or menu item will automatically popup the File->Preferences->Accounts dialog with the WebDAV account selected.
• e. The toolbar button and menu item are always enabled even if the collection detail view is already visible, clicking the toolbar button or menu item does nothing.
• f. If the summary view is displayed with an item selected, and the corresponding item detail view is visible, clicking the toolbar button or menu item will display the detail view of the collection and �unselect� the item in the summary view.

Use Case #3: Collection detail view display and edit.

• Success Criteria:

• a. A collection detail view will have the following information.
  • i From field indicating the sharer.
  • ii To field, for entering the invitee email addresses.
  • iii Notes field.
  • iv Name of the collection.
  • v Notify button in the bottom. This will be always be enabled, allowing the user to resend the notification if an error occurs or invite additional sharees.
• b. The URL for the collection is generated behind the scenes and not displayed to the user.
• c. The user enters invitee email addresses and leaves the field. Some pre-validation of emails. Bad emails will be marked by �?� around them.

Use Case #4: Publishing a collection to be shared by clicking on the Notify button.

• Success Criteria:

• a. Upon clicking Notify, items are pushed to the Webdav server. In the case of an error, a dialog pops up. If not, the list of pre-validated emails and the URL are sent.
• b. Sending the list of invitees and URL is an asynchronous operation. Any error handling associated with this will follow the email error handling design solution for 0.4.
• c. If an error occurs sending the invite to one or more sharees, the user can send a subsequent invite by clicking on the Notify button. A notification will not be received by a previous invitee if they have accepted the invitation for this share. The mechanism used to determine if a user has seen a previous invite is to check if a copy of this collection is in their repository.
• d. On resending a notification, if the invitee did not accept the share, they will receive a subsequent invite.
• e. The sharer can choose to remove invitees from the email list. In this case, the notification will not be sent. If they had previously accepted the invitation to share, they can continue to share the collection.
• f. All fields in the detail view remain read/write.
• g. Collections menu item changes to manage

Use Case #5: Sharee receives an invitation to share this collection.

• Success Criteria:

• a. A user who is specified as subscriber on the sharer side receives a popup dialog with an invitation to share. Note: behind the scenes the invitation email is received, it�s deleted and the dialog is raised.
• b. The popup dialog contains the following.
  • i URL for the share
  • ii Email address or sharer
  • iii Name of collection
• c. The user can choose to accept or decline. The have only one opportunity to do this.
• d. Upon accepting the invitation, the collection name will appear in the sidebar with a text indicator that it is shared (and added to repository).
• e. The sidebar shows this new collection as selected. The collection summary view is displayed with no item selected and the detail view for the collecion is also displayed.
• f. If the sharee is already subscribed to the collection, they will not be able to reshare it. The Notify button, menu items, To field affordances are disabled.
• g. The sharee can edit the collection name (in the sidebar or detail view) and the notes in the collection detail view.
• h. The sharee presses the synch button to push changes to the server and their collection details/items will be updated with changes made by other users.
• i. If a sharer removed this sharees name from the To field and resent the invitations, the sharee will be able to continue sharing the collection but will see their name removed from the To field when they synch the collection.

Use Case #6: Users edit the shared item and sync changes.

• Success Criteria:

• a. The users who are sharing can edit this collection offline or online.
• b. Synching is initiated by clicking a toolbar button.
• c. The "GetMail" toolbar button will be replaced by a Sync button that retrieves mail as well as syncs all the users shared folders.
• d. Any user conflicts are logged behind the scenes.
• e. The user gets what is on the server so they may lose some changes. If a user is editing an attribute and the value has changed since the last time they synched, their edited value will be replaced with what is on the server.

Deferred Features

• Polling every 10 minutes was deferred due to some threading implementation issues.

Stretch Goals

• None at this point.

Open Issues

• 1. Investigate disabling editing and sharing of some sidebar collections, ie: "In".
  • Status: This is too difficult for 0.4. Resolved
• 2. WebDAV server info will NOT be pre-populated. Users can setup their own servers or request an account.
  • Status: Resolved
• 3. We may handle some progress tracking for the sync operation by providing feedback to the user regarding the status.
  • Status: Resolved, we will not implement anything for 0.4 sharing.

-- SheilaMooney - 03 Sep 2004