Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!mintaka!athena.mit.edu!cfields
From: cfields@athena.mit.edu (Craig Fields)
Newsgroups: comp.groupware
Subject: Re: Groupware Effects on Hierarchie
Message-ID: <1990Jul25.045719.21115@mintaka.lcs.mit.edu>
Date: 25 Jul 90 04:57:19 GMT
References: <1835688710@JANSSEN.90Jul18175044@holmes.par> <1138200037@cdp> <1990Jul23.004917.6139@mentor.com>
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Reply-To: cfields@athena.mit.edu (Craig Fields)
Organization: Massachusetts Institute of Technology
Lines: 68


  I seem to have discovered this discussion rather late, but... I
happen to be finishing up an implementation of a calendar program that
allows people to make meetings with each other through it.

  The first feature I implemented to this end (after getting the
functionality of a standard calendar program in) was the ability for
the user to select a set of other users and see on a chart the times
they were busy overlayed. That is, across the top of a grid are the
days of the week, and down the left side are hours from 9 to 6, in
increments of 30 minutes. Each cell is shaded according to how many
people are busy, according to their calendar, during that half hour.
(The user may trivially block off any times s/he chooses as being
busy.)

  People found this feature alone massively useful in facilitating
making appointments with small groups of people (which in general
seems to be the need here).

  On to the code I'm finishing up now:

  The user selects a group of people s/he wishes to have a meeting
with, and potentially pages ahead a week or so to find a time that
seems to be adequate for everyone, or most everyone. There is nothing
preventing the user from selecting a time that someone has marked
busy. S/he selects the time and enters a description of the meeting,
and then instructs the program to send the meeting information to the
"meeting server." The meeting server is more or less a mail server in
functionality, but more suited in various ways to this task. The
meeting server sends notification to those recipients who happen to be
logged in that there is something waiting for them on the meeting
server.

  With the calendar program, the recipients will eventually
"incorporate" their new meetings. These new meetings will come up in a
distinct window at this point. Meetings may be tagged as "tentative,"
"final," or "cancelled," though in the case of just having received a
new meeting it is much more likely to be "tentative."

  At this point the recipient has the option of responding to the
(proposed) meeting time one of "yes," "no," or "maybe," along with a
bit of text for a counter-proposal time or whatever s/he may wish to
say about it. In addition to this, the recipient chooses whether to
add this appointment to the calendar or not, and whether or not it
should show up as time that s/he is "busy."

  These responses are returned through the server to the initiator of
the proposed meeting, who may decide either to finalize that meeting
time, or to cancel that meeting proposal and initiate a new one for a
different time. Finalizations and cancellations of meetings will again
go through the server to the recipients.

  So does anyone see any major problems with this? It's not running
yet (it hopefully will be by next week), but I don't see any problems
with it for this environment (provided of course, that people involved
actually _use_ this program and keep it up to date). Are there
environments where you would expect it to fail?

  There are a few choices to make in implementing this model, but
that's essentially it. The client is an X based Motif program, and has
a few dependencies on the environment of Project Athena. Client and
server authenticate through Kerberos, and the server notifies users of
new messages through Zephyr. Programs already exist that do
appointment making in various ways, but none that I know of are really
usable in the Athena environment.

Craig Fields       cfields@athena.mit.edu
MIT-Project Athena