Often overlooked details of booking a meeting

FindFreeTime will save people time by automating the "best time negotiation" task that now must be handled with email or phone calls. But for the automation to be effective, it must truly represent the nuances of booking a meeting.

The hard details of a meeting (guests, duration, location, etc) are obvious elements of meeting planning. Likewise are the yes and no responses to availability. But there are other classes of guests and subtle levels of availability that FindFreeTime supports that are also important. First, let's examine guests (or attendee in calendaring & scheduling parlance).

The vCalendar standard defines attendee types through the EXPECT attribute enumerations: REQUIRE, REQUEST, FYI, and IMMEDIATE. The REQUIRE value indicates that the person's presence is mandatory in order for the event to occur. The FYI value indicates that the invitation is informational only. Although it seems that the FYI'd person could accept the invitation and attend the meeting. In my opinion, the REQUEST value should be the default type (in the standard FYI is). The REQUEST type signifies that accept or not, the meeting will still go on without them. In my experience the REQUIRE and REQUEST/FYI types capture the two real world types of attendees: those who are required guests because they have some information or play some part in the event that is crucial. And those who it would be nice if they could attend, but the meeting will still go on without them. Our beta tests will include just these two classes.

If a group of people use a dedicated scheduling platform like Outlook or Meeting Maker, they can usually see at the time of meeting planning whether a potential guest has availability. It's likely that FindFreeTime will not be useful to them. But for most everyone else, knowing a guest's availability requires probing that person. And in my experience that's usually done with a barrage of emails to and from the meeting's organizer. This is the pain that FindFreeTime seeks to alleviate.

If one examines a couple of the "Are you free?" email threads in your Trash folder, it doesn't take long to discover that there are in fact four types of availability:

1. Yes, I can make that time.
2. No, there's no way at all that I can make that time.
3. Maybe, I'm not certain right now... but I should know conclusively at some future date whether that time works for me. In other words, I'll pencil it in.
   
4. Not ideal, but yes I can make that time if that's the only time available, but it causes some pain on my part. Hopefully one of the other times will work for everybody.
   

FindFreeTime's Interval Selection Interface (the ISI) allows an attendee (including hosts) to specify these subtle levels of availability. The host, or the automated meeting resolver, can then take these factors into account when finalizing the meeting.

In our XML Schema (Event.xsd), these types of availability are represented in the attendees element in the subelements confirmedAvailability, possibleAvailability and reluctantAvailablity.