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 314.
OLD:
Central Host Computer ID: host name, with admin-settable default
Status: connected/disconnected
Connect Disconnect Clear Cancel
Figure 314: shit.
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 315 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:
Here's exactly what happens when the user connects:
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 315. -- NO, it's
been updated
here.
Host Computer ID: (read only) Status: (up or down)
Figure 315: Central host dialog for a regular user.
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:
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.
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).
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.
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:
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.
NOT: The detailed notification dialog reflects change merging when it is initially displayed. Hence, the `Title', `Category', and `Remind' fields in Figure 167 contain the values most recently entered by the user, not the older values that appeared in the scheduler's view in Figure 158.
... This item-level view contains exactly the same data values as Figure 168.
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 167, 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.
Some more old crap:
.sh 4 "Summary of Super User Privileges"
Next several paragraphs are older variants of `Contact Admin'.
Other notes about `Contact Admin':
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 316 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
Thanks.
Figure 316: User requesting calendar tool information changes.
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.
We 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 317.
Figure 317: List of Calendar Tool administrators.
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 2.6.5.2. 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:
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.
"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.
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.
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,
While this could be rendered in tree, e.g., via some kind of copying rule, it's more trouble than its worth. Here's some verbiage that was going to go in the Section 2.6.3, including a screenshot of the updated group db GUI.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 318.
Figure 318: Group database dialog with explorer.
When the user presses `Explorer ...', the system display the group
viewing window shown in Figure 319.
This would be a standard kind of tree/graph-based explorer.
Figure 319: Group explorer.
This is the point at which I figured things were going to get out of hand here. Smart thinking, actually.
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
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.)
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:
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 "~".
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.
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:
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:
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 2.8.2.
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:
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 320.
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 320.
Figure 320: Font options menu.
To appear.
Figure 321: Font option values selected for month-level displays.
To appear.
Figure 322: Monthly view with user-selected fonts.
Sketch of the remainder:
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:
Methodologywise, the options requirements have been developed thusly:
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:
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).
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.
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.
"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
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:
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):
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.
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:
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 323: New group leader confirmation.
.sh 4 "Group Membership Requests"
An individual user should be able to:
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.
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.
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.
The following issues were all dealt with as appropriate.
..., subject to the following restrictinons:
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:
Of note in Figure 92 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 .
[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 beSince 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.
- changing a critical data field, without first viewing the scheduler's changes in the notification dialog
- pressing `Accept' in the item-level display, again without viewing the notification dialog
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.The next six paragraphs were unrefined issues appearing in the non-scheduler change and delete section. The issues have all been resolved, one way or another. A good rationale discussion will/would discuss which ideas were refined and which rejected.
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 versionThe only fields that cannot be changed are `Scheduled By' and `On', since these is the permanent record of the original scheduler and schedule date, which serve as the unique identifier of the item on all users' calendars.
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:
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 324 appears.
You are the scheduler of this meeting. Do you want all attendees to be notified of the change?
Figure 324: Changing or deleting a meeting as leader.
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:
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.
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.
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 138 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 325 shows the user having selected the October 1 meeting instance in a month-level display.
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.)
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 . 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 WWW browser. Selection of such an external viewing program is explained in Section 2.7.5.
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.
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:
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:Further details of these matters are covered in upcoming scenarios.
- notification is sent to all attendees
- the meeting is added to the group calendars of which the scheduler is a leader
- the leader may make changes or cancel the meeting for all attendees
- when an individual attendee deletes a leader-scheduled meeting, the leader is notified
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):
A scheduler is authorized to send (via the Calendar Tool) to user X if either of the following is true:The following attendees will not automatically be sent meeting requests because you are not authorized to schedule a meeting for them: ...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.
- she is a leader of a group of which user X is a member
- she is listed by user X as one of the individual users from whom meeting requests are accepted (see Section ).
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:
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:
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:
Some frank and 100% truthful discussion goes here.
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:
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."This statement was removed on the grounds of non-uniformity of behavior. The original rationale for having the non-uniform behavior (i.e., arrows ignore multi-window mode) was solely one of UI ergonomics. Specifically, ergonomically it is nice to leave the mouse in the same place when traversing via the buttons, so the user can just "stand" on the same button and keep moving along. The reason this is not an issue when using the menu command is that the user has to have moved the mouse anyway.
"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.
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:
The would-be rationale for choosing the item-specific style was based on the following considerations:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.