Step-by-step Sharing Initiation Process

Terminology

• Sharer = owner of repository
• Sharee = remote user who wants to access sharer's repository
• Share = the act of sharing a particular item collection.

Also, see UnifiedSharing for wireframes detailing interactions below.

Sharing a View

Sharer wants to wants to share a view (it's in actuality a collection, but to the sharer it's sharing a view).

• Requirements from sharer when initiating this share:
  • User affordance in the view to say "share this view"
  • User affordance to add people (contacts) to access control list of this view.
    • Permission levels are:
      • none
      • read-only
      • edit
      • admin
    • Permission recipients:
      • "public" (or "anyone", or "world")
      • a contact
      • a group of contacts
    • @@@ is it a contact that is added to the ACL? how does Chandler choose the right unique identifier in the contact?
    • The unique identifier will be used as the user name in subsequent authentication processes
  • Can notify sharees (i.e. people added in ACL) out of band. In this case, sharer needs a URL to inform sharee of the new share
  • Should optionally be able to notify sharees that a new share is available through IM or Email
  • Unless permission level is public, each sharee must have a password to access the share
    • Passwords are assigned per sharee per repository, not per share per sharee per repository
    • One-time key pads are used to sync up password between sharer and sharee
      • One-time key pad scenario:
        • Sharer's Chandler generates an email message to sharee containing a one-time use URL to sharer's Chandler.
        • When sharee receives and accesses the URL, Chandler presents sharee with a view to choose a permanent password.
        • Only after sharee chooses password is the new shared view presented to sharee
        • One-time use URL can mean that the URL will only the user to choose a password from this URL once. Subsequent accesses to the URL will simply show a static text message that the URL has been used.
        • Sharee uses permanent password to access shared view subsequently
• Requirements from sharee when initiating this share:
  • Sharee must receive a URL of the share, directly (out-of-band) or indirectly through email or IM
  • On navigating to this URL the first time,
    • If not using one-time key pad:
      • sharee is presented with a username/password authentication screen
      • sharee must enter assigned username and password (which is assumed to be provided out-of-band or in the email/IM
      • On authentication, sharee is presented with shared view
    • if using one-time key pad:
      • Chandler presents sharee with a view to choose a permanent password.
      • Only after sharee chooses password is the new shared view presented to sharee
      • One-time use URL can mean that the URL will only the user to choose a password from this URL once. Subsequent accesses to the URL will simply show a static text message that the URL has been used.
      • Sharee uses permanent password to access shared view subsequently
  • In both cases, Chandler offers sharee to "remember this password" for subsequent interactions
  • By default, sharee is acessing shared view by remote browsing. There should be a user affordance to change the sharing mechanism to "collection replication"
  • Sharee can also bring a single item in the shared view into a local view. In which case, that item is shared via "item replication".

Sharing an Item: Simple Basic Case: Send an static attachment by email or IM (no updates)

• Sharer should be able to attach any item in the repository to an email or IM conversation to send the item to a recipient
• On receiving the item, sharee can choose to include a copy of this item in her repository. She will have full ownership of this item, as if she created it.
• This attached item is not linked in any way to the original item. Changes in both items are not propagated in either direction

Sharing an Item: More Complex Case: Push and "Hot link"

In the above "Sharing a View" section, we describe how in a remotely browsed view can, a sharee can decide to pull an item to the local repository using "item replication" as a sharing mechanism.

However, often times, the sharer would like to "push" an item (e.g. via email) to the sharee. It would also be nice if this item were shared using "item replication" as a sharing mechanism. i.e. changes in the item by sharer and sharee(s) are propagated to each other. For example, a user may send a calendar event to a list of invitees. Invitees may respond to the event by annotation on the "Conversation" attribute of the event. In this way, we allow a lightweight, small workgroup calendar invitation process.

This sharing initiation process is similar to sharing a view but should probably be more lightweight. This hasn't been discussed, so there are a lot more open issues. I list my proposal and issues below:

• We need an user affordance to say send an item to be shared. We need to differentiate between "hot-linking" and the basic static case when sending an item
• We need to set users permissions for this item. @@@ Do we do this as in "Sharing a View" or do we need a lighter weight, implicit mechanism e.g. invitees in an email automatically have certain permissions to the item?
• If the item permission is not "public", user passwords are transmitted to sharee as per "Sharing a View"
• When sharee receives the item, @@@ can sharee also choose if item should be "hot-linked" or static?
• If item is to be hot-linked and permission is not public, sharee needs to be authenticated. When should this be done? When receiving the item? When polling for updates?

General open issue:

• We need more insight from the apps team as to how "replication" will work and what transport we use for sharing. One potential problem is the "discovery" of remote chandler repositories to notify and replicate changes.
• A particularly difficult version of this problem is how to notify anonymous sharees.

-- ChaoLam - 20 Jan 2004