Framing the question

How do we provided an end-to-end, coherent sharing experience to satisfy the most basic needs of our Kibble calendar sharing use cases in .6?

Kibble calendar sharing use cases include:

• Small group or household calendar (ie. Apps team calendar)
• Organizational calendar (ie. Blue and KKIE)
• Delegated calendar (ie. Mitch and Esther)
• Spouse calendar (ie. Mitch and Freada)

Goals

Who is the target user for .6? Our existing community or a wider audience? For example, is it more important to provide our existing community of advanced users the flexibility of experimenting with Chandler sharing on their own WebDAV servers? Or is it more important to ensure that Chandler sharing works for the layman user? In our effort to deliver a coherent and useful set of calendar and calendar sharing features in .6, are we trying to get the developer community excited in .6 to help us cross the finish line with calendar? Or are we trying to stir up user interest in the general population of early adopters?

Prioritization

Below is a proposal for rules of thumb to follow when prioritizing features wrt usability:

• Comprehension over Ergonomics For example, it's more important to have an UI that clearly explains to users that they can only share with other users with accounts on the same WebDAV server (if we decide to do this), than to provide users with time-saving affordances such as email auto-complete.

• Comprehension over Visual polish It's more important that users receive feedback about the status of the share. For example, we may simply communicate "Sharee Anabel had problems accessing the share" as text, than provide a slick iconicl presentation of feedback. OR
• If the feature can't be polished, don't do it For example, if we can't deliver an icon-based UI that provides sharing status feedback for sharees, we shouldn't provide feedback at all.

• Generic over Customized It's more important to make sure most users have a successful sharing experiences most of the time (which might mean limiting .6 sharing to a single OSAF hosted server) than to ensure that a few users can experiment with Chandler sharing on their own servers.

Motivation behind having a sharing detail view

To provide users with a centralized Share management UI where they can:

• Set ACL
• Keep track of who they've shared the collection with
• Remove sharees
• Add sharees
• Track sharee status
• View the URL of the share

To make sharing feel a lot like and as easy as sending an email. In other words, to create a generic workflow for communicating information.

Proposals we've discussed for how sharing works for the end-user in .6

[Assumption] If we decide we need to provide a way for users to discover viable sharing participants via a directory of server accounts, it would greatly simplify the UI to limit users to a single WebDAV server. That way, we don't have to worry about providing UI to match email addresses against directories from multiple server accounts.

• If users can share with anybody with tickets to access share regardless of whether sharee is an account holder on the same WebDAV server as sharer, then there would be:
  • No need to match email addresses with user accounts
  • No need to limit users to a single WebDAV server
  • A need to implement tickets
  • A need for a web UI
• Sharing invitations are addressed to sharees using email addresses
• Sharees receive the invitations in whatever email client they use
• Sharees can access the share via the Web at which point, they can subscribe to the share if they have a Chandler client
• This means the sharer doesn't have to worry about whether sharees have WebDAV accounts or not

• If users can only share with other account holders on the same WebDAV server, then there would be:
  • No need to implement tickets
  • No need to provide web UI
  • A need to match at least Full name (if not email addresses) with usernames of account holders on the server
  • A need to limit users to a single WebDAV server
• We provide an UI where sharers can select sharees from a list of account holders.
  • Add an Add button below the Invite field in the sharing detail view
  • Clicking on the Add button pops-up a checkbox list of account holders (ie. Full name, email, username) on the sharer's WebDAV server and Okay and Cancel buttons
  • Sharer checks off the users they want to share with and clicks Okay
  • Selected sharees are added to the "Invite"
  • Invitations can be send either via the server or email

• If users can share with other account holders on the same WebDAV server: View or Edit AND/OR users can make the shared collection world viewable by sharing with non-account holders, then there would be:
  • No need to implement tickets
  • A need to provide web UI
  • A need to match at least Full name (if not email addresses) with usernames of account holders on the server
  • A need to limit users to a single WebDAV server
• This would require a very complicated UI to make this intuitive and comprehensible so I'm not even going to try to describe it in detail here. The basic premise is:
  • Sharer adds email address to Invite field in the sharing detail view
  • Chandler checks invited sharees against the server's accounts
  • Email addresses that don't match an username on the server are marked (*)
  • Dialog pops up informing user that if they want to send sharing invitations to these () email addresses, they will have to make the share world-readable AND these () people will only be able to view, not edit the share
  • However, email addresses that do have matching server accounts can View or Edit the share

Proposal for improvements to Sharing workflow in .6

• We may need to change the background color of the sharing detail view ( perhaps make it a shade darker), to give users more visual feedback that they are now looking at a different "kind" of detail view.

Setting up boundaries between your stuff and other people's stuff

• Quarantine incoming shares.
  • Items from incoming shares are not automatically added to the user's All collection
  • Items from incoming shares cannot be added to other collections. They can only be deleted.
  • [OI^?] Is resharing still an issue? ie. Sheila receives a share from Lisa. Sheila adds one of the items in Lisa's share to one of her own collections and then reshares that collection with Katie. Now that item lives into two places on the server: Lisa's account and Sheila's account.

• Replace current text-based collection sharing status in the sidebar with icons. Statuses include:
  • Incoming
  • Outgoing
  • Nice to have Has pending sharing invitations (ie. User has added names to the Invite field, but hasn't clicked Send to send out the invitations.)
  • Nice to have Partially shared (ie. Only Calendar is shared)

Setting up the boundaries of what you share

• Add a mark-up bar button or a pulldown to set a single ACL for all sharees: View or Edit
• Add mark-up bar buttons or checkboxes in the body of the collection detail view to suspend syncing the collection

• Add mark-up bar buttons or checkboxes in the body of the collection detail view to allow users to select what parts of the collection they want to share
  • Share the following kinds of items in the "Foo" collection:
  • [x] Mail
  • [x] Events
  • [x] Tasks
• The correct options should be pre-checked depending on which app area the user started the sharing workflow from: All, Mail, Calendar or Tasks.
• Summary pane should update to reflect user selections. (ie. Mail and Tasks or just Events or Tasks and Events)

• Add option for sharer to share their event status with sharees. For example, if Mitch is sharing his personal calendar with Esther, he will want her to see his event status. If Blue is setting up an office calendar, her event status is not relevant to the sharees.

Managing sharing participants

• Add ability to remove "already invited" sharees from the Participants list in the detail view of shared collections

• Add (text) in parentheses next to sharees names in the sharing detail view to provide sharing status feedback.
  • For the sharer in the From: field, status options are Marcel Marceau (Subscribed) OR (Offline) as in Out-of-sync
  • For sharees in the Invite field, status options are blank as in haven't tried to send yet OR (Failed), as in failed to send.
  • For sharees in the Participants field, status options are blank, (Viewed), (Subscribed), (Failed), (Offline) as in Out-of-sync

• All writers have the right to terminate the share
• The last writer to remove themselves from the share is prompted to terminate the share
• If the share is terminated, sharing detail view is flushed clean. If the collection is shared again, it should be published to a different URL.

• Add text to display "Created by...on...." and "Last modified by...on..." information in the sharing detail view.

Advanced scenarios

• If we allow users to add incoming shared items to their own collections, we will need to figure out a way of correctly interpreting the user's intent if they "delete" the item from one of their own collections.
• For example, we could have a dialog pop up to ask them if they want to delete the item from the original incoming shared collection as well, or are they simply removing it from their personal stuff.

Simplified proposal

• 2 fields, one for Viewers, one for Editors
• Use text in parentheses to indicated newly added sharees

• ZeroPointSixSharingDV^?_Simpl.png:
  

Comp

• Assumption: Allow users to share with non-WebDAV account holders via tickets
• Still need to work on markup bar

• ZeroPointSixSharingDetailVi^?.png: