An edit by any other name...

What qualifies as an edit

• User manually changes triage status
• User manually changes communication status
• Stamping
• User locking an item to 'Never share this item'
• Editing any of the Addressing fields including 'Send as' and 'Edited by'
• Editing the Title field
• Editing the Location field
• Editing any of the Date/time fields, Recurrence, Alarms
• Editing Event Status
• Editing the Notes field

What doesn't qualify as an edit

• Changes made by Chandler
  • Auto-triaging of events based on start and end date/times
  • Auto-triaging of items when alarms and start date/times roll around
  • Auto-change in communication status from Unread to Read when user clicks on an item to view it
• Adding and removing items from Collections

• For any given collection, only edits to attributes that are shared in the sharing cloud will be pushed to the server.
• This saves Sharees from the confusion of seeing items marked and Edited and Unread when the edited attribute in question is not even shared and therefore any changes that were made to it are invisible to the Sharee.

• If there is a merge conflict where two or more Sharees edit a shared item, we display the last edit in the byline and mark the item as Unread for all Sharees.

• If a Sharee is sharing one item through two collections (A * B) that have defined contradicting sharing clouds (e.g. A is sharing triage status and B isn't) and there is a conflict in the last modified byline where A changed the triage status, but B didn't, A wins.

---

Things that are outside of the 'item sharing via email' cloud ;o)

We will not share triage status, alarms or event status when sending and updating items. We understand that there exist compelling use cases to share these attributes on a per item basis, but it's not critical path for preview and greatly simplifies the number of attributes we have to keep track of in case of a conflict merge. Of course, if the item is shared via a shared collection and edit/updates are being sent via email, the triage status, alarms and event status WILL be shared via collection shared.

---

How do we deal with edit/update via email and edit/updates via sharing?

• The server needs to know when items have been Sent and/or Updated so that the Sharee's Chandler can treat the item appropriately (e.g. Mark the item as Unread and place it at the top of the NOW section of the Dashboard)
• If the email arrives after the user has already received the item from the server, Chandler needs to 'do the right thing', namely:
  • Resolve itself with the item that already exists in the recipients' repositories
  • Not re-mark the item as Unread
  • Not re-plop the item at the top of the NOW section of the Dashboard

---

Introducing...Edit Session

We need to have a notion of a editing session. An edit session lasts as long as the user has an item selected and the item details are being displayed in the detail view. This means that even if

---

Introducing...Neutral draft state

Add a neutral draft state for drafts that are neither toMe nor fromMe.

---

Detailed workflow description that describes what happens from item creation through edits, stamping,

When I create an item

• DV Created by Me on xxx
• Dashboard
  • Comm status: Read
  • Who: CR Me
  • Date: Date created

When a sharee comes to look at this item

• DV Created by Me on xxx
• Dashboard
  • Comm status: Unread changes to Read
  • Who: CR Me
  • Date: Date created

When I view the item

• DV Created by Me on xxx
• Dashboard
  • Comm status: Read
  • Who: CR Me
  • Date: Date created

When I make an edit in the detail view or summary pane

• DV Edited by Me on xxx
• Dashboard
  • Who: ED Me
  • Date: Date edited

When I stamp the item to address it

• Toolbar Send button is deactivated
• DV
  • From: Me (by default with my email address if I've entered email account info, if not it will just remain blank)
  • To: Hint text - Add addressees
  • CC: Hint text - Add addressees
  • BCC: Hint text - Add addressees
  • Send as: Me (if I've entered email account info, otherwise display Message telling user to go fill out their email account info)
• Dashboard
  • Comm status: fromMe draft
  • Who: TO Hint text - Add addressees
  • Date: Date edited

When a sharee views this item

• Toolbar Send button is de-activated
• DV
  • From: Me
  • To: Hint text - Add addressees
  • CC: Hint text - Add addressees
  • BCC: Hint text - Add addressees
  • Send as: Me
• Dashboard
  • Comm status: Unread fromSharee draft, toSharee draft or neutral draft depending on whether the Sharee is in the From or To addressing fields
  • Who: FR Me or TO Hint text - Add addressees (depending on whether the item is toSharee, fromSharee or neither)
  • Date: Date edited

When a sharee edits this item

• Toolbar Send button activates (provided there are properly formatted addressees and Sharee has filled out email account info)
• DV
  • From: Me
  • To: Addressees added
  • CC: Addressees added
  • BCC: Addressees added
  • Edited by: Sharee on xxx (if they've entered email account info, otherwise display Message telling sharee to go fill out their email account info)
• Dashboard
  • Comm status: Read fromSharee Draft
  • Who: TO
  • Date: Date edited

Sharee addresses and sends the item

• Toolbar Send button de-activates
• DV * From: Me
  • To: Addressees
  • CC: Addressees
  • BCC: Addressees
  • Sent by: Sharee on xxx
• Dashboard
  • Comm status: Read fromSharee Sent
  • Who: TO
  • Date: Date sent

When I come back to view the item

• Toolbar Send button is de-activated
• DV
  • From: Me
  • To: Addressees
  • CC: Addressees
  • BCC: Addressees
  • Sent by: Sharee on xxx
• Dashboard
  • Comm status: Unread fromMe Sent
  • Who: TO
  • Date: Date sent

When I edit the item

• Toolbar Send button re-activates as Update button
• DV
  • From: Me
  • To: Addressees
  • CC: Addressees
  • BCC: Addressees
  • Edited by: Me on xxx
• Dashboard
  • Comm status: Read fromMe Draft of an Update
  • Who: TO
  • Date: Date sent

When Sharee views the item

• Toolbar Send button is deactivated
• DV
  • From: Me
  • To: Addressees
  • CC: Addressees
  • BCC: Addressees
  • Edited by: Me on xxx
• Dashboard
  • Comm status: Unread fromSharee Draft of an Update
  • Who: TO
  • Date: Date sent

When I update the item

• Toolbar Update button is de-activated
• DV
  • From: Me
  • To: Addressees
  • CC: Addressees
  • BCC: Addressees
  • Updated by: Me on xxx
• Dashboard
  • Comm status: Read fromMe Updated
  • Who: TO
  • Date: Date sent

---

Weird edge case - Senders, Editors and Updaters do not automatically receive email Updates to items unless they happen to be the Sender/Updater of the message or their email address is enumerated in one or more of the Addressing fields.

So in the following scenario, Sheila would not receive updates to a message she sent, unless the Updater added her to the From, To, CC or BCC fields.

From: PPD
To: Apps team
Sent by sheila@...

In the future, we will consider ways to make this easier. But it seems that without Contacts support, this will be difficult to do intelligently.

---

Phasing proposals

• Don't track edits. Only track Sends and Updates.
• Don't even differentiate between Sends and Updates.
• Don't pull down Chandler items via Email with special Chandler headers.

What's a blocker

1. Ability to edit sent items
2. Ability to see which items have changed, aka Unread status
3. Ability to send items that have already been sent