consensus@cdp.UUCP (07/03/90)
Subj: authoritairan mode 90-07-01 22:33:53 EDT From: Shep T I agree that people are very nervous about a computer telling them what to do, more nervous than if someone just told them in person. I think this is a real phenomenon and should be taken into account in building groupware. Groupware should go out of its way to seem non threatening, for this very reason. I also agree that one's personal calendar IS considered a PERSONAL thing and should not be tampered with by anyone who doesn't have permission. Tom had a great example: my boss can set up a meeting that I'm supposed to attend, but it would be pretty rude for him/her to actually open up my personal calendar and write in it without my consent. * The preceeding reply is cross-posted from the Groupware SIG on * America Online. To reply to an individual on America Online, contact: * * Christopher Allen - Consensus Development * P.O. Box 2836, Union City, CA 94587-7836 * AT&T: (415) 487-9206 * America Online: AFL MacDev * AppleLink, GEnie, MacNET, MCI: Consensus * Internet: cdp!consensus@labrea.stanford.edu * UUCP: uunet!pyramid!cdp!consensus
reaton@cdp.UUCP (07/20/90)
Gentlemen,
About this calendar argument. Am I missing something? Would
not a good piece of groupware facilitate the calendar interaction
without forcing anything?
You want to put something on someone else's calendar? Ok,
go ahead. But the system translates your posting into an e-mail
invitation which the recipient can post to his calendar by some
simple mechanism such as pushing a "calendarize" button.
Or am I missing something?
Roger Eaton (PeaceNet)plogan@mentor.com (Patrick Logan) (07/23/90)
In article <1138200037@cdp> reaton@cdp.UUCP writes: >Gentlemen, > About this calendar argument. Am I missing something? Would >not a good piece of groupware facilitate the calendar interaction >without forcing anything? > You want to put something on someone else's calendar? Ok, >go ahead. But the system translates your posting into an e-mail >invitation which the recipient can post to his calendar by some >simple mechanism such as pushing a "calendarize" button. > Or am I missing something? > Roger Eaton (PeaceNet) I was thinking of the same thing. People could make public (perhaps to varying degrees) their schedules. [Sort of an elaborate .plan] Then to schedule an appointment, a person could use a typical e-mail interface or some other interface, like a calendar combining the known appointments of everyone being invited. The receivers may choose to see appointment requests as "penciled in" in their calendar or as an e-mail message or something else. Attributes of the "request" may alter the appearance or method of reception. E.g. a boss' request would be in RED in the calendar. Some other request may show up in the trash can. -- Patrick Logan uunet!mntgfx!plogan | Mentor Graphics Corp. 8500 SW Creekside P | Beaverton, Oregon 97005-7191 |
cfields@athena.mit.edu (Craig Fields) (07/25/90)
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
cfields@athena.mit.edu (Craig Fields) (07/25/90)
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
wex@dali.pws.bull.com (Buckaroo Banzai) (07/26/90)
In article <1990Jul25.045719.21115@mintaka.lcs.mit.edu> cfields@athena.mit.edu (Craig Fields) writes:
[functionality discussion deleted]
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?
Where to begin. First off, nothing I say should be seen as a slam against
Craig, his program (which I haven't seen), or anyone else doing calendar/
scheduling systems. Craig wanted to know what the problems might be, so
here are a few off the top of my head.
First off, there are the standard problems with using email for
notifications in that (1) you can't tell when/if a message is delivered; (2)
you can't tell when/if someone's read the message you're interested in.
Second, the idea of incorporation looks at first glance something like the
transaction problem in databases. What will happen when two people have
"incorporated" the meeting into their calendars, but then the organizer
decides to change it as a result of one person's objection? Can the other
calendars be reliably "rolled back" to the state they were in before
incorporation? Remember that other (valid) events may have been
incorporated between the original time and the time you want to try a
rollback.
Third, if someone wants to counter-propose, how will they know a good time
to suggest? Will they have access to the same set(s) of calendars that the
meeting originator did?
The concept of adding an appointment but not having the time show up as busy
strikes me as kind of odd and likely to increase your rate of collisions.
Fifth, if I have made a response/counter-proposal to a meeting, how long
must I wait to know if that time is committed or if my suggestion will be
adopted? Do I see other people's counter-proposals?
None of these are total show-stoppers, but you *did* ask...
--
--Alan Wexelblat
Bull Worldwide Information Systems internet: wex@pws.bull.com
phone: (508) 294-7485 (new #) Usenet: spdcc.com!slug!wex
"Zen is the essense of Christianity, of Buddhism, of culture, of all that is
good in the daily life of ordinary people. But that does not mean we are
not to smash it flat if we get the slightest opportunity."