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 . 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 83.
Figure 83: Meeting scheduling request dialog.
The following fields in the scheduling request dialog hold the same form of information as the appointment scheduling dialog in Figure 5:
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.
Figure 84 shows the scheduler having entered information for a non-recurring
meeting of the computer science staff.
Figure 84: Scheduling a staff meeting.
Figure 85: List of possible meeting times for the csstaff meeting.
The list in Figure 85 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:
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 86 shows the
scheduler having selected the 8-9 AM time slot on September 23.
Figure 86: Selection in the possible meeting times list.
When the scheduler presses `Confirm ...' in Figure 86, the system
responds with the meeting confirmation dialog in Figure 87.
Figure 87: Staff meeting confirmation dialog.
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 2.6.5.1
discusses 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 83 ) and subsequently in the meeting confirmation dialog ( Figure 87 ). 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 .
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 88 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 88: 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:
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 .
In the case of the staff meeting in Figure 88, 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:
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 89.
Figure 89: Scheduling another 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 90.
Figure 90: List of possible meeting times for the cslect meeting.
Figure 91: Lecturer meeting confirmation dialog.
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 88 the system restores the dialog state to that shown Figure 87. 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 92.
Figure 92: Scheduling a Faculty Meeting.
Figure 93: Details of a weekly recurring schedule.
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 94.
Figure 94: Weekly recurring details filled in.
Figure 95: No times found 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 96.
Figure 96: Weekly recurring details modified.
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 97.
Figure 97: Meeting scheduling options.
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 93. 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 98,
where the second and third options are both changed to `yes'.
Figure 98: Modified meeting scheduling options.
Figure 99: Possible meeting times with one or two faculty unable to attend.
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 100.
Figure 100: Selected faculty meeting time.
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 101 shows a filled-in meeting request dialog for a computer science
special colloquium; Figure 102 shows the options settings for this request.
Figure 101: Scheduling a special colloquium.
Figure 102: Special colloquium options settings.
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 101,
the system responds with the possible times list shown in Figure 103.
Figure 103: Possible times for the special colloquium.
Figure 104: Selecting a conflicting user for the purpose of viewing that user's calendar.
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 105.
Figure 105: Scheduling a tenure review meeting.
When the scheduler selects `List Times ...', the system responds with
the no-times dialog of
Figure 95.
In this case, the scheduler deals with the situation by expanding the date and
time range for the meeting, as shown in Figure 106.
Figure 106: Modified tenure review meeting request.
Figure 107: Tenure review meeting options.
Figure 108: Very long possible times list.
Figure 109: Long possible times list scrolled to an acceptable time.
Of note in Figures
108
and
109
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 110.
Figure 110: Meeting notification dialog.
Figure 111: Recurring meeting notification dialog.
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 110, the system responds with the meeting
information shown in Figure 112.
Figure 112: Viewing details of a meeting notification.
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 110 ) and the larger details dialog ( Figure 112 ) 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:
The precise effects of delaying the accept/decline decision are the following:
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 112,
the notified user decides to edit the `Title' and `Category'
fields, and turn off the reminder, as shown in Figure 113.
Figure 113: Notification details dialog edited.
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 114
shows a daily agenda where two meetings have been confirmed by the scheduler,
but not yet accepted by the user.
Figure 114: Two meetings displayed in penciled-in form.
Figure 115: Accepted meeting changed from penciled in form.
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:
The option settings for when to accept penciled-in meetings, that is meetings scheduled by an outside party, are the following:
The option setting for when to show notification dialogs has one of the following values:
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 110,
the email message sent to user dcollins would appear as shown in
Figure 116.
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 116: Content of email meeting notification.
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:
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 117.
Figure 117: Prompting dialog for new category definition.
As shown in
Figure 113,
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 117.
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 , 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 102, 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 118.
Figure 118: Accepted meeting with non-unique identity.
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:
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:
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 two 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 , 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 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 83
). 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
85
and
87
). During the period of blockage, when a second user executes `List
Times', the system displays a dialog of the form shown in Figure 119.
Figure 119: Scheduling temporarily blocked.
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 120.
Figure 120: Fourth blocked user.
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 121, accompanied with an audible alert.
Figure 121: Notification to proceed with scheduling.
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 122.
Figure 122: Scheduling time warning.
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.
The preceding rules for concurrent scheduling apply on a host-specific basis. That is, two meetings cannot be scheduled at the same time on any paricular host. However, concurrent scheduling is not prohibited among different hosts. Further, it is possible for the same user to be connected simultaneously to two different hosts, as described at the end of Section 2.6.6.1.
Given these facts, the host-specific rules for concurrent scheduling are not sufficient to guarantee that the `Scheduled By' and `On' fields are sufficient as a unique identification for all scheduled meetings. While it is not possible for two meetings to be scheduled at exactly the same time on any single host, it is possible for this to happen on two different hosts. Further, if the same user ID is used to gain simultaneous access to two different hosts, it is possible for two different meetings to have the same values for the `Scheduled By' and `On' fields. In such cases, the value of the `Host' field is used to guarantee unique identification of two different meetings.
The circumstances under which the `Host' field is necessary to guarantee meeting uniqueness are presumably quite rare. Given the concurrent scheduling rules described here in Section 2.4.1.6.9, plus the uniqueness rules described in Section 2.4.1.6.6, the `Host' field is only necessary to guarantee unique identification of different meetings when all of the following conditions are true: