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.5 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 sharing invitations are done through specialized emails sent and received behind the scenes. Conflict resolution is also handled behind the scenes and with the server as the source of truth.

Overview

The following page describes the collection sharing functionality and workflows that we would like to support in the 0.5 release. Most of the workflows center around enhancing the invitation process and putting in place the infrastructure for setting and changing subscriber permissions.

Terminology

No new sharing terms introduced for 0.5.

Feature List

Can be found on 0.5 planning page.

Assumptions

• Only true sharing will be supported for 0.5. Remote browsing has been deferred until post Kibble.
• This spec does not address any server side requirements. These are listed in a separate document.
• All previous wedDAV accounts used for 0.4 will be wipped out. We are not going to handle the migration of any old user data or meta data.
• Any ACL work will be on the backend only. No UI will be in place to display or modify sharers and/or sharees access privileges.
  • Assume everyone has Read/Write privileges and the collection is world visible to those with accounts on the webDAV server.
• There is only email address validation for the invitee list, we do not check that the invitee has a valid webDAV account.
• Upon accepting a share, all items in the share are automatically added to the sharee's All collection.
• Sharees cannot edit the name of a share they have downloaded.
• Once a sharee is participating in a share, there is no mechanism to remove them.

Detailed Use Cases and Workflows

End to End Use Case

Sheila, wants to share her calendar with Chao and Mimi to schedule design meetings. She navigates to her calendar by choosing the calendar app from the app bar and selecting All Calendar Items in the sidebar. By selecting the Collection->Share menu item, the collection detail view is displayed. Her default webDAV account is set to pilikia (OSAF account). She then clicks on add invitees and enters email addresses for both Chao and Mimi. Sheila will have had to check with Chao and Mimi in advance to determine which email to use. Once the invitees have been added to the list, Sheila may or may not choose to add something in the notes field. She then clicks Send to send a sharing invitation to Chao and Mimi.

Chao receives the invitation as an email but he is away on vacation so the invitation sits in his inbox.

Mimi doesn't receive the invitation and emails Sheila. Sheila goes to Collection -> "Manage share" to display the share detail view. She sees that only Chao and herself appear in the participants section. Sheila adds Mimi's email again in the invite section and clicks Mimi's email incorrectly, she edits the email and click the "Send to New" button. Mimi receives the invite and selects the item in the summary view. The detail view of the inviation collection is displayed. Mimi clicks on the button to accept the share and a new item appears in the sidebar "Sheila All" with the download icon next to it. If Mimi goes to the collection detail view for that share, she will see herself, Chao and Sheila are participants. Mimi can add events to the calendar and click the sync button to upload changes to the server and download any events of changes Sheila may have made to the calendar.

Use Case: #1: Account preferences and setup

Success Criteria

• A. The webDAV account preferences dialog will now have 3 prepopulated accounts to choose from. Both Sharemation and Venue Comm are giving us a public account to use for this.
  • i. pilikia (OSAF account)
  • ii. sharemation
  • iii. venue communications
• B. By default, the pilikia account will be selected if the user tries to share out of the box. [OI^?] Need to check with Jurgen about this. SM
• C. The user can go and change the account to one of the other 2 or add a new one. Any of these can be selected as a default, using a check box.
• D. If the user does not setup the SMTP information necessary to share a collection, and attempts to send a sharing invitation, they will get an error. This happens when the sharer selects the notify button. The accounts dialog will popup to the SMTP information prompting the user to enter this.
• E. When a sharee receives the sharing invitation and attempts to download it, we automatically try and use the corresponding webDAV account selected by the sharer. If the sharer is using another webDAV server (not pilikia, sharemation, venue comm), the sharee is prompted for a username and password that they would have had to obtain from the sharer. If the sharee does not know this information, they can cancel and try to download the share later since the invitation will remain in their inbox until they delete it.

Use Case #2: Display collection detail view

Success Criteria

• A. The Share button on the toolbar should be removed for 0.5.
• B. The Collection menu contains both "Share" and "Manage Share" menu items.
• C. Depending on whether or not the collection selected has been shared, either the "Share" or "Manage share" menuitem is enabled.
• D. If any item is selected in the summary view, it is deselected when the collection detail view is displayed.
  • MimiYin 20041117: Are we going to have 2 selection colors? If we are, we can grey out the selection in the summary table and make the sidebar selection the blue "I am the focus" selection color.
• E. The collection detail view is replaced by an item detail view by selecting another collection in the sidebar or an item in the summary view.

Use Case #3: Add invitees to share this collection and send invitations

• Kibble Sharing detail view

• Sharing_detail_zeropointfive.gif:
  

• Sharing_invite.gif:
  

Success Criteria

• A. The detail view for an unshared collection has the following fields
  • i. Sharer - "me" [OI^?] We will probably just have the sharer email text for 0.5 and not the fancy "me" lozenge. Also, we are not supporting multiple email addresses per contact so there is no affordance for entering a single contact name (ie. Katie) and selecting from a pulldown list of different email addresses for Katie.
  • ii. Invite - default has "add invitees" in grey text. [OI^?] Not sure if the grey text is possible, use whatever makes sense for 0.5. SM
  • iii. Title
  • iv. Sync checkbox (default checked).
• B. The sharer can clicks on the "add invitees" field and start typing emails separated by commas.
• C. Upon tabbing out of the field, the emails are validated as in 0.4.
• D. Send button activates once email validation is complete and their is at least one valid invitee, otherwise it remains greyed out.
• E. Error handling when sending invitations will be similar to 0.4. [OI^?] Revisit with John.
  • i. Uploading the collection may fail, in this case an error icon appears next to the shared collection in the sidebar. [OI^?] Stretch goal, have an error message appear when clicking or mouse over the icon. Need to revisit this with John to find out behaviour for 0.5. SM
  • ii. The invitations may fail, in which case the sharer will receive an bounce back email from the sharee's mail server. Is it left up to the sharer to manually resend any invitation that failed.
  • iii. The collection uploads successfully in which case an upload icon appears next to the collection name in the sidebar.

• F. The detail view for an already shared collection has the following fields
  • i. Participants - Includes everyone that we believe is sharing including myself. Field is a read only list.
  • ii. Invite - default has "add invitees" in grey text. [OI^?] Not sure if the grey text is possible, use whatever makes sense for 0.5. SM. Editable field to add new invitees.
  • iii. Title
  • iv. Sync checkbox (default checked).

Use Case #4: Accepting the invitation and sharing statuses

Success Criteria

• A. Sharee receives the sharing invitation as an email in their inbox.
• B. A button on the email detail view is used to accept the share. Clicking on it accepts the share.
• C. Once the share is accepted, the button is disabled, if you have that share locally.
• B. The sharee selects the item in the summary view and the invitation detail view is displayed.
  • i. from: me
  • ii. to: invitee list
  • iii. subject
  • iv. date sent (not sure if we are going to have this)
  • v. accept button.
• C. The sharee clicks the link.
• D. The share name appears in the sharees' sidebar with an icon indicating the share was downloaded. [OI^?] Want to have a pre-defined way to name the share ie: sharer prefix in email then append the collection name.
  • i. If an error occurs, an error icon appears next to the share name. MimiYin 20041117: We probably also need to display some explanatory text in either the summary table view or the detail view (ie. We are unable to download this collection. OR We are unable to connect to your server account.)
  • ii. If it's successful, the sharee can view the full sharee list in the collection detail view.
• E. The sharee can delete the invitation or simply leave it in the Inbox to accept later.
• F. Once the sharee accepts the invite, they invitation still remains in the inbox until they delete it manually.

Use Case #5: Editing the collection detail view and resending invitations

Success Criteria

• A. Any sharer or sharee can bring up the collection detail view by
  • i. Selecting the shared collection in the sidebar and selecting menuitem Collection->"Manage share".
  • ii. Clicking on the sharing status icon in the sidebar [OI^?] Find out if this is possible for 0.5. SM
• B. The participants field is not editable. Includes the sharer as well as those who are currently sharing.
• C. A user can add new sharees but adding emails to the Invite section.
  • i. Adding something to the invite section will enable the "Send to New" button on the toolbar.
  • ii. An invitation will be sent only to these new sharees. The invitation received by the sharees will only have those names on the invite that were part of the group who were getting this invite. Once they except the share, they will see all the participants. The from field on the invite will indicate the name of the person who sent the invite, might not be the original sharer.
  • iii. If reinvite the same person who is already a participant, they will not be added twice to the participant list. We do this by matching emails, if you use a different email, it's interpreted as a different person.
• D. The user can suspend synching by unchecking the sync checkbox. [OI^?] Check with Morgen if the sharee names will still get updated or if stop synching applies to ALL updates.

Use Case #7: Sharing termination etc

Success Criteria

• A. Sharer or sharee can temporarily suspend synching by unchecking the sync checkbox in the collection detail view.
• B. A sharee or sharer can delete an item from the collection.
• C. A sharer can delete an item from there All my items collection that happens to be in the shared collection.
  • MimiYin 20041117: Not for .5, but in the future we will need to provide a dialog when users delete shared items from the All collection because in some instances, users might want to remove the item from their repository but keep it in the shared repository. For example, if Sheila is sharing the OSAF calendar and decides she can't make the next staff meeting because she's on vacation, she might want to remove the staff meeting item from her personal "All my events" collection, but she doesn't mean to delete for everybody else. This only comes up in the All collection because there isn't supposed to be a notion of "remove" in the All collection.
• F. A sharee can delete a shared collection using a menu item.
  • i. This is deleted from the user's repository but others can continue to share.
  • ii. This user's name will remain on the share list.
  • iii. This user can go back to the original invitation and download this share again.
  • iv. User can ask for another invitation if they have deleted it.
• F. A sharer can delete the collection
  • i. This would remove the share for all other sharees. The sharees can chose to keep a local copy of this collection. MimiYin 20041117: Basically the next time the sharees go to sync, they will receive an error icon next to the shared collection. They can click on the error icon to see an explanation of why the share failed: This collection has been removed from the server by the sharer. At that point sharees can either keep the collection or delete it from their repository as well.
  • ii. The share is removed from the webDAV server.

Use Case #6: Sharing a collection which has been filtered using the application bar

End to end use case

Sheila selects the Events application button and then selects All Events in the sidebar. She wants to share her entire calendar with Chao. By clicking on Share in the collections menu, she brings up the detail view changes the name to Sheila's Calendar and adds Chao's email as an invitee. She clicks Send. An "Uploaded" icon appears next to the All Events name in the sidebar. Chao receives an email invitation and accepts the share. Sheila's Calendar now appears in the sidebar with a Download icon and the Events application button is automatically selected. Chao adds a couple of events to the calendar. Chao choses Mail from the app bar and Sheila's Calendar appears with greyed out text and a greyed out download icon. Chao then adds emails to Sheila's Calendar in the Mail app area. Upon synching, only the events added to Sheila's Calendar will be uploaded to the webDAV server and shared with Sheila.

see ZeroPointFiveSidebarSpec

Items removed/deferred from Kibble and/or 0.5

• Item conversations (removed from Kibble)
• Remote browsing removed from 0.5 but still might be in Kibble. Will design workflows with only the true sharing option
  • Once a sharee has "viewed" the collection, a button appears in the detail view where they can choose "Subscribe"
  • If the user selects "Subscribe" the collection is permanently added to the user's repository.
  • The sidebar reflects the "Subscribe" status visually.
  • The sharees status is also updated to "Subscribed".
• Any complicated UI for merging conflicts will not be implemented for 0.5. After we have further experience with conflicts, we can understand what design is required. There MAY be something in Kibble (still under discussion).
• All changes to the collection are sent to sharees via email notifications (not in 0.5).
• Any user's free/busy information will be gathered from any calendar(s) they share and is available to any user with an account on the webDAV server. (removed the free/busy view from 0.5 on 11/12/04). this assumption can be removed from the sharing spec.

Mimi's original requirements listed below for validating sharees.

• • i. Validating email address: Resolves to grey lozenge with progress animation (while editing) and progress animation and grey text (after tabbing out of text field)
  • ii. Successful validation: Resolves to blue lozenge (while editing) and black text (after tabbing out of text field)
  • iii. Email address / userid not found: Resolves to red lozenge (while editing) and red text (after tabbing out of text field)

Use Case Deferred: Editing the collection detail view user permissions

Success Criteria

• [OI^?] PLEASE NOTE: This is spec'd for engineering but not available through UI in 0.5. *A. If a sharee's permissions are changed from Editor to Viewer or Viewer to Editor prior to the sharee accepting the invitation to share, this will have no visible impact, the change will be updated in the sharee's collection detail view and invitation to share once the sharee pulls the collection.
  • i.In this case, changing a user's permission simply updates the information on the wedDAV server. There are no nofications sent to the user, they simply get this update in the collection detail view the next time they sync.
• B. If a user was sent an invite with Viewer or Editor permission and they are changed to Off prior to accepting a share, they will still be able to click on the URL in the email invitation.
  • i. They will get an error dialog if they try and click on that URL to share.
  • ii. MimiYin [OI^?] Can we load the collection onto the sidebar anyway and display an error icon next to the collection? That way, when the sharee's access privileges are reactivated, the collection will automatically sync.
  • C. If a user is currently sharing a collection with Viewer or Editor permissions and they are set to Off, an error icon will appear next to the collection in the sidebar the next time the user syncs. Setting of Off suspends their ability to sync this collection.
    • i. If the user has made changes, they are updated only locally to this share.
    • ii. The next time the user tries to sync this collection, they get a popup indicating that their permissions were suspended.

Use Case Deferred: Sharing termination

• D. Once you are on the participant list, you cannot be removed.
  • i. I can remove my name from the list.
  • ii. I can remove someone else's name from the list.
  • This is a 2 step process. When the user syncs, the meta data for the list of sharees is updated. If I have removed myself, I will get an updated list of sharees with my name removed and the contents of the collection will not be updated (regardless of the state of the sync checkbox). If I remove someone else, when they sync, they will be the updated list and see that they have been removed, they will keep the current collection contents from the last time they synched. Mimi would probably like a smoother notification workflow here but if we can get the 2 phase update working for 0.5, I think this is a good initial goal.
  • ii. If user goes back to original invitation and tries to click on the sharing link, they share will fail with an explanatory message: You have been removed from this share.

Use Case Deferred: Polling and manual synching

Success Criteria

• A. As in 0.4 a user clicks the synch button on the toolbar to automatically synch all shared collections.
  • i. Sync works across mail and all shared collections. The user cannot choose to sync only a single collection in 0.5.
• B. Automatic polling at 10 min intervals will also synch shared collections as described in WebdavService.
  • i. The polling interval will be fixed at 10 min and the user can't change this.
  • ii. Any conflicts that arise (ie: we are editing an attribute that has changed and polling starts), will be handled the same way as merge conflicts.
  • iii. The user cannot turn off polling.

Use Case Deferred: Enhanced conflict resolution

Success Criteria

• A. This is still an open area for 0.5. Morgen may choose to make some changes here.

Running issues list - Status

• Need review from Mimi and Chao (11/09/04)
• Schedule second walkthrough or review with engineering for 11/11/04.

-- SheilaMooney - 03 Sep 2004