🚀 go-pugleaf

In article <1990Jul7.185933.1366@mentor.com>, plogan@mentor.com (Patrick
Logan) writes:

> I'm writing this with the same disadvantage. I have just one
> observation.  That is, even within one organization various people
> have their own preferences for maintaining their calendar[s].
> Shouldn't a scheduling application be flexible enough to accomodate
> the range of preferences as long as it accomplishes the organization's
> goal of speedier, accurate scheduling?
> 
It is interesting that people want a forcing function on their computer 
calendar's that isn't on their paper ones.  Paper calendars do not have
a physical forcing function that prevents them from being written on by
other people.  At best, they may not be physically accessible often.
But when they are, the function that people use is a SOCIOLOGICAL one.
Typically, they create a social policy by telling people "Don't write
in my calendar".  The use of a sociological function, instead of a
physical forcing function is what allows the "flexibility" mentioned above.
I can establish one case for calendar and someone else can establish
a different policy for theirs.  People can use their judgement for handling
exceptions: "I know Bill doesn't usually like people to add appointments
into his calendar without permission, but he's not around, and the
company president explictly requested his attendance..."

Use of sociological functions can work even on computer systems, (in fact
I have seen this happen to myself and others with shared computer calendars).
But many programmers seem to be upset when the sociological solutions are
not converted into forcing functions implemented by the computer system itself.
Unfortunately, this often leads to either less flexibility, or more complexity
for the user to learn how to configure the system to meet their requirements.

Scott L. McGregor
mcgregor@atherton.com