Summary

This page describes the design team's idealized view of the high-level feature set we've termed "item sharing". This needs to be grounded in engineering reality and our current architecture. Goal of this doc is to tease out missing steps in the workflow, engineering issues, different methods of implementations and their associated costs and tradeoffs. Also listed under [OI], are more advanced features we may extend in this area. Error conditions and corner cases are not described but relevant ones should be discussed.

Workflows

1. Send a content item (event, task, note) through email to one or more recipients
2. Receive a content item through email
3. Send out modifications of a content item previously received through email
4. Receive update of a content item modified by someone else

Workflow 1: Katie sends out an Event message

• This workflow is exactly the same as sending a normal email message, except it involves sending a message stamped with one or more other Chandler PIM kinds (i.e. event and/or task)
• User Katie creates a new Event (e.g. through direct manipulation on the calendar view, via the toolbar or menus)
• Katie fills in the headline, location, an event date and duration
• Katie stamps Event as a message, introducing the From and To communication fields. The headline doublesas the email subject field
• Katie fills in the To field with recipients' email addresses (say Mimi and Sheila's)
• Katie clicks on the Send button which sends out this Event as an email to Mimi and Sheila
• Note: Katie could just as easily have created the message and then stamped it as an event. Or stamped the item as a task in addition or in place of the event.
• 01_Create_event.gif:
  
• The sent email is automatically placed in the Out collection. Before the email was sent it was added to the Dashboard view's processing section. On successful sending, it was then moved from the processing section to the done section.

Workflow 2: Sheila receives Katie's Event invitation

• The email Event Katie sent out enters Sheila's In and Dashboard collections by default as any regular email
• The detail view of the email Sheila receives is similar to the detail view that Katie created. The primary difference being the message history status as shown below
• 02_Receive_event.gif:
  

• [OI] Beyond 0.5, we are considering allowing users to edit a received email (beyond stamping, marking or labeling).

Workflow 3: Sheila sends out revised Event

• Sheila wants to, say, suggest a different location to the Event and disseminate this change
• She clicks the "Update" button on the toolbar. This allows her to modify the received Event message (i.e. all the fields of the event message are now editable as if she were the creator of this event e.g. headline, location, event date, notes). The "Send" button in the detail view becomes the "Update" button. Also, the from field now says "me" (i.e. Sheila) in place of Katie, and Sheila is replaced in the To addressing field with Katie (the original sender).
• 03_Update_event.gif:
  
• [OI] Advanced feature: Sheila can change the recipients of this email message
• After modifying the Event, Sheila can click on the Update button

Workflow 4: Katie and Mimi receive revised Event

• (A) Katie and Mimi receive this revised Event as in workflow 2, but with the following new requirements:
  • The collections that previously contained Katie's original event, now contain Sheila's revised event in its place. Say Katie had the original event that sent out on her calendar. On receiving Sheila's changes, the event on her calendar is now replaced with the revised event from Sheila.
  • The exceptions to the above are the following collections. These collections contain all versions of this Event.
    • The In Collection
    • The Out Collection
    • The communications thread cluster (ad-hoc collection) [see below for more explanation]
  • All versions of this event messsage, together with regular message thread items (i.e. replies and forwards originated from this item) belong to a cluster.
• Replace_in_Dashboard.gif:
  

• Not_replace_in_Mailbox.gif:
  

• Replace_in_user-defined-col.gif:
  
• The preceding bullet (A) applies also applies to the collections of the sender (Sheila)
• There is no sophisticated conflict resolution in item updates. The most recently received item is always deemed the most updated item to meet requirements in (A)
• There is no requirement to view differences between item updates. Listing them in a cluster is sufficient.

Above workflows apply just as well to a plain email, a stamped task or a stamped task and event. -- ChaoLam - 03 Sep 2004