Heading:

Minutes of Database Applications Group June 14, 1982

Page Numbers: Yes X: 527 Y: 10.5"

Inter-Office Memorandum

ToDatabase Interest GroupDateJune 14, 1982

FromRick CattellLocationPalo Alto

SubjectMinutes of Database ApplicationsOrganizationCSL

Group meeting, June 14, 1982

XEROX

Filed on: [Indigo]<Squirrel>Doc>6-14-82.minutes

Attendees: Rick Cattell, Jim Donahue, Dave Gifford, John Maxwell, Willie-Sue Haugeland

Purpose

We met to discuss possible commonality between the user interfaces of the various database applications. The hypothesis was that we’ve had enough experiences with our respective applications to arrive at a straw-man proposal for partial consistency, e.g. what the "red" and "blue" mouse buttons mean. With our different applications in mind we arrived very quickly at some consensus, so the hypothesis is probably true. We do not want to squash experimentation in aspects of the user interface, however; only to arrive at as much commonality as seems obviously desirable at this point.

The meeting was instigated by a message from Rick with the following ideas.

Walnut, Hickory, Squirrel, Whiteboard, Viewers "Flying", and future database applications all have something in common in the semantics of the basic user actions. In particular, they all want to interpret "pointing to see something", i.e. opening up a representative of an object to see more detail. We do this with our database applications by creating a new viewer on the entity (call this the "target") selected in the original viewer (call this the "source"). The question is, where do we put the target viewer? When do we create a new viewer, and when do we try to re-use some existing one? For example, when you view a month and select a day, you usually want to create a new viewer for the day. When you select another day in the same month, should it re-use the same day viewer? What about selecting a day in another month? How can the user indicate when (s)he wants to re-use a viewer, and when (s)he wants a new one? The same questions arise for MsgSets and Msgs in Walnut, Whiteboards and their contents, and browsing in Squirrel in a personal database. Here are some possibilities, of which we may choose more than one:

(1)[Replace] Replace the source viewer with a target viewer. I believe this is the default with red button in Whiteboards and with blue button in Squirrel and Hickory. Their should be a BACK command that gets you back to the previous contents of a viewer in conjunction with this kind of selection.

(2)[Proliferate] Create a new viewer on the screen for the target. This is currently the default with red button in all the database applications except Whiteboards. It’s a bad default, because the screen fills up with viewers.

(3)[Domain-based] Re-use the most recently created viewer on an entity of the same domain (= type) if it exists. Thus there would be one Msg viewer that would continue to be re-used, and one Day viewer, and so on.

(4)[Source-based] If a selection has been made before in the source, re-use the same viewer which that created. Thus successive selections in the same MsgSet or Month will keep re-using the same Msg or Day Viewer, respectively. But if we look at another MsgSet or Month, it will use another Msg or Day viewer. Selection of items in the Msg or Day viewers, say recipients or meetings, will create a new viewer which again can be successively re-used by other selections in the Msg or Day viewer.

Options (1), (2), and (4) can be augmented by allowing the user to explicitly override re-use of a viewer by bugging a "Keep" command on the viewer that keeps it around until the user bugs "Destroy" on it. Any attempts to replace it result in a new viewer being created instead. Thus we could see two Msgs at once by Keep-ing the first one.

We could choose two of the options that are consistent across all applications, e.g. red-button means source-based viewer, blue-button means replace viewer. Or, we may want to have only of these options (say blue-button means source-based viewer) and use another button to mean selection (highlighting). This is consistent with selection and opening of icons in Viewers, for example.

There is a second, closely related problem to what one does with selection: what to do with commands that involve two entities (viewers). For example, how do you say to add or remove Msg A from MsgSet B? Or object A from Whiteboard B? This problem enters into any world with object-based commands (on Msgs, MsgSets, Whiteboards, etc.) such as ours. Rather than entering a mode where we prompt for the second argument, it would be nice to somehow "select" an entity viewer on the screen, say a Msg, and then go over and do an Add command on a MsgSet. In fact we probably want to "select" the newly created viewers in options (3) and (4) by default. That way when a Msg in a MsgSet is displayed, the Remove command in the MsgSet removes that Msg, and the Add command in another MsgSet adds that Msg.

Existing entity viewers

Willie-Sue brought up the subject of what to do when the user attempts to create a new entity viewer when a viewer on the entity is already on the screen. This could happen, for example, when the same message is in two message-sets, and the user selects it in both. Or it could happen when users are browsing through a personal database and find their way back to an entity they already have on the screen.

There are two possibilities:

(1)Ignore the fact that the same entity may already be on the screen, possibly having more than one viewer on the same entity as a result.

(2)When an entity already on the screen is selected, make that viewer be non-iconic or "blink" it by repainting. John uses this method with tool viewers on whiteboards.

Alternative (2) could save some screen real estate, although it could be confusing to flip through a number of entities and suddenly find a viewer up in the corner re-used. On the other hand, alternative (1) can be confusing, too; witness how one can accidentally create two viewers on the same text file in Tioga, editing one without noticing the existence of the other.

We finally decided that we do not normally need to have the system recognize entities already on the screen: alternative (1). If some application cares, as Walnut does with MsgSets, and Whiteboards with Tools, then they can implement a CreateProc that does the enumeration and re-uses an existing viewer if it exists. The Nut interface should probably export a procedure that does this to make these applications easier.

Willie-Sue suggested an optional oneOnly argument to DisplayProc in the Nut interface, allowing the caller to specify that alternative (2) should be taken instead of (1), the default. We decided to do this.

After the meeting, John pointed out that this optional argument must actually be three-valued, because we still need the ability to replace viewers, e.g. when a displayer nut is turned into an editor nut. So the third argument is an enumerated type specifying one of three alternatives:

(1)[replace] replace the old viewer (parent) with the new one,

(2)[any] re-use a viewer originated from the same source (parent) if their exists one else create a new one,

(3)[oneOnly] blink the existing one if there is already a displayer on the given entity, else re-use one from the same source (parent) if their exists one, else create a new one.

New and Old Viewers

We all agreed that the fourth of Rick’s alternatives described in the first section, source-based creation of new viewers, was good for all of our applications. None of us see a need for any of the others. This means that we need dedicate only one button to the function of pointing to see something. We are calling this the "open" function.

Button interpretations

We agreed that the two functions we would most like to be able to do in one mouse-click are open and select. We noted that these are exactly the functions that Viewers already provides on icons with the blue and red buttons, and that icons are exactly analogous to the selectable entity fields in a nut in the sense that they are representatives of the full object. By entity field, we mean the lines representing messages in a message set viewer, or the day boxes in a month viewer, or the icons on a whiteboard viewer. We unanimously decided, therefore, to use the same assignment used by Viewers icons:

(red)Select the field of the given viewer, by inverting or otherwise marking it. This allows it to be used in some later command in a modeless way. For example, one can delete the selected message from a message set in this way.

(blue)Open up the entity referenced by this field. That is, put a viewer for this entity on the screen by the source-based algorithm defined in the previous section.

Multiple and Global Selection

We deferred dealing with multiple selections and global selection. Multiple selection means selecting more than one entity field in a viewer. A command that can act on many objects, like removing messages from a message set, could use such a selection. Multiple selection requires a mechanism to de-select entity fields and/or a mechansim to extend contiguous selections. Global selection means selecting entities outside the viewer to which it will be used as an argument. For example, one might select a message on the screen and then select the "Add" command in a message set to which it is to be added. We decided to think about multiple and global selection for another meeting.

I can think of four kinds of commands in a nut’s menu:

(0)Commands that need only one argument, the entity itself; e.g. erasing the entity.

(1)Commands that require two arguments but only a local selection, e.g. deleting a message from a message set.

(2)Commands that require external (global) selections, e.g. adding a message to a message set.

(3)Commands that require multiple local selections, e.g. moving a set of messages to another message set.

(4)Commands that require multiple local and global selections, e.g. moving a set of messages to another set of message sets.

We might call these 0-order, 1st-order, 2nd-order, 3rd-order, and 4th-order operations.

Implementation

John agreed to make the change to the Nut interface to support our decision. Nut.Display now looks like:

PROCEDURE[e: Entity, parent: Viewer ← NIL,
method: {replace, oneOnly, any} ← oneOnly]

where e is the entity to be displayed, parent is the Viewer that invoked Display, and method is the method used to choose a new Viewer. If method = replace, then the parent is replaced. This is necessary for converting from "display" viewers to "edit" viewers, for example. If method # replace and parent # NIL, then the last viewer spawned from parent is replaced. If there is none and method = oneOnly, then Squirrel will use an existing viewer, if any. If none of the above hold, a new viewer will be created.

He also fixed Squirrel so the user can close and re-open databases from the window. To do so, the user just edits the name of the data base and then bugs "Open". The mechanisms to notify applications of closing and opening databases are already in place and used in checkpointing. In checkpointing, Squirrel takes down all nuts and re-creates them on rollback. In closing and re-opening, Squirrel should simply take down all nuts since the same entities may not exist in the new database.