This section covers all data-entry and command usage details that may not have been fully elucidated in the preceding scenarios.

2.11.1. Date Formats

Include min/max values for year, which within reason are 0 and 3000.

2.11.2. Item Uniqueness Requirements

For appts and meetings, go get it from whereever. I think we need to do a refinement of what we have so far, in that we have to unbundle recurring instances in order to make the check, or at least "conceptually" unbundle them. There's a modelling issue lurking here, viz., whether to model recurring items as physically as single or multiple items. If we go with the single-item model, the logic like the last clause of the ScheduleAppt precond, q.v., needs to to be updated to deal properly with recurring items by somehow conceptually "generating" instances of recurring appts.

For events, I think it's gotta be name only, or name plus non-overlapping date. The deal is we need to be able to distinguish between a 3-day event versus 3 separate 1-day events, at least to some extent. It seems if we allow non-unique event names, then there's no way to distinguish multi-day from multiple consecutive 1-day events. I guess the same exact thing goes for an appointment.

A subtlety here is that changing the instance date of a single recurrig item to the same date as another instance violates the uniqeness rule. It's nice that the uniqueness rule covers this case in a general way, but I think it is worth mentioning. Way better redundant than sorry.

2.11.3. Scheduling Dialogs and Item-Level Displays

Ed. Note: I think it would be quite good to summarize these requirements in tabular form, with one table for each class of dialog, with one table row for each data-entry field in the dialog.

The following data entry formats apply to any scheduling dialog or item-level display where the indicated field appears:

1. The Title and Location fields are free-form, one-line strings. If the text is longer than will fit in the provided data-entry area, then it will automatically scroll as the user types and can be repositioned using the normal text movement arrow keys or such other forms of horizontal scrolling as may be available on a particular implementation platform.

2. The value of the Location field can be selected from the pulldown list of available locations, as shown in Figure 147.
   
   

   ---

   Figure 147: List of available locations.

   ---

   
   

3. The (Start) Date and End Date are type-in fields, with checking for legal date syntax. The following are legal forms of date entry: ...

Ref to two appropriate figures for meeting request and confirmation dialogs.

The precise data-entry rules for the fields that appear in both the scheduling request and confirmation dialogs are as follows:

• Title can be entered in either the request or confirmation dialog; it must be entered before confirmation.
• Duration must be entered in the request dialog, where the system- supplied default is 1 hour; it cannot be edited in the confirmation dialog.
• Recurring is optional in the request dialog, where the system-supplied default is non-recurring; it cannot be edited in the confirmation dialog.
• Category can be entered in either the request or confirmation dialog; the default is no category.
• Security can be entered in either the request or confirmation dialog; the default is public.
• Location can be entered in the request dialog; the default is empty, which is an allowable value. Location may be edited in the confirmation dialog; if edited there, the system validates that the newly entered location is available at the meeting date. If it is not available, the system signals the condition with an error dialog as discussed in Section 2.12. If the location of the confirmed meeting is empty, it is the presumed responsibility of the scheduler to inform attendees of the meeting location via some means external to the Calendar Tool system.
• Remind is optional in the request dialog, where the system-supplied setting is not to remind. It can be edited in the confirmation dialog and is optional there as well.
• Attendees must be entered in the request dialog and cannot be edited in the confirmation dialog.
• Details can be entered in either the request or confirmation dialog; it is optional in both. There is no system-supplied default.
• Minutes can be entered in either the request or confirmation dialog; it is optional in both. There is no system-supplied default.

The precise data-entry rules for fields that appear only in the scheduling request dialog are as follows:

• Earliest Possible Date must be entered; the system-supplied default is today's date.
• Latest Possible Date must be entered; the system-supplied default is two weeks from today's date
• Earliest Start Time must be entered; the system-supplied default is the value of the normal beginning-of-day time, the default for which is 8 AM.
• Latest Start Time must be entered; the system-supplied default is the value of the normal end-of-day time, the default for which is 5 PM, minus the default value for the duration, which is 1 hour; this means the default latest start time is 4 PM.
• Earliest End Date must be entered for a recurring meeting; there is no system-supplied default.
• Latest End Date must be entered for a recurring meeting; there is no system-supplied default.

The precise data-entry rules for fields that appear only in the confirmation dialog are as follows:

• Start Date and Start Time can edited only to one of the value pairs that appears in the possibles list.
• End Date can edited only to an earlier date that is not before the start date.
• Scheduled By cannot be edited.

If the user specifies a recurring event without checking any box in the additional recurring information, the event will be set by default to recur weekly, on the day of the week that is specified for the start date of the event. [Sketch: some other defaults are made clear by default display of selection box.]

Also explain what the standard defaults are for the settings of all dialog fields and note that these default settings can be changed in the by editing preferences.

2.11.4. Required Fields

The discussion in the next paragraph needs to be more precise in specifying for which types of item which fields are required. In working on the custom lists section, I've been thinking about adding a table that there with an added third column indicating if the field value is required or optional. If this table is added here, it should probably be ref'd from the custom lists section instead of appearing directly there. The only question is that this complete table (with all three columns) is more that is need either in the custom lists section or here, but seems like a good thing that should appear somewhere. Perhaps it belongs in another place. Anyway, we'll figure it out eventually, if we live that long.

When scheduling or changing an item, the following fields are required to be non-empty and properly formated: Title, (Start) Date, Start Time, and Duration. If one or more of these fields is missing when the user presses the `OK' or `Change' button, the system responds with the error dialog shown in Figure 148.

20aug01 note: need to update this section to include target selection in list displays as well as calendar displays.

The first five commands in the `View' menu apply to a user-selected target in the calendar display, or to a default target. To select a viewing target, the user clicks on a desired location somewhere in the current display window. The "current display window" is defined precisely as the display window most recently generated by the system or the window most recently made current by the user having clicked on it or selecting it in the `View Windows' menu. The following are the specific details for how a viewing target is selected in the current display window:

For the `View Item' command, an item is selected as follows:

1. In a day, week, or month view, the user selects a scheduled item by clicking anywhere on the time range or title of the item.

2. An item cannot be selected in a year view, since no times or titles are displayed there.

3. If no item is explicitly selected by the user, the default is the first item, if any, scheduled on today's date. If there is no such item, then the `View Item' command has no effect. (The exact system response to commands with no effect is described in Section 2.12.2 on error conditions.)

For the `View Day' command, a day is selected as follows:

1. In a table- or list-style week view, the user selects a day by clicking on any of the day names that label the table columns, or on any item in a desired day.

2. In a list-style week view, a month view, or a year view, the user selects a day by clicking on the numeric date of any day, or on any item in a desired day.

3. If the current display window is a day view, the `View Day' command has no effect.

4. If no day is explicitly selected by the user, the default is today's date.

For the `View Week' command, a week is selected as follows:

1. In a day view, the selected week is the one that contains the currently displayed day.

2. In a month or year view, the user selects a week by clicking on the numeric date of any day within the desired week, or on any item in a day within the desired week.

3. If the current display window is a table-style week view, the `View Week Table' command has no effect; if the current display window is a list- style week view, the `View Week Lists' command has no effect.

4. If no week is explicitly selected by the user, the default is the week containing today's date.

For the `View Month' command, a month is selected as follows:

1. In a day or week view, the selected month is the one that contains the currently displayed day or week.

2. In a year view, the user selects a month by clicking on the name of any month or on the date of any day within the month.

3. If the current display window is a month view, the `View Month' command has no effect.

4. If no month is explicitly selected by the user, the default is the month containing today's date.

1. In a day, week, or month view, the selected year is the one that contains the currently displayed day, week, or month.

2. If the current display window is a year view, the `View Year' command has no effect.

3. If no year is explicitly selected by the user, the default is the year containing today's date.

In all of the cases where a name or numeric date is selected, the system confirms the selection by highlighting the name or date in reverse video. For example, Figure 149 shows how the system highlights the date of September 1 when the user clicks on that date number in the monthly display.

The system provides a three-way option to control the scheduling of items with overlapping times. The option settings are the following:

1. disallow overlapping times entirely

2. allow overlapping times, with warning

3. allow overlapping times, no warning

Explain what happens when a user selects the `Edit ...' item in the `Add Category' dialog. Here's a sketch:

1. A typical dialog naming/add/delete dialog comes up.

2. There's also some form of generic color chooser, e.g., RGB.

3. Deletion is prohibited if there exists any scheduled item with a category that is colored with the color to be deleted.

Dont forget to explain emacs-style reg expr search for the name lists that appear in the admin dialogs.

2.11.10. Regular Expression Filtering Patterns

While the soltice and time-change events may not strictly be considered "holidays", they are none-the-less included in the `holiday' category.

2.11.13. Dialog State Details

This is the section where we define all of the horendously boring details of what intial and historical states the various dialogs assume. Hopefully we can batch bunches of them together under a single heading. Anyway, I think it's pretty clear that such details are necessary, and I think this is the best place to put them. The motivation for this section having come into existence was slogging through the details of the custom list dialog states, and thinking how boring it was to have all of those details piled up there.

2.11.13.1. Custom List Dialog

1. List Name text box: Initially, contains highlighted text "New List". There after, dialog remembers whatever name that was in the text box when the dialog window was most recently closed; in the case when the last defined list is deleted, the dialog reverts to the intial "New List" state.

2. Field check boxes: per Table 5

3. Start and end dates: initially the default, thereafter most-recently entered

4. Command buttons:
   Add enabled when any currently undefined list name appears in the list-name text box, including the system-supplied "New List" and an empty value.
   1. Change, Delete, and Apply enabled when any currently defined list name appears in list-name text box; Apply is also enabled when the user has done some editing to a not-yet-defined list that is yet to be confirmed with Add.

The following is a way-too-complex version of things, which might be useful at some point as a class/book example, but maybe is best just nuked.

Dialog state is simply that the

• Intially, `List Name' field contains "New List", highlighted.
• When Add is the most recently invoked dialog command, the most recently added list name appears in the List Name box, unhighlighted.
• When Change is the most recently invoked dialog command, the most recently changed list name appears in the List Name box, unhighlighted.
• When Apply is the most recently invoked dialog command, the most recently applied list name appears in the List Name box, unhighlighted.
• When Delete is the most recently invoked dialog command, the most recently added, changed or list name appears in the List Name box, unhighlighted.
• When Cancel is the most recently invoked dialog command of the first four, the most recently added list name appears in the List Name box, unhighlighted.
• Aborted here when noticed that things were getting way too complex.

A long text string is scrollable in the text box and truncated in the menu, based on how wide the menu otherwise is in the dialog.

This is originally from Section 2.3.3.6. and needs to be generalized here for all combo boxes:

When `specific date' is initially selected, the system clears the text box and the user types a specific date value into the text field. When `specific date' is subsequently selected, the system restores and highlights the most recently typed value. If any of the other menu entries is selected, typing is disabled in the text field.

Sketch: Form of default names is "New XXX", where XXX is the subject, e.g., "List", "Filter". Initially, we were going to say that "New XXX" form cannot be used to save a filter, but is only displayed as the high-lighted name when the user selects the `New' item in some name menu. Howerver, instead of this, I think we should say the following. "New XXX" is the initial default name. If the user uses it, so be it, becauuse "New XXX" will not appear again if and until all extant filters are deleted. Sweet.

2.11.16. Name Completion

Need to define precisely what "change" and "most recent" mean in terms of data field editing. It seems like we'll need to model this using time stamps for each meeting field. Here's an interesting scenario that we need to make sure is well understood and covered by our rules:

1. scheduler schedules

2. user changes non-critical field F

3. scheduler changes F, elects not to notify

4. scheduler changes some critical field, therefore notifies

Explain fully that the changes that go into all other instances are the current (visble) values in the instance being used to effect the change, even if those values were the result of a previous individual change. For example, a user may confirm several changes to a single recurrint instance, then selected `all instances' and

THE FOLLOWING IS NOW DONE IN THE RECURRING-DETAILS SECTION:
Explain how chaning start date, end date, or recurring information is an effective delete, including how if such a change is made through an instance that is effectively deleted, that instance dislay is removed from the screen.

2.11.20. Picky Details about Change/Delete Button Enabling

Things work like Emacs, not as hairy-assed as they could by coninuous diffing. Viz., as sonn as an edit is made, `Change' gets enabled and `Delete' disabled. If the edit is reversed by further editing, the system does not notice that there are effectively no changes, and hence leaves the buttons in the changes-made state. If the user proceeds with a confirmed change at this point, the system goes throught the motions, but the change has no effect on the data. This just like adding a char, deleteing it, then saving in Emacs -- the same data get saved back on the file.

I believe what this means from the formal perspective is that we dont want the precond on channge that says the two args must be different. If we do have this, then we either need to enforce it with diff-style change button enable/disable, or issue an error/warning when the change is confirmed. The latter seems pretty useless, given this seems to be a "no harm done" case if we let the nugatory change just happen.