This is the working page for a summary of the 0.7 free-busy and invitation proposal that we will be sending to the design list

Use Cases

1. I have an event to announce. (ie. A party, a company holiday, a guest lunch speaker.)
2. I have a meeting to schedule with a group of people.

MimiYin: Scenarios we're not addressing

1. Inviting people to an event you're sharing on a read-only calendar

High-level Workflow stages

1. View free-busy information to pick a time
2. Send out the event/notification to a list of invitees

It's likely that these workflows will be used together (ie: #2 followed by #1) but for 0.7 we will provide them as decoupled workflows that are used independently.

1. Receive invitation in Chandler. Event is automatically added to your calendar.
2. Reply, Reply all, Forward invitations

MimiYin Are we able to cover this case? It seems like so long as Chandler is not a user's primary email client, this will be the most likely scenario.

1. Receive invitation in your email client as:
   • Email
   • .ics attachment
   • iMIP invitation
2. Drag and drop item (email, .ics file or iMIP invitation) directly onto Chandler calendar
   • Nice to have: Emails and iMIP invitations are parsed as stamped emailed/events with From and To metadata preserved.

Goals

• Provide simple way for Chandler users to send and receive "lightweight invitations" without having to know about or take into consideration what clients and/or technologies the recipients of these invitations use.
• Improve on current scheduling workflows accomplished via email with limited free-busy views of the people you most frequently schedule meetings with.

Assumptions

• Invitations versus Notifications
  • The term "invitation" often implies a set of workflows involving back and forth negotiation about attendance and time. For 0.7, event "invitations" will be treated more like "notifications" and less like some of the full-blown invitation experiences offered by full-scale enterprise calendaring systems. This means that we will keep it simple and not differentiate between the "event announcements" and "meeting invitations".
  • We will decouple viewing free-busy information from setting up and sending out the event/notification.
  • We will not support accept/decline workflows.
  • We will not support negotiation workflows.
  • Most of the time, we will be sending an invitation without clear data about the free-busy schedules for all users (as a result of decoupling these steps).
  • We will be using iMip as a protocol to send event information to recipients.
  • Once an original event/notification has been sent, all subsequent updates will be sent out as email text, with all relevant Chandler-specific metadata included as text in the body of the email. (More specifically, subsequent updates are not sent out as a Chandler item or an iMip request).

• Free-busy
  • More often than not, users will not have access to the free/busy information of all invitees.
  • The average number of persistent free-busy subscriptions users maintain will be relatively small ie: <10 for the majority of the use cases. (Primarily because we will not be providing a good way to specify a list of free-busy views ie. automatically drawing up free-busy views for invitees.)
  • People will be using Cosmo-Demo to share their free-busy information.
  • We will be using CALDAV reports supported in Cosmo 0.3 (under development now).
  • We will stage free-busy implementation to get something basic up and running earlier in the release. This will allow us to integrate better with work being done on Cosmo 0.3.

Viewing people's free-busy information

• Publish
  • Users will publish/un-publish their free-busy information to Cosmo via a menu item: "Publish free-busy/ Un-publish free-busy".
  • Users may also be able to publish free-busy information per individual calendar (we'll simply return a 3rd free-busy URL for every published calendar collection).
  • Either way, the user now has free-busy url(s) that can be sent to anyone via email, IM, verbally, etc.

• Subscribe
  • Users can subscribe to free-busy view via the same Subscribe dialog we have today for Sharing.
  • {OSAF_OI} Can users enter non-Cosmo/Chandler free-busy URLs?
  • There are several options that have been discussed for handling what happens when we subscribe to someone's free-busy ticket:
    1. Free-busy subscriptions are added to the sidebar (just like any other share) OR
    2. Free-busy subscriptions are added to a special Sandbox area that replaces the mini-calendar. The Sandbox area opens up automatically when:
       • Users subscribe to a free-busy view
       • Users select "View free-busy" from a menu item or a button in the toolbar
       • {OSAF_OI} Will it be annoying to browse free-busy without the use of the mini-calendar?

• Viewing free-busy rollup
  1. (If we put free-busy views into a special Sandbox area) User selects "View free-busy" from a menu item or a button in the toolbar OTHERWISE
  2. User overlays free-busy views with their "My calendar"
  3. User selects a time and d-clicks on their "My calendar" to a create a new event at that time

• Assumptions about free-busy views
  • Free-busy views are not modal. They are not mutually exclusive with normal calendar views.
  • As a result, we can overlay regular shared calendars with a free-busy calendar (ie: I subscribe to Katie's full calendar and Philippe's free-busy info and want to pick a meeting time).

• Requirements for viewing free-busy
  • It is important to be able to see who in particular is free/busy and who is not free/busy at a particular time
  • It is important to get a sense of how many people are free/busy at a particular time (ie. Everyone is free/busy and/or only 1 person is free/busy).
  • Free-busy calendars should be rendered differently
    • blank lozenges
    • different shaped lozenges
    • greyed out areas where you can't schedule meetings
    • mouse over free/busy lozenges for more detail
  • Based on some of the ideas and observations, Priscilla and Mimi will mockup several alternative views.

Sending events/notifications to invitees

• Feature Summary
  • Ability to send and receive iMip requests
  • Subsequent edits/modfications/updates will be sent and received as email text with all relevant Chandler-specific metadata included as text in the body of the email.

• Characters:
  • Alice - Chandler user
  • Beau - Chandler user and shares Al's calendar
  • Chloe - Chandler user (not sharing)
  • Ernie - uses come client that interprets iMip
  • Dom - uses PINE

• Use Case: #1 Event announcement Alice is attending a lecture on Wed night, sending a notification to Beau, Cloe, Dom and Ernie in case they are interested.
  • Alice creates an event for the lecture and clicks the "Send this item" stamp.
    • The date/time information automatically gets put in the body of the message
    • Alice addresses the invitation to Beau, Chloe, Ernie and Dom and clicks the Send button
    • This event/notification is sent out as an iMip request.
  • Beau:
    • Event/Notification arrives in Beau's NOW section in his Dashboard as an iMip request (email)
    • Chandler can detect this is the same event Beau is already sharing with Alice via Cosmo sharing and update it automatically on the shared calendar. This will be done either by resolving unique identifiers on either the .ics file in the iMip request or the Chandler item UUID.
    • Event is automatically added to Beau's "My calendar" (if it wasn't already in there)
  • Chloe:
    • Event/Notification arrives in Chloe's NOW section in her Dashboard as an iMip request (email)
    • Event is new to Chloe's repository and is automatically added to her "My calendar".
    • Chloe's Chandler may or may not know the Chandler event's UUID. Chandler will however, have access to the .ics file's UID.
  • Ernie: receives an iMip request in whatever his client allows.
  • Dom: just gets an email with all relevant information in the text.

• Use Case: #2 Scheduling an event Alice is trying to organize dinner outing, creates an event on Wed night at 7:00pm and notifies Beau, Chloe, Ernie and Dominic.
  • Alice overlays Beau and Chloe's free-busy information with her "My calendar". She does not have free-busy views for Ernie and Dominic.
    • Alice picks a time that works for at least herself, Beau and Chloe and creates an event on her "My calendar" by d-clicking.
    • Alice clicks the "Send this item" stamp and addresses the event to Beau, Chloe, Ernie and Dominic. In the body of the event, she suggests some alternate times that would also work for her, Beau and Chloe (since she doesn't know about Ernie and Dominic's availability).
    • This event/notification is sent out as an iMip request.
  • Beau receives this event/notification in the same fashion as use case #1.
    • Alice has the wrong address for the restaurant in the notes of the event. Beau edits the address.
    • The Send button in the toolbar turns into an Notify button. Beau clicks Notify.
    • Regardless of whether or not Beau clicks Notify, his changes will be automatically synced via the calendar he shares with Alice.
    • Everyone receives the update as email text. (Nice to have: URL to the event so that Alice and Chloe can quickly navigate to the event on her "My calendar".) OR
    • Beau doesn't click Update and his changes are automatically synced via the calendar he shares with Alice. Nobody else sees Beau's changes. OR
    • Beau clicks Reply in the toolbar and sends the address correction via a reply to the original iMip request in a separate email. All recipients of the reply will need to manually update the original event on their respective calendars.
  • Chloe receives this event/notification in the same fashion as use case #1.
    • Chloe also notices the wrong address and edits the event/notification she received. Chloe would also like to add her friend Carolyn to the dinner event.
    • The Send button in the toolbar turns into a Notify button. Chloe clicks Notify.
    • Everyone receives Chloe's update as email text. (Nice to have: URL to the event so Alice and Beau can quickly navigate to the event on their "My calendars".)
  • Ernie receives this event/notification in the same fashion as use case #1.
    • No surprise, the time Alice suggested doesn't work for him, but one of her alternate times does. Ernie tries to send a COUNTER proposal from his client suggesting the alternate time instead.
    • {OSAF_OI} How does Chandler parse this? Can we decipher it and present it as just email text?
  • Dom receives this event/notification in the same fashion as use case #1.
    • No surprise, the time Alice suggested doesn't work for him. Ernie's COUNTER proposal does work for him. However, since Ernie only sent his COUNTER proposal to Alice, Dominic doesn't know about it and so Dominic replies to the original event/notification with a different time.
    • Everybody receives Dominic's reply as email text.
    • Ernie gives up trying to use the COUNTER proposal feature and replies to everyone in an email that Dominic's proposed time doesn't work for him and suggests the same time he tried to proposed in his COUNTER proposal.
    • Everyone replies: YAY
    • Alice updates the event on her calendar and clicks Notify
    • Everyone receives Alice's update as email text (+ URL for Chandler users if possible.)

Summary of Assumptions

• Any subsequent updates/changes after the initial request has been sent and received will be done using simple email.
• We will not send out Notifications of edit/updates automatically. Alice and Beau share the event via Cosmo, so they can collaboratively edit the event and see each other's edits via Syncing without the use of Notifications.
• The purpose of sending an event/notification to a fellow sharee (Al to Beau) is to provide Al with a mechanism focusing Beau's attention on the event.
• As a Stage 2 feature, we may want to consider ways to make it possible for Chloe (non-sharing Chandler user) to send out edit/updates to other Chandler users as more than just email text (as 1st class Chandler items).

Next Actions

• Sheila drafting spec with requirements, assumptions and use cases
• Mimi and Priscilla will mock up several designs for displaying free-busy calendars in the sidebar.
• Mimi and Priscilla to mock up several designs for the consolidated free-busy view.
• Design will list out assumptions about what we think is hard, so engineers can respond to that.
• Engineering discussion around implementation details.