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:
Figure 147: List of available locations.
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:
The precise data-entry rules for fields that appear only in the scheduling request dialog are as follows:
The precise data-entry rules for fields that appear only in the confirmation dialog are as follows:
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
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.
-- To appear. --
Figure 148: Required fields error dialog.
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:
For the `View Day' command, a day is selected as follows:
For the `View Week' command, a week is selected as follows:
For the `View Month' command, a month is selected as follows:
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.
Figure 149: Reverse video selection highlighting.
The system provides a three-way option to control the scheduling of items with overlapping times. The option settings are the following:
Explain what happens when a user selects the `Edit ...'
item in the `Add Category' dialog. Here's a sketch:
2.11.9. String and Pattern Matching Rules
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
2.11.11. Boolean Expression Filtering Patterns
2.11.12. System-Defined Events
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.
Dialog state rules:
126.96.36.199. Custom List Dialog
Dialog state rules:
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
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
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.
2.11.15. Default Names
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
2.11.17. Meeting Minutes
2.11.18. Merging Scheduler Changes
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:
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.