Hi Marc,
Thank you for elaborating on your scenarios. Please see more in-line.
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 think this is an interesting use case. The target user we've been
working with is someone who defines their own projects and defines
their own deadlines (and is having difficulty doing so effectively
because their list of responsibilities changes so rapidly.) (More of
a project manager than an individual contributor on a project.)
But there's nothing in Chandler's design that would prevent people
from maintaining the kind of calendar you're describing.
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.
Yes people certainly have deadlines. However, when you're going to
work on a project to meet that deadline is harder to pin down for a
lot of people.
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.
Mimi
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...
Could you talk a little about how you come up with the percentages
for your work?
Thanks,
-Marc Gibeault
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
