This is a bit of geeky post, but I can’t help it.
We have a group scheduling program where I work. Anyone on the system can check my availability and “invite” me to a meeting. It’s handy for group scheduling, and even though it takes away from me a modicum of control over my calendar, it saves up for having to type up and email my availability around whenever someone asks for it. Plus, I can always decline to attend a meeting.
The main problem it has is a total lack of knowledge about geography. Here’s a typical problem:
I was just “invited” to a meeting on the other side of campus (about a 15-minute walk) immediately after another meeting was scheduled to end. So, technically, I’m “available” at the scheduled time, but I can’t physically get to the other meeting location until 15 minutes after the meeting starts. And both happen to be important meetings that involve lots of other people, so I can’t request an alternate time without inconveniencing others.
This can be partially solved by social engineering—simply ask everyone on the system to be mindful of stacking meetings up against one another. But most of the time, the scheduler has no choice, and certainly can’t be expected to view each meeting that bumps up against the desired time, calculate walking distances to-and-from a venue, etc. etc. Furthermore, I have chosen to hide the details of my meetings from others, so all they have to go on is start and end times.
In the old days, this was all accomplished by beings called “secretaries” who would manage the busy schedules of important executives such as myself. And make coffee. These days, however, everything’s all done by these new-fangled computing machines (except making coffee). Luckily, the problem I described can be rather simply (I think) and completely solved by the software itself. All it would require is a database of locations and their latitude and longitudes, plus some algorithm for calculating travel times. This is not as crazy as it seems. There already is a database of campus buildings, and something like Google Maps could easily allow someone to plot their exact coordinates down to the meter. Google Maps, MapQuest, and all the various ampping applications also can provide “travel time” estimates. It’s all out there; it just needs to be integrated.
Upon adding a group event and selecting the location from a pre-defined list of buildings, the program would look at everyone’s schedule and check the location of the meeting just prior to the new event. (if there is no meeting, each user would have a pre-defined “base location” to use). Some simple math based on the distance between the two locations and the average human being’s foot speed would raise a warning flag if any individual did not have sufficient travel time to arrive to the meeting on time.
All of this could be defined in the application layer without needing to mess with the underlying data or the format standards on which it is based. The “Location” in iCalendar format, or whatever, would still be the “Location.”
This would solve another problem, too. Directions. I haven’t been to every building on campus. Furthermore, virtually nobody’s been to my building, which is on the edge of the most unfashionable sector of campus. My little reminder chime goes off 15 minutes before a meeting. Sometimes, I’ll look at the window and say: “Oh great. I have no idea where Sassafras Hall is,” and then learn it’s way the hell over on the other side of the Interstate or something. I would love I the reminder bell could go off 15 minutes before I need to leave rather than 15 minutes before the meeting starts, and pop up a nice little map showing me exactly where Sassafras Hall is. Again, we have campus maps, and they take parameters; again, the technology is already there and it’s just a matter of integrating it.
Obvious problems (and proposed solutions):
Off-campus meetings. This could be addressed, however, by allowing an alternative method of inputting an “other” location, which would simply not trigger the distance calculator. The application would act as it does now with no loss of functionality. Commonly-used off-campus locations could be entered to the database. A similar problem already exists if the calendar can’t find event data for someone (due to security settings). It goes ahead and adds the meeting, but does no “free/busy” checking.
Differences in definitions of “walking distance” (especially to accommodate individuals with disabilities). Stephen Wright once said: “Anywhere is walking distance, if you have the time.” But travel speeds vary from person to person. One solution would be to allow each user to specify their average travel speed as a “Preference” in the program. To be more complex about it, an individual could be able to flag whether or not they have access to transportation to/from a given event, and the algorithm could factor that in when making calculations. For example, if I’m at some distant location but I indicate that I have a car with me, someone should be permitted to schedule me for, say, 15 minutes after the meeting ends instead of 45 minutes. [My data center also houses the computers that track Seattle metro buses via GPS, so that opens up a whole realm of potential transportation services to integrate into my imaginary scheduling software].
Complexity. It would be much simpler to just have a user block off “travel time” to and from a given meeting as a separate event on a meeting-by-meeting basis. I sometimes do this if I have to take the bus to a doctor’s appointment, or something. The problem is, however, that I’m rarely that on top of my schedule. Usually, I have no clue where I’m supposed to be until the little chime goes off and tells me. Plus, I’ve had meeting invitations flow in 2 and 3 at a time, so I don’t even have a chance to review each one and figure out how much travel time I need. Finally, there’s still the problem of not knowing where all my various meetings are. I want that little map!
So, software developers, let’s go going on this!
