Problem: Scheduling serious business meetings often requires multiple rounds of back-and-forth. In the degenerate case, everyone describes a vague version of their availability first (like "oh, I'm mostly free later this week") because specifying their exact availability would be tedious, then once enough people have kind of implied their availability someone suggests some times, then some people confirm, then some other people say they can't do that time, can we do a different time? then a different suggestion is selected, then no one really objects so that's when the meeting likely happens. This is pointless and time consuming.
Proposed Solution: For business meetings which fit this pattern (vs parties, external events, etc., which must happen at a specific time), attendees only tell Calendar about constraints. It automatically schedules meetings which satisfy these constraints.
Walkthrough: As a host, this might look something like:
- You go to Calendar and choose Create Event → Schedule Meeting... or similar.
- This puts you into a modal create workflow which gives you constraint controls instead of start time + end time controls.
- Broadly, you specify the meeting duration and a range of acceptable dates and times, using some reasonable interface. For example, you might be scheduling a lunch meeting and acceptable times are 11AM - 2PM on this Thu, Fri or next Mon.
- You fill in the rest of the details and hit "Create Event".
You arrive on the event detail screen, where everything looks normal, except:
- Calendar has chosen a start time from the available times.
- The start time is marked "(Tentative)".
- The event as a whole probably has a "(Tenative)" label, although maybe this isn't necessary.
As an attendee, the workflow looks like this:
- You get a normal email about the event.
- It marks the start time as tentative.
- It has additional instructions: "If this time doesn't work for you, specify your availability when RSVP'ing to the event."
- You RSVP. When you click "Attending", you get a scheduling dialog instead of a confirm dialog. This dialog uses similar "constraint controls" to those above.
- In the scheduling dialog, you specify additional constraints ("I can't make it on Thursday") using these controls.
- If there is a better time for the meeting to take place given the new constraint information, the meeting is immediately rescheduled.
- When the last attendee RSVPs, the meeting is no longer "Tentative".
Considerations: Overall, the system should have these properties:
- Events should always have a time, even if that time is marked "tentative". If we wait for everyone to RSVP before scheduling the meeting, one person not RSVP'ing prevents the meeting from happening. This is bad/undesirable. The tool should generally be pushing meetings toward happening and happening with less involvement, not more.
- When selecting constraints, we should fill in all of the events we know you're attending by default.
- Users can always adjust constraints later, if their schedule changes.
- Your preferences should count more if you RSVP than if we passively read your status out of your calendar (to encourage users to RSVP, and improve the accuracy of constraints).
- In cases where two alternative times are about equally attractive, your preferences should count more if you RSVP earlier than if you RSVP later (to encourage users to RSVP promptly).
- We should leave probably blocks between meetings by default. (Eventually, we can add formal locations and have more information about how long it will take people to travel between meetings.)
- While we don't want to reschedule meetings idly, I think we should start by being fairly liberal about rescheduling in order to get a better time and then make them less fluid in response to feedback if necessary. For instance, it might be bad to move 10 AM meeting if it's currently 20 minutes before the meeting. But we can be gradual about this in various cases where this is important: fluid reschedule by default -> no reschedule by default -> require a confirmation -> require a confirmation plus a note apologizing for being a jerk -> require an explicit rescheduling edit by the host. We might also want to let the event owner easily "lock" a meeting to a specific time (basically, remove the "fluid" magic).
Constraint Cascading: This will introduce a hard computer-sciency problem where you try to RSVP to a fluid meeting and you're busy at all of the available times, but some of your conflicts are other fluid meetings which could be moved. If we were really smart, we could automatically move those meetings around and find an optimal schedule across your whole set of fluid meetings. We should just ignore this for now because it's almost certainly extremely hard. If the feature is good/useful overall, we can consider being smart about it later.