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.

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 68.

Figure 68: 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 names. Attendee names are those of individual calendar tool users or user groups. User and group names can be entered in one of two forms: ID or nickname. The ID of a user or group is the unique identifier by which the user or group is known in the Calendar Tool system. A nickname is an optional user-defined identifier by which a user or group is known. IDs and nicknames are defined and searched for as described in Section 2.6. The names 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 scheuler 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 occurrances, as described in Section 2.5.2.2. Details of how users view meeting minutes are covered in Section 2.5.1.2.

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

Figure 69: 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 70.

Figure 70: 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 70 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. 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 71 shows the scheduler having selected the 8-9 AM time slot on September 23.

Figure 71: Selection in the possible meeting times list.


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

Figure 72: 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 three additional data fields below `Minutes'. The `Scheduled By' and `On' fields are read-only text. The values of these two fields are set by the system to the ID of the user performing the scheduling and the date/time on which the scheduling occurs. Below the scheduler ID 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. 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 68 ) and subsequently in the meeting confirmation dialog ( Figure 72 ). 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.3.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 73 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 73: 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 dialogs 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. Each attendee except the scheduler is notified of the meeting, as discussed in Section 2.4.1.5.

  2. The meeting is added to the scheduler's calendar, whether or not the scheduler is an attendee.

  3. The meeting is added 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.

  4. 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.4.

In the case of the staff meeting in Figure 73, 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. notifies all members of csstaff except the scheduler;

  2. adds the meeting to the scheduler's calendar;

  3. adds the meeting to the csstaff group calendar;

  4. 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 74.

Figure 74: 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 will consider 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 as an option. The `Details ...' aspect of recurring meetings is covered in the next meeting-scheduling scenario as well as in Section .

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 75.

Figure 75: 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 75 and presses `Confirm ...', whereupon the system displays the confirmation dialog in Figure 76.

Figure 76: 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. notifies all members of cslect, which does not include the scheduler;

  2. adds the meeting to the scheduler's calendar, even though the scheduler is not an attendee;

  3. adds the meeting to the cslect group calendar;

  4. 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 73 the system restores the dialog state to that shown Figure 72. 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, cancelling the scheduling operation is a three-step process: first the confirmation is cancelled, then the possibles list, and finally the original scheduling request dialog.

Once a meeting is confirmed, the item that appears in the scheduler's 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 cancelling scheduled meetings are discussed in Section 2.5.2.2.

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 77.

Figure 77: 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 78.

Figure 78: 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 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 79.

Figure 79: 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 80.

Figure 80: 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.

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 81.

Figure 81: 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 80, 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 82.

Figure 82: 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 will 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 78. Recurring details for other intervals are described in Section .

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 83, where the second and third options are both changed to `yes'.

Figure 83: 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 84.

Figure 84: 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 83. 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 85.

Figure 85: 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 86 shows a filled-in meeting request dialog for a computer science special colloquium; Figure 87 shows the options settings for this request.

Figure 86: Scheduling a special colloquium.




Figure 87: 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 86, the system responds with the possible times list shown in Figure 88.

Figure 88: 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 89 shows the scheduler having selected user mhutchen for viewing.

Figure 89: Selecting a conflicting user for the purpose of view his 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 89, 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.

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 90.

Figure 90: 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 80. In this case, the scheduler deals with the situation by expanding the date and time range for the meeting, as shown in Figure 91.

Figure 91: Modified tenure review meeting request.


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

Figure 92: 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 93.

Figure 93: 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 94.

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


The scheduler then proceeds to confirm the meeting.

Of note in Figures 93 and 94 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

Describe all of the details of meeting notifications.

2.4.1.6. Further Operational Details of Meeting Scheduling

Describe important operational deteils of meeting scheduling, as indicated by the titles of the subsections that follow.

2.4.1.6.1. The Contents of Group Calendars

2.4.1.6.2. Scheduling Over Private Items

Explain that private items are not visible to a scheduler, and so will get scheduled over.

2.4.1.6.3. The Status of Not-Yet-Accepted Meetings

Explain that non-yet-accepted meetings are considered as scheduled for the purposes of possible times computation.

2.4.1.6.4. Creation of New Categories

Explain the unusual and subtle case of when a leader-scheduled meeting has a category that is not defined in an attendee's calendar.

2.4.1.6.5. The Role of the Location Database

Describe the limited role of the location database in meeting scheduling.

2.4.1.6.6. Non-Unique Scheduled Meetings

Explain the resolution of the unusual and subtle case of a leader-scheduled meeting not being unique in an attendee's calendar, in terms of having the same date, start time, duration, and title.

2.4.1.6.7. Concurrent Scheduling

Describe the rules for two or more users trying to schedule a meeting at the same time and the way that one user cannot indefinitely block other waiting users.



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