Of note in Figure 91 is the "[2]" suffix in the `On' date field. The suffix indicates that this is the second meeting scheduled by estier on the same date. The suffix number is increased for each additional same-date meeting made by the same scheduler. The suffix ensures that the `Scheduled By' and `On' fields provide unique identification for the purposes of changing or deleting a meeting, as discussed in Section .

6.37. Possible fodder for meeting change/delete section rationale

[in the sched delete confirmation dialog] The user may edit any data fields accept `Scheduled By' or `On'. 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 cancelled meeting.

The following was improved by the policy of disabling scheduler-changed data fields in non-scheduler item-level displays with not-yet-accepted scheduler changes:

While it may be imprudent to do so, the user may continue to change his own copy of a scheduler-changed meeting, prior to accepting or declining the scheduler's changes. A particularly imprudent sequence of actions would be

1. changing a critical data field, without first viewing the scheduler's changes in the notification dialog
2. pressing `Accept' in the item-level display, again without viewing the notification dialog

Since the system retains the most recently changed data values, this action sequence could override scheduler changes that the user never sees. And blah, blah, blah about a bit of the rationale behind this.

The following was way too simple an explanation for what it was aimed at:

Explain that for the accepting user, accepting the notified changes has exactly the same effect as if the user had made the changes herself to her own calendar.

The following turned out to be wrong, since we show scheduler changes and deletions in penciled-in form on users calendars:

Explain how attendee display screens are updated. Viz., changes don't happen until acceptance of change/delete notification.

The following turned out to be too complicated, since we went the most-recent change route for merging scheduler changes:

Deal with the issue of what happens when the user has changed one or more data fields when the notification arrives. It probably needs to be some kind of diff3 deal.

Any critical meeting change made by the scheduler must be reported to all attendees. As discussed in the next two sections, individual users may decline to receive notifications or change their own copies of meeting announcements. The policy upheld by the Calendar Tool is that the scheduler's version of a meeting is considered to be the definitively correct version. Attendees are always notified of scheduler changes, which they may deal with as they see fit.

Change restrictions are imposed on a meeting scheduler because the scheduler is considered the responsible party for the meeting and it has to make sense there, ... or something like that.

An individual user can change any fields of a group meeting (except `Scheduled By' and `On'), since the user owns the item. The user can even do stupid things like change or remove attendees, or other changes that may not make good sense. It's up to the user. Any such changes are reflected only in the individual user's copy of the item. The official record of the meeting is the one that appears in the user calendar of the user who scheduled the meeting.

Or maybe it's a bit more sensible to allow only some of the fields to be changed, viz.: category and reminder. Changing any of the other fields is arguably non-sensible.

OK, here's the deal. If for some reason, the scheduler cannot or does not want to use the Calendar Tool to notify attendees of a meeting change, then it does in fact make sense to allow individuals to change all fields. The following warning dialog probably makes good sense to make things all nice and happy:

 Changing any of the following fields makes your version
of this meeting inconsistent with the scheduler's version:

           (Start) Date, End Date, Start Time,
          Duration, Recurring, Location, Minutes

Or maybe we don't want the scheduler to have to be the attendees' nanny. I.e., we don't care if an attendee deletes a meeting. Attendees are assumed to be grown ups that can come to a meeting or not. If an attendee wants to inform the scheduler that s/he can't make it, then the attendee can do it through some means of communication outside of the Calendar Tool. I'm leaning towards this, just to keep things from getting out of hand notificationwise. I.e., not having attendee cancellation notifications go to the scheduler will make things less cluttered.

Do these examples:

...
1. Delete the tenure review meeting; show how the details field can be used to send a message to the attendees, even though it will be deleted upon acceptance of the notification -- THIS CANT HAPPEN because you cant edit then delete. ... all other examples were dealt with properly

Basically, the same rules should apply as for individual meetings (see Section 2.5.2), but with the wider-ranging consequences of having to notify all participants.

The dialog for changing or deleting a recurring works a la Claris. When a leader changes or deletes a group meeting that she scheduled, a dialog of the form shown in Figure 327 appears.

You are the scheduler of this meeting.  Do you want all attendees to be
notified of the change?

We (?may/probably?) also want to allow for someone other than the original scheduler to cancel a meeting, which seems most sensibly restricted to leaders of the at least one of the groups for which the meeting was scheduled. While this may weaken the cancellation security a bit, it's probably the easiest and most sensible way to do it, without getting involved with some big complicated deal like what precentage of attendees you must have control over in order to cancel a meeting. The issues we need to deal with in this regard are the following:

1. Should people other than the scheduler be able to cancel a meeting at all? Pros are convenience, cons are security and complication of who to allow.
2. If we allow non-schedulers to

Somewhere in here, talk about changing minutes locations for recurring meetings. A reasonable scenario is edit each individual meeting record with the specific file in which minutes are held. At the exact moment of this writing, I'm still thinking about whether to allow directories for minutes of recurring meetings. If this subsequently gets figured out, then we'll deal with it here accordingly.

6.38. Possible fodder from appt changing section

As the dialog explains, the user is being asked to select how many of the recurring instances to change. If the user selects `This one', then only the single instance shown in the item-level display is changed. All other instances remain unchanged. If the user selects `All', the system changes each and every recurring instance per the edits made in the item display. If the user selects `Future', the system changes the displayed instance and all future instances. If the user selects `Cancel', no changes are performed. For any selection, the system removes the confirmation dialog from the screen. For any selection except `Cancel', the system changes the button state to the initial configuration. For `Cancel', the button state remains unchanged.

In this scenario, the user selects `This One' in the confirmation dialog, whereupon the system proceeds with the single-item change and all necessary view updates.

6.39. (Weakly) Possible fodder from meeting item viewing

Depending on the user who is viewing the meeting, different data fields are editable. Specifically, the scheduler of a meeting may edit all data fields except `Scheduled By'. User's who are not the scheduler may edit some of the data fields. Figure 137 shows the case where a non-scheduler is viewing the meeting, with the non- editable fields disabled (the edit fields have grey borders). Further details on editing scheduled meetings are covered in Section 2.5.2. Selecting a recurring item for viewing is the same as a non-recurring item. Namely, the user selects the desired instance in the current display window then excutes `View Item'. For example, Figure 328 shows the user having selected the October 1 meeting instance in a month-level display.

6.40. Possible fodder from task item viewing

Make note also of the fact that task titles are integer-enumerated in day and week views, not so enumerated in month views or lists. This is a Clarisism that we may want to reconsider. (Update: nope, we aint' reconsidering it at this late date, having drawn all of the task view pictures this way.)

6.41. Possible fodder in the area of external file viewing

The following was nuked from the meeting scheduling requirements:

The `Browse ...' button next to the `Minutes' text field leads to a file browser, of the form described in Section 2.8.2 The browser is used to select the name of a file or directory that will hold the minutes. If the minutes are to be located in a URL, the scheduler can browse for the location in terms of a file name, and then type the additional URL prefix in the text field. Alternatively, the scheduler can type the entire file name or URL without using the browser. The minutes field is optional and may therefore be left blank.

The following was nuked from the item-level meeting viewing section:

The figure shows the default form of minutes display in plain text form. As an option, the Calendar Tool system administrator can select an extern program for viewing minutes, such as a web browser. Selection of such an external viewing program is explained in Section .

It is entirely the responsiblility of the scheduler to name the files in such a way that users can discern which minutes file applies to a particular meeting occurance.

6.42. 2aug01 -- Nixing the notificaiton enabling stuff (then not)

But "oh contrair" to what follows. Per latest version of meeting scheduling stuff, users can in fact decline all forms of notification. Rationale needs to be written accordingly.

OK, I think I'm ready to forget about the whole user-enabling of meeting notifications, and simplify it to these rules:

1. only leaders can schedule meetings for groups
2. anyone can schedule meetings for individuals

The deal about only group leaders being able to schedule for a group seems pretty sensible to me at this point. The deal is that if someone wants to be authorized to schedule for a group, it's easy enough to be added to the leader list for that group.

The bottom line is that it's pretty much like email, in that anyone can send to anyone else. There's a bit more in favor of receivers in that only group leaders can define aliases to send to. There's a bit less in favor of receivers in that "penciling in" can be done, which is a bit more "personal" than just dropping something in a mail box. However, it really just looks that way, in that it's not really writing on another user's file. After some usage, we may want to allow users to have an option to disallow penciling in. OK, I think I just talked myself into providing the option to at least toggle penciling in on or off.

The following verbiage was nuked because of this nix:

Meetings scheduled by group leaders have an official status that meetings scheduled by non-leaders do not have. Specifically, the following apply to leader-scheduled meetings:

1. notification is sent to all attendees
2. the meeting is added to the group calendars of which the scheduler is a leader
3. the leader may make changes or cancel the meeting for all attendees
4. when an individual attendee deletes a leader-scheduled meeting, the leader is notified

Further details of these matters are covered in upcoming scenarios.

Sketch: The scheduler wants to schedule a one-time meeting among some Cal Tool users. There is no user group defined for the attendees and the scheduler does not have notification priveleges for any of them. Hence what the Calendar Tool can do is find some meeting times, and the scheduler can notify the attendees externally. So, the scheduler tries a narrowish range of possible times and comes up empty. The scheduler then widens the times, finds some, and makes a choice.

When scheduler is unauthorized to schedule a meeting for one or more attendees, the system displays a dialog of the following form (this should most likely go in error conditions section):

The following attendees will not automatically be sent meeting requests because
you are not authorized to schedule a meeting for them: ...

A scheduler is authorized to send (via the Calendar Tool) to user X if either of the following is true:

1. she is a leader of a group of which user X is a member
2. she is listed by user X as one of the individual users from whom meeting requests are accepted (see Section ).

Explain that the Caltool requires one of these forms of authorization to avoid (in)advertant spewage of mail by unauthorized Cal Tool users. Furthermore, the receiving users will have explicitly authorized the the Cal Tool to send them msgs when they either accept group membership or set their options to allow meeting announcements from selected Cal Tool users. This user acceptance is an important piece of non-spam business.

The meeting scheduling auto-notification rule is the following: a Cal Tool user must take some explicit action in order for the Cal Tool to send a meeting notification. That explicit action is one of the following: accepting membership in a group; setting an option that authorizes a particular Cal Tool user to schedule meetings for the granting user. The point is to strike a balance between the following: (1) want to give users control over from whom they accept meeting notifications; (2) want to allow non-leaders to be able to schedule occasional meetings based on users calendars.

Users can elect not to receive email notification but not cal tool notification. The only way not to receive cal tool meeting notification for a group is to be removed from that group. The way not to receive meetings scheduled by non-leaders is not to set the option the default for which is off.

Here's a bit of overly complicated spec for the possible meetings time list that may be of some historical interest:

The items are sorted in the three separate sections:

1. possible times that all attendees can make
2. possible times that overlap with optional items for one or more attendees, but not with any must items
3. possible times that overlap with must items for one or more attendees, and possibly with optional items for some attendees

The following notes were removed from meeting-scheduling; there may be some useful rationale fodder in them.

6jul01 IMPORTANT NOTE: An important realization that I'm coming to is that the idea of allowing group leaders to physically "pencil in" is probably a major invitation for security breaches and implementation problems, which means I'm inclined at this point to say that there's always a dialog that pops up during or at the initial lanuch of the tool that asks the user to accept or reject a scheduled meeting. In this way, group leaders, including the maximal leader, can never directly write on any user's calendar.

Thots:

1. Lose the columns in the Attendees list in Fig 12 and the check boxes at the bottom of Fig 13. In Fig 12, the `Attendance Required' flag is not needed fro reason described below. The `Not Registered' flag can be figured out by the system and a dialog of the form "The following are registered users of the Calendar System, do you want to include them in the attendees list anyway?" Of the check boxes at the bottom of 13, the first goes in the new "Adj Parms" dialog described below and the second check box is gone, for reasons described below.
2. Add an "Adjust Parameters" button at the bottom of the dialog.
3. Don't think the "Attendance Required" flag really helps, given the new way we'll display the possibles list.
4. OK, here's the new I think pretty darn cool way to display the possbles list: All times where all can meet, followed by all times all but one can meet, etc. This gives a good set of information and I think obviates the need for attendance required since we can double click to see who cant come. Plus in the scheme of things at a practical level, I dont think it really helps any, since if we dont care about someone, then why bother to include them in the first place, plus, again, we'll now be about to see them in the list of people who cant make it.
5. In current Fig 13, lose choice for screen alert -- it's mandatory. Per recent addtions to user options, the user can control when she sees alert -- at starup, exit, during use. Also, recent thinking is that group leaders are the only ones for whom Cal Tool notification will be sent of scheduled meetings. This will prevent (in)advertent scheduling of meetings by peons. As far as scheduling for individuals goes, this is controlled by the users's settings of from who to accept announcements.

This was wacked from the task-scheduling section:

17dec00: I think we want to include a due time for tasks. Don't think we need durations. The motivation is for reminding, including being reminded in a smaller granularity that a whole day. The time can be left blank, in which case it defaults to the currently set value for the end of the normal day range setting. (I think the last bit is pretty cool and sensible, actually.) 10jul01 update: As cute as the last bit is, it goes because tasks without a time are considered to have times latter that all those with times, per latest details of list sorting. Keep it simple, dickhead.

Here's the basic story we want to tell:

1. Show the reader how some basic scheduling happens, using an appt as a representative example item.
2. Then, without getting into all the details of scheduling just yet, show how the user views calendars.
3. Then return to finish up the details of scheduling.
4. Wrap up viewing and scheduling finer points, particularly changing and deleting, which is a combination of viewing and scheduling functionality.
5. Do the admin and options commands.
6. In terms of menu commands do file, edit, and help last, since they are the most mundane.
7. Follow the scenarios with the real nitty gritty details of data entry, error handling, and GUI requirements.

Some frank and 100% truthful discussion goes here.

6.48. Filter Dialog Layout

Pretty darn complex. Thot about trying shortest/longest pair, but decided on current form because (a) it can be shared with task priorty; (b) expression is nice and general and with the popular advent of search engine query exprs, the concept of a search expression is not entirely foreign to what might be considered typical users.

At this point, I'm not 100% clear on the relative expressive power of various forms of GUI versus text expr, and I don't think I want to be. E.g., what are the ease-of-use versus power trade offs in a smalles/largest numeric par GUI versus a bool expr text box? I thought about it plenty and am happy with the result.

Specific actual issues in this case are:

1. Most of it won't be used much by typical users.
2. Since I'm designing it for me, and I'm happy, we've achieved the goal of customer satisfaction.

See (and discuss here or elsewhere).

In an earlier version of the requirements, the following statement was made in Section 2.3.2.1 regarding the behavior of the next and previous arrow buttons vis a vis the behavior of the `Next' and `Previous' menu items:

"... Pressing one of these arrows has the same effect as the corresponding menu command, with one exception. The exception is that the setting of multi-window mode is ignored when the arrow keys are used. That is, pressing an arrow key always changes the display in the window to which it is attached, and never displays a new window."

"Mouse-steady" traversal could be achieved in multi-window mode by having the windows stack up directly on top of each other, but this should be rejected as too easy a way to have invisible windows pile up on the screen.

In the end, we figured that it is easy enough for the user simply to turn off multi-window mode to get the ergonomically desirable behavior. In general, the presumption is that multi-window mode will be off far more often than it is on anyway, with users turning it on temporarily to set up a particular form of side-by-side display, and then turning it off. Hence, the disadvantage of non- uniform behavior is greater than an ergonomic inconvenience that can easily be avoided by changing an option setting.

6.51. Precise Behavior of Next and Previous at the Item Level

The exact behavior of `Next' and `Previous' can be specified in a number of ways. Two different behaviors were considered in these requirements. The behaviors can be characterized as an all-item traversal versus a type-specific traversal. In the all-item style, `Next' and `Previous' traverse through a list of all scheduled items of all types. For example, consider a schedule consisting of the following three items: a 4PM Monday appointment, a 9AM Tuesday meeting, and a 10AM Tuesday appointment. Consider also that the current display is the 10AM Tuesday appointment. In the all-item style of traversal, pressing `Previous' changes the display to the 9AM Tuesday meeting. In the type-specific style, pressing `Previous' changes the display to the 4PM Monday appointment.

As explained in Section 2.3.2.1, the all-items style was chosen. The rationale for doing so based on the following considerations:

1. the effect of the item-specific style can be exactly achieved using filtering; e.g., to traverse only through appointments, the user filters out the other item types
2. with multi-window mode off, the all-item style does cause the size of the item- level window to change when traversing to an item of a different type, which could be distracting to the user; however, this was deemed to be an acceptable distraction, given the more important ability to traverse easily among all items, plus the aforementioned fact that item-specific traversal can be achieved via filtering

The would-be rationale for choosing the item-specific style was based on the following considerations:

1. the all-item style traversal would cause the size of the display window to change when traversing between different types of item; this could be distracting
2. while the all-item traversal has the advantage of allowing the user conveniently to traverse among different types of item, the same effect can be achieved in multi-window mode as follows:
   1. the user turns on multi-window mode
   2. she selects to view an appointment item
   3. she selects to view a meeting item
   4. she uses `Next' and `Previous' in the two different windows

The time range; times not in the range will not appear at all until the option value is reset; I'm considering a quick command to toggle between full and reduced display, but maybe it's really just as easy to change the option. This is really a minor ergo matter, but worth considering for its perhaps general applicability. To whit, the reason that a separate toggle-full-partial view command is useful in addition to changing an option setting is that it's typically not that easy to change back to a previous option setting, even with general undo/redo. I.e., the user would go to the options, find the option for how man hours to display in the daily view, change that to 'show full', with presumably a quick way to select 'full', then go back to the daily display. But then if the user wants to change back to the restricted range that was the previous option setting, there seems to be no quick way to do this based on general commands such as undo. We might want to postulate some general way to do this, but it seems rather esoteric and a case where we're trying to get a bit too scientific in the UI design for our own good.

We should consider allowing time range to be changed for a single appt, affecting only a single display, as well as for the full calendar, affecting all daily displays.

What fields of the scheduling details are displayed; depending on how carried away we get here, we could lapse into UI building, which I do NOT want to get into in this version of the system. OK, let's not get carried away at all; here's the deal. The only options the user has for display is (i) whether or not the actual time is shown along with the title, (ii) whether or not duration arrows are shown, and (iii) whether or not dashed lines are shown. The precise position of the dashed line is up to the system. A funky thing that can happen is for a really short event, the text height of the event title may be physically taller (in terms of time displacement) than the duration of the event. In order to keep this from happening, the system will automatically adjust the height of the daily display based on the granularity of the time division option set by the user. Specifically: (i) the display always shows one hour granularity of labels; (ii) the height of each hour is equal to one text-line -- NO this sucks -- there should either be no setting of time division at all by the end user (i.e., get rid of the option), or the option setting should only be used to prevent a meeting from being scheduled of a particular duration, but in any case, the time division option should not affect the height of the display. Rather, if a user schedules a bunch of really short meetings within one hour, then some little micro scroll bars should show up in the individual hour that is affected and/or the hour should grow to a different size wrt to the other hours in the day and then if necessary the whole day can be scrolled down to see other hours. YES -- I like the last of these ideas. Viz., that the height of an hour within a day will grow if necessary to show all non-overlapping appts that start (and end, except may for the last), within that hour. The default height for an hour should be two lines, based on the height of the current font. One last thing about the duration arrow -- it won't be drawn if there's not enough vertical room based on the height of an arrow head and some reasonable default for the minimum size of the line tail of the arrow.

6.53. Start/End versus Start/Duration, Revisited

Below it says we've gone start/end time, but I'm leaning towards going back to start time/duration, given that it makes more sense overall. The specific reasons now are: (1) we liked it better in the first place, and I think there was a good reason for this that I've forgotten; (2) the late-night appointment thing is infrequent, but important enough; (3) the major conceptual problem of distinguishing multi-day recurring from multi-day single I'm pretty sure will be a non-issue when we think it through.

OK, here's the gist of what we've been worried about recently. There's a consistency problem with tasks vis a vis other items when it comes to the due date, particularly with a recurring task. Viz., if there's a fixed due date for a recurring task, what does this mean the due dates are for the tasks that recur. Though I've not looked into it perhaps to the total depth necessary, it appears that both Claris and dtcm have problems here. It's particularly noteworthy in Claris, where in the Task creation dialog, 'Due Date' changes to sense at all.

A related problem is in the creation of the generic ScheduledItem object. Yes, we know of course that inheritance should not drive requirements, but the other way around. That said, there seems to be a good reason for inheritance in the modeling sense, since we would like to use the notion of a generic scheduled item in sorting, and probably other cases. What's useful about generics in these cases is that we can refer to common fields shared by all of the objects. Anyway, if we go for tasks having due dates instead of (start) dates, the structure of the generic scheduled item starts to break down. What happens is we can change the StartDate component to just "Date", but this then lacks modeling power, since the generic "Date" field is in fact interpreted as "Start Date" or "Due Date" in specializations. An alternative is to name the type of the generic field StartOrDueDate, but feels like it's getting pretty hokey.

The serendipitous solution to this mini-mess appears to be the consistent use of duration in all items. In appointments and meetings, it has the obvious meaning, and the UI provides hours and minutes to enter its value. In tasks, the meaning of duration seems pretty clear as well, plus the definition of "due date" is the sum of start date plus duration. This seems to be quite sensible indeed, and the only small drawback is that the words "due date" don't appear explicitly in the task scheduling dialog. However, we may well use the term "due date" in other UI windows, such as some form of task list. (Though such a list may not happen in version 1, for the sake of simplicity.) Also, the UI for duration of tasks and events can include a days entry box (and maybe nix the minutes box), since tasks and events typically span days, whereas appointments and meetings do not. So, the conclusion here is using duration instead of end time seems to work very well overall, and serendipitously allows the ScheduledItem object to be nicely defined.

6.54. Start/End versus Start/Duration (Older Ideas)

We've gone to start/end, since it appears to be the method used in other calendar systems. The reason is probably because of the underlying conceptual problem with start/duration with respect to scheduled items that span a single day. In one sense, it would be nice not to restrict an item to be within one day, particularly for night people who do regularly do things around midnight. Evidently, since there aren't a lot of people like this, calendaring systems don't care that scheduling a meeting to start at 11PM and last to 1AM the next day is a problem.

However, the deep conceptual problem is distinguishing between a multi-day recurring event from a multi-day single event. We need to think about this. And I'm not just falling off here -- I really haven't thought it out fully nor do I want to right now.

6.55. Big Issue about Factoring Options

Well, we've never fully come to terms to what exactly an option is and how it should be represented in a UI. This issue comes a bit more into focus when we consider whether UI access to options should be distributed across command menus and individual dialogs and/or centralized in an "centralized" `options' menu. There's more to say and think about here.

27jul02 update: cWell wonder of wonders, I do believe we have come to a firm and quite satisfactory decision here.

6.56. Old Remarks from the List Viewing Section

OK, what we need to do is make sense of applying filters to both calendar and list views. I think this can be perfectly sensible, in fact. A potential oddity is filtering a calendar view by date range, since this type of filter seems to make more sense for lists, where it's a way to shorten the lists. However, upon a bit of reflection, a date-filtered calendar view is probably just fine if it means that filtered-out items simply don't show up in whatever calendar views are showing -- which come to think of it is just the normal meaning of filtering (duh). So, for example, if we filter out all but a particular range of dates within a month, in the month view the filtered-out dates are simply displayed as blank. This sounds just fine to me. In the scenario, we'll go through all the other forms of filtering and ensure there sensibleness in both calendar and list views. Cool.

6.57. Filtering Issues

This is potentially a rather complex area. In the style of dialog chosen, one of the key alternatives is whether the "Apply filtering to" choices are one-of radio buttons or multi-select check boxes. At first, the Emacs user in me wanted to make them check boxes, but this is really overly complex and potentially confusing to the user. Hence, for simplicity sake we changed to one-of radio buttons.

The trade-off here is a pretty straightforward of power versus simplicity. The even more specific pro/con is that with check boxes, it's easy to define the same filtering for two or more types of item, whereas with radio buttons the user must repeat the defs for each type. However, the complexity of how consistently to define what selecting one after two have been selected means is high, and any convenience gain is outweighed by the complexity. Plus if we analyze things in terms of how frequently one is likely to do this, the decision was to keep it simple. The future work section discusses the broader issue of much more powerful filtering capabilities.

Here's something that was item under the heading "sketch of ideas" in the filtering section; it may or may not be useful here:

I don't think the named filter menu is a good style of UI, primarily from a convenience standpoint. The main issue is that it requires the user first to define a filter before using it at all, when naming and storing a filter is likely to be secondary for most users. Rather, the primary thing they want to do is define a quick filter, and then after they've used it, save it if it appears to be particularly useful. So, what we need is a filtering dialog that's very simple at the top-level, and allows more advance form of filtering as a second-level option.

1. UNHOT FLASH: Let's leave the "Which dates" option at the monthly level. Then yearly will be simply a boolean, with no yearly calendar displayed. Even though yearly could be specified using monthly, we'll leave it as a convenience for the user, i.e., a quick way to do a yearly thing.
2. HOT FLASH: Let's nix the "Which dates" option at the monthly level. It's redundant with the yearly level. This leaves us with the monthly level allowing the user to specify recurrence using the "nth week in the month" form, and the yearly level allowing the user to specify recurrence using the "list of dates" form. I think this works out well.
3. NOT Deprecated: Days of week versus dates selections are mutually exclusive. In terms of GUI rendering, if anything is selected in the days display, the date display is disabled (physically greyed out). If anything is typed in the date edit box, the days display is disabled.
4. Details of potential conflict between specifying some or all of 4th, 5th, and last weeks need to be clearly specified. To whit, for months with 4 weeks only, the specifications for the 5th week do not apply, and the specification for the last week, if present, override any specification for the 4th week, if present. For months with 5 weeks, the specification for the last week, if present, override any specification for the 5th week.

Per the latest thinking, there are no yearly interval details. The yearly interval is simply an on/off setting indicating that an item recurs once every year on the same date.

6.59. Maximum Date Range

Some interesting variations happen here in different systems. Claris just plain blows it. Emacs specifies that 0 is the min, and has a very large max, but blows it at some point (I've not experimented exactly where) due to int overflow error.

Yahoo calendar does not provide a 'Goto Date' of any form, so it is limited to whatever is predefined. Netscape quits at 1990 and 2037, not exactly sure why. I've yet to investigate what outlook does.

It might be argued that as long as the tool doesn't blow up, it shouldn't really matter how it behaves "on the fringe". However, I would argue that a quality tool should never output "bizarre" results, even when the results don't really matter.

6.60. Lists

28dec00 Ed. Note: I'm leaning towards losing the 'Format ...' item at the bottom. The rationale is that we can allow the user to control which columns are visible in an custom view, but don't need to for the fixed views. The problem with allowing it for the fixed views is that it'll be redundant with what you can do in the custom views, and probably confusing. There may not be a perfect solution here, so we should just get on with it.

6.61. Canonical Modeling Form

Interestingly, it looks as if the cannonical simple-print form may (or could have) shed some good light on the canonical modelling form, with respect in particular to how to model recurring instances.