Hi Alan, I am re-routing this to the design list because I think this
discussion is getting involved enough that it really belongs on a
list where the subscribers are more interested in getting into the
weeds with design issues :o)
I think there may be some high-level approach mismatches that are
getting in the way of understanding.
First, some clarifications:
+ I am not saying that CEOs are the only people that are hard to find
meetings times with. I simply gave that as an extreme example.
+ I am not saying that we are only designing for groups so small and
so tightly knit that everyone knows everyone else's calendar inside-
out and that there is no need for negotiation when scheduling meeting
times.
What I am saying is that scheduling, for the small work groups we've
defined is an annoyance, but not an all-consuming headache in their
daily work lives.
Instead, the focus of Chandler for the near future is to provide
small work groups and households with a better solution for sharing
and collaborating on calendaring and task management. These are small
groups that can and do live without structured scheduling workflows a
la Outlook + Exchange.
Without free/busy and in-line accept/decline workflows, scheduling is
definitely a pain, but not impossible. We've found through
interviewing users that in such environments, it's incredibly hard to
get people to even maintain calendars that are faithful
representations of their schedule. Given that, adding on something
like a commitment scale feels over the top. People are also really
sensitive to personal preferences. So even if there is an opening/gap
in someone's schedule, if they would prefer not to meet at that time,
that preference is respected.
In the end, our theory is that for small workgroups, negotiation is
unavoidable and preferred and so we're better off working to make
the negotiation as painless as possible and haven't tried as hard to
render negotiation unnecessary with affordances for more transparency
around event status.
That being said, there is no question that there are many work
environments where Exchange or something like it is indispensable.
However, for now, that is not our focus and we believe that the small
work group, as we've defined it, does constitute a significant user
population.
Mimi
On Mar 23, 2007, at 8:35 AM, Alan Mandel wrote:
Hi Mimi and all,
Thank you for your thoughtful and detailed replies. I'm going to
respond, but I know you are all super-busy (even without access to
your shared calendars!), so don't feel obligated to continue the
thread.
And thanks for that topical journal entry on negotiation etc.!
In my workgroup experiences, we came up with a great many protocols/
customs in the way we did our engineering. So it would not have
been a burden for us, for example, to have a guideline like this:
"When scheduling a meeting, flag the Commitment Level appropriately
if you know it, from the drop-down list. As a guideline:
0 = No entry [default]
1 = Must attend (e.g., you're the facilitator)
3 = Important to attend (e.g., participant in a code review)
5 = Will only attend if bored"
Scheduling a meeting with a dozen people is so time-consuming
because of its serial nature: you find a proposed time, then need
to hear back from everyone before you take the next step, etc.
It's great to see the features that you're adding that will shorten
this loop! For sure, there's a plethora of other factors to
consider in scheduling a meeting, but for me waiting for responses
on 'Commitment Level' caused the majority of the iterations on the
scheduling loop. I think my usual questions were:
A) Are you available anytime sooner?
B) Do you have to attend Meeting X?
C) Can you arrive late/ leave early in Meeting X?
D) How early/late do you work?
E) Can you reschedule Meeting X?
Commitment level would go a long way to short-circuiting the loops
for (A) and (B).
There are also missed opportunities. In overlaying calendars, I
always tended to just skip over (i.e., not consider) timeslots in
which more than one or two people had conflicts. So knowing up-
front that the conflicts were "soft" would have been wonderful.
While emails/negotiations are a great supplement, they aren't as
concise or efficient as a "choose one list."
Actually, I've had trouble scheduling meetings with just a couple
of people (who were not CEOs) if either: a) they were managers; b)
the scheduled meeting needed to be more than 90 minutes; or c) The
participants spanned time zones such that the working hour overlap
was reduced. The latter was particularly troublesome because the
limited overlap not only reduced the number of viable timeslots,
but the density of conflicts during the overlap was much higher
since all meetings with geographically dispersed participants
needed to be crammed into the available overlap.
From the responses I've read, it seems to me that the definition of
"small workgroup" is being quite narrowly defined by the Chandler
team. You're assuming that there are few if any private (detail-
less) meetings, that the number of people is pretty limited, and
that the team is homogenous enough to know at a glance the
Commitment Level of anyone's event. Excepting for family, I doubt
that anything in my career (college, four high-tech jobs at
companies of varying sizes over a 25-year period) would have
simultaneously met these criteria.
If the scope is being kept narrow just for the purposes of getting
the product released, then that is emminently sensible. But I'd be
concerned if Chandler 1.0-2.0 is fundamentally based on (and
limited by) the presumption that the generic "small workgroup" has
all these characteristics.
Don't get me wrong: with or without the Commitment Level feature,
I'm excited and eager to use Chandler. It's just that I sense
killer feature in here somewhere, so I'm impatient. I know, I
know, then I should contribute. Well, I downloaded all 100MB+ of
sources yesterday. A billion bits is a little intimidating. :-)
Thanks again!
-Alan
Mimi Yin wrote:
Hi Alan,
Here's a bit more design background which may clear up a few of
your questions.
In our experience, the tricky part with small workgroups is that
it's hard to get to enter this kind of data into any 'system'.
Many people simply store these kinds of fine-grained distinctions
in their head.
Many times, people don't really know if they 'need' to attend an
event or not, because so many of these decisions are relative.
Perhaps the event they have blocked off from 1-2PM today is not
that important, but then again, perhaps it's more important than
the event you're trying to book them for. They can't know until
you make the proposal.
Instead, as Jeffrey said, our approach has been to provide users
with some flexibility around scheduling so that it's easy for
people to negotiate their way to a good meeting time.
Here are some ideas from a list discussion we had a little over a
year ago: http://wiki.osafoundation.org/Journal/
NegotiationAndScheduling
That being said, there are ways to use the attributes we have
today to figure out how set in stone an event is...assuming you're
sharing calendars...
+ Event status in Chandler is specific to the user, it can be
shared or not shared. So when an event is Tentative or FYI, it's
Tentative or FYI to the 'owner' of the calendar.
+ Addressing fields. To:, CC: and BCC: are good clues about
whether someone is required to attend a meeting or not.
Finally, re: small workgroups. In Chandler vernacular, workgroup
means an almost closed, discrete group of people working together.
It's not to say that the workgroup never interacts with people
outside of itself, but it would be safe to say that over 80% of
people's daily interactions are within the workgroup. So I have no
doubt that scheduling a meeting with just 1 other person can be
extremely difficult, if if both people are CEO-types with tightly
packed schedules. But the size of any individual meeting wouldn't
qualify that group as a small workgroup.
So you can imagine that if there is a group of 10-15, even up to
30 people who work closely together all the time, each person
would get a pretty good sense of all the meetings that go on
within the group and even many of the meetings that happen outside
of the group (e.g. meetings with board members, client meetings,
etc.).
I hope that clarifies more than confuses. You've definitely
identified a problem that we want to solve and are working towards
solving, even in Preview, but we're coming at it from a different
tack. As Katie said however, we don't know what our plans are for
1.0 as of yet and based on the dogfood feedback we get, we fully
expect to continue iterating on our scheduling workflows.
Mimi
_______________________________________________
chandler-users mailing list
[EMAIL PROTECTED]
http://lists.osafoundation.org/mailman/listinfo/chandler-users
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
