[Design] RE: Free-busy in public calendar

Marc Gibeault mgibeault at alto-design.com
Mon Feb 6 14:42:03 PST 2006

Hi Mimi,

>Date: Mon, 6 Feb 2006 10:00:07 -0800
>From: Mimi Yin <mimi at osafoundation.org>
>Subject: Re: [Design] Free-busy in public calendar
>To: Chandler Design list <design at osafoundation.org>
>Message-ID: <4B3B7E66-C542-4039-8917-2029BF1060B7 at osafoundation.org>
>Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
>Hi Marc,
>Thank you for the screenshot. (This is definitely the right place to  

Welcome! Pleased to be relevant...

>It seems like this kind of calendar could be shared / maintained by  
>users simply as a separate calendar.

Yep, good idea. Everyone in our workgroup would then have at least 3
calendars; This "workload" calendar, a personnal calendar and a "normal"
public calendar.

>At a workflow level however, it seems like it's generally hard for  
>people to do this kind of long-term time-based planning. (ie. This  
>week I'm going to work on X, next week I have a bunch of meetings to  
>take care of, the following week I'm away at a conference.)

I disagree here. The way I think of it, it may be my project manager that
will fill this up for me!
If this project manager can view and edit the "workload" calendards of all
his "ressources" he can do some planning. And if another project manager
wants to assign some projects to me, he'll see how I'm doing by taking a
look there. 
I don't see meetings or conferences in there, just the main underlying tasks
I am paid for. And these are easy to put there as they were planned when our
company took the job (at least it's supposed to).

>One of the central assumptions driving Chandler's design is that  
>people are interrupted with such a constant stream of requests for  
>their time, that the best laid plans become irrelevant before you've  
>even had a chance to record them.

No, I have to finish this bunch of CAD files by the end of march and send
them to the customer. I have strict deadlines as do most people I know.
>Perhaps a more realistic scenario for this kind of calendar usage  
>would be at a working group level. (ie. This week, we are addressing  
>"Issue: X", next week we're going to be evaluating candidates for Y,  
>the week after, our international team is convening here for a week  
>of intensive all-day training sessions...)

If you're only thinking about about bug-smashing and feature-implementing
software development, maybe. I don't know much about that. But in product
development that's not the way it's happening.
>Another way to think about it might be to allow a special Free-Busy  
>field where users can "describe" the F/B time blocks without  
>revealing specific details about their events.

Let's see... But take a look again I the screenshot I posted. It shows on
what I'm working (can be several projects at once) and my workload and
possible availability with percentage. And this kind of "event" allows
"normal" scheduling of meetings, etc...
-Marc Gibeault

More information about the Design mailing list