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

Figure 80: 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 81 shows the scheduler having entered information for a non-recurring meeting of the computer science staff.

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

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

Figure 83: Selection in the possible meeting times list.


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

Figure 84: 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 80 ) and subsequently in the meeting confirmation dialog ( Figure 84 ). 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 85 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 85: 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 85, 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 86.

Figure 86: 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 87.

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

Figure 88: 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 85 the system restores the dialog state to that shown Figure 84. 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 89.

Figure 89: 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 90.

Figure 90: 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 91.

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

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

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

Figure 94: 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 90. 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 95, where the second and third options are both changed to `yes'.

Figure 95: 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 96.

Figure 96: 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 95. 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 97.

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

Figure 98: Scheduling a special colloquium.




Figure 99: 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 98, the system responds with the possible times list shown in Figure 100.

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

Figure 101: 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 101, 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 102.

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

Figure 103: Modified tenure review meeting request.


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

Figure 104: 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 105.

Figure 105: 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 106.

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


The scheduler then proceeds to confirm the meeting.

Of note in Figures 105 and 106 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 107.

Figure 107: 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 108.

Figure 108: 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 107, the system responds with the meeting information shown in Figure 109.

Figure 109: Viewing details of a meeting notification.


This display has the same information as in the meeting confirmation dialog accepted by the scheduler ( Figure 85 ). The user can edit any of the data fields in the notification dialog except for `Scheduled By' and `On'. Complete details of meeting editing are presented in Section 2.5.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 107 ) and the larger details dialog ( Figure 109 ) have `Accept' and `Decline' buttons. If the user chooses `Accept', the meeting is added to the user's calendar as a scheduled item. If the user chooses `Decline', the meeting is not added to the user's calendar.

To delay the accept/deline decision, the user can close the notification dialog window, using the `View Windows Close' command. A 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 occurance 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 109, the notified user decides to edit the `Title' and `Category' fields, and turn off the reminder, as shown in Figure 110.

Figure 110: Notification details dialog edited.


The user then presses `Accept', whereupon the system adds the meeting to the user's 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 109 and 110 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' or `Decline' 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 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 2.5.2.2 and 2.5.2.5.

Prior to an accept/decline decision, a confirmed meeting appears on a user's calendar in penciled-in form. Here "confirmed meeting" means a meeting that has been confirmed by its scheduler. 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 111 shows a daily agenda where two meetings have been confirmed by the scheduler, but not yet accepted by the user.

Figure 111: 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 110, the system displays the daily agenda shown in Figure 112.

Figure 112: Accepted meeting changed from penciled in format.


This figure shows an updated version of the daily agenda from Figure 111 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.

In terms of Calendar Tool data storage, a not-yet-accepted meeting is not physically part of a user's local workspace or filespace. This is because a scheduler does not have write access to attendees' calendars. When Calendar Tool data are accessed through the Calendar Tool itself, each individual user has exclusive write access to her or his local calendar data. Therefore, not- yet-accepted items are stored in a centralized Calendar Tool repository until accepted by individual users. Further details of user data protection are covered in Section 2.14.

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 notification dialogs and not-yet-accepted items is controlled with two option settings. The option for when to show notification dialogs has one of the following values:

When the `any time' setting is on and a notification is received while the Calendar Tool program is not running, receipt of the notification causes the Calendar Tool to be started, after which the notification dialog is displayed. When the Calendar Tool is started in this context, only the command menubar and notification dialog appear on the screen, without any other default initial display windows.

The system also provides an option to enable or disable the appearance of not- yet-accepted items. The option is a show/hide toggle, with the default setting of `show'. When the `show' setting is selected, all not-yet- accepted meetings are shown in penciled-in form in daily, weekly, and monthly calendar views, as well as in all list views. At the item level, not-yet- accepted meetings appear with different command buttons, as described in Section 2.5.1.2. The system dynamically updates all active displays that are affected the meeting being scheduled. An "affected" display is one in which the penciled-in item should appear. Details of dynamic view updaing are covered in Section 2.5.6. When the `hide' setting is selected, not-yet-accepted meetings do not appear at all in calendar or list views.

Given the two preceding options, it is possible for a user to disable entirely any form of meeting notification. Viz., if the user chooses the `never' setting for notification dialogs and the `hide' setting for not-yet-accepted items, meetings scheduled by other users are invisible via the Calendar Tool. The prudence of this combination of option settings is questionable, but left to users' discretion.

The system displays the notification dialog for any given meeting at most one time. The notification dialog appears as soon as the state of the user's host 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 dialog is allowed to appear, the system never displays it.

When viewing another user's calendar, not-yet-accepted meetings always appear in penciled-in form, independent of the current user's or other user's setting of the show/hide penciled-in option. Hence, a user can hide penciled- in items for her or his own calendar, but not for the calendars of other users. Hiding penciled-in items also has no affect on meeting scheduling. For the purposes of meeting scheduling, all not-yet-accepted meetings are considered scheduled, as discussed further in Section 2.4.1.6.3.

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 107, the email message would appear as shown in Figure 113. 

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 113: 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 electonic 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.

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 ID or nickname of the group appears in the attendees list
  2. the ID or nickname of a supergroup of which the group is a member appears in the attendees list
A group is not considered an attendee if all members of the group are listed individually as attendees, but the group ID or nickname is not listed directly or by subgroup inclusion.

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

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 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 setting of the show/hide option for penciled-in items has no affect on the status of the items for scheduling purposes. Specifically, if a user chooses to hide penciled-in items, their times are still considered unavailable for meeting scheduling.

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 attendees' calendars. When a notified user accepts a meeting with a category that is undefined in the user's calendar, the system prompts the user with a dialog of the form shown in Figure 114.

Figure 114: Prompting dialog for new category definition.


This figure corresponds to the special colloquium meeting shown in Figure 98 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 110, 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 114.

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.2, 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 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 99, for example. The uniqueness condition can also be violated for private items on attendees' calendars.

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

Figure 115: 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. Title editing is presumably the most typical.

For either `Retitle' or `Edit' selection, the system removes 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 fails to edit the title and again presses `Accept', the system redisplays the non-unique warning dialog.

2.4.1.6.7. Pending Notifications

Depending on the state of an attendee's Calendar Tool computer 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.

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.13.5, 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. Section 2.13.5 discusses this issue in detail.

By default, the system removes pending notifications from all 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 to the user 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'.

2.4.1.6.8. Concurrent Scheduling

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 up to the point of the first `List Times' command in a scheduling request dialog (such as Figure 80 ). 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 82 and 84 ). During this period of blockage, when a second user executes `List Times', the system displays a dialog of the form shown in Figure 116.

Figure 116: 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 117.

Figure 117: 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 will be 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 wating queue by pressing `Cancel' in the suspended scheduling request dialog.

When the active scheduler confirms or cancels the meeting 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 mans 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 118, accompanied with an audible alert.

Figure 118: 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 119.

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



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