Whiteboards: A Graphical Database Tool JAMES DONAHUE Xerox Corporation and JENNIFER WIDOM Cornell University
The “Whiteboards” system is intended to be an electronic equivalent of the whiteboards and corkboards that we have in our offices. A Whiteboard database has similar qualities of storing disparate collections of data and saving their spatial location in a window to help with organization. A Whiteboard database can contain references to arbitrary entities: text files, notes, programs, tools, pictures, etc. Whiteboards runs as an application in the Cedar programming environment developed at the Xerox Palo Alto Research Center. Categories and Subject Descriptors:
H.2 [Database
Management];
H.4.1 [Office
Automation]
General Terms: Design, Management Additional
Key Words and Phrases: Databases, programming
environments
1. INTRODUCTION One of the problems with developing electronic extensions of our offices is that computer systems frequently lack the flexibility of many of our “low-tech” office tools. As a simple example, a typical office at the Xerox Palo Alto Research Center (Xerox PARC) has a whiteboard and a corkboard; the whiteboard is often filled with random notes about work in progress (lists of things to do, sketches of algorithms, etc.), while the corkboard has stuck to it letters to be answered, business cards of people who must be contacted and perhaps even artwork. Most computer systems, while having all sorts of filing and retrieval systems, generally do not have tools that allow such collections of relatively unstructured items to be organized. Moreover, spatial clues are often used to organize the material stored on whiteboards or corkboards; for example, the upper-right-hand corner may contain the latest performance figures for a software system being developed. Again, most of our computer systems do not allow spatial relations to be exploited. The “Whiteboards” system is intended to be an electronic equivalent of the whiteboards and corkboards that we have in our offices. A Whiteboard database has similar qualities of storing disparate collections of data and saving their spatial location in a window to help with organization. A Whiteboard database can contain references to arbitrary entities: text files, notes, programs, tools, Authors’ addresses: J. Donahue, Xerox Corporation, Palo Alto Research Center, 3333 Coyote Hill Rd., Palo Alto, CA 94304;
[email protected]. J. Widom, Department of Computer Science, 405 Upson Hall, Cornell University, Ithaca, NY 14853;
[email protected]. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 0 1986 ACM 0734-2047/86/0100-0024 $00.75 ACM Transactions on Office Information
Systems, Vol. 4, No. 1, January
1986, Pages 24-41.
Whiteboards: A Graphical Database Tool
Fig. 1.
25
Cedar screen.
pictures, etc. Furthermore, a Whiteboard display allows the user to move these entities around on the screen and then to save their positions in the database; thus spatial relations among items can easily be established and maintained. Because of their simplicity and flexibility, Whiteboards have become widely used inside the Computer Science Laboratory at the Xerox Palo Alto Research Center. Whiteboards runs as an application in the Cedar programming environment [7]. We first give a brief description of the Cedar user interface and discuss some of the important software components of the Cedar environment. We then talk about how one browses a Whiteboard database. One important use of Whiteboards has been to build a database for documenting the Cedar system itself: We describe this particular Whiteboard database to illustrate the simplicity and flexibility of the system. We then describe how a user creates and edits a Whiteboard database. Next we discuss some of the more interesting implementation aspects of Whiteboards, especially the treatment of transactions in the system, and give some observations about the Cedar environment based on the implementation of Whiteboards. 2. THE CEDAR ENVIRONMENT 2.1 User’s Interface
Figure 1 is a picture of a Cedar display; the salient characteristics for this presentation are that the screen is divided into two columns and a row of icons ACM Transactions on Office Information Systems, Vol. 4, No. 1, January 1986.
26
l
James Donahue and Jennifer Widom
at the bottom. Each noniconic window has a menu associated with it; the screen itself also has a row of menu buttons (for system operations) across the top. Each window can display text or graphical data or can hold buttons to invoke operations of the various tools in Cedar. The icons in the icon row represent items of potential interest that are not currently in active use. These include files that have been recently examined, electronic mail messages, and control windows for various tools that have been run (e.g., the mailbox and tool box icons in the picture). Moving the mouse over an icon and clicking with a mouse button “opens” the icon, creating a full-sized viewer in the left or right column. Although the contents of the windows in this screen are unimportant, one of them, the window in the left-hand column, is a Whiteboard window (windows in Cedar are called “viewers”), which displays the contents of a Whiteboard stored in a public database. Also, in the icon row there is another Whiteboard (labeled Basics). Several Whiteboards from a public or private Whiteboard database may exist simultaneously on the display at a given time. Finally, note that pictured on the open Whiteboard viewer are two more iconic Whiteboards (labeled cedar and ToolBox). These too can be opened and displayed on the screen. For further discussion of the Cedar user interface, see [7]. 2.2 Programmer’s
interface
There are several important components of the Cedar programming environment that provide the basis for the Whiteboards implementation; they are Alpine-a transaction-based file server, written in the Cedar language [2]. Alpine provides page-level file access and locking and is used primarily as the storage medium for databases. The Whiteboards code does not directly use Alpine, but the fact that public databases are stored on Alpine servers does affect the Whiteboards implementation, for example, in its handling of transactions. Cypress-an entity/relationship model relational database system [3]. Cypress is used by a number of database applications in Cedar, including an electronic mail storage system, a database of information on Cedar users, and Whiteboard databases. Cypress does not provide its own transactions, but simply lets the user open Alpine transactions on Cypress databases. Cypress runs on the client workstations and uses the Cedar remote procedure call protocol to access pages of tiles stored on Alpine servers. Viewers-the Cedar window manager [l, 71. Viewers is the arbiter of the user input and display hardware in the Cedar programming environment. It provides the illusion to the programmer that there is a private display, mouse, and keyboard associated with each application, while allowing the user to simultaneously interact with many such applications. Imager-the graphics package in Cedar. Whiteboards uses the Imager to display the pictures of Whiteboards on the screen. Tioga-the Cedar editor, used for both program and document preparation. Whiteboards may include windows containing editable Tioga text. When we discuss the Whiteboards implementation, how each of these components is used in the system. ACM Transactions
on Office Information
we describe in more detail
Systems, Vol. 4, No. 1, January 1986.
Whiteboards: A Graphical Database Tool
Cedar
5.2 Documentation
l
27
Browser
Las1 edited by: Donahue. November 1.1984 9:2?:54 mlt PST This database descritws L bwge portion of the available Ceaar documentation and includCs references lo L number of the most widely used Ceadr tools, The aalab()Lseconsists of several Whiteboards. erch of which contains references to other whiteboards. lo various filer that contain document&lion ana Cedar interfaces. and lo tools that you will fin0 useful,
will (nfler L little while) clelte this viewer on your screen. To browse around the whileboards. just MIDDLE click the icons lo “open” them -displaying the text file or starling the tool (Note: sldrling I tool may take some time, ~9 files may need to be fetched from the server). The ToolBox whileboard below contains a (growing) number of Cedar tools for your snjoymenl. Also, check the BriejingBIurb below for the scoop on PARC and Cedar.
The whiteboards given below provide information about the basic opett&m of CeOa$ the Cedar lr?gulge. the major compqnents of the Cedar system (things you’ll use most of ths llms). the most w”d”a,y used Ceahr tools (like the mail system, etc.), and the important progtrmminginterfaces of I Also. &d the Introduction referenced below -_ it gives important general informdlion about the use of Cedar. And. when you get tirea of reading all of the information you will (eventually) need, try out the games!
The Briejing
Blurb
The tlulh about PARC and Cedar _- everything you w~nl to know about lhs locrl environment (including hints im gracious living), The glossary provides 811the “PARC-speah” you’ll need lo gel by.
SHlFT IllDOLE a> open icon hlllsize
Fig. 2. Whiteboard viewer.
3. BROWSING
WHITEBOARDS
3.1 The Structure of Whiteboards
and the Browsing Operations
A Whiteboard viewer contains a collection of text boxes and icons. The spatial arrangement, along with the contents of the text boxes and the names of the icons, is stored in a Whiteboard database. The Whiteboard browser is responsible for storing the arrangement of a Whiteboard in a database and then later reconstructing the viewer from the stored information. Additionally, the browser implements the semantics of “opening” an icon on a Whiteboard: Opening a Whiteboard icon has the same effect as opening a similar icon that is instead residing in the icon row of the Cedar display (recall Figure 1). This may involve opening a file (for text file icons), performing database operations (for Whiteboard icons or icons that refer to entities in other databases), or running a program (for tool icons). Figure 2 is a picture of a Whiteboard named Cedar, on ACM Transactions
on Office Information Systems, Vol. 4, No. 1, January 1986.
28
l
James Donahue and Jennifer Widom
which there are icons for other Whiteboards (e.g., Basics), text files (e.g., Glossary.tioga), and tools (e.g., WalnutSend). The important points to note about this Whiteboard display are the following: (1) The viewers on a Whiteboard can be positioned arbitrarily. Like a whiteboard in an office, the spatial arrangement of the display can be used as a tool in organizing information. (2) A text box (for instance, the box containing the heading Cedar 5.2 Documentation Browser) may contain any formatted text that can be created using Tioga. Such a viewer on a Whiteboard is no different from the viewer used in normal document creation-all formatting options are available, and the text box contains a “scroll bar” so that the amount of text may arbitrarily exceed the size of the window. The scroll bar is used to bring the hidden portions of the text onto the Whiteboard display. The size of a text box can be easily changed by “dragging” one of the corners of the box with the mouse. (3) Any icon that can appear in the icon row on the bottom of a Cedar screen can also appear on a Whiteboard. This includes icons that refer to text files, other Whiteboards, entities from other databases, or Cedar tools. The fact that Whiteboards can contain other Whiteboards means that one can build up arbitrarily complicated graphs of Whiteboards, making them quite suitable for information browsing. These connections among Whiteboards are easy to insert using the Add Selected editing operation, described later. The three basic operations that the Whiteboard browser comprises are described below. Each one is activated through use of the mouse.
(1) Open Icon. When the cursor is positioned over an icon on a Whiteboard and the middle mouse button is clicked, the selected icon opens on the screen. In general, the new window created will share the column in which the containing Whiteboard is displayed. For example, if we are examining the Whiteboard pictured in Figure 2 and wish to activate the WalnutSend tool, a click over the appropriate icon results in the display shown in Figure 3. As described above, the semantics of opening an icon vary according to the icon selected. A text file may be fetched and displayed, another Whiteboard may be opened, or a Cedar tool may be run. In each case, if the appropriate item is already present on the user’s screen, the system will display the existing copy rather than create a duplicate. (2) Open Icon Full Size. The semantics of this operation are identical to “Open Icon,” with the exception that the selected item is displayed in one entire column; any other windows present in that column (including the Whiteboard from which the icon was selected) are reduced to iconic form in the bottom row of the display. (3) Expand Whiteboard. This feature allows the user to browse quickly through an existing network of Whiteboards. Expanding a Whiteboard icon (that resides on an opened Whiteboard) results in the iconic display of all Whiteboards contained in the selected Whiteboard. These new icons can then be opened or likewise expanded. Thus a few such operations will result in a display of all accessible Whiteboards in the database being perused. For example, after expanding the Language Whiteboard icon in Figure 2 and then continuing to ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January
1986.
Whiteboards: A Graphical Database Tool
Cedar
5.2 Documentation
29
Browser
Last edited by: Donahue, November 1.1984 9:27:54 am PST This database describes a large portion of the avail.¶ble Cedar documentation and includes references to a number of the most widely used Cedar tools. The database consists of several Whileboards. each of which conlrins references to other whiteboards. to various files lh&l contain documentation md Cedar interfaces. and to tools that you will find u&ful, If you are running Cedar and would like to browse this database, the command: ///Commands/Whitebodd Cedar will (after a little while) create this viewer on your screen. To browse around the whileboards. just MIDDLE click the icons to “open” them -- displaying the text file or starting the tool (Note: starting a tool may take some time. as liles may need to be fetched Irom the server). The ToolBox whiteboud below contains L (growing) number of Cedar tools for your enjoyment. Also. check the BriefingBlurb below for the scoop on PARC and Cedar.
construction and browsing of Whiteboard The whiwbnards given below provide information about the basic operhlion of Cedar. the Cedar Get s_tere Save Forms New hbject: m .: ~Rec1p1ent54 :: Kopies To4
Default
PrevMsg
Split
P&es
Levels
Message4
Fig. 3.
Opening an icon.
expand some of its “descendants,” we obtain the structure shown in Figure 4. The user can then proceed to open any of the pictured Whiteboard icons. These three operations make up the Whiteboard browsing system. The user interface is simple but powerful, since we are able to treat a disparate group of entities in a very generalized manner. The system that most closely resembles Whiteboards is the “spatial data management system” (SDMS) [5]. Both Whiteboards and SDMS are based on graphical viewing of databases, thus exploiting spatial relationships and encouraging easy browsing of the data. However, SDMS is designed so that first a database is created in a conventional symbolic fashion, and then it is mapped to a graphical browser. In the Whiteboards system the user manipulates the graphical interface only; the database is created and updated automatically. Hence, in SDMS icons are viewed as representations of database entities; in Whiteboards ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January 1986.
James Donahue and Jennifer Widom
Cedar
5.2 Documentation
Browser
Last edited by: Donahue, November 1.1984 9:27:54 ant PST This database describes a large portion of the available Cedar documentation and includes references to a number of the most widely used Cedar tools. The database consists of severe.1Whitebards. each of which contains references to other whiteboards. to various files that contain documenIation and Cedar interfaces, and to tools that you will find useful, If you are running Cedar and would like 10browse this database. the command: ///Commands/Whiteboazd Cedar I wilt (after L little while) c~er.te this viewer on your screen. To browse around the whiteboards, just MIDDLE click the icons to “open” them -- displaying the text file or starting the tool (Note: starting L tool may take some time, as files may need to be fetched from the serve?). The ToolBox whiteboard below contains a (growing) number of Cedar tmls for your enjoyment. Also, check the Brief ingBIurb below for the scoop on PARC and Cedar,
construction bnd browsing of Whiteboard The whiteboards given below provide information about the basic operation of Cedar. the Cedar la?guage. the major components of the Cedar system (things you’ll use most of the time), the most wtdely used Cedar tools (like the mail system, etc.). and t&e unportant programming interfaces of Ce4ltr. Also, read the Introduction referenced below -- it gives important general information t,bout the use of Cedar. And, when you get tired of reading all of the information you will (eventually) need, try out the games!
Fig. 4.
Expansion
on a Whiteboard.
the reverse is true-database entities are simply hidden representations of icons (and text boxes). Finally, we note that unlike SDMS, Whiteboards is fully integrated with the tools of the programming environment in which it is embedded; in particular, the icons that can be stored on a Whiteboard include all of the common Cedar tools. 3.2 The Cedar Whiteboards
The initial work on the Whiteboards system was done primarily as a means of experimenting with the spatial organization of personal data-it seemed like an attractive way to structure a large and fairly unstructured collection of things (a common problem in the office environment). However, it became obvious that the same flexibility that made Whiteboards suitable for managing personal information would make it attractive for managing the large collection of diverse ACM Transactions on Office Information Systems, Vol. 4, No. 1, January 1986.
Whiteboards: A Graphical Database Tool
..“““_
Cedar
..““““*““-”
-““.““.
Language
-.---
----.
l
----
Documentation
C.dU ‘rl
The Cedar programming language is stt extension of Mesa; it is described in the Overview document given below. See the Components and Interfaces whiteboards for some of the most commonly used Cedar interfaces. The Cedar Syntax file gives the complete (and accurate!) syntax for the lattgauge. while the Cedar Style document gives helpful hints on how to make your Cedar programs a delight to the eye,
Examples Documenfaf ion zr> The Cedar Examples document includes a number of interesting Cedar programs that illustrate most of the importan~lmgurge features and use many of the basic Cedar interfaces. WHITE@%RD INSTRUCTIONS: LEFT .L move entity; CTRL LEFT .> delete entity; MIDDLE .> open icon SHIFT MIDDLE .> expend icon; RIGHT => grow text box
Fig. 5.
The Language Whiteboard.
information that makes up the documentation and code of a system like Cedar. Thus, we built a collection of Whiteboards to describe the Cedar system itself. The “root” of the Cedar documentation Whiteboards is the Whiteboard labeled Cedar, shown in Figure 2. It contains basic information about Whiteboards themselves, how to get a particular Whiteboard displayed (so that one can go from the picture in hard-copy documentation to the real thing), some generally useful “cultural” items like the Briefing Blurb, and finally a collection of additional Whiteboards giving detailed information on various aspects of the system. For instance, from the Cedar Whiteboard one can choose to display the Language Whiteboard (Figure 5), which contains references to (1) the documents defining the Cedar language, (2) a document giving a collection of example programs, (3) additional Whiteboards describing important components and programming interfaces in the system. Each of the Whiteboards referenced on the Cedar Whiteboard (like the Lanincludes references to other Whiteboards-all include a reference back to the root Cedar Whiteboard, and many include references to Whiteboards that give more detail about particular aspects of the system. In all, there are 18 Whiteboards in the database connected in a general graph structure, mirroring the high degree of interconnection in the Cedar system itself. Perhaps the most interesting of these Whiteboards is the Cedar ToolBox (Figure 6). In addition to fully illustrating the diversity of objects that can be organized together on a Whiteboard, it points out one of the aspects of the Whiteboards system that we have found particularly useful. In any large,
guage Whiteboard)
ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January
1986.
32
.
James Donahue and Jennifer Widom
1 A Cedar
ToolBox
Here are a number of useful (and fun) tools. To find out’more about their us$, check out the whiteboards given below (especially the Tools whiteboard for documentatmn)
~~)~ To evaluate Cedar expressmns
Cedar
WQfCh
Mail
Tools
For sending and receiving mail and getting on distribution lists
Watch your MDS and VM disappear before your very eyes
IMailTools
::::::::::‘,3’~ .::;j:j:j: g::.’,:,? “’ ‘Y
EditTool
I::: :::;., 4iliiib ,:::j: ::::::::.:.:,:.:.:.:.:.:,:.:.:
Make all youi documents a pleasure to look *t (if not to read). The EditHistory Tool will let you undo some of Ihe mistakes you may have just made.
SpellingTool
c*clt
To get the words right
Need to Delver?
Fig. 6.
Cedar ToolBox.
changing environment such as Cedar, one problem is trying to guarantee that accurate information exists (in some form) about the available tools. But even having accurate information is not sufficient; there are the additional problems of knowing that a tool exists, but not where to find it, or being oblivious to the proper tool because one has not come across it in the mountain of system documentation. Users of large programming environments need browsing tools such as Whiteboards so they can spend some time just “hunting around,” familiarizing themselves with what is available in the system. Whiteboards allows the user to browse through available tools, with the additional advantage that from a Whiteboard the user can activate any tool pictured. Thus a user need not know in advance the exact name or where the necessary files are stored on the file servers in order to run the tool. We have found the Cedar Whiteboards to be extremely helpful as a means of introducing newcomers to the features of the Cedar environment. ACM Transactions on Office Information Systems, Vol. 4, No. 1, January 1986.
Whiteboards: A Graphical Database Tool reeze
Resee AddSelected
AddTool
Erase
HELP
Grid:
1 Save
Published high-level Cedar papers Describes the use of Cedar for computel graphics research. Beach, Graphics Interface 84 (Canada, June 84).
features (UserExec. NewStuff) from a user/program developer viewpoint.
cooperation work fmoothly.
categork q them q catalog
HO”IWM CIPII
The CatalogCategories whiteboard represents our attempt to go through the Cedar Catalog and 1) group the entries into possible subsections of the paper, and 2) decide on their relative importance. The attempt was only partially successful: the categories did not seem compelling anb the categorization was sometimes arbitrary. Swinehart and Zellweger September 27.1984 4:34:04 pm PDT The House of Cards is great! It should serve as the unifier of a collection of Cedar papers -- each of can highlight a differenl “layer” tf the house. Jim
C*dawap.P O”t!h
October 11.1984
09:34:04 PDT
A rough outline based upon the HouseOfCards and the CatalogCategories. Sign up for pieces you’d be willing to write!
a.
A place for further discussion/comments. Comments by Jim D., Rick Beach
Fig. 7.
Public Whiteboard
about Cedar papers.
Other public Whiteboard databases have been built for use by groups within the lab; for instance, here is a Whiteboard from a database of notes shared by some of the people working on various papers about the Cedar system (Figure 7). A Whiteboard database of documentation on a major project to build a new high-performance workstation in the Computer Science Laboratory at Xerox PARC is also being used. The documentation on a project like this comes in many forms-notes, diagrams, documents, mail messages-and the “free-form” nature of a Whiteboard database makes it easy to collect and organize this diverse collection of items. This database contains approximately 20 different Whiteboards, covering various aspects of the hardware or software; there is also a Meeting Whiteboard, which contains information about the agenda of upcoming design meetings. Finally, there have been several personal Whiteboard databases built. Next we discuss how Whiteboards are created, edited, and saved in a database. ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January 1986.
34
l
James Donahue and Jennifer Widom
4. CREATING
AND EDITING WHITEBOARDS
In addition to browsing existing public Whiteboards, Cedar users may create, edit, and save their own personal collection of Whiteboards. Indeed, there is no distinction made in the user interface between public and private Whiteboard databases; it is simply the access controls that the file servers provide that prevent users from making changes to public databases for which they do not have write permission. (We have not implemented more fine-grained access controls to allow users to change only some of the Whiteboards in a database.) A new, blank Whiteboard (or a previously saved Whiteboard) is initially retrieved and displayed through the command interpreter (the Cedar equivalent to the UNIX’ “shell”). Editing a Whiteboard consists of adding text boxes or icons (documents, tools, etc.) to a Whiteboard, deleting unwanted text boxes or icons, changing the text in a text box, and spatially arranging the entities in a Whiteboard viewer. The browser and editor are fully integrated; thus, one can easily activate tools, fetch text files, and move through networks of Whiteboards while editing. The following operations comprise the Whiteboards editor: (1) Add Text Box. This operation is invoked by moving the mouse to the position on a Whiteboard where the new box should appear and clicking the appropriate mouse button. The text box is initially empty and of a fixed size; however, it may be easily grown, shrunk, or moved to a different position. The text in a text box is inserted using the usual Tioga operations. (2) Add Selected. This is the facility for placing icons on a Whiteboard. This operation is invoked through the Add Selected menu item visible at the top of the Whiteboard examples given above. It takes the current “selected viewer” (the Cedar user interface has at most one selected viewer, either an icon or a fullsized window, at a time to simplify the handling of input to multiple windows) and adds it in iconic form to the Whiteboard. The initial position of the new icon is fixed, but, as will be described below, the added icon can be moved using the mouse to place it where the user deems most appropriate. Cedar tools, documents, other Whiteboards, and entities belonging to other databases can all be placed on Whiteboards using this operation. Being able to add other Whiteboards allows the user to build up the complicated graph structures found in the Cedar Whiteboards. (3) Add Command File. Although most Cedar tools use their own viewers and therefore may be selected for addition to a Whiteboard through the Add Selected operation, some tools are activated only through a command line (for example, a command to compare the contents of two text files). The Add Command File operation is provided to enable such tools to be added to Whiteboards as well. Adding a command file is taking a document and adding it to a Whiteboard; the difference between performing an Add Command File on a document rather than an Add Selected is that, when the document is “opened,” its contents are treated as a sequence of command lines, rather than as something to be displayed on the screen. This allows long sequences of operations to be encapsulated in a single entity that can be kept on a Whiteboard. ’ UNIX is a trademark of AT&T Bell Laboratories. ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January
1986.
Whiteboards: A Graphical Database Tool
35
The preceding three operations allow the user to add text boxes and arbitrary Cedar entities to a Whiteboard. The following four operations are useful for arranging the contents of a Whiteboard: (4) Grow Text Box. Any existing text box on a Whiteboard may be expanded or contracted using this operation. Since the text box need not be as large as the size of the contained text (recall the existence of a scroll bar in each viewer), there is no difficulty in this regard when the size of a text box is altered. The mouse is used to select the text box and adjust its dimensions as desired. (5) Move Entity. Any Whiteboard entity may be moved using the mouse. The item is selected and then “dragged” along the Whiteboard viewer until the mouse button is released, indicating the new location for the icon or text box. (6) Delete Entity. Any Whiteboard entity may be deleted by positioning the cursor over the item and clicking the appropriate mouse button. As described more fully later, deletions are not irreversible until the user has requested that the edited Whiteboard be saved in a database. (7) Set Grid. This is a feature that aids in the aesthetic organization of Whiteboard items. An integer value is used to define the coarseness of the Whiteboard “grid,” constraining the allowable placement of items on the Whiteboard. When the user indicates the desired location of an entity, the system places that item on the Whiteboard in the nearest position that conforms with the current grid. A grid value of 1 corresponds to the size of a single bit on the bit-map screen, in which case items may be placed arbitrarily. The current grid size of a Whiteboard is also stored in the database. Finally, there are three operations for undoing or saving edits, and even erasing the Whiteboard entirely: (8) Save. Editing a Whiteboard does not immediately update the database; this is only done when a Save is executed. Save makes permanent all of the updates since the last Save or Reset by recording them in the database. (9) Reset. Reset causes all editing operations since the last Save (or since the beginning of the session) to be discarded; the Whiteboard is redrawn in its original state. (10) Erase. This operation can be used to erase the entire contents of a Whiteboard. Since it is merely another editing operation, it may be undone using Reset (restoring the contents of the Whiteboard) as long as the edits have not been written to the database as the result of a Save. This completes the description of the Whiteboards editor. Coupled with the browser, it is a powerful system for creating, editing, saving, and perusing organized collections of diverse objects. 5. BUILDING THE WHITEBOARDS
SYSTEM
IN CEDAR
The Whiteboards system is implemented in the Cedar programming language and runs in the Cedar programming environment. The construction of the system shows nicely some of the benefits of the integration provided in the Cedar environment (more on this subject can be found in [4]). ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January
1986.
36
l
James Donahue and Jennifer Widom
Compiler, Binder BasicPackages: Random, RefThb. RopeFile,
I
FS. BTree Terminal, SimpleTerminal
I
RPC
I 1
Communication,
Pup, GrapevineUser.
SafeSlora&e. Rope. ProcessProps, BCDSl,,ff, Real
CedarRuntime:
I STP
I
VM MrraRunUme:
PrincOps. processes. suntime errots
Microcode D* machine
mouse. bitmap diswlay
Fig. 8.
Ethernet
Cedar House of Cards.
The first thing to note about the Whiteboards system is the small amount of code needed to produce it; the entire listing of the program text, including the programming interfaces, is 60 pages (maybe 3000 lines of code), with the viewers and database code underlying the system each accounting for roughly half its size. The project was initially begun by John Maxwell as a “hack” and was picked up by Jim Donahue, who redesigned the program interfaces and worked out more carefully the details of transactions in the system. As a summer intern, Jennifer Widom reimplemented the entire system in a period of about eight weeks, with some help from Jim Donahue. This was a rather small undertaking considering the value of the system that was produced. Certainly one of the reasons this was possible is that the Whiteboards code rests at the top of an extremely rich system; there were a number of things that we did not have to do ourselves, but could share with other parts of Cedar. This is best described graphically, through the use of another Whiteboard, the House ACM Transactions
on Office Information Systems, Vol. 4, No. 1, January 1986.
Whiteboards: A Graphical Database Tool
37
of Curds in Figure 8, which shows the various software packages in Cedar upon which Whiteboards was built. We do not discuss all the details of implementing the system, but focus on three areas of particular interest: managing transactions in Whiteboards, the efficient handling of the user’s movement of the mouse, and the opening of tool icons on a Whiteboard.
5.1 Database Structure and Transactions A Whiteboard database has a fairly simple structure. Each Whiteboard in the database contains a number of “Whiteboard items”; the generic properties of a Whiteboard item include its position on the Whiteboard and its size. Whiteboard items belong to one of two classes: text boxes and icons. Text boxes have associated contents (actually stored as two strings, one for the text and one for the formatting information). For each icon on a Whiteboard, we store in the database (1) the name of the icon picture to be used when the icon is displayed, (2) the label to be displayed on the icon (these two things constitute sufficient information to paint the icon when displaying the Whiteboard), (3) the “type” of icon, i.e., whether it is a document, command file, tool, Whiteboard, or other database entity (this determines the semantics of opening the icon), (4) an “entity name” for the icon (which is frequently different from the icon label so that short names, which look better on the display, can be used for the labels), and finally, (5) for tool icons only, an “argument” that is used when the icon is opened. A transaction on a Whiteboard database is one of the following operations: displaying a Whiteboard (interrogating the database for all of the information necessary to position each Whiteboard item, fill each text box, and paint each icon), opening an icon (where all that is needed is the additional name and icon type information), or committing all of the user edits to a Whiteboard. This last operation is the most difficult one to implement and is worthy of some further discussion. Instead of actually performing updates to a Whiteboard database as a user edits a Whiteboard on the screen, we simply log the edits and then “play” the entire update log when the user saves the changes. Since a Whiteboard may have a quite complicated structure, it is impractical to reconstruct the entire contents of a Whiteboard when updating it. The operations that may be logged here are those described above: changing the position or size of a viewer, adding or deleting a viewer, changing the contents of a text box, or erasing a Whiteboard completely. The trick in this is to make the logging efficient in both time and space. One of the most frequent operations performed is creating a new text box and then filling it-it will not do to log each keystroke. We simplify the cost of keeping the log by only recording the subwindow on which an action is performed, rather than capturing the complete semantics of the action. For instance, if an icon is moved in a Whiteboard, we log the fact of the move and a pointer to the subwindow that has changed position; only when ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January 1986.
38
l
James Donahue and Jennifer Widom
replaying the log to update the database do we actually extract the new position of the icon on the Whiteboard. Note that this log does not contain sufficient information to undo operations; indeed, if the same viewer is moved twice, replaying the first operation in the log will accurately record the new position (not the position after the first move actually occurred), and the replay of the second move will have no effect. In fact, recording more information would simply duplicate other facilities in Cedar-Tioga, for example, provides an edit history that can be used to undo changes in any window being used to edit text, even if it is on a Whiteboard. The other problem in this scheme is to guarantee that the updates performed on the database will actually produce a structure consistent with that currently displayed on the screen. To guarantee this, each Whiteboard also has a version stamp stored in the database. Before attempting to “play the log” to update the database, the version stamp in the database is compared with the version stamp obtained when the Whiteboard was displayed-if they agree, then the update may proceed. One interesting side effect of using version stamps is that transaction aborts from the database are treated only as indications that there might be interference, rather than as assertions that there was interference. Our file servers (like most transaction-based systems) may abort transactions for reasons other than interference-we can always recover from this by retrying the log replay operation after first rechecking the version stamp. This means that our users will almost certainly never see a transaction abort unless there is real interference. In particular, they should never see an aborted transaction on a private database. Maintaining a version stamp means that we can also close the transaction if there are long periods of user inactivity (something that is very common in interactive environments); the version stamps provide long-lived read locks. We currently do not implement any write locks on Whiteboards. If an attempt is made to update a Whiteboard for which the version stamp is changed, the update fails and the user is forced to redisplay the Whiteboard (thus losing his edits) before he can proceed. (We do not do the redisplay automatically, though; thus the user has the opportunity to save any changes to text boxes before resetting the display.) Currently, the amount of updating of shared Whiteboards is relatively small, so that losing edits has not been a problem. There have been requests from several users for write locks, though, and we shall probably implement a mechanism for giving sole access to a public Whiteboard in a future release. 5.2 Handling of Mouse Movement and Button Clicks One notable fact about the Cedar House of Cards is that it is not a strict hierarchy. While the diagram given in Figure 8 shows the dependencies among various pieces of the system, the lower level interfaces are not encapsulated in the higher level components. Instead, the Cedar system is open, so that programs needing access to low-level facilities can use them without any great difficulty (see [6] for more details about how Cedar is structured). Moreover, the interfaces available to a Cedar programmer go right down to the hardware, so it is not necessary to understand the fine details of the system to use even quite low-level ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January 1986.
Whiteboards: A Graphical Database Tool
39
components. An important example of this is found in the code used to perform the movement of boxes on a Whiteboard. To move a box on a Whiteboard, the user first “selects” it by clicking the mouse in the vicinity of the box and then “drags” it by moving the mouse with the mouse button held down-when the button is released the move is finished. The main problem in implementing this is keeping up with the mouse; the code that samples the mouse positions and shifts the window on the screen must be able to sample and move at a rate that can follow fairly rapid mouse motion. Keeping up with the mouse means that we cannot use the layer of the window manager that provides “virtual keyboard and mouse” facilities to an applicationit just cannot be made to go fast enough. Instead, we use a lower level interface (just above the keyboard interface) that provides a simple stream of mouse and keyboard samples (we did not have to delve into the details of polling the mouse and keyboard ourselves). This same interface is used by the window manager to build its virtual keyboard facility, but it is not hidden by the window manager from outside clients. The painting of a Whiteboard during a move is also done with low-level operations (again for performance) that manipulate bit maps directly. Fortunately, not all of the code had to be designed with the same attention to performance. For instance, the code that displays a Whiteboard when it is opened and the code that draws the lines between Whiteboard icons when one is expanded use higher level interfaces. These operations do not have performance constraints that are hard to achieve, and the higher level interfaces are generally much easier to use. For instance, the Viewers window manager in Cedar provides a simple highlevel interface to the mouse and keyboard for handling the normal processing of mouse-button clicks. An application can register with Viewers a parsing algorithm, in the form of a Terminal Input Processor (TIP) table that gives a mapping from mouse-button and keyboard events (e.g., the up and down strokes of the buttons and keys) into a set of program events. Thus, the TIP table for Whiteboards includes an entry that states that holding the left mouse key down while the shift key is also down is to be interpreted as “add a new text box”; all of the Whiteboard editing and browsing operations that the user can trigger with the mouse are defined in the TIP table in a similar fashion. Viewers manages the distribution of all of the mouse and keyboard events to the appropriate application programs (so each application has the illusion of having its own mouse and keyboard), and the events of concern to a particular application are translated using the TIP table registered by the application. This makes it easy for an application to change the way in which events are signaled without having to change a lot of code. For example, the operation for adding a new text box by a single mouse click was added quite late in the development of Whiteboards; to add it to the user interface involved only adding one line to the TIP table and adding one more case to the code that did the discrimination of the input events. (TIP tables are described further in [6]). 5.3 Opening Tool Icons
For consistency, it is important that the user interface for Whiteboards treat the viewers on a Whiteboard no differently from normal text viewers and icons. The ACM Transections on Office Information Systems, Vol. 4, No. 1, January 1986.
40
l
James Donahue and Jennifer Widom
set of Tioga operations used on a text box is the same as that used on any other Tioga viewer, and the mouse button clicks on a Whiteboard icon behave just as they would on an icon in the icon row. Text boxes are easily handled, A text box is created as a viewer of the Text class; Tioga registers a collection of procedures with the Viewers window manager to provide the semantics of Text viewers. This means that Whiteboards itself contains no explicit code to provide any of the Tioga operations; they are all provided implicitly through the viewer class registration mechanism in Cedar. Icons, though, lead to some interesting complications. If an icon is in the icon row on a Cedar display, then the tool that created it must already be running. This is not true for Whiteboards, since the tool icons are simply stored as descriptive database entities; thus, opening an icon may involve first running a program to create the tool. As mentioned above, for each tool icon in the database we store the “entity name” of the icon and an optional argument. When a tool icon is being “opened,” the entity name is taken as the name of the tool; with the argument it is interpreted as a command to be executed using a command interpreter. One remaining question is how the entity names and arguments initially get stored in the database. When a tool is selected and added to a Whiteboard viewer, a tool database which contains information about the structure of tool viewers, is interrogated. This information consists of a set of hints to determine that a viewer was created by executing a particular tool and of a pattern to be used to extract any necessary argument information from the herald line at the top of the viewer. When an Add Selected operation is performed using a tool viewer, the tool database is interrogated to determine the name of the tool and any additional argument information to be stored in the Whiteboard database. (The tool database code is quite small-on the order of a couple of pages-and includes procedures for doing tool cross-referencing and keyword lookups.) There is a rather loose connection between the tool information stored in a Whiteboard database and the actual program that is loaded when a tool is opened. The actual program that will be run when a tool icon is opened from a Whiteboard is determined by the tile structure of the workstation on which the Whiteboards system happens to be running. In practice, there is substantial regularity in the workstation file systems (in particular, the Commands directory generally contains a complete collection of the important Cedar tools), so users are generally not surprised by the results. In a research environment like ours, the looseness of the connection seemed to be a virtue. In particular, a Whiteboard does not need to be changed when new versions of tools are released. 6. CONCLUSIONS As electronic office information systems continue to advance, we expect to find more and more need for facilities that enable the user to maintain organized collections of miscellaneous notes and objects, just as is typically done using office whiteboards and corkboards. We have built into the Cedar environment such a general-purpose information management tool, Whiteboards. Whiteboards provides a flexible system and a simple user interface, allowing a user of the Cedar environment to create, edit, and save organized collections of rather diverse ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January 1986.
Whiteboards: A Graphical Database Tool
l
41
electronic objects. In addition to its extensive use as a means of managing personal information, we have found the Whiteboards system to be particularly useful in constructing a documentation database for the Cedar system itself. The flexibility Whiteboards provides in displaying icons that represent tools, documents, other Whiteboards, or even entities stored in other databases (for instance, one can put electronic messages or sets of messageson a Whiteboard) makes it possible to integrate the documentation in an uncommon but highly desirable fashion. The Cedar documentation database has been in use for over a year, and has been very valuable in helping people get acquainted with Cedar. The integration and simplicity of use of the Whiteboards paradigm thus has much to recommend it as a means of building browsers for large programming environments, while it is equally useful as a tool for personal information organization and retrieval. REFERENCES
1. BEACH, R. J. Experience with the Cedar programming environment for computer graphics research. In Proceedings of Graphics Interface 84 (Ottawa, Canada, June). Canadian Information Processing Society, 1984. 2. BROWN,M., KOLLING, K., AND TAFT, E. The Alpine file system. Report CSL-84-4, Xerox Palo Alto Research Center, Palo Alto, Calif., Oct. 1984. 3. CA?TELL, R. G. G. Design and implementation of a relationship-entity-datum data model. Report CSL-83-4, Xerox Palo Alto Research Center, Palo Alto, Calif., May 1983. 4. DONAHUE,J. E. Integration mechanisms in Cedar. In Proceedings of the SIGPLAN Conference on Language Issues in Programming Environments (Seattle, June). ACM, New York, 1985, pp. 245-251. 5. HEROT, C. F. Spatial management of data. ACM Trans. Datubuse Syst. 5, 4 (Dec. 1980)‘ 493-514. 6. SWINEHART,D., ZELLWEGER,P., AND HAGMANN, R. The structure of Cedar. In Proceedings of the SIGPLAN Conference on Language Issues in Programming Environments (Seattle, June). ACM, New York, 1985, pp. 230-244. 7. TEITELMAN, W. A tour through Cedar. IEEE Softw. I,2 (April, 1984), 44-73. Received May 1985; accepted October 1985
ACM Transactions
on Office Information
Systems, Vol. 4, No. 1, January 1986.
