I asked Mimi put together an evaluation of what elements, workflows would be required for a complete sharing user experience in Kibble. This assumes that both users are Chandler users and deals only with the collection sharing workflow. This does not address the setup and management of accounts etc.

Main Sharing Features

Managing participants

• adding and removing sharees
• transfer of single ownership for a share
  • ie: Sheila creates a design share with Mimi and Chao. Sheila moves teams and no longer needs to have access to this share, she makes Chao the owner.
• setting permissions/changing permissions
  • setting readonly or readwrite for an entire share
  • changing or suspending access privileges per user
• resending failed invitations to share

Sharing status feedback

• visual feedback in the sidebar
  • full vs partial share (sharing the whole collection or only tasks or events for a collection)
  • outgoing vs incoming share
  • failure status
  • offline - don't sync
• per sharee status - viewed, not viewed, failed.

Managing items/share

• renaming a share
• deleting/removing item and collection behaviours
• marking items as private (included in the collection but not in the share)
• personal annotations
• delete shared collection from your repository then access share again from invitation
• suspend synching
• deleting a share from the server - sharing termination.
• matching received invitations and tasks with the shared version of the event
• matching sent and received emails with the shared version of the email

Other stuff

Mimi and I then discussed what issues, other features might be necessary or dependent based on the context of what we are sharing ie: if we are sharing calendar events, are there specific features that might not apply to sharing tasks or email.

Notes about sharing and All collection (dashboard)

• Currently all items in a shared collection automatically appear in the user's dashboard (All Collection). Mimi and I have been examining whether or not we want to continue with this or give the user the option to not have them included. We decided that it was more important to keep the sidebar mental model simple and consistent and not build in too many structural distinctions between shared and unshared collections right now.
• After many discussions, we have decided to keep it very simple for Kibble and continue to add all shared items to the dashboard. Instead we will use triage status and other mechanisms to make sure that the user's dashboard doesn't become cluttered when they first download a share. Once this is working and we have a chance to use sharing, we can determine if we need to set attributes for this. We felt that it would be wrong to try and predetermine all the scenarios for why items are shared. Instead we will let the user do whatever makes sense for them.

• Email, Tasks and Notes
  • All items in shared collections appear in the dashboard but automatically go to the Done section. (Since Triage status like alarms are not shared.) This allows the items to live somewhere where the user can see them but doesn't clutter the users Now section. We really leave it up to the user to determine how to deal with these, we do not try and predetermine why they might be using this share.

Events

• The main concern with events is that they somehow affect the user's free-busy status. If all events from shared collection appeared in either the Done or Later dashboard sections (depending on whether it's a past or future event) and were set to FYI, the user would be able to see them but there free-busy info would not change unless they were attending one of these events and explicitly changed the status on the event themselves.
• Also events that do not have an alarm set on them should go directly from the Later to the Done sections of the Dashboard view once the event is past. Since alarms are not shared, newly shared events will have no alarms. If a user sets an alarm on a shared event however, the event will appear in the Now section of their Dashboard view when the alarm goes off.
• ie. Blue may share the Office Events calendar with the entire office. As a sharee, the events arrive into my Dashboard collection as FYI events in the Later and Done sections with no alarms. If I get specifically invited to any of these events (ie. Blue sends me a capital N otification by stamping the event as an email and sending it out), the status is changed to confirmed and affects my free/busy schedule. If I set an alarm on any of these events, they will appear in the Now section of my Dashboard at the time of the alarm. Otherwise, they go directly from Later to Done once the event has past.
• We can probably live without the "going directly fron Later to Done" feature if that's harder than just allowing all events to show up in the Now section once the event has started or once the alarm has gone off (whichever comes first). It might not turn out to be such a drag.

Sharing communications ie: email

• In the context of an email, it is important to distinguish the owner of an email from who appears in the who column. Currently in the UI, the who column provides visual feedback wrt whether an email is sent by you or sent to you. And depending on whether an email is outgoing or incoming, the who column displays either the to field value or the from field value. In a shared collection of emails however, the question arises, from whom's perspective is the who column calculated? If Chao and Sheila are sharing a collection of email and one of the emails is an email from Chao. Does the who column display To:Sheila from Chao's perspective? Or does it display From:Chao from Sheila's perspective. What if Sheila's looking at an email that is not To:Sheila but From:Chao. Does the who column display it as an outgoing email because it's outgoing from Chao's perspective?
• [OI^?] Since sharing email is not a key use case for Kibble, we can probably keep sharing simple and not address this. Email can be shared but we do not do anything special to give it context. Email shares would just work like everything else. In other words, you see the shared email from the perspective of the sharer of that email....However, if the email you are sharing also happens to be an email sent to you from the sharer, then the version that you received (which is an incoming email) should overwrite the verions that the sharer sent (which is an outgoing email).
• This makes sense because if you're sharing emails with someone, it's most likely that you're collaborating with them on something and sharing this information as if you were the same person. (ie. 2 people who work different shifts as customer service representatives.)
• Perhaps we should indicate that items are shared in the message history column? We could generalize it and think of it as a communications history?
• [OI^?] Can you reply to or forward an email that somebody else sent or received? If not, we can simply disable the feature for now, but it's probably something we want to be able to do later on.

Sharing events

• What information gets shared?
• Does the event status get shared?
  • No, to keep things simple, shared events would automatically be FYI. This solves a couple of problems.
    • I download a share and all the events go into my All collection. Unless I was attending one of these events, I don't want the shared events reflected in my free busy information. In this case they would not since they are FYI. If I were attending one of those events, I would add it to My Calendar and set the status.
    • If I share something, events that others add may not be events that I am attending. By making those automatically FYI as well, I can view them but only set the status or move them to My Calendar when it makes sense.
    • If I share my whole calendar, it works the same way. All events would have my status since it's meaningful to me. If others have write privileges and add an event, I will see it but I would be responsible for setting the status.

• Do alarms get shared? No, alarms are personal. If I accept a share with events, none of those events would have alarms when I download the collection. If I setup a share and others add events, I will not see any personal alarms that they have added.

• Triage status is not shared.

Tasks stamped as Events

• Personal annotations are important - it would be good to have a notes fields for personal annotations.
• We would like to get these in but not CRITICAL for Kibble. Maybe add to list for 0.7 if we have time.

Sharing and the Sidebar

• How do we prevent users from creating multiple filtered shares per collection?
• [OI^?] For 0.6 we will revisit the sidebar workflows. A simplification could simply be that each sidebar collection can only have 1 share. The user can specify what things should be included in that share, ie: events and tasks or just events. It could be originally setup to share events then later it's expanded to include tasks. But the task share and the events share are a single share with a single list of sharing participants.

Old Notes (not relevant)

Old Who Column Proposals

• Proposal 1: Add an owner column and calculate the who column from the perspective of the owner.
  • The owner is the person who added the email to the share. The owner will typically be either the sender or recipient of the email.
  • Sheila receives an email from Chao - From=Chao, To=Sheila -> Owner=Sheila, Who=Chao
  • Sheila sends an email to Chao - From=Sheila, To=Chao -> Owner=Sheila, Who=Sheila
• Pure Tasks, Events and Notes don't have a Who column but they have a creator, the person who added it to the share.
• Proposal 2: For shared collections, display both the from column and the to column
• Proposal 3: Leave the summary view alone. Display the who column from the perspective of the owner of the email. Keep track of who the owner is (ie. Item added by: So-and-so) in the detail view of the shared item.