14,15c14,15 < This section covers details of data entry and command usage that have been < fully elucidated in the preceding scenarios. --- > This section covers all data-entry and command usage details that may not have > been fully elucidated in the preceding scenarios. 17c17,19 < --- > > > 19c21 < 2.11.1. Default Action in Dailogs When Enter Key Pressed --- > 2.11.1. Command Enabling and Disabling 23,24c25 < Spell this out, as generically as possible, for all dialogs. It's very < annoying not to have this work right. --- > Cover exactly which and when commands are enabled and disalbed. 26c27 < --- > 28c29 < 2.11.2. Command Enabling and Disabling --- > 2.11.2. Pressing OK (4sep02) 32,61d32 < Cover exactly which and when commands are enabled and disalbed. One known ref < to this section is from < < Section 2.3.6.4, < < wherein is raised the issue of calendar "modification" commands being disabled < when the current calendar is that of another user or group. Another issue is < that just about all commands should be disabled where there is not current < calendar open. <

< Points to cover: <

< All but New, Open, and Exit are disabled in the < File menu <
< The Schedule menu, and all of its items, is disabled when there is no < open calendar. <
< All but the last four items in the View menu are disabled where there < is no open calendar. <

< I think a table with each command, or groups of commands would be good. The < table would have two columns -- commands and when enabled. State the commands < are disabled in all other circumstances. The commands column would probably be < well organized by menu, so there's a couple levels of command hierarchy in it. < < 3 "Pressing OK (4sep02)" <

122c93 < Figure 323. --- > Figure 305. 134c105 <

Figure 323: Dates entered in different format than set in --- >

Figure 305: Dates entered in different format than set in 145c116 < Figure 323 --- > Figure 305 148c119 < displayed item appears as shown in Figure 324, where the dates and times are --- > displayed item appears as shown in Figure 306, where the dates and times are 158c129 <

Figure 324: Dates entered shown per current option setting. --- >

Figure 306: Dates entered shown per current option setting. 230,237d200 < We don't need to include Sched-By, On, and/or Host as part of uniqueness as < well, in case (rare) that two people schedule exactly the same meeting on two < different hosts. This was addressed already in the meeting-scheduling section, < < here, < < and should be reiterated here. <

280c243 < of available locations, as shown in Figure 325. --- > of available locations, as shown in Figure 307. 286c249 <

Figure 325: List of available locations.

--- >

Figure 307: List of available locations.

291,298d253 < The deal with this this is that it could get too long, in which case the < location DB dialog should come up instead of a pulldown list. There needs to < be a way to set the length value at which the listing changes from a pulldown < to the separate dialog window. Also, the down-pointing arrow should change to < somthing like a right-pointing arrow when this happens. And one more detail -- < if a location is selected from the DB, then what should appear in the type-in < text field is the of the form <Name>, <Number>, i.e., the < comma+space-separated concatenation of the location name and number. 440c395 < dialog shown in Figure 326. --- > dialog shown in Figure 308. 449c404 <

Figure 326: Required fields error dialog.

--- >

Figure 308: Required fields error dialog.

487c442 < Section 2.17.39 --- > Section 2.17.33 555c510 < example, Figure 327 shows how the system highlights the date of September 1 --- > example, Figure 309 shows how the system highlights the date of September 1 565c520 <

Figure 327: Reverse video selection highlighting.

--- >

Figure 309: Reverse video selection highlighting.

610c565 < Figure 8. --- > Figure 9. 633,645c588 < appear in the admin dialogs. An important detail is how the fuck the regular < expression search is enacted, which is not at all clear from the discussion < (actually mention) of it in the "other user" section. Presumably, it could < work like emacs' incremental re search, but this needs to be clarified. <

< A really great motherfucking idea is to move re search to the future work < section. I think I'll do it. (Good for you, motherfucker.) <

< OK, motherfucker, not motherfucking quite. RE search is pretty major part of < filtering. So, what we can do to speed things the fuck up here is to cite some < external source for the definition of regular expression, and be done with it. < We do still need to explain moby re search in the admin dialogs, or eliminate < it there, which would probably be just fine. --- > appear in the admin dialogs. 683c626 < how boring it was to have all of those details piled up there. --- > how boring it was to have all of those details piled up there. 708c651 < Add enabled when any currently undefined list name appears in the --- > Add enabled when any currently undefined list name appears in the 712c655 < Change, Delete, and Apply enabled when any currently --- > Change, Delete, and Apply enabled when any currently 762c705 < and needs to be generalized here for all combo boxes: --- > and needs to be generalized here for all combo boxes: 764c707 < When `specific date' is initially selected, the system clears the text --- > When `specific date' is initially selected, the system clears the text 766c709 < `specific date' is subsequently selected, the system restores and --- > `specific date' is subsequently selected, the system restores and 946c889 < --- > 948c891 < 2.11.26. Units of Measure --- > 2.11.26. Non-Modal, Calendar-Specific Dialogs 952,1102d894 < Put this here, or probably someplace else, but the bottom line is the "pixel" < must be defined as "the atomic unit of screen-size measure for a particular < display". This is the measure used by the underlying operating environment to < describe screen measurements, as in the screen size is 1024 x 768 "pixels". < < <

< 2.11.27. Options Data <

< <

< Hopefully in most cases, details have been covered in other dialogs to < which otions apply. I believe the following are specific to options: <

< In scheduling meetings: the left and right screen positions are in pixels and < must be between 0 and the max dimensions of the screen. <

< < <

< 2.11.28. Lexical Sorting <

< <

< Unless stated explicilty to the contrary, all preceding refereneces to < "alphabetic order" mean case insesnitive order based on the lexical colating < sequence in use on a particular operating environment. Typical lexical < collating sequences are ASCII and UNICODE. < < <

< 2.11.29. Dialog Memory <

< <

< Specified as options for scheduling dialogs. <
< As most recently closed for (I think all) others; should proably itemize these, < with the following having come particularly to mind: <
- < the file dialogs, which should remember the last path they were on; at startup < they should always go to the user dir <
- < major edit dialogs, which presumably come up the last way the looked when < closed during the current session, and some other reasonable defatul way after < start up; this reasonable default is most likely just the way the appear in < their first figure in the scenarios <
- < need to make a decision about the little detail of whether dialogs remember < when ever closed, or only when closed with confirmation (`OK'), but < not with `Cancel'; the idea here would be that if they're closed with < `Cancel', they'll remember the last time they were closed with < `OK', or the last time they were opened, whichever occurred most < recently. <
<

< < <

< 2.11.30. Email Address Validation <

< <

< < <

< 2.11.31. Unbounded Limits on Calendar Size and Numbers <

< <

< < <

< 2.11.32. Calendar Specificity and Modality of Dialog Windows <

< <

< One way or another, include unprocessed meeting notifications in the category < of pending edits. The term "pending edit" is used explicitly in the file < section for the close (and exit) commands. The def there is this <

< A pending edit is any unconfirmed or unapplied change the user has made in one < or more of these dialogs. <

< The term should be defined more fully here, if necessary, in terms of the < lowest level of dialog editing detail. <

< Here's a tad of fodder about reviewing unprocessed notifications that may < require an explicit dialog of its own, but I think and hope the fuck not, < instead piggy backing on the existing way that notifications are reviewed in < the meetings section, and doin the thing about the system proceeding without < further confirmation, answering affirmatively on the users behalf everywhere. <

< Here are non-model editing dialogs that are calendar-specific, one-per- < calendar: <

< all four scheduling dialogs <
< category editing dialog <
< custom lists editing dialog <
< custom filters dialog <
< options dialog <

< Here are non-modal selecting dialogs that are calendar-specific, one-per- < session: <

< find -- if calendar changes, the find happens in it <
< goto date -- if calendar changes, the goto happens in it <

< Here are non-modal viewing dialogs that are calendar-specific: <

< view other user dialog <
< view group dialog <

< Here are non-modal dialogs that are not calendar-specific: <

< host connection table -- lines in the table are calendar-specific, but the < overall table applies to the entire session <
< all three database viewing dialogs <
< contact admin -- dialog is self-contained in that it contains the host address < to contact <

< Here are the modal dialogs, all are calendar-specific: <

< everything in the file menu -- cal-specificity of save/load settings is that < saving save those of current cal, loading loads into currennt cal <
< admin->password dialog <
<

1113c905 < custom filters --- > custom fileters 1117,1124c909 < host(s) -- 9jul94: I think this needs to go as cal-specific data, since we'll < have the connection table save it; a problem with having it cal-specific is < that their could be confusion with connection table, e.g., the connection table < might well be expected to grow and shrink as cals are opened and closed; also, < it seems cleaner to have host association be independent of the cal itself, < since hosts may come and go, and we can have the connection table be the place < where this is dealt with, rather than having a potentially obsolete host in a(n < old) cal. --- > host(s) 1145,1150c930,935 < file, regular File->Save does that). Load means load from a type-specific data < file or from part of a cal file. Changes to any and all cal-specific data are < saved to the specific cal file to which they belong using the File->Save < command, thereby obviating the need for a separate Save command in the cal- < specific data editing dialogs. As a brain-assisting convenience, the offer-to- < save dialog may mention the type of the data that are unsaved, as in --- > file). Load means load from a type-specific data file or from part of a cal > file. Changes to any and all cal-specific data are saved to the specific cal > file to which they belong using the File->Save command, thereby obviating the > need for a separate Save command in the cal-specific data editing dialogs. As > a brain-assisting convenience, the offer-to-save dialog may mention the type of > the data that are unsaved, as in 1192c977 < I think the following paragraph is way too confusing and potentially error --- > I think the following paragraph is way too confusing and potentially error 1202,1203c987,988 < one dialog total for each (calendar-specific) data-entry command, and < the dialog applies to one of these: --- > one dialog total for each (calendar-specific) data-entry command, and the > dialog applies to one of these: 1223c1008,1010 <

> pros: avoids window proliferatino, of which there is potential for much already 1225c1012,1014 < pros: avoids window proliferation, of which there is potential for much already --- > cons: see individual points that follow immediately >

> (L i 1227,1228c1016,1017 < cons: For the the current calendar, this requires that dialog contents change < when cur calendar changes, including the notion of a "pending" operation for a --- > the current calendar: requires that dialog contents change when cur > calendar changes, including the notion of a "pending" operation for a 1230,1233c1019,1024 < between calendars. For the calendar that was current when the dialog command < was originally executed, this makes it potentially confusing as to which < calendar dialog applies to and potentially inconvenient to change scheduling < focus between calendars. --- > between calendars >

> the calendar that was current when the dialog command was originally > executed: makes it potentially confusing as to which calendar dialog > applies to and potentially inconvenient to change scheduling focus between > calendars 1237c1028 <

1243c1034 <

--- > 1246c1037 <

1252,1253c1043 <

--- > 1303c1093 < Closing this window will close the calendar. --- > Closing this window will close the calendar. 1371a1162,1203 > >

> 2.11.27. Units of Measure >

> >

> Put this here, or probably someplace else, but the bottom line is the "pixel" > must be defined as "the atomic unit of screen-size measure for a particular > display". This is the measure used by the underlying operating environment to > describe screen measurements, as in the screen size is 1024 x 768 "pixels". > > >

> 2.11.28. Options Data >

> >

> Hopefully in most cases, details have been covered in other dialogs to > which otions apply. I believe the following are specific to options: >

> In scheduling meetings: the left and right screen positions are in pixels and > must be between 0 and the max dimensions of the screen. >

> > >

> 2.11.29. Lexical Sorting >

> >

> Unless stated explicilty to the contrary, all preceding refereneces to > "alphabetic order" mean case insesnitive order based on the lexical colating > sequence in use on a particular operating environment. Typical lexical > collating sequences are ASCII and UNICODE. > > >

> 2.11.30. Email Address Validation >

> >