2.13. Graphical User Interface Details

2.13.1. 28jun01 Note

May be OK to relax dialog history requirements if a particular GUI environment does things consistently differently. Give some examples, of e.g. Java versus how things are defined here.

2.13.2. View Command Display Details

2.13.2.1. Resizing Windows

The default size of the view displays is based on the size of the currently selected display font. In specifying display size, the following standard units of typographic measure are used:

Unit Meaning
p one printer's point = 1/72 inch
S user-selected font size in points; default font is 12-point courier
V vertical height of text line, including vertical spacing = 1.2 x S
em width of a representative "m" character = 6 x S

Based on these units, Table 10 defines the default size for each of the view- level display windows.

View Level Dimensions
item 60em wide by 34V high
day time column is W+4em wide, where W is the width in characters of widest displayed time; title column is 64em wide; total height is TIem x Rem, where TI is the current setting of the time increment option and R is the total number of displayed rows based on the current settings of the normal time range and show/hide 24 hours options
week each day column is 10em wide; total width is N columns, where N is the number of days based on the current setting of the normal day range option; total height is 24V
month each day cell is 10em square; total width is 7 cells; total height in cells is based on the number of days in a month
year 72em wide; total height is 14V + W1V + W1V + W1V + W1V, where each Wi is number of weeks in the month with the most weeks for each of the four quarters of the year.

In all displays, border lines are 1p and the spelled-out date banner at the top is 1V high.

The user may change the default font family and size in the preference setting dialog.

In general, all views scale evenly when the display window is resized, but font size does not change. There is no maximum window size, other than that dictated by the physical limits of a particular display screen. The minimum window size is generally based on the size of the currently selected text font. Specific details of resizing windows follow.

Display features for the day view:

The precise default format of an item listing is as follows:

  1. The item begins with the starting and ending times, separated by a dash.
  2. If the starting and ending times are both in the AM or PM, then the numeric time values are separated by a dash with no surrounding spaces, and the pair is followed by one space and then "AM" or "PM" designation.
  3. If the starting time is in the

2.13.2.2. Details of Horizontal Overlap Display

The example to address here is when in the context of Figure 18 the user adds appointments at the following times: 3-4PM, 2:45-3:15PM, 3:15-3:45PM.

Here's the rule that I think works, which may be easier to explain if we think some more about it. For any day, create sets of items with any overlap whatsoever. Sort those items by the normal criteria, vis a vis earliest start time, shortest duration, alphabetically earliest title. Within this list, move all items over as far as possible to the left, as long as the no two items in the same column overlap and the sorting criteria continue to be met. It appears what we're doing is maximally filling each column, i.e., not leaving any space blank in a column if a none overlapping item will fit there. If tow or more items will fit in a give space, then the one chosen is the one earliest in the sorting order, with the unchosen one relegated somewhere to the right, in the (recursively) correct position. "Recursively correct" means in the leftmost column where it will fit such that all criteria are met.

2.13.3. Banner Augmentation

Other user, if any, comes first, preceded with "-- USER: ". Filtering, if any comes next, per details described elsewhere. If banner isn't wide enough, text is truncated, with trailing "..." added, and expands if window expands.

Don't forget about the "SCHEDULER CHANGED" annotation and where it fits in the banner pecking order. It's probably first, therefore pushing other possible augmentations to the right, with "..." addded as necessary.

2.13.4. Window Positioning for Next/Previous Commands

At the day through year levels, the window position stays fixed at the top. At the item level, the window position stays fixed at the bottom. OK, the spelling out in the last sentence made me realize that its pretty bogus and non-orthogonal. So, we'll change the item-level display to have the time and data at the top.

2.13.5. Non-Modal Dialogs

Make sure the effect of window closing is 100% defined. Hopefully close === Cancel works most or all of the time.

Unless otherwise noted in the scenarios, all dialogs are non-modal. It would be prudent here to list exactly the (hopefully few) cases where modal behavior is enforced. We should also discuss what happens when would-be modal dialogs are closed, viz., and not necessisarily limited to, reminders and meeting notifications. Another interesting case is when the same user executes two or more `Schedule Meeting' operations while an original such operations is in the synchro stage. It seems clear that this should mean that the user is put in the queue behind himself (!).

I'm thinking that --maybe-- modal dialogs should never appear in the windows list, hence we don't need to mention window modality when we discuss the `View Windows Close' command, as we don't currently do. We do need to address the issue that any "pending" activities are canceled with a window is closed.

Somewhere we need to address what it means for the system to interrrupt a modal dialog, particularly with the proceed-to-schedule notification. In this case, I'm pretty sure that it should mean the modal dialog is canceled, which means we have to be careful to put a cancel button in all modal dialogs.




Prev: error-conditions | Next: multi-user-envir | Up: functional | Top: index