Heading:qjk40(635) Minutes of Database Applications Group June 14, 1982y756qjk40 Page Numbers: Yes X: 527 Y: 10.5"qjk40 Inter-Office Memorandumz18592l4445y762\f5b To Database Interest Group Date June 14, 1982z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f1 2f0t2 1t0 23t6 1f1t0 4f0t7 1t0 From Rick Cattell Location Palo Altoz18592l4445d2998y716e25\f1 4f0t2 1t0 12t6 1f1t0 8f0t7 1t0 Subject Minutes of Database Applications Organization CSLz18592l4445d2998e25\f1 7f0t2 1t0 32t6 1f1t0 12f0t7 1t0 Group meeting, June 14, 1982z18592l4445 XEROX z18592l508y644e14(2116)\f2 5f0 Filed on: [Indigo]Doc>6-14-82.minutes Attendees: Rick Cattell, Jim Donahue, Dave Gifford, John Maxwell, Willie-Sue Haugelande30 e10 Purposee12jk40\b7B 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.e12jk40 The meeting was instigated by a message from Rick with the following ideas. e12jk40 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:e12jk40 (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.l4269d3264e12jk40(0,4256)(1,65535)(5,65535)(6,65535) (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.l4269d3264e12jk40 (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.l4269d3264e12jk40 (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. l4269d3264e12jk40 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.e12jk40(2116) 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.e12jk40 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.e12jk40 Existing entity viewerse12jk40\b 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.e12jk40 There are two possibilities:e12jk40 (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.l4269d3264e12jk40(0,4256) (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.l4269d3264e12jk40 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.e12jk40(2116) 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.e12jk40\30i3I 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.e12jk40\33i7I 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:e12jk40 (1) [replace] replace the old viewer (parent) with the new one,l4269d3264e12jk40(0,4256) (2) [any] re-use a viewer originated from the same source (parent) if their exists one else create a new one,l4269d3264e12jk40 (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.l4269d3264e12jk40 New and Old Viewers e12jk40(2116)\b19B 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.e12jk40 Button interpretationse12jk40\b22B 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: e12j\134i7I225f1 156f0 (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.l4269d3136e12jk40(0,4256)\6u6U (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.l4269d3136e12jk40\7u4U Multiple and Global Selectione12jk40(2116)\b 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.e12j\25i8I16i6I I can think of four kinds of commands in a nut's menu:e12j\f1 54f0 (0) Commands that need only one argument, the entity itself; e.g. erasing the entity.l4269d3264e12jk40(0,4256)\f1 (1) Commands that require two arguments but only a local selection, e.g. deleting a message from a message set.l4269d3264e12jk40\f1 (2) Commands that require external (global) selections, e.g. adding a message to a message set.l4269d3264e12jk40\f1 (3) Commands that require multiple local selections, e.g. moving a set of messages to another message set.l4269d3264e12jk40\f1 (4) Commands that require multiple local and global selections, e.g. moving a set of messages to another set of message sets.l4269d3264e12jk40\f1 105i3I We might call these 0-order, 1st-order, 2nd-order, 3rd-order, and 4th-order operations.e12j(2116)\f1 87f0 e12j Implementatione12jk40\b14B (635) 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]l4269 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.j 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.j