High-level Goals

Why do we care about interoperability?

• To provide users with choice about which clients they use.
• Why do we care about providing users with a choice in clients?
• Choice creates a marketplace of ideas which in turn breeds innovation and progress by allowing for different approaches to similar problems and for different clients to provide custom functionality to niche markets.

In other words: different strokes for different folks.

Challenge: How do we deal with the tension between standardizing implementations to facilitate the interoperation that is crucial to allow for creative solutions to well-worn problems.

Empirical approach

Workflow exploration: Common themes and components across 3 models of communications:

• Invitations
• Wiki
• Bugzilla
• See raw notes from meeting for scenarios: OpenDesign20060127

What are some common components of all 3 workflows?

• Some discrete unit of content (ie. an event, a wiki page, a bug)
• An owner(s) of the content
• Content is communicated to a select group of recipients, sometimes with a wrapper around the content (ie. a special note) by the owner
• PUSH recipients of the content + wrapper ("N"otification or PING)
• PULL consumers of the content (no wrapper), assuming there is public access to the information
• Subsequent edits/updates to the content (most commonly done by the original owner of the content.
  • All edits/updates to the content are communicated via "n"otifications or (silent updates). Edited items are marked as "changed" so that PULL consumers of the content can see which items have been changed since last viewing the collection.
  • Some subset of edits/updates will be so huge and significant that the editor/updater will feel compelled to send out a "N"otification or PING of the change to certain recipients, thereby actively alerting the recipients of the change and (re)focusing their attention on the item by dropping the updated item at the top of the recipients' list of NOW items.
• Subsequent communications of the content to different sets of recipients

What are some cultural considerations that are perhaps at odds with the "standards" model of invitations?

• Assumption that free-busy information is universally available for all invitees (assumes a corporate setting where everyone is on the same system).
• Assumption that there is a one-to-one mapping between calendar-based free-busy information and a person's actual availability for meetings (assumes a corporate setting with a standard "work-day").
• Single workflow for both large meetings and small group meetings (forces all negotiations about the event to go through the meeting organizer).
• All invitations must go out with a specific proposed time, as opposed to no proposed time or a few different proposed times.

Chandler adds another dimension of complexity: Sharing

• Does the recipient already share the event? read-only? read-write? via Cosmo? some other CalDAV client? some other WebDAV client? a .mac account?
• Does the recipient use Chandler?

Considerations unique to invitations

• Does the recipient use an email client that supports iTIP over iMIP?

Assumptions

• Users should always be able to edit content items they:
  • create
  • receive via p2p communications (ie. email) and
  • read-write sharing.
• Users should be able to (re-)communicate content items as many times as they want.
• Users should not have to understand the subtleties between different technology-based modes of communication in order to complete these workflows (ie. via WebDAV sharing, CalDAV sharing, .mac sharing, iTIP over iMIP, SMTP).

Technology-centered design: 3 separate workflows for getting an invitation out the door

Scenario 1: Communications via Sharing

Event organizer (Al in the notes)

1. Create a new event on a shared calendar
2. Enter the names of sharees that you want to PING about this new event
3. Enter a greeting (optional)
4. Click Send capital "N"otification or PING message

What the recipient sees (Bo: Chandler user, Sharee)

1. The event on the shared calendar is automatically added to the recipients "My calendar"
2. The event's triage status is automatically changed to NOW and dropped in at the top of the recipients NOW section. "N"otifications effectively "focus" or "re-focus" the recipient's attention on the item. It is a way for the sender of the PING to drop an item at the top of a recipient's Inbox.
3. The recipient should now be free to edit and Send an update PING of the item.

(Items that have been changed via "n"otifications (or silent updates) are marked as "changed" wherever they appear in Chandler. However, sharees are not actively "alerted" of changes, but instead can view changed items by looking for them in the collections they appear.)

Scenario 2: Communications via iTIP over iMIP

Event organizer (Al: Chandler user)

1. Create a new event (OI: Is this the same event as in Scenario 1? or a separate event?)
2. Click an invite button
3. Enter a list of recipients who you know use clients that support iTIP over iMIP
4. Click Send

What the recipient sees (Chloe: Chandler user, non-Sharee)

1. Receives a new event
2. OI: Can edit new event?
3. OI: Can Send event again? (as a new, separate event? or as the same event?)
4. Can reply, reply all and forward the invitation.

Scenario 3: Communicating via Email

1. Create a new email (Al: Chandler user)
2. Copy and paste event information into email
3. Enter a list of recipients who you know do not use clients that support iTIP over iMIP

What the recipient sees (Dominic: non-Chandler user, no iTIP/iMIP support)

1. Email text
2. Can reply, reply all and forward the email invitation

What's wrong with this picture?

• Forces the user to make decisions they are neither interested in making nor equipped to make.
• How would the event organizer know what clients their invitees' are using?
• How would the event organizer know which invitees are sharing this event already?
• Inconsistent UI: A single Chandler recipient will
  • Sometimes receive a sharing "Notification" or PING which is an event + greeting
  • Sometimes receive an item via email.
  • If they receive the former, they can Edit the item and send out a "N"otification.
  • If they receive the latter, they can edit the item but cannot "Send" it out again.
• Meeting organizer is getting responses to the invitation via multiple channels and has to do a lot of manual collating to pull all the threads together.
  • "N"otification PINGS from sharees
  • Email responses from non-sharees whose clients support iTIP over iMIP
  • Email responses from non-sharees whose clients do not support iTIP over iMIP

Ultimately the question is: Is the user going to get the difference between "Notifying" fellow sharers of a new item in a shared collection versus "Sending" a single item out via email? Conceptually, they're the same. They're only different at the implementation / technology level.

Human-centered design proposal: A unified approach to getting information out and about.

Central thesis: Users should Send out different "packages" of the same item because they want to customize the wrapper for different audiences...not because they must use different technologies for different recipients.

1. For the in-laws: Mathilda and I would like to invite you to our dinner party next Thursday night.
2. Fo yo homeys: Yo dawgs, we gettin' down in the shizzy wiff some lip-smackin grub-licious.
3. For your sister, who you're slightly pissed off at: You coming or what?

Single workflow for getting the word out. Event organizer

1. Create a new event
2. Enter a list of people who you want to receive this event + greeting wrapper.
3. Click Send.
4. Event organizer can send out subsequent invites or event + wrapper with different greetings for different sets of recipients. The event itself maintains a master list of everyone that has been invited (a la e-vite).

What the recipients see (Chandler user, sharing and non-sharing)

1. Receive the event + wrapper in the NOW section of your Dashboard

(Note: If you are already sharing the event through a shared calendar, Chandler resolves the two events to be the same event)

1. Can edit and send out a "N"otification or PING update to everyone on the invitation.
2. All Sharees' edits will automatically update the "shared" event on the server. All subscribers to the event will see the event marked as "Changed" when they go look at the collection(s) it belongs in.
3. Can send replys, reply alls, and forwards that are separate from edit/update "N"otifications.

What the recipients see (non-Chandler user whose client doesn't support iTIP over iMIP)

1. Same as above

• Communications eco-system
  

The resulting interaction is recorded in a thread as follows:

Thread around an invitation (UI would looks something list this, with icons replacing the text in the left-hand column).

ITEM	Organizer sends original invitation
Reply	Recipient replies to it
ITEM	Another recipient edits and sends out a "N"otification of the update
	("n"otification of edits) not recorded in the thread
Reply	Another recipient replies to it
	("n"otification of edits) _not recorded in the thread
Reply	Another recipient replies to it
ITEM	Another recipient edits and sends out a "N"otification of the update
	("n"otification of edits) _not recorded in the thread
ITEM	Another recipient edits and sends out a "N"otification of the update
ITEM	Organizer sends out final "N"otification of final update

This meets all of our criteria

• Some discrete unit of content (an event)
• An owner(s) of the content (event organizer)
• Content is communicated to a select group of recipients, sometimes with a wrapper around the content (ie. a special note) by the owner (invitation wrapper)
• PUSH recipients of the content + wrapper ("N"otifications or PINGs)
• PULL consumers of the content (no wrapper), assuming there is public access to the information ("n"otifications for sharees)
• Subsequent edits/updates to the content (most commonly done by the original owner of the content.
• Subsequent communications of the content to different sets of recipients

Phasing: What do we do first if we can't do it all for 0.7?

0.7

1. All items are "sent out" as emails
2. All items are "sent out" as (emails + URL) to item (for sharees)
3. Chandler users can receive iMIP requests as items. Subsequent edits and updates are still sent out as (emails + URL: only for Chandler users)
   • Proposal is to not implement item locking (making the iMIP request non-editable by the user)
   • As a result, items may get out of sync
4. Event items are "sent out" 1st time as iTIP/iMIP items [(iTIP/iMIP) + Email text], subsequent edits and updates continue to be sent out as (emails + URL: only for Chandler users)

Post 0.7

1. All items are sent out as "items" [Interoperable version + Chandler item + Email text]
2. Subsequent edit/updates "N"otifications are sent out as [(New iTIP/iMIP items) + Chandler item + Email text]
   • Danger of loss of data, but users are unlikely to tamper with items in an irreversible way (ie. deleting and replacing)...ie. how often do people use the versioning feature on the wiki?
3. Maintain a thread of edit/updates "N"otifications.
4. Selecting a subset of recipients to sent PING with "N"otifications

Post 1.0

1. Ability for content owner to "lock" certain attributes
2. Ability to "Communicate" or Send/Edit/Update read-only items
3. Sending a different "wrapper" greeting to different sets of recipients