2.5.2. Changing and Deleting Scheduled Items

Changing and deleting scheduled items is performed in item-level displays. As illustrated in the preceding section of the requirements, all item-level displays have `Change' and `Delete' command buttons to perform these operations. The enabled/disabled state of these buttons is consistent in all four types of item. Specifically, when the system initially displays an item-level view, the `Change' and `Clear' buttons are disabled and the `Delete' button is enabled. This is illustrated in the display excerpt shown in Figure 143.


Figure 143: Initial state of command buttons in all item- level displays.



What this means is that `Change' and `Clear' are not applicable until the user edits one or more data fields. Furthermore, the `Delete' command is only applicable prior to any data field editing, or after the user presses `Clear' to remove the edits.

As soon as the user performs an edit to some data field, the initial state of the command buttons is reversed. Namely, the `Change' and `Clear' buttons are enabled and the `Delete' button is disabled. This is illustrated in Figure 144.


Figure 144: State of command buttons after user edits one or more data fields.



The command buttons remain in the Figure 144 state until the user executes `Change' or `Clear', or re-edits all edited data fields back to their original values. Executing the `Change' command changes the item in the affected calendars and all affected displays. Executing the `Clear' command clears all edits, restoring the data fields to their original values when the item-level view was initially displayed, or most recently changed. No calendar changes are made when `Clear' is executed. When either `Change' or `Clear' is executed, the command button state returns to that of Figure 143. The command buttons also return to this state when the user re-edits all edited data fields back to their original values.

When the user executes and confirms `Delete', the system removes the item from the affected calendars, removes the item-level display from the screen, and updates any affected display windows.

Since the different types of scheduled item share many data fields in common, many aspects of changing items are common to all types. Aspects of item deletion are also common among the different types of item, such as the general form of the confirmation dialogs. The most wide-ranging effects of change and delete are made to meetings by meeting schedulers. Such changes and deletions potentially affect meeting attendees.

As noted in Section 2.4.1.5, there is a separate copy of a meeting for the scheduler and for each attendee. The system allows schedulers as well as attendees to change or delete their own individual copies. This multi-user access to meeting items leads to functional requirement details that must be carefully considered. The scenarios presented in Section 2.5.2.2 address these details.

2.5.2.1. Changing and Deleting Appointments

To change a scheduled appointment, the user edits one or more data fields in the item-level display and then presses the `Change' button. For example, Figure 145 shows the user having edited the date and time fields of the dentist appointment scheduled in Figure 6.


Figure 145: Date and time changes to the dentist appointment.



The change to the date is from September 25 to 29; the change to the start time is from 8 AM to 8:30. When the user presses `Change' in this display, the system responds with the confirmation dialog shown in Figure 146.


Figure 146: Change confirmation dialog.



When the user presses `OK', the system changes the item per the edits made to the data fields. If the user presses `Cancel', the changes are not made. In either case, the confirmation dialog is removed from the screen and the item-level display again becomes current. In the `OK' case, the command button state is returned to its initial configuration ( Figure 143 ). In the `Cancel' case, the buttons remain in the edits-performed state ( Figure 144 ).

In this scenario, the user selects `OK' in the confirmation dialog, whereupon the system proceeds with the appointment change. After the change is confirmed, the system updates all display windows that are affected by the change. For example, the month view shown in Figure 21 is changed to that shown in Figure 147, where the dentist appointment has been moved from 8-9:30 on the 25th to 8:30-10 on the 29th.


Figure 147: Updated view after confirmed appointment change.



All other display windows that contain the dentist appointment are updated to reflect the confirmed change. Further details of dynamic view updating are covered in Section 2.5.6

All data fields may be edited in the item-level view of an appointment. The same data-entry rules apply when changing an appointment as when initially scheduling it. These rules are covered in detail in Section . In addition to these data-entry rules, there are the following restrictions on changing a recurring appointment:

  1. a recurring appointment cannot be changed to non-recurring;

  2. changes made to any of the following data fields in a recurring appointment apply to all instances of the appointment:

Figure 148 shows the user having edited an instance of a recurring appointment.


Figure 148: Edits made to a recurring appointment.



Here the start time for the September 29th instance of the racket ball appointment has been changed from 8-9 AM to 7-8 AM. When the user presses `Change', the system responds with the change confirmation dialog in Figure 149.


Figure 149: Confirmation dialog for changing one instance of a recurring appointment.



The user selects `OK' whereupon the system proceeds with the single- instance change and all necessary view updates. For example, the month view in Figure 147 is updated to that in Figure 150.


Figure 150: Updated view after another appointment change.



The figure shows the time change to the September 29th instance of the racket ball appointment. The times of the other instances on the 1st, 8th, 15th, and 22nd remain the same.

The user decides to perform another change to the racket ball appointment, by deleting the last three weeks from the recurring schedule. To do so, the user moves to the October 1 instance and performs the edit shown in Figure 151.


Figure 151: Additional edits made to a recurring appointment.



Here the user has changed the end date from December 31 to December 10. Of note is that the user moved to an instance other than the edited September 29. If the user had remained at September 29 to make the all-instance change to the end date, then the September 29 start-time change would be made to all instances as well. Since this is not what the user wants, the end-date change is made in another instance. Even after an individual instance has changed, it remains an instance of the same recurring appointment. Therefore, it may be used to effect changes to all other or all future instances. This issue is discussed further in Section 2.5.3.5.

The user proceeds to press `Change' in Figure 151, in response to which the system displays the confirmation dialog in Figure 152.


Figure 152: Confirmation dialog for changing all instances of a recurring appointment.



When the user presses `OK', the system performs the change, which the user then inspects by opening the month view for December, shown in Figure 153.


Figure 153: Updated view after further appointment change.



The previously scheduled racket ball instances for December 15 through 31 are now gone.

If the user changes an appointment with `all future' selected, the system displays the dialog of Figure 154.


Figure 154: Confirmation dialog for changing all future instances of a recurring appointment.



The dialog contains the appropriate wording change to reflect the `all future' selection.

To delete a non-recurring appointment, the user presses `Delete' in the item-level display. In response, the system displays the confirmation dialog of Figure 155.


Figure 155: Delete confirmation dialog.



The user presses `OK' to proceed with the delete, in response to which the system deletes the appointment from the user's calendar and removes both the confirmation dialog and item-level display from the screen. The system also updates any affected display windows by removing the deleted item. If the user selects `Cancel', the system performs no delete and removes the confirmation dialog, leaving the item-level display in its state prior to `Delete' having been executed.

When the user executes `Delete' for a recurring appointment, the system displays one of the three confirmation dialogs shown in Figure 156, based on the setting of the change/delete radio buttons.


Figure 156: Delete confirmation dialogs for a recurring appointment.



When the user presses `OK', the system deletes the one or more instances as selected, removes the item display from the screen, and updates all affected display windows by removing the deleted item(s). If the user selects `Cancel', no deletions are made and the item-level dialog is made current. In either case, the confirmation dialog is removed from the screen.

2.5.2.2. Changing and Deleting Meetings

The change and delete commands for meetings behave much the same as they do for appointments. A significant difference is when a scheduler changes or deletes a meeting, all attendees can be notified. Scheduler deletion of a meeting is the means by which the meeting is effectively canceled for all attendees.

Individual users can also change their own local copies of scheduled meetings. When both schedulers and non-schedulers make changes to the same meeting, their changes must be reconciled. What it means to have separate copies of the "same meeting" is that values of the `Scheduled By', `On', and `Host' fields are the same in each of the copies. The set of values for these three fields constitutes the unique identification of a meeting on all users' calendars. This is the reason why these values cannot be changed after a meeting has been scheduled.

The precise relationship between the scheduler and non-scheduler copies of a meeting can be characterized as follows. The meeting copies are "synchronized" when they contain exactly the same values for all data fields. The synchronized state exists when an attendee accepts a meeting without making any changes, and the scheduler makes no changes subsequent to confirming the scheduling operation. Synchronization also occurs when a non-scheduler accepts scheduler-initiated changes, as discussed in Section 2.5.2.2.1.

When the scheduler and/or non-scheduler change their copy of a meeting, it becomes "unsynchronized". The only time an unsynchronized meeting is brought to the attention of an attendee is when the scheduler changes the meeting and then notifies the attendees. At this point, the user must be able to identify which data fields have been changed and by whom. To assist in this identification, the system color codes the changes when it displays the change notification dialog. Table 9 describes this coding.



Changed By
Scheduler
Changed By
Non-Scheduler
Color
no no black
yes no blue
no yes green
yes yes red (a conflict)

Table 9: Color Coding of Meeting Changes in Change Notification Display.



In order for change notifications to be sent and received, the scheduler and attendees must be connected to the same Calendar Tool central host computer, and it must be the host from which the changed meeting was originally scheduled. The scenarios of Sections 2.5.2.2.1 through 2.5.2.2.5, assume that the scheduler and affected non-schedulers are so connected, and that the changes they make do not conflict. Sections 2.5.2.2.6 and 2.5.2.2.7 address the cases where scheduler and non-scheduler make changes while disconnected from the host and then subsequently reconnect. Section 2.5.2.2.8 covers conflicting scheduler and non-scheduler changes.

2.5.2.2.1. Scheduler Changing Meetings

To change an existing meeting, the meeting's scheduler edits its item-level display, in the same manner as appointment editing is performed (see Section 2.5.2.1. ). If the scheduler wants all attendees of the meeting to be notified of the changes, the scheduler must be connected to the same central host computer to which she was connected when the meeting was originally scheduled. If the scheduler is not connected to this host at the time a change is confirmed, then the changes are made only to the scheduler's local copy of the meeting and no change notification is sent (see Section 2.5.2.2.6 ).

As described in Section 2.4.1, some of the data fields of a scheduled meeting are computed by the system, based on the initial scheduling request. This means there are scheduler restrictions on changing some meeting data fields. Furthermore, some data fields are sufficiently critical to the meeting that all attendees must be notified if one or more such fields are changed. Table 10 summarizes what changes, if any, are allowed by the scheduler and which field changes require attendee notification.



Data Field Changes Allowed Notification Required
Title any except empty no
(Start) Date any future date, with warning if conflicts detected yes
End Date same as Start Date yes
Start Time any, with warning if conflicts detected yes
Duration same as Start Time yes
Recurring any, with warning if conflicts detected yes
Category any no
Security any no
Location any available at time(s) of meeting yes
Priority any no
Remind any no
Attendees any, with warning if conflicts detected yes
Details any no
Minutes any no
Scheduled By none  
On none  
Host none  

Table 10: Summary of allowable changes to meeting data fields by the scheduler.



The table entries listed as "any" are still subject to the general data entry rules described in Section

Figure 157 shows edits made by the scheduler to the staff meeting confirmed in Figure 88.


Figure 157: Duration and details changes to the staff meeting.



The changes are to increase the duration from 1 hour to 1.5 hours and to update the agenda. When the scheduler presses `Change', the system responds with the confirmation dialog in Figure 158.


Figure 158: Confirmation dialog when scheduler changes critical meeting field, with conflicts.



The contents of this dialog reflect two conditions of the change:

  1. One or more critical data fields have been changed, Duration in this case; this requires that all attendees be notified.

  2. There is a time conflict for one or more attendees; the scheduler is informed of this condition in the dialog.
If the scheduler chooses `OK', the system proceeds with the change on the scheduler's calendar and notifies all attendees of the change, except for the scheduler. If the scheduler chooses `Cancel', the system performs no changes. In either the `OK' or `Cancel' case, the confirmation dialog is removed from the screen and the item-level meeting display becomes current.

In this scenario, the scheduler chooses `OK'. The scheduler's calendar is changed and all affected display windows are changed on the scheduler's display screen. In this case the scheduler is among the attendees and also appears in the conflicts list. The scheduler receives no notification, since the dialog itself serves this purpose. The fact that the meeting conflicts with existing item(s) on the scheduler's calendar is handled in the normal way, i.e., the item is subsequently displayed in overlapping format, as illustrated in Section 2.3.1.

When the scheduler confirms the change, all attendees are notified. Complete details of attendee change notification are covered in Section 2.5.2.2.3

The definition of time conflict when changing a meeting is the same as when the meeting is initially scheduled. Viz., a conflicting item on an attendee's calendar is any non-private item that overlaps with the changed meeting. Such a conflict can arise when the scheduler makes a change to one or more of the following meeting fields:

In the case where the Attendees list is changed, the users checked for conflict are those in the changed list, i.e., all original attendees not deleted from the list, plus any newly-added attendees.

The system provides no means to recompute a list of possible meeting times via the `Change' operation. All that the system does is detect and report attendee time conflicts. If the scheduler wants to reschedule the meeting at time when there are no conflicts, the scheduler must re-execute the `Schedule Meeting' operation to view a list of non-conflicting possible times. The scheduler can then choose a time from that list for the change, using copy and paste. Alternatively, the scheduler can delete the original meeting and re-execute the `Schedule Meeting' operation from scratch.

Figure 159 shows the scheduler having edited an instance of the recurring lecturer meeting scheduled in Figure 91.


Figure 159: Scheduler edits a recurring meeting.



The change is to the `Minutes' field for a single meeting instance. In this example, the current date is assumed to be after the first occurrence of the lecturer meeting, so the change to the `Minutes' field is considered a normal operation. When the scheduler presses `Change' in Figure 159, the system displays the dialog in Figure 160.


Figure 160: Confirmation dialog when scheduler changes non- critical meeting field in a recurring meeting.



Because no critical data field has changed, the dialog provides the option of whether or not to notify all attendees. In this case, the scheduler leaves the default `Notify' setting on and presses `OK', whereupon the system updates the scheduler's calendar, updates any affected displays on the scheduler's screen, and notifies all attendees of the change.

Figure 161 shows another change to the lecture meeting, this time to future instances, at and beyond the October 1 instance.


Figure 161: Location change to future lecturer meetings.



The figure reflects the scheduler having navigated to the October 1 instance, i.e., the scheduler did not change the instance date. The changes are to the `Location' and `Details fields. Location is a critical field that requires attendee notification. The `Details' field has a textual note indicating the location change. This is an example of using `Details' for a slightly different purpose than may be typical, viz., a note about a change. Since this change will appear in all future instances, the scheduler may later perform individual edits to the `Details' field.

When the scheduler presses `Change' in Figure 161, the system displays the dialog of Figure 162.


Figure 162: Confirmation dialog when scheduler changes critical field for future instances.



When the scheduler confirms the Location change, the system checks that the new location is available at all meeting times, that is, the times of all future instances. If it is not available, an error message is issued, as discussed in Section The system also performs the appropriate calendar and display changes.

Figures 158, 160, and 162 show three examples of the confirmation dialog for changes made by a meeting scheduler. There are sixteen possible configurations for this dialog, based on whether there are attendee conflicts, whether the meeting recurs, and whether attendee notification is to happen. The following is a description of all possible configurations:

2.5.2.2.2. Scheduler Deleting a Meeting

To delete a non-recurring meeting, the scheduler presses `Delete' in the item display. In response, the system displays a dialog of the form shown in Figure 163.


Figure 163: Confirmation dialog for scheduler-deleted meeting.



Scheduler deletion of a meeting always requires attendees notification. Therefore the delete confirmation provides no notification option.

The scheduler presses `OK' to proceed with the delete, in response to which the system deletes the meeting from the scheduler's calendar, deletes the meeting from all attending group calendar(s), and notifies all attending users. The system also updates any affected display windows on the scheduler's screen by removing the deleted item from those displays. Updates to attendee screens are performed as described in Section 2.5.2.2.3. If the scheduler selects `Cancel', the system performs no delete and removes the confirmation dialog, leaving the item-level display in its state prior to `Delete' having been executed.

Deletion of a recurring meeting applies to all instances selected by the change/delete radio buttons, with the same effects for each instance as non- recurring deletion. The confirmation dialogs are shown in Figure 164.


Figure 164: Confirmation dialogs for scheduler-deleted recurring meeting.



When the scheduler cancels a meeting with `Delete', the meeting is permanently removed from the scheduler's calendar, and from the calendars of all accepting attendees. If the scheduler wants to retain a record of a canceled meeting, the scheduler can perform cancellation with `Change' instead of `Delete'. To do so, the scheduler can type an appropriate cancellation text in the `Title' and/or `Details' fields. To bring the changed field(s) to the attention of notified users, the system color highlights the title and border of the changed field(s), as described in the next section.

2.5.2.2.3. Meeting Change and Delete Notifications

When the scheduler changes a meeting such that a notification is required or selected, the system notifies each attendee, except the scheduler. The notification is sent in an on-screen change notification dialog, of the form shown in Figure 165.


Figure 165: Meeting change notification.



This is a notification for the change made in Figure 157. The message indicates the scheduler's ID plus the time and date of the changed meeting.

If the attendees list in a meeting is changed, the change notification is sent to those users appearing in the attendees list prior to the change who have not been deleted by the change. Users deleted from or newly added to the attendees list are sent a different form of notification, as described below.

When a scheduler change causes a time conflict with one or more existing items in a notified user's calendar, the notification message has the following line appended:

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

The user can view the complete details of the change by pressing the `View ...' button in the initial change notification dialog. For example, when the user presses `View ...' in Figure 165, the system responds by displaying the notification details dialog in Figure 166.


Figure 166: Viewing details of a meeting change notification.



The data fields changed by the scheduler are highlighted with widened blue borders and field titles in bold blue type. The data fields changed by the attending user are highlighted with widened green borders and field titles in bold green type. Unchanged data fields are shown with normal black borders and titles. Note that for multi-component data fields, such as Duration, the data field title is highlighted as are any changed components. Unchanged components are not highlighted, hence the `hr' component is shown in normal black type.

In Figure 166, the scheduler changes in blue are those made in a preceding scenario (see Figure 157 ). The non-scheduler changes in green were made before the user accepted the meeting (see Figure 113. ). The case of conflicting scheduler and non-scheduler changes is not shown in Figure 157; it is covered later in Section 2.5.2.2.8.

All data values shown in Figure 166 are those in the scheduler's copy of the meeting. The user can compare these values with hers for the same meeting by viewing the same meeting using the `View Item' menu command, as discussed in Section 2.5.2.2.5

There are `Accept' and `Decline' buttons at the bottom of the detailed notification dialog. To the left of the buttons is a label explaining that the buttons apply to the changes made by the scheduler. The user can edit any data fields except `Scheduled By', `On', and `Host'.

The user can respond to a meeting change notification in one of three ways: accept the change, decline the change, or delay a decision. Both the smaller change notification dialog ( Figure 165 ) and the larger details dialog ( Figure 166 ) have `Accept' and `Decline' buttons. If the user chooses `Accept', the changes are merged into the scheduled item in the user's calendar. If the user chooses `Decline', the changes are not merged. The prudence of declining scheduler changes to a meeting may questionable, but left to the user's discretion.

To delay the accept/decline decision, the user can close the notification dialog window, using the `View Windows Close' command or equivalent window shortcut. 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 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.

In the case of Figure 166, the notified user decides to edit the `Duration' field from the scheduler changed value of 1.5 hours back to the original value of 1 hour, as shown in Figure 167.


Figure 167: Change notification details dialog edited.



In this scenario, the viewing user is one of those for whom the scheduler's change has created a conflict, as indicated in the small notification dialog in Figure 165 Therefore, the user re-edits the duration to avoid the conflict. This is an example where a user legitimately edits a scheduler-generated data value. The issue of what constitutes a "legitimate" user edit of a meeting is discussed further in Section 2.5.2.2.5.

When the user presses `Accept' in Figure 167, the system merges the scheduler's changes into the user's copy of the meeting item. Change merging is accomplished by retaining the most recently entered value for each meeting data field. For this staff meeting, the user has changed the `Title', `Duration', `Category', and `Remind' fields more recently than the scheduler. Therefore, the user's values for these fields are retained in the changed version. In the case of `Title', `Category', and `Remind', the user's edits where made prior to the original acceptance of the scheduled meeting ( Figure 113 ). The `Duration' field was edited by the scheduler ( Figure 157 ), but then subsequently edited by the user in the notification dialog ( Figure 167 ). Therefore, the user's edit to `Duration' is the most recent, and it is retained in the changed version. The scheduler's change to the `Details' field is most recent, and therefore appears in the accepted version. All of the other data fields are unchanged by either the scheduler or user from their original scheduled values, and hence are retained as they are. Any user edits made in the notification dialog are reflected in the ultimately accepted changes. As a result, when the user executes `View Item' after pressing `Accept' in Figure 167, the system displays the item-level view shown in Figure 168.


Figure 168: Scheduler changes merged into meeting.



The item view has a full date description at the top, with `Change' and `Delete' command buttons instead of `Accept' and `Decline'.

The policy to merge only the most recent changes may not be optimal in all circumstances. For example, the user may wish to retain a previous value, as was the case with the meeting `Duration' in the preceding example. The system provides no option to select a different merge policy. The user can view the change notification and item displays side by side to inspect the differences between scheduler and user versions of a changed meeting. The user can then edit any scheduler-changed fields in the notification dialog.

There are two local copies of a meeting for each user who has not yet accepted or declined scheduler changes. The copy shown in the item-level display is that stored in the user's local calendar, without any not-yet-accepted scheduler changes. The copy shown in the change notification dialog reflects changes made by the scheduler. The scheduler-changed copy of the meeting is stored in the notification dialog itself, and is not yet a scheduled item in the user's calendar. The meeting in the user calendar refers to the scheduler-changed copy, via the `View ...' button, as shown in Figure 171. In terms of physical storage, the notification copy of the meeting is stored on the user's local computer when the notification is received from the central host computer. In this way, the user may subsequently disconnect from the central host and still have a record of the scheduler changes to that point. Further discussion of local and central data storage are covered in Section .

To undo any edits made after the change confirmation dialog is initially displayed, the user can press `Clear'. As illustrated in Figures 166 and 167, 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.

When a scheduler changes a recurring meeting, the notification dialog text is one of the following, based on the scheduler's setting of how many instances to change:

"User user ID has changed one instance
   of the recurring meeting on
date"

"User user ID has changed all instances
     of the recurring meeting on
date"

"User user ID has changed all future instances
  of the recurring meeting starting on
date"
The user ID is the ID of the scheduling user. In the one-instance and future-instance messages, date is the instance date. For the all- instances message, date is the start date.

When the scheduler deletes a meeting, attending users are notified with a dialog of the form shown in Figure 169


Figure 169: Delete notification dialog.



This is the notification for the meeting scheduled in Section 2.4.1.4. For deletion of a recurring meeting, the dialog text is changed in the same way as for a change notification, with the word "changed" replaced with "deleted".

To view details of the scheduler-deleted meeting, the user presses `View ...' in Figure 169. In response, the system displays the dialog in Figure 170.


Figure 170: Viewing details of a meeting delete notification.



To the left of the command buttons is a label explaining that the buttons apply to a deletion performed by the scheduler. The user may edit any data fields except `Scheduled By', `On', or `Host'. Performing edits is only meaningful if the user plans to decline the deletion. The user may choose to do so if she wants to retain a copy of a canceled meeting.

If the user presses `Accept', the system deletes the meeting from the user's calendar, updates all affected displays, and removes the delete notification dialog(s) from the screen. If the user presses `Decline', no deletion is performed. If the user has edited one or more data fields prior to pressing `Decline', the system displays a change confirmation of the form shown in Figure 172. If the user confirms the change, the system removes the notification from the screen. If the user cancels the change, the notification dialog remains, with no action having been taken.

Prior to an accept/decline decision for a scheduler changed or deleted meeting, the meeting appears in penciled-in form. As discussed in Section 2.4.1.5, the penciled-in format appears in daily, weekly, and monthly calendar views, as well as in all list views. The format is illustrated in Figure 114. In item-level calendar views, meetings with not-yet-accepted scheduler changes or deletion are indicated by additional command buttons at the bottom of the display. Details of this are presented in Section 2.5.2.2.5

The appearance of change/delete notifications is controlled by the setting of the meeting notification option described in Section 2.4.1.5. Also described in that section is the option that controls the appearance of penciled-in items. When an attending user is connected to the originating central host, and options settings permit, the system dynamically updates all active displays that are affected by a scheduler meeting change. An "affected" display is any attending user's display that shows the item prior to being changed. In all such displays, the item is dynamically changed from normal format to penciled-in format. In item-level displays, scheduler changes are indicated with the dynamic appearance of extra command buttons. The format of these item-level displays is described in Section 2.5.2.2.5. Further details of dynamic view updating are covered in Section 2.5.6.

After the user makes the accept, decline, or delay decision in any notification dialog, the notification is never redisplayed. If the start date and time of the meeting pass before the user makes the accept/decline decision, the system automatically executes decline on the user's behalf. As a result, the scheduler's changes are ignored, and the meeting is changed from penciled-in form back to a regular scheduled item. If the start date and time of the meeting pass before the notification dialog is allowed to appear, the system never displays it. The further details of notification handling discussed in Section 2.4.1.5 apply to change/delete notifications in the same way as they apply to originally scheduled meetings.

In terms of physical storage, the scheduler-changed copy of the meeting is effectively part of the change notification itself, not in the user's local calendar. This effective behavior is necessary so that the user can compare, if desired, the complete content of the extant local copy of the meeting with the scheduler-changed copy, as explained in Section 2.5.2.2.5.

In the case where a meeting change involves addition or deletion in the `Attendees' list, the notification for added or deleted attendees is different from the change notification described above. Specifically, each newly added attendee receives a regular meeting notification, as described in Section 2.4.1.5. The only difference in the added-attendee notification is that the third line of text is changed to "with you as an added attendee" instead of "with you as an attendee" (see Figure 110 ). The notification is sent to newly-added attendees in lieu of the change notification shown in Figure 165. The process of accepting or declining an added-attendee notification is precisely the same as described in Section 2.4.1.5.

Each removed attendee receives a meeting delete notification, as described above near Figure 169. The only difference in the deleted-attendee notification is that the first line of text is changed to "User ... has deleted you as an attendee of the meeting" instead of "User ... has deleted the meeting". This notification is sent to removed attendees in lieu of the change notification sent to retained attendees.

2.5.2.2.4. Group Calendar Changes

When a meeting scheduler confirms a change or delete, the effects are reflected immediately in all attending group calendars. As explained in Section 2.4.1.6.1, only a group leader can schedule a meeting for a group. Accordingly, only changes made by a group leader affect the group calendar.

The set of categories defined for a group calendar consists of the union of the categories for all items appearing in the calendar. When a scheduler changes or deletes the category for a meeting, the change or deletion is reflected in the set of defined categories as necessary. Specifically,

  1. if a category change leads to the definition of a new category, that category is added to the group calendar;

  2. if a meeting deletion is for the last group calendar item that contains a particular category, that category is deleted from the group calendar.

Group calendars are "virtual" in the sense that they are not directly editable. Change and delete on group calendars is effected by a group leader when the leader changes or deletes on the leader's own calendar. Calendar Tool system administrators can purge items from a group calendar, as described in Section .

2.5.2.2.5. Non-Scheduler Changing and Deleting Meetings

Non-scheduler change or delete of a meeting is performed in basically the same manner as appointment change or delete. Non-scheduler change or delete affects only an individual user's local calendar and no attendee notifications are sent. As noted earlier, the item for any meeting is stored as an individual copy in each user's local calendar. This means that scheduler and non- scheduler changes are performed on separate copies of the same meeting. The scheduler and non-scheduler copies are merged whenever an attending user accepts a scheduler's changes.

The only meeting fields that a non-scheduler can never edit are `Scheduled By', `On', and `Host. This is because, as noted above, the set of values for these three fields constitutes the unique identification of a meeting on all users' calendars. All other fields are editable, subject to the following conditions:

  1. the general data-entry rules in Section must be followed

  2. the edit restrictions for recurring appointments in Section 2.5.2.1 must be followed;

  3. if an item has not-yet-accepted scheduler changes, the data fields that the scheduler has changed are not editable in an item-level display until the user accepts or declines the scheduler changes.
Of note is that the scheduler editing restrictions in Table 10 do not apply to non-schedulers.

Given the reasonably liberal policy for non-scheduler edits, it is possible for a user to make imprudent changes to a meeting. For example, changing the date or location is typically not prudent, unless the user has information of the change from outside the context of the Calendar Tool. When a non-scheduler executes the change operation, the system displays a general warning in the confirmation dialog, but imposes no further restrictions on the change. The alternative to this liberal change policy would involve a potentially complicated definition of what constitutes "legitimate" change to a meeting by a non-scheduler. The developers of the Calendar Tool requirements decided to avoid the complications of such a definition.

Change and delete operations are executed from the item-level view of a meeting. Examples of these views are shown in Section 2.5.1.2. The examples in that section show regularly scheduled as well as not-yet- accepted meetings. There are two additional forms of item view for meetings with not-yet-accepted scheduler changes or deletion. Items with not-yet- accepted scheduler changes appear in the form illustrated in Figure 171.


Figure 171: Item-level view of meeting with not-yet-accepted scheduler changes.



This is the item-level view of the changed staff meeting before the changes have been accepted by the user, and before any changes have been made in the change notification dialog. That is, it is the result of a `View Item' command for the meeting changed by the scheduler in Figure 157, before the user has performed any action in the change notification dialog.

The display in Figure 171 contains the same information as the regular item- level view in Figure 137, with the addition of accept/decline command buttons at the bottom. For added clarity, the banner of the display is augmented with the "SCHEDULER CHANGED" text. The additional command buttons have the same functionality as in a change notification dialog, such as Figure 166. That is, the buttons allow the user to accept, decline, or view details of the scheduler's changes.

The data values in Figure 171 are those most recently entered by the user, independent of the scheduler changes. Hence, the not-yet-accepted changes to the `Duration' and `Details' fields do not appear. To see these changes, the user can select the `View ...' command, in response to which the system displays the detailed change notification dialog of Figure 166.

To prohibit conflicting changes, the system disables editing in data fields that have scheduler changes not yet accepted by the user. Hence, the `Duration' and `Details' fields are disabled in Figure 171. These are the same fields shown with blue highlight in the unedited notification dialog of Figure 166. The user can edit and confirm changes to any of the other editable data fields in Figure 171. The purpose of disabling scheduler-changed data fields in the item view is to force the user to edit such fields in the notification dialog, where they are clearly indicated as having been changed by the scheduler.

As explained in a preceding scenario, the scheduler-changed copy of the meeting is not officially a scheduled item in the user's calendar. As such, it does not appear separately in calendar views, only the user's copy so appears. The only access to the scheduler-changed copy is through the `View' command in the item-level view of the user's copy (Figure Figure 171 ) or in the meeting change notification ( Figure 165 ).

Once any scheduler-generated changes to a meeting are dealt with, the use may make any desired changes to a meeting. When the user presses `Change' in the item view of a non-recurring meeting, the system displays the confirmation dialog in Figure 172.


Figure 172: Non-scheduler change confirmation dialog.



The dialog informs the user that changing an individual copy of a meeting is likely to result in differences with other users, namely the scheduler and other attendees. It is "likely" in the sense that the user's version will differ from other users unless all of them make exactly the same changes. When the user presses `OK', the system proceeds with the change on the user's local copy and updates all affected displays. Pressing `Cancel' in the confirmation dialog results in no calendar or display changes.

The change confirmation dialogs for recurring meetings differ in the first sentence of the dialog text. The first sentences are:

"Are you sure you want to change this instance
          of the recurring meeting?
"

"Are you sure you want to change all instances
          of the recurring meeting?
"

"Are you sure you want to change this instance and
  all future instances of the recurring meeting?
"
the appropriate one of which appears based on the user's setting of how many instances to change.

When a user views an item with not-yet-accepted scheduler deletion, the display appears as shown in Figure 173.


Figure 173: Item-level view of meeting with not-yet-accepted scheduler deletion.



As in Figure 171, there are both change/delete and accept/decline command buttons. In this case, the label beside the accept/decline buttons indicates that they apply to a not- yet-accepted scheduler deletion. For added clarity, the banner of the display is augmented with the "SCHEDULER DELETED" text.

The two groups of command buttons in Figures 171 and 173 correspond to the two different copies of a meeting with not-yet-accepted scheduler changes or deletion. The change/delete buttons operate on the pre- accept copy. The accept/decline buttons operate on the notification copy with the scheduler's not-yet-accepted changes.

Meeting deletion by a non-scheduler is processed in the same manner as appointment deletion, as explained in Section 2.5.2.1 The only difference is that the word "appointment" in the confirmation dialogs of Figures 155 and 156 is replaced with the word "meeting".

A non-scheduler deleting a meeting has no effect on any other users' copies of the meeting. In particular, a user who deletes a meeting is not removed from the attendees list in any one else's copy of the meeting.

After an attending user deletes a meeting, that user does not receive any subsequent change or delete notifications from the scheduler of the meeting. Operationally, this can mean that the notifications are never sent to the local computer, or are deleted upon receipt by the local computer. The effective behavior is that a user never sees change/delete notifications for a locally deleted meeting, i.e., a meeting deleted by an attending user but not by the scheduler.

It is possible for a meeting in the user's local calendar to be in the not-yet- accepted state when the scheduler makes (further) changes, or deletes the meeting. This is the case where the user has not yet accepted the original scheduling of the meeting, but the scheduler has made a later change or deleted the meeting. Operationally, there is no difference in such cases compared to that described above (around Figures 171 and 173 ), except that the banner of the item-level display window reflects the not- yet-accepted state of the original meeting. Specifically, when the scheduler changes a not-yet-accepted meeting, the item-level banner is "Not-Yet-Accepted Meeting -- SCHEDULER CHANGED" (cf. Figure 171 ). The banner for a scheduler-deleted not-yet-accepted meeting is "Not-Yet-Accepted Meeting -- SCHEDULER deleted" (cf. Figure 173. ).

2.5.2.2.6. Offline Scheduler Change and Delete

As noted in Section 2.5.2.2.1, the scheduler must be connected to the originating central host in order for meeting attendees to be notified of changes or deletions. If the scheduler is not so connected, she cannot change any critical meeting field or delete the meeting until a connection is re-established. If the scheduler attempts to confirm such a change or delete, the system displays the error message described in Section . The scheduler may change non-critical meeting fields when not connected to the originating host. When the scheduler confirms such a change, the system displays the warning dialog shown in Figure 174.


Figure 174: Warning when changing a meeting while not connected to the originating host.



This dialog appears whenever the scheduler is not connected to the originating host, even if connected to some other host. There are appropriate different forms of the dialog text for recurring meetings, as described in Section 2.5.2.2.1.

If the scheduler subsequently connects to the originating host, the attendees are not then notified. The scheduler must make and confirm additional changes in order to have the opportunity to notify attendees. When a subsequent change is confirmed while connected, it is based on the cumulative editing that has been performed, both online and offline, since the last time the meeting was synchronized.

2.5.2.2.7. Offline Non-Scheduler Changes

A non-scheduling user may make changes to her local copy of a meeting whether or not she is connected to the originating central host. The only operational difference when not connected is that the user may change a field that has also been changed by the scheduler. Such a change is possible when a scheduler change notification has not yet been received due to the lack of connection, or having set the notification option to `never'. When a scheduler change notification has been received, the system is able to prevent conflicting changes by disabling edits to scheduler-changed meeting fields, as shown in Figure 171. The system can continue to prohibit conflicting changes any time after the change notification has been received, even when subsequent changes are made offline. This is the case because the system retains the change notification on the local computer once received.

2.5.2.2.8. Conflicting Scheduler and Non-Scheduler Changes

A conflicting meeting change occurs when a non-scheduling user changes a meeting field that has also been changed by the scheduler, before the scheduler change notification has been received. As discussed in the preceding scenarios, the Calendar Tool system is designed to avoid conflicting meeting changes insofar as is possible. As long as a non-scheduling user remains up to date with scheduler change notifications, the system prohibits conflicting changes. The user can accomplish this up-to-datedness by retaining or establishing a central host connection any time prior to editing a scheduled meeting, and by not setting the meeting notification option to `never'.

A conflicting change becomes apparent to the non-scheduling user when the user reconnects to the originating host and then receives the scheduler's change notification. In this case, conflicting data fields are shown with red highlights. For example, suppose the user had made a conflicting change to the `Details' field of the meeting shown in Figure 166. In such a case, the change notification dialog would appear as shown in Figure 175.


Figure 175: Conflicting change.



Here the red-highlighting indicates the conflict in the `Details' field. In terms of change merging, the system treats conflicting changes the same as non-conflicting changes. Namely, if the user presses `Accept', the system merges the scheduler's and user's changes by retaining the most recently entered value for each meeting data field. Given that the merge behavior is the same for both conflicting and non-conflicting changes, the only purpose for distinguishing them is informational. That is, when viewing the change notification dialog, the use can see precisely which fields have been changed and by whom.

2.5.2.2.9. Pending Change/Delete Notifications

Depending on the state of an attendee's connection to a central host, it is possible for a scheduler to send one or more change/delete notifications before an attending user accepts or declines any of them. The system retains only a single change/delete notification for any given meeting. The retained notification corresponds to the most recently confirmed change or delete executed by the meeting's scheduler. To be clear, there is a single notification for any particular meeting, corresponding to the most recent change or delete operation. There is not a separate notification for change and for delete. By the nature of the delete operation, once confirmed it is be the last notification produced by the scheduler. Hence, once a delete notification is sent, no further notifications will follow. The definition of a "particular meeting" is based on the unique identification provided by its `Scheduled By', `On', and `Host' values.

Pending change and delete notifications are stored in the same queue as initial meeting scheduling notifications, as described in Section 2.4.1.6.8. Change and delete notifications are commingled with initial scheduling notifications, in confirmation time order. For a change or delete operation, the confirmation time is defined as the time at which the scheduler presses the `OK' button in the change or delete confirmation dialog. For any given meeting, the system removes any existing notification from the queue before entering a later notification. If notification for a particular meeting is sent to a user at the same time the user is viewing a previous notification for that meeting, the newer notification is not added to the queue until the user makes the accept, decline, or delay decision for the earlier notification. If the circumstance arises where a scheduler sends two or more notifications while a user continues to view a previous notification, the system maintains the policy that at most one change/delete notification appears in the queue for any given meeting. When the user ultimately acts on an earlier notification, the system adds the single most recent notification to the user's queue.

2.5.2.3. Changing and Deleting Tasks

Changing and deleting tasks is much the same as appointments. The task fields that differ from an appointment are:

  1. `Priority', which is numeric for a task

  2. `Completed' and `Completion Date', which are not present in appointments
Editing functionality for all other fields is the same as for appointments. Figure 176 shows the user having edited an instance of the recurring task shown in Figure 140.


Figure 176: Edits made to a recurring task.



Here the `Completed' check box has been turned on by the user. When the user turns `Completed' on, the system responds immediately by entering today's date in the `Completion Date' field. The user may edit the completion date to any legal, non-empty date value. The system imposes no range restrictions on the completion date, meaning a task can be completed any time before, on, or after its due date. In the case of Figure 176, the user changes the system-entered value of September 23 to September 21 and presses `Change'. If the user turns `Completed' off after having turned it on, the system clears and disables the `Completion Date' field.

The change and delete confirmation dialogs for tasks are the same as they are for appointments, with the word "appointment" replaced with "task". When a task change or delete is confirmed, the calendar and display affects are as described for appointments.

2.5.2.4. Changing and Deleting Events

As with the other types of item, change and delete of an event is executed in the item-level display. For example, Figure 177 shows the user having edited the event scheduled in Figure 141.


Figure 177: Birthday event changed.



The edits are a change of the start date from September 23 to September 25, and a change from private to public security. When the user presses `Change', the system displays the dialog in Figure 178.


Figure 178: Event change confirmation dialog.



The event delete confirmation dialog is the same as that for change, with the word "change" replaced with "delete". Since events do not recur, there is only a single form of change and delete confirmation dialog. There is no distinction between single-day versus multi-day events in either confirmation.

When the user confirms an event change or delete, the user's calendar and active display windows are updated accordingly. Change of a multi-day event affects all of its days. Deletion of a multi-day event deletes all of its days. The effect of deleting one or more days of a multi-day event is achieved by changing the start or end date values. The start and end dates of a multi- day event always represent a contiguous range of days. Hence, the system provides no means to delete one or more middle days of an event, between but not including a start or end date.

The user cannot change or delete the system-defined events presented in Section There is an option to hide these events if the user does not want to see them.




Prev: item-level-viewing | Next: recurring-details | Up: finer-points | Top: index