[Design] A calendar that tracks people and locations

[Grant Baillie]

On Jun 1, 2006, at 5:18, Callum Macdonald wrote:

> Nobody has anything to say about my ingenious brainwave that's  
> going to change the world? :)

Hi, Callum

Sorry for the delay, and welcome to the list :). These are cool  
ideas, especially for users who travel a lot: IMHO it wouldn't  
interfere with users being  able to build up a mental picture of  
their schedule, but would help avoid unfortunate scheduling errors.

 From an engineering perspective, Chandler's model (and UI) for  
location is still pretty rudimentary: in the long run, it's easy to  
imagine that being beefed up, and having the app suck down web 2.0  
data for those "transit appointments" (airline & public transit  
schedules, maps & driving directions, etc). The devil, of course,  
would be in the details the application logic of integrating all that  
data. Even in simple cases (like, calling in to a meeting scheduled  
in a shared calendar as being in a different time zone), it's non- 
trivial to make the location inference correctly.

While people here have thought about some aspects of your "ingenious  
brainwave" :) (e.g. events with start & end times in different  
timezones, which are supported by some clients, like Lotus Notes), I  
don't know of anyone having looked in depth at a location-savvy  
calendar. I also don't think that we (OSAF) could undertake to do  
this in the Chandler 1.0 timeframe: We're more focused on different  
devilish details: dealing with sharing and scheduling in small  
workgroups. However, it would be a great opportunity for a third- 
party parcel (plugin) writer.

--Grant

> On Fri, 2006-05-26 at 12:27 +0700, Callum Macdonald wrote:
>
>> Hi Guys,
>>
>> New on the list, I've done a quick search and I don't see anything on
>> this thread, so thought I'd start it off.
>>
>> I have this idea that my calendar should be smarter. Specifically, I
>> think it should be aware that my appointments are in *locations*.  
>> That I
>> need to physically move from one location to another, spending  
>> time in
>> *transit*. Those locations might be in different *time zones*.
>>
>> In terms of comparing my availability with others, our locations  
>> should
>> be taken into account. If I'm in Bangkok and I'm scheduling a meeting
>> with someone in New York, I can't squeeze them in for lunch  
>> between my
>> bank manager in the morning and my daughter from school in the
>> afternoon.
>>
>> For example, I schedule an appointment with a client. My calendar  
>> knows
>> my default location is in Bangkok between 9 and 5. I schedule the
>> appointment for 9am, so my calendar prompts a 30 minute transit time
>> before the meeting from my home location to my appointment and  
>> then a 30
>> minute transit time from my appointment to my office location.
>>
>> After a few hours in the office, I'm flying to Europe for a  
>> meeting the
>> following day. I enter my flight as a transit appointment, and add a
>> timezone change of -6 hours into the GMT+1 timezone. While I'm at  
>> it, I
>> enter my return flight as a transit appointment and return to my  
>> normal
>> time zone.
>>
>> I set up a few appointments in Europe and enter those. My calendar
>> automatically prompts me to enter them in local time and visually  
>> shows
>> the appointments in local time on my daily calendar. It shows my  
>> transit
>> time as a squashed / expanded transit appointment as I move  
>> timezones.
>> It also shows me my appointments in my home timezone time alongside
>> their local times. Just so I know what time my body will think it is!
>>
>> My availability is publicly available through my calendar  
>> published on
>> my web site / server. My calendar doesn't show my appointments, but
>> based on my rules, it shows my availability and if I've set the  
>> transit
>> appointment to be public, it shows my location on a given day.
>>
>> Thus my colleagues in Europe can check my schedule and suggest
>> appointments at times when they know I'll physically be in the  
>> region.
>>
>> I see this as a natural development from the basic calendaring
>> functionality that has existed for years.
>>
>> Before I get carried away, is this already in the design plan for
>> Chandler? Has it been considered and thrown out for a very good  
>> reason I
>> haven't thought about? Am I going stark raving mad, would this be  
>> about
>> as useful as an ashtray on a motorbike?
>>
>> Any and all comments would be gratefully received.
>>
>> Kind regards,
>>
>>
>> Callum.
>>
>> Blog: http://www.callum-macdonald.com/
>>
>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design