NOTE: There needs to be a place for privileged admin-specific options, in particular these:

• default size limit for user calendars; int text field with empty default, meaning no limit
• defaults for db dialogs, using the same style as the defaults for scheduling dialogs
• Time to Complete Meeting Scheduling While Others Are Waiting: int minutes (default 2)
• possibly other stuff in the privileged admin menu

The options dialog that runs under Calendar Tool Administration has the same overall format as for regular users, except that the buttons along the bottom of the dialog are limited to, Save, Clear, and Cancel. There separate dialog `Save' and there is no `Apply' button. Since there are no calendar viewing commands in the Calendar Tool Administration program, setting options does not apply to a calendar being viewed, but to the initial default values for those options for Calendar Tool users, as stored in the Options file.

NOTE: This paragraph needs to be fixed per the latest and greatest options set up. The default option values set by the administrator are available to users in two ways. When running the Calendar Tool, the user can select the `Defaults' button in the `Options' dialog. This allows the user to set options to the default values set by an administrator, as described above.

The other way that administrator-set options values are made available to regular users is through a Calendar Tool program distribution created by the administrator. That is, when an administrator creates a program distribution using the `Admin Distribution' command, the option values that have been set by the administrator are installed in the distribution program as the defaults for that program.

Here's the deal for "inheritance" of options:

1. First global options are set.
2. Then user-specific options are set, possibly overriding admin options.
3. Finally, calendar-specific options are set, possibly overriding either of the previous levels.

Explain how the first three kind of options are ?all? settable by user and are therefore explained in the next section. The difference between what the admin does versus what a regular user does is that under `Admin->Global Options', the admin is setting the global defaults for all users, some or all of which may be changed by users on an individual basis. I think it's also worth mentioning that an admin can be a regular user if she wants to be. I.e., there need not be a special user account that is "the" admin; there can be if that's how a group of users wants to set things up, but there need not be. If an admin wants to be are regular user, she needs to be aware that functions performed under the `Admin' menu have potentially global effects, and must exercise according care in the execution of the functions.

The Admin options are viewable by regular users but settable only by system admins, so they're described here in this section of the requirements.

.sh 4 "Administrative Options"

.sh 5 "Root System Administrator"

.sh 5 "Group Leader Privileges"

A bit of rationale: Since we're nixing pencil in, there was a bit of thought just now that group leaders may not be all that necessary. However, there are other useful reasons to have them. Also, I think it's reasonable to say that group leaders are the only ones who can schedule meetings for which online notification will be sent by the tool. So in effect what we've done is demote pencil power in to notify power.

With that bit of rationale, here are the group leader privileges as we currently see them:

1. Meeting notifications sent to attendees.
2. 3jul02 NOTE: The following option is obsolete, given the details described in the latest changing-and-deleting section, in particular the fact that a leader cancels a meeting without deleting it by using the change operation instead of delete.
   Cancellation notice sent when group leader deletes a meeting; deleted for non- recurring, marked as CANCELED for recurring (maybe, or probably better just to nuke it or maybe make this an option).
3. Can add and remove members for group.

4aug03 Update to the 17jul03 update: We've now got it all figured out, with the new setup for the user record with ID and password, and the way host connection now happens.

17jul03 Update: I don't think the following issue has been adequately addressed yet. To whit, there needs to be some way for a user on a local machine to be validated as a legitimate (registered) user on a Calendar Tool central host. The, I think, so-far unspecified way I've had in mind for this to happen is that the system performs the validation by matching the value specified in the `Computer User ID' field of the Calendar Tool user record with the value of the value of the `Calendar Tool ID'. The problem with this is that if the user is coming from some kind of local computer without a user ID, or that's not passworded, or has some funky convention for user ID names, then this might not work. There's also the issue of security when accessing the central host. With the local-id-matches-caltool-id scheme, there's only the security access at the local machine, which may be considered weak.

In thinking about this, I think there's also a problem with the whole idea of listing the IDs of the local host computers in the caltool user record, particular in the case of access from a machine with a non-static IP address. As I recall, the reason for this is to allow the central host to send notifications to particular users on particular machines, whether or not the cal tool is running on those machines. The idea that this is nice stems, it seems, from Claris' ability to pop up a reminder even if Organizer is not running. However, I think there's a significant difference between this and the ability of a central host to send a meeting notification to some other machine altogether. In the Claris reminder case, it can be implemented with an entirely local "at" daemon of some kind, or the Windoze equivalent. In case of the remote meeting notification, the communication has to go across the wire to some known network address via a PUSH.

So, first off, I now have a significant question about whether the "any time" option is really viable for meeting (and other) central-host-generated options. In order for this to work, either the central host needs to have IP addresses to send to, with a daemon running on the other end, or when a local machine starts up, or when a particular local user logs in, the local machine has to fire up a daemon the communicates with a central host, including performing the user validation that we mentioned above, in order to be able to receive notifications without the cal tool running. On a multi-user machine, this could be a huge problem. Given this, I'm thinking that it's reasonable to say that notifications can only happen when the cal tool is running and when a user is explicitly connected to one or more hosts. So, in order to check if a meeting has been scheduled, one must explicitly connect to the host from which the meeting originates.

So, I'm thinking we need to have a new, and if we're lucky, simpler scheme where the user must provide an ID and password when connecting to any particular central host.

4aug03: And so it is.

4aug03 reply to 26jul03 consideration in the next paragraph: NOT. We require connect with a particular calendar, period. If this is inconvenient for people who want to "just browse", tough shit. Bottom line -- a calendar is a necessary part of the entry ticket to a central host, along with, of course, a registered ID.

26jul03: consider allowing central host connection without a calendar, which means user can look around at other people's stuff but not receive any updates. Hence, all of the places where we say that the user must be connected, we mean "must be connected with a particular calendar".

When the user executes the `Connect' command in the `File' menu, the system displays the dialog 342.

OLD:
      Central Host Computer ID: host name, with admin-settable default

                        Status: connected/disconnected


               Connect    Disconnect    Clear    Cancel

To connect or disconnect to a host, the user selects the desired row in the list and presses `Connect' or `Disconnect'. When the designated file for a particular host is opened, the system attempts to establish a connection with the central host for that file; when the file is closed, the system disconnects. (See multi-user-envir for more info.) A host must have a designated calendar, i.e., the `Calendar' column cannot be empty and must contain the name of a valid readable/writable calendar file. A calendar can be associated with two or more hosts, but at most one of them can be connected at any given time. If the user tries to connect to a host with an associated calendar that is currently connected to another host, the system displays the dialog in Figure XXX.

Figure 343 shows the user ... . When the user presses connect, the system ... .

If the user has specified a default user ID and password in the options (see Admin Options section), then those are the ones sent to all hosts, i.e., they show up as the default type-ins in the connect confirmation dialog. This means it's nice etiquette in a particular multi-host environment to use the same user IDs on hosts where it's reasonable to expect that the same user will be connecting.

The specific rules for calendar/host association are the following:

1. a calendar may be associated with zero or more hosts, at most one of which can be connected at any given time;
2. each host in the connection table must be associated with exactly one calendar (which per the preceding rule may a calendar that is associated with other hosts)

Here's exactly what happens when the user connects:

1. local cal copied to and replaces host cal, except for pending meetings scheduled since last connection (call these "new pendings")
2. new pendings are added to local cal (and remain in central host cal)
3. all notifications queued on host are processed, per Section . I.e., if user accepts notifications (whenever connected or at initial connection), then the notifications are all displayed.

To add a new host, press `Add' to which the system responds by bringing up and add dialog, which if confirmed adds the new host in its lexically sorted position in the list. To change, select item and press `Change' to which the system responds by bringing up a change dialog, which if confirmed makes the change, including resorting if necessary. [The following in-line-editing of change doesn't work because it'd be hard to tell if select meant place edit bar or select for delete: To change, edit a row and press `Change' (the all host and cal columns of all extant rows are always editable).] To delete, select a row and press `Delete', in response to which system brings up delete confirmation dialog. Both add and change enforce unique-host constraint.

OLDER: When the user presses `Connect', the system verifies that the selected host computer is operational, has an active Calendar Tool server running, and that the user is registered with the Calendar Tool on that host. If the verification is successful, the system establishes communication with the chosen host and sends the user's community calendar file there.

The `Central Host' dialog looks like Figure 343. -- NO, it's been updated here.

The central host ID is read-only to a regular user. The ID is set automatically when an administrator updates the user database or changes the central host. Specifically:

1. when a user record is added or changed, the central host for that user is set to that listed in the user's record
2. when a user record is deleted, the central host for that user is set to empty
3. when an administrator changes the central host ID, the central host for all users is set to the newly changed ID

OLD: As noted in the introduction, there is a single calendar file that is known to the Calendar Tool system for each user. This is the file named `Calendar' stored in the user's Calendar Tool directory listed in the user's database record. Only items scheduled in this calendar for are visible to other users of the Calendar Tool system.

NEW: The `Local Directory' command allows the user to set the directory on the local computer where the Calendar Tool looks for standard files. Cite section that describes the files and say that a normal file chooser comes up with the message "Enter the name of the directory where the Calendar Tool looks for standard files:". Also, explain that this file is set to some typical default location (platform-specifically) at initial installation.

6.6. Nixed in Favor of Explicit Dialog Settings

But, alas, the next paragraph is full of shit, since we have now in fact put (most of) this stuff explicitly in dialog(s).

During process of creating a distribution, consider allowing the admin to set up a pre-defined connection table and pre-defined local-files value. I'd say the best, and most orthogonal way to handle this is to have the admin define an Initialization file that's included with the distribution. This is in fact a good idea in general, viz., a distribution is defined a copy of the app itself, plus a set of standard files. I think this provides a good amount of flexibility and makes good use of the standard files setup, i.e., it's in keeping with the philosophy that the standard files fully define a cal tool config, without any hidden values buried inside the app itself or in some obscure file (the latter being Microsoftesqe, it would seem).

6.7. What's on the Host

8aug03. It's not just the "public portions" of a user calendar, whatever those might have been, but all of the user's calendar. The viewing commands take care of not showing to other users calendar items or parts thereof that aren't supposed to be visible. An added benefit, though perhaps a weak one, is that the user can consider the central host copy of the calendar to be a full backup.

6.8. More nukation from admin, here re. purging and capping

NOT, it's part of the File->-- THIS NEEDS TO BE ADDED TO THE COMMAND MENU. --

For large installations and/or for central hosts with limited storage resources, Calendar Tool administrators can purge scheduled items from the central host calendars of some or all users. Sketch of functionality:

• select user by ID or with radio button `all'
• select before and after dates

Hmm, if we follow the latest functionality for local-to-central cal copying, it may not do any permanent long-term good to purge without lowering limits as well. So, it looks like we need some kind of coordination with purging and item-limit setting. Shit, one more fucking thing to work out.

For any or all users and groups, can cap the number of items for that user that are stored in the central calendar. When the cap is reached, items are removed such that an equal number of items, +/-1, appear before and after today's date. Notification is sent to the user when the cap is reached, including an annoying message every time it changes, which means the user either has to do something to clear out old junk or ask the admin to increase the cap.

Changing the cap size to a value smaller than the current number of items effectively executes a purge operation.

6.9. Nuked from Change/Delete Section 28 Jul 03

NOT: The detailed notification dialog reflects change merging when it is initially displayed. Hence, the `Title', `Category', and `Remind' fields in Figure 166 contain the values most recently entered by the user, not the older values that appeared in the scheduler's view in Figure 157.

... This item-level view contains exactly the same data values as Figure 167.

If the scheduler has changed the `Category' field, the category name is highlighted in boldface font, but in the normal color of the category. (There is no category change in this scenario.) For all other changed data fields, the entire field value is displayed in bold red, not just the individual characters or lines to which edits were made. For example in Figure 166, The entire text of the `Details' field is shown in bold red, even though only two lines of the text have been changed by the scheduler.

6.10. Nuked from Admin Section 27 Jul 03 through 11 Aug 03

Some more old crap:
.sh 4 "Summary of Super User Privileges"

1. Maybe on this one. Can cancel any leader-scheduled meeting. We need to clarify that the super user can see only the meeting in the group calendar, not in any individual user's calendar.
2. Can delete items from group calendars.
3. Can delete any user. The user's calendar wont be affected, but the user will no longer participate the way a registered user does.
4. Cannot see any more of any user calendar than any other user can; cannot change or delete anything from any user's calendar.
5. Can cap the number of items that appear in the central Cal Tool repository for any particular user or group.

Next several paragraphs are older variants of `Contact Admin'.

Other notes about `Contact Admin':

• Dialog simply displays name of current host (which is host to which current calendar is connected (with msg "Current calendar is not connected to a central host")) along with email address of admin of current host (with msg "no admin email is available for this host" if there is no email address.
• Caltool uses same technology as web browser to launch user's selected e mail program when the user presses 'Send Message' in the dialog.

Here's an older version of a user-to-admin message:

A user can look up the electronic mail address of any administrator using the `List Admins' and `Users' commands in the `Admin' menu. Figure 344 shows a typical mail message sent by a user requesting an administrator to make some changes to the user's Calendar Tool user information.

To: caltool_admin@csc.calpoly.edu
From: rich@ailab.calpoly.edu
Subject: Changes to calendar tool user information

Dear calendar tool admin:

I have changed my office computer and email address.  Please make the following
changes to my calendar tool user information:

    email: rich@ailab.calpoly.edu
    host computer: acorn.ailab.calpoly.edu
    user id: rich
    caltool directory: c:\home\calendar

Some old crap:

A regular user cannot change any of the values in a user database information record [in the DB dialogs; password can be changed indirectly using the password command.] If a user needs one or more information fields to be changed, the user must request the changes be made by a system administrator. There is no specific Calendar Tool command to make such change requests. An electronic mail request is presumably typical.

OK, a big bunch of stuff has been nuked from the admin section, including a lot blather on the design of the central host. If you're interested, check out admin.me version 1.23, which is a check point with all of the blather before it was nuked. But fuck it, I'll put the juicier bits of fodder here so I don't have to go dredge it out of the CVS log. To whit:

So fuck it again, I didn't feel like putting anything here. Go see v 1.23 if you care (I already have a couple times). Diffing v 1.23 and 1.24 is probably a pretty good way to focus on the juicy bits I was thinking about putting here.

IWe need to remove the ID and Passwd columns, which were recently added, since they should not be stored locally, but rather on the host. So, if we want to change the host password, we need to be connected, which means that leaving the Password command in the regular-user Admin menu is correct.

     Central Host           ID  Passwd        Calendar                Connected
     ==========================================================================
     19.62.146.83                             Personal Calendar
     csc.calpoly.edu                          Work Calendar               X
     falcon.csc.calpoly.edu                   Work Calendar
     onion.csc.calpoly.edu                    Lab Calendar                X


                  Connect    Disconnect    Change Password

           Add Host    Change    Delete    Save    Clear    Cancel

.sh 3 "User Communication with Administrators"

NOT. To avoid the need for message-handling functionality in the Calendar Tool Administration program, there is no means for a regular user to communicate with an adminstrator via the Calendar Tool. To do so, the user must look up the adminstrators' email addresses using the `Admin->List Admins' command and communicate via email, look up the phone number, or otherwise communicate with the admin outside of the context of the Calendar Tool.

.sh 4 "Listing Administrators"

Describe that `List Admins' shows who all the admins are, Figure 345.

The `Validate' button is used to validate user information that is external to Calendar Tool administrative control. This is the information entered in the `Email' through `Computer User ID' fields. Details of the validation are covered in Section 2.11.25

[NO to the following, per the latest revelation the no admin data are ever stored on local user machines see below : In conjunction with the notification message, the Calendar Tool on the new user's host computer is reconfigured with the ID of the Calendar Tool central host.]

Details of central host configuration are covered in Sections and 2.6.6.

In the scenarios to follow, privileged administrator access is covered in Sections 2.6.1 through Section . Access to administrative commands by regular users is covered in Section 2.6.6. In the scenarios, the term "administrator" refers to a user with administrative privileges running the Calendar Tool Administration program. The term "user" refers to a regular user running the regular Calendar Tool program. Also, the term "privileged Admin menu" refers to the command menu in the Calendar Tool Administration interface ( Figure 4 ). The term "Admin menu" refers to the menu accessible from the regular user Calendar Tool interface ( Figure 2 ).

There are two contexts in which administrative commands appear -- in the admin program and after the user establishes a connection in the regular UI.

When the user establishes a connection with a remote host, the `Admin' appears on the menubar. Prior to establishing a connection, or after close all connections, the `Admin' menu is not in the menubar. Since establishing a connection is a precondition to working with the administrative commands, it's described here.

TODO:

1. Remove `Admin Privileges' radio buttons from add/edit user dialogs, replacing them with a separate admin-editing dialog. NOT to what follows -- there are not admin users any more, just an admin password for any given installation of CalTool Admin. NOW OUT: The latter dialog is accessed via an `Edit Admins ...' item in the privileged admin menu, which replaces the current `List Admins ...'. This means that the non-privileged Admin menu has a `List Admins ...' item whereas the privileged Admin menu has `Edit Admins ...', which is cool.
2. Change `Item Limit' to `Size Limit', to avoid malicious flooding of a user calendar with an excessively long `Details' field value.
3. Update things as necessary throughout to eliminate admins as regular users, leaving a UNIX-style admin that exists solely by virtue of knowing the admin password, which in this case is used to invoke the CalTool Admin program on some host. As with UNIX admins, it's up to them to arrange sharing of the password(s), including whether they want different passwords for different hosts. This updating entails:
   1. Changing the `List Admins' item in the regular-user Admin menu to `Contact Admin', which brings up a dialog allowing the user to submit a message to the admin of the Calendar Tool central host to which the current calenndar is connected. This command is disabled when the current calendar is not connected to a central host. What's probably nice is to have the dialog come that says that in order to contact an admin, the user has to be connected, and offering to op the `Central Host' dialog so the user can connect where desired. But this is unnecessary now, since the entire Admin menu only appears when connected. Cool that the banner has the current host name, BTW.
   2. Removing `List Admins' entirely from the priv admin menu, as described above.

OK, the evidently unspoken rationale for having local host user ID be part of the cal tool user record was this. The local machine would provide the user- level access structure, including passwording, and then the cal tool would rely on this in the sense the mapping from local ID to cal tool ID was the only cal tool validation necessary, the user having (presumably) entered a password to gain access to the local machine. The perceived advantage of this is that the user on a local machine does not have to log in twice, once to the machine and then again to the cal tool. There are at least a couple problems with this structure however. The first of which was noticed pretty early on. That is that it's a pain for the admin to have to have multiple local computer potentially listed in the user records. At the same time, it's a pain, or evern unrealistic to require that the user IDs be the same on all connecting local machines. Another problem, which is just now coming to light, is that it is in some circumstances unrealistic to expect a specifi local-side login protocol that the remote cal tool server can rely on. What comes to mind most clearly is the access-from-internet-cafe configuration, where the ID of the connecting machine cannot possibly be known (in advance) to the remote caltool server.

Given these problems, the user model that is better is to require both user ID and password in the caltool user record. The inconvenience of double login can be avoided by allowing the user to specify a default cal tool user ID and password as an option. These will be automatically supplied when a user connects to a remote host. Also, admins on a number of cal tool hosts in a given organization can take care to give each user the same cal tool ID on all hosts, so a single default will work for a given user connecting from one or more local machines. The bottom line here is that the cal tool does not rely on any local-machine login protocol to validate that a cal tool user can connect to a remote host.

The other thing that has to be changed in this new user model is the idea that the regular user interface to the cal tool can know the (local) user ID at start-up time, therefore know the cal tool ID (since it's the same), and therefore know whether to start up the registered or non-registered UI. The deal (now) is that launching the cal tool locally does not in and of itself make a connection to a remote host, even though it might seem to do so by virtue of the auto-connect-on-open option. The important point is that launching the cal tool locally cannot necessarily mean that a remote host connection is automatically being made, and even if it is that a particular single cal tool ID is to be used for the connection. Therefore, automatically matching a local ID to a cal tool ID at start up, or even explicitly requiring al login at cal tool start up, is not generally useful. The login is part of the connection process, not the start up process. Given this, there either need to be two separate "regular" user apps, or we can just forget about the unregisted version, just leaving all of the would-be missing features disabled. Another alternative might be to have the entire Admin menu not appear until a connection, but that can't work with exactly the current Admin menu, since it's got the connect command on it (indirectly). So, it's either two separate apps, or one with Admin permenantly disabled. It's not all that hard to provide two, so what the heck, I think we should just do it.

CONCLUSION: OK, here's the deal. We've moved the `Central Host ...' command from the `Admin ...' menu to the `File' menu, and renamed it `Connect'. Also, we've moved `Local Directory ...' to the file menu, renaming it `Local Files ...'. The point is to avoid the chicken-and-egg problem noted above where we can't get to connect if the `Admin' menu is initially not in the menubar. With these changes, we can say that the `Admin' menu does not appear until at least one successful connection is established. Further, the DBs and admins to which the `Admin' menu apply at any given time are the host to which the current calendar is connected. If the current calendar is not connected to a host, then the admin menu is disabled, but still on the menubar. The `Admin' menu disappears from the menubar when all connections to cal tool central computers are severed.

7jul04 NEW CONCLUSION: Fuck the chicken-and-egg bullshit around the Admin menu. Just leave it the fuck up all the time, with the DB commands and passwd command disabled unless the current calendar is connected. This means we move the Connect command back to the Admin menu where it belongs. The fact that it belongs in the Admin as opposed to File menu was brought pretty clearly home when I tried to write a decent intro paragraph to the Flie section, whereupon it became pretty darn clear that Connect is only weakly related to file processing. Furthermore, the fact that I've seen fit to explain the connect command fully in the Admin section makes it quite clear indeed that it should be an Admin as opposed to File menu command.

6.12. ``View ...'' versus ``Edit ...'' as Button and Menu Item Names

"View ..." is used when there is more information to see about a particular item of data. The displayed dialog may allow editing, with Change and Delete commands, but without an Add command. "Edit ..." is used when the when the displayed dialog has all editing commands, include Add. "Edit ..." is the menu item for categories, lists, and filters. "View ..." is used as the menu or button for other viewing/editig dialogs, including meeting notifications, meeting minutes, and a few others.

6.13. The Explicit Delay Button in Meeting Notifications

It's clearer than just having the user close the window to delay. It was decided that a Delay button is not necessary in the item-level view of a not- yet-accepted item since the user isn't necessarily there to make an accept/decline decision the way she is in the notification dialog.

6.14. Group Explorer

Thought about adding a tree-style group/user explorer, but it's a bit much given that the group structure is potentially a graph, not a tree. E.g,

campuslect = cslect
csdept = csfac, cslect, csstaff
cslect = b,c,f

... To access the group database, the administrator selects the `Groups ...' command in the privileged `Admin' menu. In response, the system displays the dialog in Figure 346.

When the user presses `Explorer ...', the system display the group viewing window shown in Figure 347.

This is the point at which I figured things were going to get out of hand here. Smart thinking, actually.

6.15. Nuked from Admin; Presumably to Go In Some Form in Installation

sh 3 "Initial System Configuration"

12aug02 Update: Think about moving the last paragraph above here. Or perhaps it belongs in the installation section, with only a ref to it here.

29jul02 Update: I think this section stays, in addition to the high-level installation section. An important point (if not the point) of a cal tool admin doing a config is to coordinate the cal tool app's hard-wired locale of a user's cal tool dir with the convention for it to use in users' cal tool admin user db records.

3jul02 Note: This section may go in favor of the higher-level installation section that's now been added. Still need to work this out fully.

Talk about what things look like straight out of the box to the admin and what needs to be set up. Constrast this to the essentially negligable set up required for non-admin users.

Need to be able to set default for calendar-host mapping, for convenience of the user. This way, when it comes up out of the shrink wrap, it'll be config'd.

6.16. Fodder from Wincow Viewing Section, Ca. Aug 02

NOTE prime: OK, it looks like we're going (back) to the rule that a calendar cannot be windowless. This avoids the problem of what window should be current when a windowless calendar is current. This decision obsoletes all of the discussion notes that follow that refer to a solution that assumes windowless calendars are legal. Further, this decision lets us leave the chronological current-on-top layout of the windows submenu as is, as well as leaving the related scenario narrative pretty much, if not entirely in tact. (The bottom line for the "But fargs" that follow is that we'll have both windows and cal lists chrono sorted.) But farg, we need to reconcile the chrono-sorted windows list with the alpha-sorted calendar list. I'm inclined at this point to go with alpha sorting for both, given that things seem a bit twitchy with all the movement in the chrono-sorted list. But farg again, the alpha sorting of the windows lists does not give any chrono information. So, the two kinds of sorting (chrono for windows, alpha for cals) may be OK, given that chrono for cals is a bit funky to determine, since it could be "most recently open" or "most recently active based on window selection". But farg one more time, I think we can define chrono order for cals just fine, it being "most recently visited (i.e., current)" based on window order. I.e., the chrono order of the cals can be defined as a suborder of the cals in the windows list.

NOTE: The new deal is that when a calendar has no active window, the menubar window should be current when the user selects that calendar. This means that we need to adjust our thinking about "current" versus "has focus" in terms of cal tool windows. The (mini) problem is that the command window gets focus a lot, whenever the user clicks on it to run a command, however when this happens, we don't really want to move it to the top of the windows list. Also, even when the menu window is current, there's still the notion of a current calendar, the open window for which is current. Hmm, maybe we need to separate "current window" from "current calendar" even more clearly than we've done so far. Another way to help deal with the issue is to list windows alphabetically in the windows list instead of chronologically, with the current window checked in lieu of it being at the top of the list. Well, the problem with this is that if we consider the menu to be a window, then technically it should always be checked, since it's always physically current whenever the user runs the View->Windows command. Farg.

OK, here's the conundrum we're dealing with: We don't want to make the menubar window current unless there's a windowless open calendar. OK, how bout we go back to the rule that windowless calendars are disallowed, or more precisely, view-windowless calendars are disallowed. (It really doesn't have to be view- windowless, since the user could open a view, open a schedule dialog, then close the view, leaving the scheduling dialog as the (sole) window open on the calendar. This should be just fine, as long as there's at least one cal- specific window open.)

6.17. Meeting Notifications and Calendar-Host Association

Much thought given to whether notification options should be global (i.e., for the entire tool) versus calendar-specific. Also, some thought was given to having an option to auto-accept scheduled meetings. The first idea was nixed because we do not want to open the global/local option can of worms at all. The second idea was nixed because it can effectively be achieved by leaving the `Not-yet-accepted Meetings' option as `show' and setting the `Accept Notification' option to `never'. In this way, the user is not bothered with seeing the notifications, which is presuambly the point of the auto-accept option. Without the auto-accept option, meetings that would appear in normal type on calendars instead appear penciled in. But this is fine, because it means that if the user bothers to look at the details of the meeting, all she has to do to get it to normal type is press accept (instead of cancel or close) in the viewing dialog.

Much thought was also given to the cal-to-host assciation rules, the possibilities being:

1. ... enumerate 'em

The `Home directory leading path' setting defines the default leading file name path prepended onto the `Calendar Tool Directory'. If the path is non-empty, it is prepended iff the value specified for a particular user is not an absolute or user-relative path, where absolute paths start with "/" or "<drive-letter>:" and user-relative paths start with "~".

6.19. Decision about User Control Over Notifications

24jul02 bottom line -- There are two basic categories of notification: meeting and admin. The user has full control over meeting notifications, none over admin notifications.

6.20. Some Uncommonly To-The-Point Fodder from the Options Section

Provide a dialog that looks like this:

OUT:

    Accept Calendar Tool Meeting Notifications from the leaders of these groups:
        * all
        * specific group list, with a radio button beside each, scrollable in
          case there are a large number of groups defined
        * none
:TUO (see "NO" paragraph below)

    Accept Email Meeting Notifications from the leaders of these groups:
        * all
        * specific group list, with a radio button beside each, scrollable in
          case there are a large number of groups defined
        * none

    Accept Email Meeting Notifications from new groups you're added to:
        * yes
        * no

    Accept Meeting Notifications from these individuals:
        * all
        * specific user list
        * none

But OK, here's a case where rejecting requests from some group leaders makes perfectly good sense -- I'm going on vacation and I don't want my calendar and possibly email cluttered up with meeting requests.

So, here's a nice happy medium -- the leader of a group for whom meeting requests are turned off is notified when the turn off happens. This may be getting overly complicated, but hey so's the whole darn system.

NO, screw the happy medium -- users CANNOT decline meeting notification from the leaders of groups they're members of, only email notifications. If they're gonna participate in the Cal Tool community, they're on the hook for receiving meeting notifications.

NO, NO, users can turn off notifications, as imprudent as it may be. See latest version of meeting scheduling section.

The ability to accept meeting request from individuals effectively allow Cal Sys users the ability to establish unofficial groups, by establishing mutual acceptance of meeting requests.

Some question/details pursuant to the above dialog idea:

1. Should a user be able to accept meeting requests from the leader of a group she's not a member of? Well, this doesn't really make much sense, because if she's not a member, then she won't normally be sent a meeting request for that group, so it looks like the answer is "no". This means that a user is only asked to accept from member-of groups. [But this is basically bogus, given latest requirements that non-leaders can schedule meetings, and users have full control over penciling-in, in that nothing happens on a user's own local calendar until the user accepts the meeting.]
2. The radio-buttoned of groups list should probably be in tree form, since it will allow the user to select subgroups by clicking on a parent group.
3. The default ..., fell off.

When the user presses `Save' the system first performs `Apply' (if it is enabled), then saves all option settings in the current calendar. If no calendar is open, options are saved in the standard `Options' file. As with the `Apply' button, `Save' is initially disabled, becoming enabled when the user changes the options settings in one or more tabs, makes current a calendar with unsaved changes, or loads a new options file. While execution of `Save' performs `Apply', the converse is not true. Therefore, the settings in the options dialog exist in one of three states:

1. unapplied and unsaved
2. applied but unsaved
3. applied and saved

Saving options for the current calendar does not save any unsaved scheduled items in the calendar. Scheduled items are saved using the `File Save' command, described in Section .

6.22. Hopefully Final Nukes for Options

Admin
  Default shared user calendar file name: [default = "Calendar"]
  Home directory leading path:

In thinking through clearly how the IPC will work, it must be based on the fact that the host does not have direct write access to the local machines. Something like message passing must happen, along the following lines:

1. When local cal tool (and/or local cal tool server) starts up, it sends hostname/uid message to central host and establishes two-way comm.
2. When local host has cal updates, it sends message to central host with the data.
3. When central host has notifications and pencil ins, it sends message to local host with the data.
4. Implementors can figure out how to ensure that messages sent from the central host are properly processed when the cal tool user app is not running. Such messages consist of meeting and other notifications sent by cal tool admins. A lccal cal tool server is presumably in order, but the user does not have any control of it, i.e., the local user is (must be) unaware of any local server that is running.

  For User-Entered Data:
    Font Name: pulldown of font names
    Size: pulldown of environment-specific ints
    Style: one of Plain, Bold, Italic, Bold Italic
    In these displays: one of     For thes items: one of
      Item                             Appointment
      Day                              Meeting
      Week                             Task
      Month                            Event
      Year                             All items
      Lists
      Dialogs
      All displays
  For Permanent Text:
    -- same as type-in text --

The user can set font options for two forms of text: scheduled items and all other text. The font settings under `Scheduled Items' apply to the text of scheduled items as it appears in day, week, month, and list views. The settings under `All Other Text' apply to all other text appearing in Calendar Tool display windows, including user-entered text as well as permenant system-generated text.

The `Font' and `Size' data-entry fields are used to enter basic font information. There are two forms of display text for which font selections can be made: typed-in text and permanent text. The settings for typed-in text apply to all text entered by the user in the text-entry fields of dialogs. Permanent text settings apply to all unediable text that appears in displays, except for the text in window banners. Display-banner text is considered to be under the control of the underlying operating environment, and is therefore not settable from within the Calendar Tool.

The font options tab provides no control of font style or color. The normal, boldface, or italic style of text is controlled entirely by the system. The user can change the text color of scheduled items using the category editing features described in Section 2.5.5. No other control of text coloring is available.

The text of warning and error messages is always shown in bold typeface, indepednent of the `Style' option selected for permanent text. The settings for font name and size do apply to error and warning message text.

The `Scheduled Items' settings apply to all text entered by the user, blah, blah, blah. The `Headers and Labels' settings apply to all of the header and labeling text, such as current date, dates, etc, blah, blah, blah

... Describe that font, style, and size entries are platform-dependent, but give some typical values. The `Font Name' and `Size' menus are platform-specific lists of available fonts and their sizes. The `Style' shown in Figure 348.

The `Display Type' pulldown menus specify the types of displays to which the selected fonts apply. The possible selections are the same for both menus and are shown in Figure 348.

Sketch of the remainder:

• Describe that the `Restore Defaults' puts everything back to the system-wide default settings. If the user wants to see what the system default was but not actually go back to it for all displays, she does `Restore Defaults' and then `Cancel'.
• Show another example of the effect of font changes on the user-db admin dialog, to clarify the what exactly is user-entered versus header-and-label information.
• Define precisely, probably in tabular form, what the different forms and types of text are, for all possible displays and dialogs.

There's no question we went around quite a bit about how best to do options. We considered making them global for all calendars, calendar-specific but still applicable to multiple calendars at the same time, and the current solely calendar-specific style. All of this is a bit much, given that changing options is not likely to be all that frequent an activity, but we do want to get it right.

There have also been plenty of go-rounds for specific details. Noteworthy considersaions are these:

1. the button arrangement, which corresponded to the different global versus calendar-specific explorations
2. Others that maybe I'll think of at some point.

Methodologywise, the options requirements have been developed thusly:

1. Do preceding scenarions, describing applicable options as they are developed and refined.
2. When all options are introduced, scan all sections for them and organize them into the options hiearchy.
3. Do the detailed scenarions for the options dialog.
4. Refine in earlier sections as necessary.

1jul02 Note. If it's not the case already, and I do not think it is, I believe there should be an option setting for each and every data-entry field in each and every dialog. If this is done entirely uniformly, it seems that we may be able to have the same data-entry dialogs used for default setting as for actual data entry. This could be pretty cool if we could pull it off. -- Done. --

4jan01 thot about 14dec00 thot: Hmm, with movement of prefs to options menu, I'm not sure about the tabbing dialog any more. We may want to put a prefs menu back, with `Edit Prefs' being tool prefs versus the top- level `Options' menu being data prefs. I'm not sure the distinction is worth making, so I guess we have to think about this some more. 24jul02 update -- screw this. --

14dec00 thot (and I think it's quite a good one): organize preferences into a tabbing dialog with exactly one tab for each menu. -- Done. --

Among the other options, there should be some for little things. Here's the beginnings of a list:

• (yes/no) remind on File Save As -- turn on/off the reminder about only the default calendar name being used for group scheduling purpose. 6jul02 note: forget this -- the user has to be a big girl; but perhaps we'll have some special annotation in the menubar banner to indicate when the community calendar is active.

Once upon a time, there was going to be a `Defaults ...' button in the options dialog to restore "default" option values. This has been replaced now with `Load ...' button, the dialog for which is given just below. The deal is we now have what are best called "standard" options, in the Options file, rather the kind of "inherited from" default options we had been envisioning earlier.

Once upon a time, we said that: "The three radio buttons at the bottom left of the options dialog indicate which option settings are currently active". These buttons are now nugatory, given the current scheme of things, viz., the only "active" options are those for the current calendar. To make other options "active", they have to be loaded, and in the current scheme of things, they become active (and unsaved) for the current calendar only. As rationalized above, to make a set of options active for multiple calendars, they have to be loaded separately for each calendar (which can be done with a script, in the (presumably quite rate) case that we want to do it for a bunch of calendars).

6.27. Here's an Important Bit that Finally Got Handled

This bit is not really in and of itself a part of rationale, but the idea that it's an important piece of information that lingered as only a note for a long time is interesting rationalewise, or someotherwise at any rate. Anyway, here is a note from the options `Times and Dates' section that finally got officially dealt with. Finally dealing with this note led to an addition to the previously-thought-done structural viewing section.

1. Be sure to say that none of the settings of these options will ever leave anything out. I.e., the breadth of a display, hour and daywise is maximum of the normal range setting and the range determined by actually scheduled items.

The following are the notes that elucidate the real deal for options. These notes were refined into the current requirements in the Options section. Only the last item of these notes needs to survive as rationale, since all of the other items have been incorporated nearly verbatim in the requirements, whereas the last item appear no where since it's pretty much strictly rationale. OK, try this for how to deal with "global" versus calendar-specific options.

• Each and every calendar has its own options, period. When a calendar is created, the default options are copied into it. When a calendar's options are saved (see details below for how), they are stored within the calendar's data file. I.e., there is a single file containing calendar data plus options for that calendar.
• The standard (default) options are stored in the file ~/.CalendarTool/Options.
• If the user changes and applies options while the calendar tool is running, the changes apply to the current calendar only, as unsaved options for that calendar.
• If user exectues `File Save' for a calendar with unsaved options, the file-save dialog contains the message and radio buttons:

          "There are unsaved options for this calendar."
           (x) Save these changed options for this calendar
           ( ) Don't save changed options, i.e., leave the most
               recently saved options for this calendar as is
  

• If the user exits or closes a calendar with unsaved options, then in addition to whatever offer-to-save file messages there may be, there are also offer-to- save options messages. Viz., there is one such message for each active calendar for which options have been applied but not saved. The text of these offer-to-save messages should most likely be integrated into the file offer-to- save dialogs, so two dialogs don't appear if both the file data and options need to be saved for a particular calendar.
• There's no (non-scripting) way to change options for all existing calendar files, or even for all currntly open calendars, as there would be if there was a dynamic options selection feature in the GUI, i.e., that allowed local options to be turned off in order to dynamically enable the "global" default options in the Options file. The rationale here is that there are not likely to be a lot of calendar files period, let alone a lot of them that all need to have their options changed at once. In another system, it might be worthwhile to have a GUI way to select dynamically whether to use global or local options, but not in the Cal Tool given the preceding observation about the small number of files.
• See the save and load dialogs below for how the user performs these options operations.

And the following section was just nuked from the options section, per the explantory 29jul02 remark that preceeds the rest of the notes:

.sh 3 "The Format of Options Files"

29jul02 Update. For doability, we need to abandon the idea of option files being parsable command files, or even user-accessible text files, at leas for now. The reasons are several:

1. With the latest scheme of options semantics, the single-options-file idea is basically dead. This is because options are now embeded in every calendar file, and as such, not that amenable to formating as command streams or even in textual format, unless we want to impose parsing requirements, which at present we do not.
2. Putting the standard Options file in command-stream format might still work, but if we do so its format will be inconsisten with the calendar-embedded options, so we'll skip this too.
3. We're getting pretty darn close to dropping the whole command language thing anyway, which if it happens would make the whole options-as-commands thing moot.

Here's where things started, before the 29jul02 bail out:

This should be, a la emacs, executable commands. Here's a plausible/possible exaple:

caltool.options.timesAndDates.set...
file.open("PersonalCalendar");
Schedule.ScheduleAppointment(
    new Appointment(
    );

24jul02 -- Try this (29jul02 -- italics after each point indicate whether the point has been incorporated (OK) or nixed (NIXED) from the requirments):

• Calendar data created with any `Schedule' or `View' command are stored in individual calendar files. (OK)
• Calendar-specific option data are also stored in the calendar files. (OK)
• All-calendar option data are stored in a separate "Options" file (or some such name) in the cal tool user dir (folder), where this dir is as spec'd in the user's record. This is where we might use the idea of putting all-calendar options in the init file (as "set" commands), or have seprate options and init files. I'm inclined towards the emacsesque options-in-init-file-as-commands form. (OK somewhat, but refined to latest semantics of standard Options file and set command stuff NIXED.)
• Note that even though no user record data are stored in local files, the installed calendar tool itself must have some knowldege of the location of the cal tool folder; we could do this netscape/mozilla style and put this in a fixed (known) place under the user's, or figure it the you-know-what out so that the installed cal tool always knows where it needs to go to find its options file. (OK)
• We need to figure out if we want to have the standard format of a calendar file be readable text, or generate a separate plain text file as a save option. Given the presumed Java implementation, it's probably the former for starters, since we'll only have to write a generator. Eventually, I'd really like the text form to be the form, with a full-blown parser, so we can edit cal files in emacs and just read them in to the cal tool. (We've figured it out, having NIXED the parseable file format idea totally for this version of things, and therefore most likely forever (!).)

Nuked the following idea in favor of a button at the bottom of the options dialog. I think we made the right decision.

NOTE: Add a separated `Save ...' item at the bottom of the `Options' menu. It launches a dialog that asks something like the following:

    * Save for this calendar only
    * Save for all calendars

    Options name:   [ .calendar_options ]    ( Browse ... )

    ( OK )    ( Clear )    ( Cancel )

Note also that this item probably only applies to non-admin users, since for the admin, the options settings are saved as part of the complete set of admin DBs, meaning admin-level options are covered by `File Save'.

The following was a related bit of murky thinking about defaults-related porcessing in the appt-scheduling section. It's (obviously) been refined. Note that the reference to "the preceding two refs" were to places I vaguely understood as where the details of global default setting would go.

To clear all information entered in an appointment dialog, the user presses the `Clear' button. In response, the system clears all typing areas and restores all other data-entry fields to their default states. Details of default settings are covered in Sections and To cancel a scheduling command entirely, the user presses the `Cancel' button. In response, the system removes the dialog from the screen without performing any scheduling action.

[NOTE: The preceding two refs need to be fixed, and we need to figure out exactly what scheduling options include, in particular if they allow default values to be entered for each and every field. Perhaps the easiest and most general solution is simply to have a `Set Defaults ...' button in each schedule options subtab. This button brings up a standard dialoag for each type of scheduled item, with "DEFAULTS" somewhere prominently in the banner or title. I think this is pretty cool, actually, because it will illustrate a nice general and orthogonal way to allow the user to set defaults.]

We need to rationalize how we let the pedagogical goal influence the model structure of scheduled event a bit, given that we wanted to specify (and subsequently implement) a "good looking" inheritance struture. This includes a dicussion of the Event item, which we've gone back and forth with in terms of exactly what fields it has. As of 9mar02, we in fact have the situation that the implementation is wrong vis a vis the specs, since the implementation has location in an Event, whereas the spec has SimpleSecurity. This component change to Event apparently happened on 16jul01, according to the CVS log entry of that date for version 1.17 of schedule.rsl. The only explanation of what was evidently some deeper thought on the subject was "Removed Location and added SimpleSecurity to Event (this being a significant update).". I guess the thinking was that location doesn't necessarily make sense for an event, particularly for things like holidays, as well as for the example events we have in the scenarios, like "Jim's birthday". Anyway, this biz should be discussed here. Yes, we just did, and so just a bit of "grooming" of this discussion needs to happen before we release this tome.

6.31. A Feature Removal (!)

The following started out to be an Advanced Option, but as the bulleted items indicate, it's not needed.

A useful but low priority option would be to find all events that have reminders turned on. This would be useful to me because I may have accidently turned on a reminder when I didn't want to, or forgot to turn on a reminder for something I should have. Anyway, this is a low priority requirement.

Ah, but we can do this pretty easily as follows:

• filter out all but events
• sort event list by reminder, which will put all events with reminders on first in the list

Removed the `List Admins' command in favor of having an a`admins' group that has the IDs of all users with admin privileges.

The following was decided to be too cumbersome:

The `Members' and `Leaders' lists are editable by direct typing. To add, delete, or change a user from either list, the adminstrator performs the appropriate typing.

The following was enacted as stated, and this paragraph is a bit of rationale, perhaps:

what happens to all of the meetings for a group when the group is deleted; I think the group name just stays there; hopefully we haven't provided a way for the user to double click on an attendee group to see its information; if we have, that has to give a "the group no longer exists" error message when executed on a deleted group; otherwise, we just have the somewhat funky state where a group name is in a meeting, but if the user goes to look up that group it won't be there; this will have to be the only indication to the looking user that the group has been deleted

This stuff got nixed:

[Include a field that allows the existence of the group and/or its membership to be kept private. Also include confirmation protocol that allows the intended group leader to accept or decline becoming group leader.]

When the administrator assigns one or more users to be a group leader, the assignment does not take effect until the assignee(s) is(are) notified and confirm the assignment. Specifically, when the uGroup Add command is confirmed by the administrator, a confirmation request is made to each of the assigned group leaders. The form of the confirmation request depends upon the current setting of an assigned leader's reminders options. Specifically, the confirmation request is sent immediately as an on-screen pop-up window if the assigned leader has `on screen' selected as the default value for receiving reminders. For any other setting default reminders setting, the system sends the leader confirmation request via email.

To avoid the potential difficulties of interfacing the Calendar Tool with a variety of different email systems, blah, blah, blah ... .

---

Figure 351: New group leader confirmation.

---

.sh 4 "Group Membership Requests"

An individual user should be able to:

1. see what group she's a member or
2. request (demand?, force?) removal from the group
3. request (demand?, force?) membership in a new group

Recall that all intances in the same collection must have the same start and end dates. To see why this is necessary, consider the case where some instances in a collection, call them "Part A", have an later start date than other instances, call them "Part B". If this were allowed to happen, then the calender would have to appear inconsistent from the perspective of either Part A or Part B. If the later end date of Part A is considered the correct, then there are later items in the calendar than any of the Part B instances indicate. Hence, when locating at a Part B instance, the end date is inconsistent with the items that are actually in the calendar. Coversely, if the earlier end date Part B is considered correct, then the Part A instances are inconsistent with the calendar, since they indicate that there should be items in the calendar that are not there.

6.35. Rationale for Changing and Deleting Meetings

Discuss all of the issues related to scheduler and non-scheduler change and delete. There's a boatload of fodder below that needs to be dragged into here.

6.35.1. From the end of the change and delete section

At least some of this section is wrong. It should be nuked entirely.

When the user changes the status of an item from non-recurring to recurring, or vice versa, the change has a more global effect on the calendar than does a change to any of the other data fields.

When the user changes an item from non-recurring to recurring, what was a single item becomes an instance of a recurring item. When the change is confirmed, calendar and list views may have multiple new items added to their displays.

When a recurring item is changed to non-recurring, the effect varies depending on the scope of the change selected in the change confirmation dialog. When just one instance is changed from recurring to non-recurring, that instance becomes a single non-recurring item, dissociated from all other instances with which it was previously associated. All other instances except the changed one remain as associated instances of the same recurring item. Any subsequent changes made to the changed instance have no effect on the formerly associated instances. Changes made to any formerly associated instance have no effect on the changed instance, but do have an affect on the remaining associated instances.

When all or all future instances are changed from recurring to non-recurring, all of the affected instances become single items, dissociated from all other previously associated instances. Subsequent changes to any dissociated instance affect that instance only. In the case of a change to all future instances, subsequent changes to a still-associated past instance affect all past instances, but none of the dissociated future instances. .sh 4 "Changing and Deleting Past Items"

There may be something to say here -- not sure right at the moment.

6.36. From the task scheduling section

The following issues were all dealt with as appropriate.

..., subject to the following restrictinons:

1. for a non-recurring task, the completion date must be on or after the due date
2. for a recurring task with `this instance' selected, the completion date must be on or after the instance date
3. for a recurring task with `all instances' selected, the completion date must be on or after the instance date

Refer to all fields that are in common with appoinemts, which should be all be completed and completion-date. Do two or three scenarios for these fields and we should be done.

The following was moved from the task item viewing section, since it appears pretty clearly to belong here instead.

More notes based on task viewing work:

• tasks can be completed early or late, without the kind of annoying "carry forward" behavior of Claris
• the default completion date entered for a task will be the current date by default, but it's fully editable without interference from Cal Tool (or perhaps we'll allow interference or prevention via an option, but I'm inclined not to, not least for reasons of simplicity)
• tasks can be scheduled and "back dated" without interference from the tool (again, interference of some kind may be a settable option, but it definitely won't be the default behavior)

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.38. 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 352 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.39. 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.40. (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 353 shows the user having selected the October 1 meeting instance in a month-level display.

6.41. 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.42. 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.43. 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.49. 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.52. 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.54. 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.55. 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.56. 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.57. 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.58. 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.60. 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.61. 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.62. 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.