Overview

Exploration of the workflows and prioritization for Chandler users to schedule events with someone else. Basically we need to understand what workflows are important for Kibble as they relate to Chandler and non-Chandler users.

Based on a brainstorming session between Mimi and Sheila.

Kibble Workflow: Scheduling an event with someone else

• Accepted invitation User A creates an event and sends an invitation (emails the event) to User B. User B receives this invitation which is actually just an event. It appears on User B's calendar.
• Declined invitation We are not going to have explicit state management. User B can delete the event if they do not want to attend.
• Updated invitation User B has accepted an event inviation from User A. User A changes the time or details and sends an update to User B, overwriting the original invitation with the new invitation.
• Check schedule then invite User A checks to see if User B has published their free-busy and if so, views their schedule. User A then selects an available time, creates an invitation, fills in the details and sends it to User B.
• Set up invite then check schedule User A creates an invitation, enters User Bs info then checks user Bs schedule to see if this time works, makes adjustments if necessary then sends the invitation.

Sending Invitations

• This invitation workflow should handle an event, or scheduled task (specific date/time), an all day event or scheduled task and an anytime event or scheduled task.
  • How do we handle anytime events? [OI^?] Get a proposal from engineering.
  • How do we handle scheduled tasks? Are they tasks with a due date? Can task due dates have reccurrence? [OI^?] Get a proposal from engineering. MimiYin After meeting with Katie yesterday, I think we determined that it would be best if Scheduled Tasks appear on the calendar, meaning that they would probably be best modeled as iCal Events?
• User A should can send an update that includes changing from a specific time event to an anytime or all day event.
• If User A sends a recurring event, the recurrence should be inherited with the event.
• How do we send a single instance of a recurring event to some people and the entire recurring event to other people?
  • Use case: A guest lecture series that has the same people invited for all of the lectures and 1 changing guest for each lecture.
  • Ok for now to simplify and have User B get all the recurring events.
  • We might want to look at different ways for users to handle this ie: send options for single vs recurring, accept options for single vs recurring. Mimi would probably prefer to have this specified on a per user basis. We can send the invitation to 3 people, 2 get all reccurrences, 1 gets only one. Not sure how we would even do this. (See notes on recurrence below). [OI^?] Pick a straightforward solution. Inherit recurrence and
• Should work for Chandler to Chandler users as well as to non-Chandler users.

Invitations and Shared Calendars

The above workflows are straight-forward when User A and User B are dealing with events on personal calendars. Things get a bit weird in the case of shared calendars. The following workflows address how to keep this consistent.

1. User A gives read only privileges to User A's All calendar to User B

• • There is nothing special about User A's All calendar, User B will see a share with a bunch of events all set to FYI status (which is the default event status for User B since the assumption is that all of User A's events are simply FYI events for User B). User A's events will also appear on User B's All calendar but are not part of User B's free-busy since they aren't User B's events.
  • User A creates a new event on User A's Shared All calendar and sends a capital N otification invitation via email to User B. User B receives the invitation in User B's Dashboard view (aka All collection). The emailed invitation replaces the shared version of the Event that User B received via sharing User A's All calendar. User B's event status on the event is set to "confirmed". As a result, the event is then included in User B's free-busy time. User B can delete the event or change the status, details etc. [OI^?] Does User B's changes propagate back to User A? even though User B hasn't been granted write access on the collection? Probably not.
  • If User A looks at the event in User A's All calendar, User A would see all the people User A invited and the event would be set to User A's event status.
  • If User B looks at the event on User B's All calendar, User B would see the same list of attendees and User B's event status.
  • If User B looks at the event for that event in the "User A's All calendar" that User A shared with User B, User B would see User B's event status.
  • User A adds all kinds of stuff to the calendar that User B may or may not care about.
    • If User B is an attendee at the event, User B will receive a capital N otification invitation which replaces the version of the event that User B received via sharing User A's All calendar.
    • If User B is not an attendee, User B will not get a capital N otification invitation.
      • [OI^?] "n" notifications - we may not have this for 0.6 but probably need a simple plan for Kibble.
      • MimiYin So this is the difference between N otifications and n otifications. Basically, you get N otifications in the form of email invites and email updates to invites if you are on the invitee list for an event (To, CC or BCC). You only receive n otifications (ie. notices in your status bar and sharing logs) if you are sharing the item through a shared collection, but you are not actually on the invitee list. In this sense, User B only gets pinged about changes to User A's calendar if User B is attending an event on user A's. Otherwise, User B simply gets a notification in the status bar and / or a (# new or edited) next to the shared collection in the sidebar.

2. User A gives User B write privileges to their All calendar

• • So how is this really different from the above scenario? MimiYin It's not really. Both are examples of users sharing their personal calendar with someone else. A counter-example would be more like, an user sharing a group calendar (ie. Sheila shares the Design Group calendar with Mimi and Chao).
  • The main difference here is that User B can be adding events directly onto the share (User A's Calendar). This should be consistent though.
  • Also if User B receives a capital N otification invitation for an event on the shared calendar, User B's edits to the event would propagate back to User A.
  • User B adds an event directly onto the shared calendar for User A (schedules something for User A). If User B were not attending, the event would be created with status=FYI. User B sends a capital N otification invitation to User A. When User A receives the invitation, it replaces the shared version of the event that User A. User A's status is set to confirmed.
  • User B adds an event onto the User A's shared calendar. Unless User B sends a capital N otification invitation to User A, User A's event status will be set to FYI. User B's event status will be automatically set to confirmed.

3. User A has an All calendar and a separate Work calendar. User A gives User B read only privileges to the Work calendar

• • So how do events end up in the Work calendar share?
    • User A can add an event and send an invitation to User B which will go on User B's calendar.
    • User A could have a scheduled event in their All calendar and drag it to the Work calendar (it would be in both the Work and All Calendar).
  • I don't follow this...can't you just put an event in a user-defined collection but it will still be in the All collection. I don't think it matters if it's an incoming or outgoing share? -> MimiYin Ah, you can't move items out of the All collection. Deleting items from the All collection, deletes it everywhere, including shared collections.
  • Anyone invited to events will receive capital N otifications event invitations which are automatically added to their calendars.
  • Participants of the share that are not attending events will receive "n" notifications for changes. Participants of the share that are not explicitly invited to an event will have an event status of FYI.
  • Each sharing participant sees their personal event statuses on all shared events. In other words, event status is outside of the sharing cloud.

4. User A has an All calendar and a separate Work calendar. User A gives User B write privileges to the Work calendar

• • This should be exactly the same as #2.

5. User A has their own personal calendar All and a collection called Office Calendar. Imagine Blue managing the Office Calendar with staff meetings, social events, people's PTO etc

• • Some people may have read only access, others read/write.
  • This scenario should not be any different. All users attending an event will see it on their calendar with their status. Other events will appear as FYI.

Checking a person's schedule (TBD)

Notes on Recurrence

• Need to work out recurrence and how this is propagated.
• Recurring events deletion - choose between
  • this one
  • this one and all future
  • all occurrences
• Editing should have these 3 options as well.
• Adding attendees are just like edits.
• Kibble solution - simple recurrence - inherited when sending an event invitation.