Calendar Scheduler: Design considerations

The challenge arises from two source: the multiparty, distributed, heterogeneous, asynchronous nature of calendars; and the need to accommodate personal preferences, some of which are either private or poorly articulated.

This problem may face considerable hardware and environmental constraints. For example, personal electronic notebooks do not yet communicate freely, so it is not possible to assume that all calendars of interest will be either instantly or simultaneously accessible.

Users' expectations are also a factor in considering alternatives; it is probably not acceptable to completely reschedule everyone whenever a meeting is changed: there must be some stability as meetings are added and removed. This problem may be made arbitrarily more complex by considering what it means for a time to be "convenient" for a participant or group of participants. What kind of constraints may a user place on the allowable schedules?

Some key considerations affecting the architecture are:

• Individual flexibility: How rich a set of individual preferences can be expressed and accommodated?

• Heterogeneity: How well are different personal calendar representations handled?

• Priorities and Conditions: How well can the system resolve conflict when degrees of intensity about preferences can be provided?

• Ease of use: How easy is it for a person to define and manipulate a set of meetings to attend? How will the information from multiple machines be consolidated? How well are regular meetings handled? Can quorums be defined?

• Optimality: If there is a schedule, will the system find it? Can the architecture support contingency strategies, e.g., in the absence of complete information?

Updated Halloween 95 by Mary Shaw
Comments to maintainer