🚀 go-pugleaf

Actually, there's a distinction beyond the importance of a meeting
that I think is important for more automated calendar agents to take
into account and that is rescheduability (pardon the hideous
neologism).  Some very important appointments are easy to reschedule
and I would be willing to move them to be able to attend another
meeting (e.g., a meeting with a member of my research group who's
around every day); others are perhaps not so important but fixed
(e.g., public lectures or seminars).  Depending on the amount of
notice, appointments might move from one category to another; e.g.,
given a few week's notice, I can change a doctor's appointment; given
only a few days, it's essentially fixed.

This particular feature of meetings is relatively common for people to
discuss when negotiating over a meeting time (e.g., "How about 3?"
"I'll have to see if I can move my other appointment and get back to
you." vs. "There's a seminar I wanted to attend" (i.e., if there's no
other time, then okay, but I'd sooner not)) but does not seem to be
either easy to make explicit (i.e., exactly which appointments are you
willing/able to reschedule?  How easy is it to move this meeting vs.
that meeting?) or often represented in computerized calendars.

However, it's also one that a computerized calendar system might offer
a significant advantage in handling.  In particular, rather than your
having to check with the other person, change your appointment and then
call back the original requestor, your calendar agent could do it all
for you (or as much as you wanted to let it) and simply present you
with a message saying, e.g., "The best time for the group meeting was
3; you were scheduled with Bob then, but he can make it at 4 instead;
shall I go ahead and change your schedule and confirm these two new
meetings?"

Kevin

In article <46147@brunix.UUCP>, muru@iris.brown.edu writes:

> a) The prominent scenarios for an office scheduling are:
> 1) Each participant has equal access to anyone's calendar (can R/W on any
>    calendar).
> 2) Same as 1 except that s/he can R anyone's calendar but only W his or her
>    calendar.
> 3) A select group of participants (typically managers) having R access
>    to all calendar's but (in)directly having W access to all (or most)
>    calendars. Situations for this scenario was pointed out by Scott McGregor
>    mcgregor@hemlock.Atherton.COM - Article 236.
> 
> Technically, scenario 2) seems to be the most appropriate for which
scheduling
> systems should be aimed at.
> 

> I would appreciate if someone could post a summary of the important
conclusions
> drawn from previous discussions on this topic that I have missed. 

Considering the scenarios above, scenarios 1) and 3) have the opportunity for
most leverage as groupware, that is, a technology that fundamentally
changes the way all members work.  Scenario 2) is most like a
personal productivity tool, in that everyone still has to go through
the personal work of doing the scheduling requested of them.  You can
really see this clearly in the interactions that are done to actually
get a meeting scheduled--typically mail system mediated propose-and-formalize
type negotiations.  In some cases these negotiations are via agents instead
of direct person to person, in which some additional groupware type
support is perceived, though perhaps less than if the user MUST
involve themselves in meeting negotiation when they would not care
or have a choice.  Since scenario 2) has more personal productivity
tool attributes and less groupware attributes, it is less subject
to problems that arise from machine mediated interpersonal control.

Scenarios 1 and 3 do significantly change the way individuals participate
in group actions.  This can lead to threatening machine mediated interpersonal
control, but also offers the opportunity to significantly reduce the amount
of personal overhead work needed to conduct group activities.  Details
in the construction of the system and its suitability for the specific
workgroup with its existing work cultural norms are crucial for acceptance.
Because work cultures vary so widely and details matter so much, this
does not bode well for a single product getting wide acceptance, and
may therefore inhibit development of such systems.

Scott McGregor
mcgregor@atherton.com