IMIP Invitation Workflow

Status Discussing design alternatives for .6

Option 1: Modeling IMIP invitations as 2 items: Email with an Event attachment

• two_item_model.gif:
  

1. Red user sends out an invitation to Blue user as an Email stamped as an Event.
2. Blue user receives an email with an IMIP attachment which is an Event. The triage status of the email is Now.
3. Blue user d-clicks on the Event attachment, which spawns a new event item on their calendar with a triage status of Later
4. Blue user edits the Event item and can stamp it as an Email
5. Blue user sends out Event item stamped as an Email to Red user
6. Red user receives an email with an IMIP attachment which is an Event.
7. Red user d-clicks on the Event attachment, spawning a new event item on their calendar which replaces the original Email stamped as an Event invitation Red user sent out to Blue user.

• Advantages
• Easier to implement?
• Works more like Apple iCAL

• Disadvantages
• Does not work like Outlook
• Inconsistent with stamping mental model
• More items to manage

Option2: Modeling IMIP invitations as 1 item: Email stamped as an Event

• one_item_model.gif:
  

1. Red user sends out an invitation to Blue user as an Email stamped as an Event
2. Blue user receives it in the Now section of their Dashboard view asn an Email stamped as an Event
3. Blue user edits the invitation
   • Chandler immediately creates a new version of the invitation (v.2) and
   • Retires the original invitation (v.1) which means that it can only be found in the In collection
   • The Send button in the Detail view toolbar changes to a Send update button
4. Blue user sends an update (v.2) of the invitation to Red user as an Email stamped as an Event
5. Red user receives v.2 of the invitation as an Email stamped as an Event.
   • Chandler immediately replaces v.1 of the invitation with v.2 (in all the collections v.1 is a member of, except for Out)
   • Red user now has 2 versions of the invitation. v.1 lives in Out. v.2 lives everywhere else, including In.
6. Show on calendar feature Red user can click a button in the detail view of the invitation to view the invitation in a new tab on the Calendar.

General rules wrt editing and _dummy versioning of sent and received emails

• Chandler creates a new version of all sent and received items as soon as the user edits the item.
• This does not include, setting triage status, privacy status, stamping the item, filling in any new attribute fields that appear as a result of stamping, editing private annotations or editing the collections attribute on an item.
• If a user edits a received item, a new version of the received item is created, replacing the original item in all the collections it is a member of except for In.
• All subsequent edits are counted as the same version.
• If a user then Sends this newly edited version of the received item as an update, the item is moved from In to Out.
• If a user edits a sent item and sends out the edits as an update, both versions of the item can be found in Out.

Potential weirdness when emailed invitations interact with shared events

• Scenario: What if a user receives an invitation for an event that they are sharing through a shared calendar with the sender of the invitation?
  • This shouldn't be a problem. The receipient of the invitation replaces the shared copy of the event with the copy received via email.

-- MimiYin - 15 Dec 2004