2.4.1. Scheduling Meetings

The scenarios in this section show how meetings are scheduled for Calendar Tool users. A scheduled meeting has all the information that an appointment has, plus the following additional information:

Meetings are scheduled among registered users of the Calendar Tool system. For convenience, the Calendar Tool provides administrative functions to define groups of users among whom meetings may be regularly scheduled. Complete details of defining user groups are covered in Section 2.6.3. For the purposes of meeting scheduling, a group is viewed simply as a collection of Calendar Tool users with a common group name. When the group name is listed in the attendees list for a meeting, all members of the group are considered attendees.

User groups have leaders, who are themselves Calendar Tool users. When a group leader schedules a meeting for a group, the system automatically notifies group members about the meeting and adds the meeting to the group calendar. Meetings can also be scheduled by users who are not group leaders, with individual users as attendees. Administratively, scheduling a meeting for a group as a whole is restricted to leaders of the group.

Meeting scheduling takes place in the context of a multi-user operating environment. Complete details of the environment are covered in Section 2.14. The following paragraph summarizes the environment features that are relevant to the meeting-scheduling scenarios presented in this section.

The Calendar Tool multi-user operating environment consists of a central host computer and user client computers. Calendar Tool users, including meeting schedulers, run the Calendar Tool on their local client computers and connect to a common central host computer via some form of computer network. User calendars are stored in files on their local computers. In addition, the central host has a copy of each user's calendar. When a meeting is scheduled, a not-yet-accepted version of the meeting is added to the central host calendars of all attending users, i.e., the meeting is "penciled in". For attending users who are actively connected to the central host, the meeting is also penciled in on their local calendars. Once a meeting is penciled in, a meeting notification is sent to each attending user. The user can respond to the notification by accepting the meeting or declining to accept it. Accepting means the meeting is changed from a penciled-in meeting to a regularly- scheduled one. Declining means the penciled-in meeting is removed from the calendar. If a user is not connected to the central host when a meeting is scheduled, the meeting is penciled in on the central host, and will subsequently be penciled in on the local calendar the next time the user connects. Notifications sent when a user is not connected are queued on the central host for delivery when the connection is next established.

In the scenarios that follow, meeting schedulers and meeting attendees are all assumed to be actively connected to the same central host computer. Details of establishing a central host connection are presented in Section 2.6.6.1. Since meeting scheduling is an inherently multi-user operation, it can only be performed when the scheduler is connected to a central host computer. When not connected to a central host, meeting scheduling is disabled.

2.4.1.1. A Group Leader Scheduling Two Straightforward Meetings

The scenario in this section presents a group leader scheduling both a non- recurring and recurring meeting, with some variations in scheduling details. In this scenario and the meeting scenarios to follow, "the scheduler" refers to the user performing the scheduling.

To begin the meeting scheduling process, the scheduler selects the `Meeting' command in the `Schedule' menu. In response, the system displays the dialog shown in Figure 84.

Figure 84: Meeting scheduling request dialog.


Scheduling a meeting is much like scheduling an appointment, as described in Section 2.2. The principle difference between meeting versus appointment scheduling is that a meeting dialog defines a range of possible dates and times, rather than a single date and time as for an appointment. Hence, a meeting dialog holds a form of scheduling request. Key elements of the request are a date/time range, a list of attending users, and an optional meeting location. When the dialog is filled in, the system computes all the dates and times that satisfy the request. The scheduler then chooses a specific desired meeting time from those computed.

The following fields in the scheduling request dialog hold the same form of information as the appointment scheduling dialog in Figure 6:

The scheduler enters information for these fields in the same manner as for an appointment, as described in Section 2.2.

The date and time fields for a scheduling a meeting are notably different than for an appointment. In the case of a meeting, there are earliest and latest possible dates, and earliest and latest possible start times. These date and time ranges are used by the scheduler to indicate the range of acceptable dates and times in which the meeting can be scheduled. For a recurring meeting, the earliest and latest end dates are enabled. These fields indicate the acceptable range of dates for the last occurrence of a recurring meeting.

The Recurring checkbox and Interval menu are the same for meetings as they are for appointments. The recurring details are different for a meeting request, as discussed further below.

The Attendees field contains a comma-separated list of attendee IDs. The IDs are those of individual calendar tool users or user groups. The ID of a user or group is the unique identifier by which the user or group is known in the Calendar Tool system. IDs are defined and searched for as described in Section 2.6. The IDs in the Attendees list need not be unique. The system ignores duplicates in the attendees list in that only a single meeting notification is sent to each attending user, even if a user is listed more than once in the attendees list. Duplication of users in the attendees list can arise when a single user is a member of two or more groups appearing in the attendees list.

The `Minutes' text field specifies the location of the meeting minutes as a WWW URL. In the case of a recurring meeting, the scheduler may specify the URL as a directory rather than as an individual file. When a directory URL is entered, the scheduler must subsequently enter the name for each individual minutes file by editing individual meeting occurrences, as described in Section . Details of how users view meeting minutes are covered in Section 2.5.1.2.

Figure 85 shows the scheduler having entered information for a non-recurring meeting of the computer science staff.

Figure 85: Scheduling a staff meeting.


The earliest and latest possible dates are the Monday and Friday of the week of September 20. The earliest and latest start times are 8 AM to 6 PM. The category is blank and there is no reminder. To proceed with the scheduling operation, the user presses the `List Times ...' button. In response, the system displays a list of possible meeting times, as shown in Figure 86.

Figure 86: List of possible meeting times for the csstaff meeting.


The scheduling request dialog remains on the screen, but all of its data-entry fields and command buttons are disabled until the meeting confirmation process concludes.

The list in Figure 86 contains all the meeting times that conform to the values entered in the scheduling request dialog. Each item in the list consists of a time range, day of the week, and date. If the listed items span to or more years, date includes the year. The precise meaning of "conform to" is as follows:

  1. All meeting dates in the possibles list are between the earliest and latest possible dates entered in the scheduling request dialog.
  2. All meeting start times are between the earliest and latest start time range entered in the scheduling request dialog.
  3. All meeting durations are the value entered in the scheduling request dialog.
  4. For all attendees, there is no non-private scheduled item for the attendee that overlaps with any listed meeting time.
  5. If the location in the request dialog is in the location database ( Section 2.6.4 ), then the location is available at the scheduled time and date. A location not in the database is assumed to be available at any time.
The list of possible times is sorted first by date and second by time, from earliest to latest. The default maximum number of listed items is twenty, which value can be changed as an option setting. The minimum number of items in the list is one. When there are no conforming possible times, the system displays an alert message instead of the list, as discussed in the next meeting scheduling scenario.

To select one of the possible meeting times, the user clicks on the desired item in the list and presses the `Confirm ...' button, which becomes enabled when the user makes a list selection. For example, Figure 87 shows the scheduler having selected the 8-9 AM time slot on September 23.

Figure 87: Selection in the possible meeting times list.


When the scheduler presses `Confirm ...' in Figure 87, the system responds with the meeting confirmation dialog in Figure 88.

Figure 88: Staff meeting confirmation dialog.


The confirmation dialog contains the information entered in the initial scheduling request dialog, with the date and time ranges replaced with the single date and time selected from the list of possible times. There are four additional data fields below `Minutes'. The `Scheduled By', `On', and `Host' fields are read-only text. The values of these three fields are set by the system to the ID of the user performing the scheduling, the date/time on which the scheduling occurs, and the Calendar Tool central host computer on which the scheduling occurs.

The scheduled `On field is formated as

ddmmmyy hh:mm:ss
where dd is the date, mmm is the short month name, yy is the year, hh is the hour in 24-hour clock time, mm is the minute, and ss is the second. Section describes the format of Calendar Tool host computer names.

Below the `Host' field is a check box indicating whether or not to send email notification to all attendees. All attendees are automatically notified of a confirmed meeting with a pop-up dialog, as explained in Section 2.4.1.5. An email message can be sent in addition to the Calendar Tool dialog notification.

The scheduler can edit some of the data-entry fields in the meeting confirmation. The uneditable fields are those that affect how the list of possible times is computed, as well as the `Scheduled By', `On', and `Host' fields. These fields have greyed and dashed borders to indicate their disabled state. The complete information for a meeting is that entered initially in the scheduling request dialog ( Figure 84 ) and subsequently in the meeting confirmation dialog ( Figure 88 ). Information that is not necessary for the possible-times computation can be left blank in the initial request dialog. For example, if the meeting title is left blank in the scheduling request dialog, it can be entered subsequently in the confirmation dialog. The exact data entry rules for the request and confirmation dialogs are given in Section 2.11.7.1.

While the meeting confirmation dialog is displayed, the original request dialog and possible times list remain on the screen for reference purposes. However, all of the data-entry fields of these earlier two dialogs remain inactive while the confirmation dialog is displayed. Changes made in the confirmation dialog do not affect any of the values in the original scheduling dialog. For example, if the scheduler edits the title in the confirmation dialog, the title remains as initially entered in the scheduling request dialog.

Figure 89 shows the scheduler having edited the meeting confirmation dialog by adding a reminder and correcting a spelling error in the original `Details' data field.

Figure 89: Meeting confirmation dialog with some edits.


After completing the edits in the meeting confirmation dialog, the scheduler confirms the meeting by pressing the `OK' button. In response, the system schedules the meeting. On the screen, the system removes the three pending dialog windows -- the possible meeting times, the confirmation dialog, and the original scheduling request dialog.

The precise effects of scheduling a meeting are the following:

  1. The system adds the meeting to each attendee's calendar on the central host computer and marks each meeting as "not-yet-accepted"; i.e., the meeting is "penciled in".
  2. For all attendees who are actively connected to the central host, the system also pencils in the meeting on the user's local calendar; for attendees not connected, the local penciling in occurs when a connection is next established.
  3. The system notifies each attendee except the scheduler, as discussed in Section 2.4.1.5.
  4. The system adds the meeting to the scheduler's central host calendar as well as to scheduler's local calendar, whether or not the scheduler is an attendee. The meeting item in the scheduler's calendar is a regular item, i.e., it is not marked as not-yet-accepted.
  5. The system adds the meeting to the calendar of all groups that appear in the attendees list. Details on the contents of group calendars are covered in Section 2.4.1.6.1.
  6. If the specified location is in the location database, the location is marked as booked for the duration of the meeting. If the location is not in the database, then no location-related action is taken.

Only a group leader can schedule a meeting for a group. If a non-leader attempts to do so, the system responds with an error message, as described further in Section 2.12.3.

In the case of the staff meeting in Figure 89, only the single csstaff group appears in the attendees list. In this scenario, the scheduler is assumed to be a leader of that group, as well as a member. Therefore, when the scheduler confirms the staff meeting, the system:

  1. adds a not-yet-accepted meeting to the central host calendars of all members of csstaff, except the scheduler;
  2. adds a not-yet-accepted meeting to the local calendars of all members of csstaff who are currently connected to the central host, except the scheduler; attendees who are not connected will receive the not-yet-accepted meeting when a connection is next established
  3. notifies all members of csstaff, except the scheduler;
  4. adds the meeting to the scheduler's central host and local calendars;
  5. adds the meeting to the csstaff group calendar;
  6. marks the 14-238 location as booked for the duration of the meeting.

The scheduler now proceeds to create another meeting, following the same procedure as for the preceding staff meeting. The resulting filled-in request dialog is shown in Figure 90.

Figure 90: Scheduling another meeting.


This is a recurring meeting for computer science lecturers. The earliest and latest start dates are the same as for the staff meeting. Since the meeting is recurring, the latest and earliest end date fields are enabled. Also, the word "Possible" in the two start date labels is changed to "Start" to clarify the display as that of a recurring meeting.

The recurring interval of the meeting is `weekly', which is the default. In this case, the scheduler does not specify any further recurring details. This means that the system considers all days of the week in the normal day range for which times are available. The default normal day range is Monday through Friday, which can be changed using `Options ...' as explained in the next meeting-scheduling scenario The `Details ...' aspect of recurring meetings is covered in the next scenario, as well as in Section 2.5.3.4.

When the scheduler presses the `List Times ...' button for the lecturer meeting, the system responds with the list of possible meeting times shown in Figure 91.

Figure 91: List of possible meeting times for the cslect meeting.


For a weekly recurring meeting, each item in the list consists of a time range, day(s) of the week, start date, and end date. The scheduler selects the third item in Figure 91 and presses `Confirm ...', whereupon the system displays the confirmation dialog in Figure 92.

Figure 92: Lecturer meeting confirmation dialog.


The scheduler accepts the meeting without further edits by pressing `OK' in the confirmation dialog. In this scenario, the scheduler is assumed to be a leader but not a member of the cslect group. Therefore, when the scheduler confirms the lecturer meeting, the system:
  1. adds a not-yet-accepted meeting to the central host calendars of all members of cslect, which does not include the scheduler;
  2. adds a not-yet-accepted meeting to the local calendars of all connected members of cslect, which does not include the scheduler;
  3. notifies all members of cslect, which does not include the scheduler;
  4. adds the meeting to the scheduler's calendar, even though the scheduler is not an attendee;
  5. adds the meeting to the cslect group calendar;
  6. marks the 14-238 location as booked for the duration of the meeting.

Before a meeting is confirmed, the `Clear' button in the confirmation dialog clears all changes made since the system initially displayed the dialog. For example, if the user presses `Clear' in the dialog of Figure 89 the system restores the dialog state to that shown Figure 88. The `Cancel' button in the meeting confirmation dialog removes the dialog from the screen and re-activates the possible-times dialog. Pressing `Cancel in the possible-times dialog removes it from the screen and re-activates the original scheduling request dialog. `Cancel' there removes the dialog, thereby canceling the scheduling operation entirely. Hence at the level of the meeting confirmation dialog, canceling the scheduling operation is a three-step process: first the confirmation is canceled, then the possibles list, and finally the original scheduling request dialog.

Once a meeting is confirmed, the item in the scheduler's local calendar is that through which attendee-wide changes or cancellation are performed. This is the reason that a scheduled meeting is added to the scheduler's calendar even if the scheduler is not an attendee. Changing and canceling scheduled meetings are discussed in Section .

2.4.1.2. A Group Leader Encountering Difficulties While Scheduling

This section presents a scenario where the scheduler must adjust scheduling options in order to arrive at an acceptable meeting time. The scheduler in this scenario is a different Calendar Tool user than in the preceding scenario.

To begin, the scheduler selects `Schedule Meeting' in the command menu and fills in the dialog as shown in Figure 93.

Figure 93: Scheduling a Faculty Meeting.


In this case, the scheduler wants to schedule a recurring meeting on a specific day and time. The single specific time is chosen by entering the same 1 PM value for both the earliest and latest start times. To select a specific day of the week, the scheduler presses the `Details ...' button to the right of the recurring interval. In response the system displays the dialog shown in Figure 94.

Figure 94: Details of a weekly recurring schedule.


The first field in the dialog specifies the number of days per week on which to schedule a recurring meeting. The default value is one; the maximum possible value is 7. The second field specifies the allowable days for the meeting. The default days are Monday through Friday. The number of allowable days must be greater than or equal to the days per week, and at least one allowable day must be checked.

The third and fourth fields specify, respectively, the minimum and maximum number of days between each meeting occurrence. These last two fields are enabled if the `Days per week' value is greater than the number of allowable days. As an example, consider the days per week set to 2, allowable days set to the default, and the last two fields set to 1 and 2 respectively. These settings specify a meeting scheduled two days per week, with each meeting one or two days apart. This allows Monday/Wednesday, Tuesday/Thursday, Monday/Thursday, or Tuesday/Friday meeting times.

In the current scenario, the scheduler wants to schedule the faculty meeting for Mondays at 1PM, and so fills in the details dialog as shown in Figure 95.

Figure 95: Weekly recurring details filled in.


where only the Monday checkbox is selected. In this scenario, the scheduler is acting on an assumed agreement made among the meeting attendees. Specifically, the computer science faculty attendees have been asked in advance to leave the 1-2 PM MWF time slot free on their calendars. This request is assumed to have been made through some means outside of the Calendar tool, such as in-person contact or other communication. Unfortunately, not all faculty have honored the request. Hence, when the scheduler presses the `List Times ...' button, the system responds with the message shown in Figure 96.

Figure 96: No times found dialog.


This message indicates that the system is unable to find any meeting times that conform to the values entered in the scheduling request dialog, by the definition of "conform to" given above.

To address the outcome of no possible meeting times being found, the scheduler can change one or more of the values entered in the scheduling request dialog and re-execute the `List Times ...' command. For example, the scheduler can change the range of possible times, dates, or days on which the meeting can be scheduled. In this scenario, the scheduler decides to leave the date and time range the same, but expand the possible days from Monday only to Monday, Wednesday, or Friday. To do so, the scheduler reselects the recurring `Details ...' command and changes the values as shown in Figure 97.

Figure 97: Weekly recurring details modified.


Here the scheduler has checked the Wednesday and Friday check boxes in addition to the Monday check box. Having made the desired changes, the scheduler presses `OK' in the details dialog and `List Times ...' in the scheduling request dialog. In response, the system again displays the no- times-found dialog of Figure 96, meaning that the system is still unable to find any conforming meeting times. It must be the case that one or more faculty have scheduled appointments or meetings in the 1-2 PM MWF time slots.

The other way to deal with the no-times outcome is to adjust one or more scheduling option values. To do so, the scheduler presses the `Options ...' button at the bottom of the scheduling request dialog. In response, the system displays the dialog in Figure 98.

Figure 98: Meeting scheduling options.


The first option setting is the length of the possible times list, the default value for which is 20. The second and third options specify whether a meeting can be scheduled at the same time as items with `optional' or `must' priority on attendee calendars. If the default value of `no' is selected for both options, the system does not attempt to schedule a meeting at the same time as any non-private scheduled items. If `yes' is selected for either or both options, then the system will allow a meeting to be scheduled at times that overlap with optional and/or must items. Such items will appear in the possible times list, flagged with the IDs of the affected attendees.

The fourth scheduling option specifies the specific allowable days on which non-recurring meetings can be scheduled. The default days are Monday through Friday, inclusive. This option applies only to non-recurring meetings, since the `Details' dialogs contain more specific settings for the allowable days of recurring meetings. Recurring details for weekly meetings are shown in Figure 94. Recurring details for other intervals are described in Section 2.5.3.4.

The final scheduling option indicates the time increment on which meetings can start. The default is for meetings to start on the full hour. The other selections are on the half hour, quarter hour, or at any time. For the `any time' selection, the smallest possible increment is five minutes.

The scheduler proceeds to adjust the scheduling options as shown in Figure 99, where the second and third options are both changed to `yes'.

Figure 99: Modified meeting scheduling options.


Having made the desired option changes, the scheduler presses `OK' in the options dialog and `List Times ...' in the scheduling request dialog. This time the system responds with the dialog shown in Figure 100.

Figure 100: Possible meeting times with one or two faculty unable to attend.


The new list of possible times has two additional columns containing the user IDs of attendees with items scheduled at conflicting times. The columns appear in the list when the scheduler selects the `yes' setting for the second and/or third scheduling option, as is done in Figure 99. A user is listed under `Optional Conflicts' for each possible time where the user has an optional, non-private scheduled item that overlaps with the possible time. A user is listed under `Must Conflicts' for each possible time where the user has a must, non-private scheduled item that overlaps with the possible time.

The default sorting order for a list with overlap columns is the same as without the columns -- first by start date and second by time, from earliest to latest. The user can click on either of the overlap column headings to change the default sorting order. For both columns, the primary order is from the smallest to largest number of users with overlapping times; the secondary, tertiary, and quaternary orders are date, time, and alphabetic by user ID. Clicking on the `Possible Times' column label restores the default sorting order. The sorting order for the names in any conflicts row is alphabetic.

The `View User' button at the bottom of the list allows the scheduler to view the daily calendar of any user listed in one of the overlap columns. To do so, the user selects one of the user IDs and then presses the `View User' button, which becomes enabled upon selection of an ID. This command is discussed further in Section 2.4.1.3

For this scenario, the scheduler elects to choose the 1-2 PM Monday meeting time as originally planned, as shown in Figure 101.

Figure 101: Selected faculty meeting time.


The scheduler presses `Confirm ...' in the possible times list and `OK' in subsequent confirmation dialog. The system then notifies all attendees, including those with overlapping items. The notification message for the attendees with overlapping items makes note of the condition. Details of attendee notification are covered in Section 2.4.1.5.

2.4.1.3. A Super-Group Leader Scheduling a Meeting

This section presents further details of meeting scheduling. Here the scheduler is the leader of a Calendar Tool supergroup, which is a group comprised of other groups.

Figure 102 shows a filled-in meeting request dialog for a computer science special colloquium; Figure 103 shows the options settings for this request.

Figure 102: Scheduling a special colloquium.




Figure 103: Special colloquium options settings.


It is a non-recurring meeting, to be held on October 29 or 30, between 1:30 and 4 PM; the category is set to `CS Special'. The attendees are the `csall' user group, and three additional individual users. The options allow the meeting to be scheduled at the same time as both optional and must items. The increment is changed from `full hour' to `half hour'.

As defined in Section 2.6.3, csall is a Calendar Tool supergroup, comprised of the subgroups csfaculty, cslect, and csstaff. These groups are in turn comprised of individual Calendar Tool users. When a supergroup is listed among the attendees of a meeting, individual attendees are all members of all subgroups. The complete set of attendees is comprised of all group members plus all individual users appearing in the attendees list.

When the scheduler presses `List Times ...' in Figure 102, the system responds with the possible times list shown in Figure 104.

Figure 104: Possible times for the special colloquium.


Given the large number of requested attendees, there are a large number of time conflicts listed in the conflicts columns. To determine the most acceptable time, the scheduler can use the `View User' command to examine the calendars of one or more users listed in the conflicts columns. For example, Figure 105 shows the scheduler having selected user mhutchen for viewing.

Figure 105: Selecting a conflicting user for the purpose of viewing that user's calendar.


When the scheduler clicks anywhere in a user name, the system highlights the entire name and enables the `View User' button. When the scheduler selects `View User' in Figure 105, the system displays the daily agenda for mhutchen for Thursday October 29. Viewing such conflicting user calendars may assist the scheduler in choosing a meeting time that overlaps with relatively less important scheduled items.

After viewing some user calendar information, the scheduler decides to choose the 4-5:30 time slot on Thursday October 29, and confirm the meeting. In response, the system notifies all members of csall plus the three individually-listed attendees; the system adds the meeting to the csall group calendar, as well as to each subgroup calendar. The scheduling of meeting for a supergroup has a fully transitive effect on all sub(...sub)groups. That is, when a meeting is scheduled for a supergroup, it is also scheduled for all its sub(...sub)groups, including adding the meeting to the sub(...sub)group calendars.

2.4.1.4. A Non-Leader Scheduling a Meeting for Selected Individuals

The final meeting scheduling scenario presents an individual user scheduling for a selected number of individual users. The attending users are not members of a group that could be used for the meeting at hand. The scheduler begins by entering the request information shown in Figure 106.

Figure 106: Scheduling a tenure review meeting.


The meeting is non-recurring, confidential security, for six individual attendees. In this scenario, the entered value for the meeting location is assumed not to be in the location database. This means that location has no effect on the possible times computation. The same would be true if the location field were empty.

When the scheduler selects `List Times ...', the system responds with the no-times dialog of Figure 96. In this case, the scheduler deals with the situation by expanding the date and time range for the meeting, as shown in Figure 107.

Figure 107: Modified tenure review meeting request.


The scheduler also changes the last two scheduling options, as shown in Figure 108.

Figure 108: Tenure review meeting options.


Saturday is added to the allowable days and the `Start on' interval is set to `any time'. When the scheduler again presses `List Times ...', the system responds with the result in Figure 109.

Figure 109: Very long possible times list.


In this case, the scheduler has been a tad over-zealous in date/time and options settings, since the possibles list contains a large number of times. As might be typical among Calendar Tool users, many time slots on Saturday are available among the selected attendees. Hence combining a `Start on' setting of `any time' with Saturday as an allowable day results in a large number of possible times. Rather than adjust the date/time ranges or options further, the scheduler scrolls through the list of possible times to find one that is acceptable and selects it, as shown in Figure 110.

Figure 110: Long possible times list scrolled to an acceptable time.


The scheduler then proceeds to confirm the meeting.

Of note in Figures 109 and 110 is how the possible times list contains all allowable times, including ones that overlap such as 8-9 AM and 8:05-9:05 AM. The list contains all distinct meeting times that individually conform to the scheduling request values and option settings. Two possible times are distinct if they differ in at least one value of start time, end time, or date.

2.4.1.5. Receiving and Accepting Meeting Notifications

When a meeting scheduler confirms a meeting, the system notifies each attendee, except the scheduler, with a dialog of the form shown in Figure 111.

Figure 111: Meeting notification dialog.


This a notification dialog for the non-recurring staff meeting as scheduled in Section 2.4.1.1. The message indicates the scheduler's ID plus the time and date of the meeting. To notify a user of a recurring meeting, the system displays a dialog of the form shown in Figure 112.

Figure 112: Recurring meeting notification dialog.


The message indicates the scheduler's ID plus the time and date of the first occurrence of the meeting.

When a meeting overlaps with one or more existing scheduled items in the user's calendar, the notification message has the following line appended:

NOTE: this meeting conflicts with N existing item(s).
where N is the number of scheduled items that have overlapping times with the requested meeting and "item(s)" is singular if N = 1, plural otherwise.

The user can view the complete details of the meeting by pressing the `View ...' button in the initial notification dialog. For example, if the user presses `View ...' in Figure 111, the system responds with the meeting information shown in Figure 113.

Figure 113: Viewing details of a meeting notification.


This display has the same information as in the meeting confirmation dialog accepted by the scheduler ( Figure 89 ). The user can edit any of the data fields in the notification dialog except for `Scheduled By', `On', and `Host'. Complete details of meeting editing are presented in Section 2.5.2.2.5

The user can respond to a meeting notification in one of three ways: accept the meeting, decline the meeting, or delay a decision. Both the initial meeting notification dialog ( Figure 111 ) and the larger details dialog ( Figure 113 ) have `Accept', `Decline', and `Delay' buttons. If the user chooses `Accept', the meeting is added to the user's local calendar as a scheduled item. If the user chooses `Decline', the meeting is not added to the user's calendar. If the user chooses `Delay', the system removes the notification dialog from the screen and the meeting remains in a not-yet-accepted until the user decides at a later time. If the user has edited any data in the notification, pressing `Delay' clears those edits. Edits to a not-yet-accepted meeting are only retained if the user accepts the meeting.

The precise effects of accepting a meeting are the following:

  1. The system removes the not-yet-accepted marking from the meeting in the user's local calendar.
  2. If the user is currently connected to the originating central, the system removes the not-yet-accepted marking from the meeting in the user's central host calendar; if not connected, the system will remove the not-yet-accepted mark on the central host the next time the user connects.
  3. The system removes the notification dialog from the screen.
The precise effects of declining a meeting are:
  1. The system deletes the not-yet-accepted meeting from the user's local calendar.
  2. If the user is currently connected to the originating central, the system removes the not-yet-accepted meeting in the user's central host calendar; if not connected, the system will remove the meeting on the central host the next time the user connects.
  3. The system removes the notification dialog from the screen.

The precise effects of delaying the accept/decline decision are the following:

  1. The meeting remains marked as not-yet-accepted on both the local and central host calendars.
  2. The system removes the notification dialog from the screen.

The system displays a meeting notification dialog at most once for each meeting. Once the notification dialog is removed from the screen, it will not appear again. It is possible for a notification dialog never to appear, based on the notification option settings described in Section 2.4.1.5.

If the user closes the notification dialog without selecting `Accept', `Decline', or `Delay', the effect is as if `Delay' were selected. The user cannot delay an accept/decline decision beyond the date and start time of a non-recurring meeting, or beyond the date and start time of the last occurrence of a recurring meeting. If a user fails to accept or decline within this time, the system automatically executes decline on the user's behalf. As a result, the declined item is removed from all affected displays, including the complete removal of any item-level view for the declined item.

In the case of Figure 113, the notified user decides to edit the `Title' and `Category' fields, and turn off the reminder, as shown in Figure 114.

Figure 114: Notification details dialog edited.


The user then presses `Accept', whereupon the system adds the meeting to the user's local calendar as a regular scheduled item. To clear any edits made after the confirmation dialog is initially displayed, the user can press `Clear'. As illustrated in Figures 113 and 114 the `Clear' button is disabled until the user performs some editing.

When the detailed notification dialog is displayed, the initial smaller notification dialog remains active. The user can press `Accept', `Decline', or `Delay' in either dialog. When the user does so, the active dialog is removed from the screen, and the other dialog, if displayed, is also removed.

The item for an accepted meeting is stored as an individual copy in each accepting user's local calendar. In this way, any changes that a user makes to an accepted meeting are local to that user and do not affect any of the other attendees. Changes made by the meeting scheduler can be announced to all attendees, if the scheduler chooses to do so. Further details of changing and deleting meetings are covered in Sections and 2.5.2.2.5.

Prior to an accept/decline decision, a not-yet-accepted meeting appears on a user's calendar in penciled-in form. In terms of screen display, a penciled-in meeting appears in light-grey italic type in daily, weekly, and monthly calendar views, as well as in all list views. For example, Figure 115 shows a daily agenda where two meetings have been confirmed by the scheduler, but not yet accepted by the user.

Figure 115: Two meetings displayed in penciled-in form.


The meetings are in the 8 AM and 2:30 PM time slots. Once a penciled-in meeting is accepted, it appears normally in all calendar and list views. For example, if the user selects the `View Day' menu command after accepting the staff meeting in Figure 114, the system displays the daily agenda shown in Figure 116.

Figure 116: Accepted meeting changed from penciled in form.


This figure shows an updated version of the daily agenda from Figure 115 where the previously penciled-in staff meeting is now shown as a regularly scheduled item, with its edited title and new category color.

In item-level calendar views, not-yet-accepted meetings are indicated by different command buttons at the bottom of the display. Details of this are presented in Section 2.5.1.2. accurate any more.

From the perspective of a meeting's scheduler, notification is sent to the attendees immediately upon confirmation of the meeting. At any point between scheduler confirmation and attendee acceptance, the meeting appears in penciled-in form on the calendars of all attendees who permit penciling in.

From the perspective of an attending user, the appearance of not-yet-accepted meetings and notification dialogs are controlled by two factors:

  1. whether or not the user is connected to the Calendar Tool central host computer on which the meeting is scheduled
  2. the settings of meeting-scheduling options that control the acceptance of penciling in and meeting notifications
The necessary enabling condition for local receipt of penciled-in meetings and their notifications is an active connection to the Calendar Tool central host computer on which the meeting is scheduled. Details of establishing a central host connections are covered in Section 2.6.6.1.

The option settings for when to accept penciled-in meetings, that is meetings scheduled by an outside party, are the following:

When either of the first two settings is selected, meetings are penciled in to the central host calendar immediately upon confirmation from the scheduler; meetings are then penciled in the local calendar as the setting indicates. When the `never' setting is selected, meetings scheduled by other users are automatically declined, without ever appearing on central host or local calendars. The `never' setting may not be advisable in all circumstances, in the sense that the user may miss important meetings. However, the use of this setting is left to the user's discretion.

The option setting for when to show notification dialogs has one of the following values:

  • `at the same times pencil-in is accepted' -- Notifications appear at the same times penciled-in items are copied to the local calendar, i.e., whenever connected to the host or at initial host connection.
  • `never' -- Notifications never appear, whether or not pencil-in is accepted.
The dependence of the notification option on the pencil-in option disallows the case where notifications are accepted but pencil-in is not. The converse, however, is possible. I.e., notification acceptance can be `never' when pencil-in acceptance is something other than `never'. In this case, the only indication of a meeting having been scheduled is its appearance in penciled-in form in a calendar or list view

The acceptance or non-acceptance of penciled-in meetings is a separate issue from whether they appear on a calendar. Using the filtering functions, the user can control the visibility of penciled-in items, as described in Section 2.3.3.2 and Section 2.3.4.1.15.

The system dynamically updates all active displays that are affected by a meeting being scheduled. An "affected" display is one in which the penciled-in item should appear. Details of dynamic view updating are covered in Section 2.5.6.

The system displays the notification dialog for any given meeting at most one time. The notification dialog appears as soon as the connection state of the user's local computer and the setting of the notification option allow. After the user makes the accept, decline, or delay decision, the notification dialog is never redisplayed. If the start date and time of the meeting pass before the notification dialog is allowed to appear, the system never displays it.

A meeting scheduler may optionally elect to send email notification to all attendees. Email notification is sent in addition to the standard dialog form of notification. The body of an email notification contains the text that appears in the initial notification dialog, plus an additional explanatory sentence. The user ID that appears in the notification dialog is replaced with the user's full name, as defined in the Calendar Tool user database ( Section 2.6.2 ). The sender of the message is the meeting's scheduler. The message subject is "Meeting notification". For example, had the scheduler chosen to send email notification for the meeting notified in Figure 111, the email message sent to user dcollins would appear as shown in Figure 117. 

From: estier@calpoly.edu
To: dcollins@calpoly.edu
Subject: Meeting notification

Ellen M. Stier has scheduled a meeting at 2 PM on Monday September 21
with you as an attendee.  Please use the Calendar Tool to accept or
decline this meeting.

Figure 117: Content of email meeting notification.


The sender's email address and the email addresses of the attendees are those defined in the Calendar Tool user database. The body of the message is left justified in 72 character columns.

The Calendar Tool sends email notifications using the electronic mail facilities of the underlying operating environment. Once an email notification has been sent, its further handling and delivery are beyond the control of the Calendar Tool. If the meeting notification option is sent to `never', email notifications are not sent.

2.4.1.6. Further Operational Details of Meeting Scheduling

A meeting differs from the three other types of scheduled item in that meetings involve multiple users. The multi-user aspects of scheduled meetings give rise to operational details that must be carefully considered.

2.4.1.6.1. The Contents of Group Calendars

A group calendar contains scheduled meetings in which the group is among the attendees. A group is considered to be among meeting attendees in the following cases:

  1. the group ID appears in the attendees list
  2. the ID of a supergroup of which the group is a member appears in the attendees list
If the group ID is not listed directly or by subgroup inclusion in the attendees list, then the group is never considered an attendee, even if all members of the group are listed individually as attendees,

As noted above, only a group leader can schedule a meeting for a group. The group calendar is not itself editable. Any changes made to a meeting in the scheduler's calendar are automatically reflected in the group calendar for that meeting. Section 2.5.2.2 presents complete details of changing and deleting scheduled group meetings.

A group calendar has its own category definitions. The set of group calendar categories is comprised of the categories that appear in the scheduled meetings within the calendar. Category changes made by group meeting schedulers are reflected in the group calendar.

Group calendars exist only for explicitly defined groups in the Calendar Tool group database, as defined in Section 2.6.3. There are no group calendars for meetings with lists of individual users, such as the meeting scheduled in Section 2.4.1.4. In terms of physical storage, a group calendar is stored only on the central host computer where the group is administratively defined. Group calendars are not copied to any local user computers.

2.4.1.6.2. Scheduling Over Private Items

Scheduled items with `private' security are by definition invisible to all other users, where "other" is a user different than the user on who's calendar the private item is scheduled. For the purposes of meeting scheduling, the scheduler is always considered an other user, even if the scheduler is listed among the attendees. Therefore, all private items are entirely invisible when the list of possible times is computed, including private items on the scheduler's own calendar. This means that the times during which any private item is scheduled are considered available without conflict for meeting scheduling.

2.4.1.6.3. The Status of Not-Yet-Accepted Meetings

As explained above, not-yet-accepted meetings are those that have been confirmed by the scheduler but not yet accepted by an attendee. These are the items that appear in penciled-in form on the calendars of users who have not yet accepted. For the purposes of possible times computation, a not-yet- accepted meeting is considered a scheduled item. This means that the times of not-yet-accepted meetings are considered UNavailable for meeting scheduling. An individual user's filter setting for penciled-in items has no affect on the status of the items for scheduling purposes. Specifically, if a user chooses to filter-out penciled-in items, their times are still considered unavailable for meeting scheduling. Sections 2.3.3.2 and 2.3.4.1.15 describe the ways in which the user can filter out penciled-in meetings.

2.4.1.6.4. Creation of New Categories

A scheduler may specify a category when scheduling a meeting. That category must be defined in the scheduler's calendar, but may not be defined in one or more attendees' calendars. When a notified user accepts a meeting with a category that is undefined in the accepting user's calendar, the system prompts the user with a dialog of the form shown in Figure 118.

Figure 118: Prompting dialog for new category definition.


This figure corresponds to the special colloquium meeting shown in Figure 102 for an attendee on whose calendar `CS Special' is undefined. A meeting category is considered undefined in an attending user's calendar if there is no category of same name and color in the user's calendar. Comparison of category names is made on a case- sensitive, character-by-character basis.

As shown in Figure 114, an accepting user can edit the meeting category prior to accepting it. This means that a user can change the category assigned by the scheduler to empty or a category already defined in the user's calendar. If such a change is made, the system does not display a category definition dialog of the form shown in Figure 118.

2.4.1.6.5. The Role of the Location Database

The role of the location database is strictly limited in scheduling a meeting. Specifically, when the scheduler enters a `Location' value that is in the location database, the system excludes from the possibles list any times during which that location is unavailable.

The meeting operation performs no "room finding" computation, as in finding a room that is available and of a proper size for a meeting. When the `Location' field is empty, the system assumes that the meeting can be held at any location. In this case, it is the responsibility of the scheduler to inform attendees of the location by some means external to the Calendar Tool. When the `Location' value is non-empty but not in the location database, the system assumes that the location is available at any time. In either of the latter two cases (empty location or non-database location), the location database has no role at all during the possible times computation.

2.4.1.6.6. Non-Unique Scheduled Meetings

As discussed in Section 2.11.6, the Calendar Tool disallows multiple scheduled items with exactly the same values for date, start time, duration, and title. This uniqueness condition can be violated for meetings scheduled for one or more attendees when a scheduler allows a meeting to be scheduled at the same time as optional or must items, as in Figure 103, for example. The uniqueness condition can also be violated for private items on attendees' calendars, and when the same calendar is associated with more than one central host computer.

The uniqueness condition is not checked at the time the scheduler confirms the meeting, but rather at the time an attending user accepts the meeting. Specifically, if an attending user accepts a meeting that violates the uniqueness condition, the system prompts the user with a dialog of the form shown in Figure 119.

Figure 119: Accepted meeting with non-unique identity.


As the dialog explains, the user presses `Retitle' to have the system change the title by adding a suffix. The suffix added is the string "[n]", where n is a unique integer starting at 2 and incremented as necessary to guarantee unique titles. If the user presses `Edit', the system (re)displays the detailed notification dialog, in which the user can edit the title. The user could satisfy the uniqueness condition by editing the date, start time, or duration instead of the title, but such editing is presumably atypical.

For either `Retitle' or `Edit' selection, the system removes the non-unique warning dialog from the screen. In the case of of `Edit', the user is returned to the state where the meeting can be accepted, declined, or delayed. If the user presses `Accept' without editing the title (or other field) to meet the uniqueness condition, the system redisplays the non-unique warning dialog.

Prior to acceptance, penciled-in meetings that violate the item uniqueness condition overlap with one or more extant calendar items. As described in Sections Section 2.3.1 and 2.3.2, overlapping items must be ordered for the purposes of display and next/previous traversal. For items that meet the uniqueness condition, unambiguous ordering is based on start time, duration, and title. In the case of non-unique penciled-in items, the ordering must be determined using additional fields of the meeting. Specifically, the ordering of non-unique penciled in items is defined as follows:

  1. a penciled-in item with the same start time, duration, and title as an extant item goes after the extant item
  2. in the presumably rare case of two or more penciled-in items with the same start time, duration, and title, the ordering of these items is based first on the `On' value, second on `Scheduled By', and third on `Host'.

2.4.1.6.7. Notifications for Multiple Calendars from Multiple Central Hosts

As described in Section 2.6.6.1, the user can be connected to more than one central host with more than one calendar. The specific rules for calendar/host association are the following:

  1. a calendar may be associated with zero or more hosts, at most one of which can be connected at any given time;
  2. any single host must be associated with exactly one calendar.
These rules mean that multiple notifiations may arrive when the user is actively connected to more than one host. Since the host-to-calendar association must be unique, the meeting notifications from a particular host are always directed to one specific calendar. That a notification is "directed to" a calendar means that when the user accepts a notification, the accepted meeting is added to the calendar that is associated with the host from which the meeting originates. Specifically, when the user accepts a meeting that originates from host X, the system performs the following actions:
  1. makes the calendar associated with host X current, per the calendar currency rules specified in Section 2.3.6.4.
  2. completes the accepting actions described in Section 2.4.1.5.

As explained in Section 2.7.3.3, the options for accepting meeting notifications are calendar-specific. This means that a user sees or does not see notifications based on the option settings for each calendar individually.

2.4.1.6.8. Pending Meeting Notifications

Depending on the state of an attendee's connection to a central host and the setting of notification options, it is possible for meeting notifications to be sent by a scheduler at one time and seen by an attendee at a later time. The system maintains a queue of pending meeting notifications for each requested attendee. Notifications are maintained in the queue in confirmation-time order, from earliest to latest confirmation time. Confirmation time is defined as the time at which the meeting scheduler presses the `OK' button in the meeting confirmation dialog. In the presumably rare case of two meetings being confirmed at exactly the same time from to different central hosts, the items are ordered in ascending lexical-sort order of host name.

As soon as conditions arise for a user to see meeting notifications, the system displays one dialog for each entry in the user's notification queue. The dialogs are displayed successively in queue order, with the system waiting for the accept/decline/delay decision between each display. For example, if a user's notification queue contains four entries, the system successively displays four separate notification dialogs. When the user makes the accept/decline/delay decision in one notification dialog, the system displays a dialog for the next entry in the notification queue.

As explained in Section 2.11.26, most Calendar Tool dialogs are "non-modal", including meeting notification dialogs. This means that the user is not required to respond to meeting notifications prior to performing other Calendar Tool operations. If the user fails to respond to one or more notifications prior to exiting the Calendar Tool, all un-responded notifications are discarded. Section 2.11.26 discusses non-modal dialogs in further detail..

By default, the system removes pending notifications from users' queues after the time for the notified meeting has past. The user can change this default behavior with an option setting.

Notifications are not queued when a user selects the `never' setting for the option that controls when to show notifications. During the period that the `never' setting is in force, notifications are discarded. If the user sets the option to some value other than `never', notifications are displayed or queued subsequently. Hence, a user cannot "catch up" on missed notifications that were sent while the notification option was set to `never'.

Since notification options are calendar-specific, pending notifications are therefore calendar-specific. As explained in the preceding section, all notifications are associated with a specific calendar. Given this, notifications are entered into and removed out of the pending queue based on the option settings for each calendar individually. For example, suppose the user has three calendars with notification options set to `whenever connected', `at initial connection', and `never' respectively. Notifications for the `whenever connected ' calendar are queued when the connection to the host is inactive; notifications are displayed as soon as the connection is established and during the time it remains established. For the `at initial connection' calendar, notifications are queued up to and immediately after the establishment of the host connection; all pending notifications are displayed immediately after the connection is established. Notifications for the `never' calendar are never queued and never displayed.

2.4.1.6.9. Concurrent Scheduling

For a given Calendar Tool central host, it is possible for two or more Calendar Tool users to execute the `Schedule Meeting' command concurrently. In such circumstances, the system imposes synchronization restrictions in order to ensure consistent scheduling behavior. Specifically, two or more users may perform scheduling concurrently on a particular host up to the point of the first `List Times' command in a scheduling request dialog (such as Figure 84 ). Upon execution of `List Times' by the first user to do so, all other users are blocked from executing `List Times' until the first user confirms a meeting or cancels both the confirmation and possible times dialogs (such as Figures 86 and 88 ). During the period of blockage, when a second user executes `List Times', the system displays a dialog of the form shown in Figure 120.

Figure 120: Scheduling temporarily blocked.


As the dialog explains, the user is informed that another user is currently in the process of scheduling. If the second user presses `Wait', the system adds the user to a waiting queue. When the user presses `Wait', that user may perform other Calendar Tool operations while waiting. When a waiting user is allowed to proceed, the system notifies the user as discussed below. If the user presses `Cancel' in the blocking dialog, the scheduling operation is canceled entirely, as if the second user had pressed `Cancel' in the scheduling request dialog.

When a third user and beyond execute `List Times', the system continues to respond with the blocking dialog, incrementing the number of users in the waiting queue each time an additional user presses `Wait'. For example, when a fourth user beyond estier executes `List Times', the system displays the dialog in Figure 121.

Figure 121: Fourth blocked user.


The number of users shown in the queue does not include the currently active scheduler, e.g., estier in this case.

If a user fails to take action in the blocking dialog, other users may proceed ahead of the non-acting user. As this occurs, the system dynamically increments the number of users in the queue while the blocking dialog remains on the screen. As other users complete their operation, the system decrements the queue length. When all other users complete their work, the blocking dialog is removed from the screen and the `List Times' operation for the non-acting user proceeds. In this way, a user who takes no action in the blocking dialog is able to proceed after all other users have completed scheduling. After a user presses `Continue' in the blocking dialog, the user can remove herself from the waiting queue by pressing `Cancel' in the suspended scheduling request dialog.

When the active scheduler confirms or cancels the meeting scheduling operation, the system removes the first user from the waiting queue. If this user is the only one waiting, then the system proceeds with the `List Times' operation that was originally blocked for the waiting user. Proceeding with the `List Times' operation means that the system displays the possible times list as the top-most display window on the screen, interrupting any Calendar Tool operation the waiting user may have been performing. The system issues an audible alert as an additional cue that the `List Times' operation may proceed.

If there are two or more users waiting in the queue, the system displays a dialog of the form shown in Figure 122, accompanied with an audible alert.

Figure 122: Notification to proceed with scheduling.


As the dialog explains, the user has 30 seconds to respond before being put back at the end of the waiting queue. If the user does respond within 30 seconds, the system proceeds with the blocked `List Times' operation for that user, and that user thereby becomes the active scheduler.

To promote fair service among users, the system monitors the amount of time a scheduler takes to complete or cancel a meeting scheduling operation while other users are waiting. The default time-to-complete increment is two minutes, which value can be set as an administrative option. If the waiting queue is non-empty, a completion timer starts when the possible times dialog is displayed for the current scheduler. If the waiting queue is empty when the possible times dialog is displayed, the completion timer starts when another user enters the waiting queue.

When a scheduler has spent two minutes in the scheduling operation while one or more users are waiting, the system displays a time warning dialog of the form shown in Figure 123.

Figure 123: Scheduling time warning.


As the dialog explains, the scheduler is offered two additional minutes to complete the scheduling operation. If the scheduler presses `Continue', the system removes the warning dialog from the screen, allowing the scheduler to continue with meeting scheduling. The system continues to redisplay the dialog at two-minute intervals until the scheduler completes or cancels the scheduling operation, or fails to respond within fifteen seconds to the warning. Cancellation of the scheduling operation, either by explicit button press or 15-second timer expiration, is equivalent to the user pressing the `Cancel' button in the scheduling request dialog.

There is no limit to the number of times that a scheduler may respond with `Continue' in the time warning dialog. In theory, this allows a user to block indefinitely all other users from scheduling. Such a circumstance is presumably unlikely and must be remedied by means outside of the Calendar Tool system.

Given the calendar/host association rules, it is not possible for the same calendar to be actively connected to more than one host at any given time. This means that a scheduler can never scheduler a meeting on more than one host at a time, which means that the concurrency rules are applicable to a pool of users on exactly one host at a time.



Prev: [none] | Next: task-scheduling | Up: more-scheduling | Top: index