To appear in ACM Transactions on Information Systems.
* Current address: McKinsey & Co., 18/F Two Exchange Square, Central, Hong Kong.
** Current address: Harlequin, Inc., 1 Cambridge
Center, Cambridge, MA 02142.
This paper describes a series of tests of the generality of a "radically tailorable" tool for cooperative work. Users of this system can create applications by combining and modifying four kinds of building blocks: objects, views, agents, and links. We found that user-level tailoring of these primitives can provide most of the functionality found in well-known cooperative work systems such as gIBIS, Coordinator, Lotus Notes, and Information Lens. These primitives, therefore, appear to provide an elementary "tailoring language" out of which a wide variety of integrated information management and collaboration applications can be constructed by end users.
For as long as computers have been used for practical tasks, software designers have tried to match their systems to the situations in which they are used. This problem is perhaps nowhere more important than in designing software to support groups of people working together [Kyng 1991]. In some approaches to this problem, software designers study organizations using systems analysis techniques (e.g., Yourdon [1989]) or social science methodologies (e.g., Galegher, et al. [1990], Sproull & Kiesler [1991], Olson & Olson [1991]). In participatory design approaches to this problem, the eventual users of a system (who already know about the context of its use) work with software developers in its initial design (e.g., Greenbaum & Kyng [1991], Schuler & Namioka [1993]).
An even more extreme version of the participatory design approach is not just to involve users in design but to let them become designers by giving them end-user programming tools (e.g., MacLean, et al. [1990], Fischer & Girgensohn [1990], Nardi & Miller [1990], Mackay [1990]). For instance, with products like spreadsheets and Hypercard, end-users, who have no specific training in software development, can create for themselves more and more of the kinds of applications that would previously have required substantial work by professional programmers.
In this paper, we focus on one important class of such end-user programming tools. We call this class of systems radically tailorable since they allow end users to create a wide range of different applications by progressively modifying a working system. Radically tailorable systems are not new; perhaps the best known examples of existing radically tailorable systems are spreadsheets. However, we believe it is useful to articulate two desirable properties of such systems in order to help create more systems with these properties.
First, we use the term "tailorable" to mean that these systems can be changed without ever "really programming." More specifically, by "tailorable", we mean that end users (not skilled programmers) can progressively modify a working system (such as a spreadsheet) without ever having to leave the application domain and work in a separate underlying "programming" domain. With conventional programming languages, it is, of course, possible to change a working application. Doing so, however, requires that someone (usually a trained programmer) modify instructions that are related in potentially very complex ways to what the end user of the application sees on the screen. In radically tailorable systems, on the other hand, changes are made directly in the context of a working application, usually on the same screens. In this way, radically tailorable systems can help reduce the "cognitive distance" between using an application and designing it (c.f., Hutchins, et al. [1986]).
Second, we use the term "radically" to suggest that very large changes can be made by tailoring. Radically tailorable systems, therefore, differ from "ordinary" tailorable systems (such as word processing programs with "Preferences" parameters) in the degree to which users can create a wide range of substantially different applications. For instance, starting with the same blank spreadsheet, users can create applications ranging from personal budgeting to sales forecasting to corporate finance.
Radically tailorable systems are not the only approach to matching cooperative work tools to their contexts of use, but we believe they will be an increasingly important one. One of the key problems in designing radically tailorable tools is picking a set of building blocks at the "right" level of abstraction. That is, the building blocks should not be so low-level that they require significant effort to do anything useful, nor so high-level that they require significant modification whenever the users' needs change (see diSessa [1985]).
In this paper, we describe a set of experiments with one such set of building blocks. The building blocks are embodied in a radically tailorable system for cooperative work called Oval, the name of which is an acronym for the four key building blocks of the system: objects, views, agents, and links[1]. The experiments we describe are tests of the generality of these building blocks: What is the range of different kinds of applications that can be implemented "naturally" with these building blocks and the user level tailoring facilities provided by the Oval system?
To answer this question, we focus in this paper on four applications that are already believed by many people to be valuable for supporting cooperative work. Three of these applications were developed elsewhere: gIBIS [Conklin & Begeman 1988], Coordinator [Winograd 1987], and Notes [Lotus 1989]. One was developed in our laboratory: Information Lens [Malone, et al. 1987b]. For each of these systems, we attempted to emulate as much as possible of the functionality of the original system, using only the user level facilities provided by Oval. We also identified (and in some cases performed) system level modifications necessary to emulate the functionality of the original systems more closely. With a few exceptions, the basic functionality of the original systems was achieved with only user level modifications.
In addition to these primary test applications, we also developed a number of other demonstration applications to support such tasks as project management, software bug reporting, quality management processes in manufacturing, organization chart display, and purchase approval routing. A sample of these other applications are described briefly here to provide further illustration of the kinds of applications that can be constructed with Oval. In general, we have focused our work with Oval only on asynchronous cooperative work applications, not on synchronous cooperative work applications such as shared editors, shared drawing tools, or videoconferencing systems.
Taken together, these tests demonstrate that the four key components of Oval (objects, views, agents, and links) provide a tailoring language with which a wide range of asynchronous cooperative work tools can be constructed.
Because we believe the novel contribution of this paper is a subtle one, it is important to be explicit about what we believe the contribution to be. First, let us be clear about what is not new here. The individual components of Oval (objects, views, agents, and links) are not new; each of them has been used before in at least some (and sometimes many) previous systems. Similarly, the applications emulated in our experiments are not new either; in fact, we chose them, in part, precisely because they were already well known. Finally, the notion of having systems that can be modified by end users is not a novel idea; research on "end user programming", for instance, is a growing area.
What we believe is novel about the Oval system is the choice of building blocks and the particular way of combining them that is both simple and surprisingly powerful. That is, we believe the primary innovation in Oval is a user interface that has two important properties: (1) It is simple and intuitive for users to understand, and (2) It provides users a surprisingly large amount of functionality for creating and modifying a wide range of applications. This basic user interface approach was described in our previous work (Lai, Malone and Yu [1988], Malone, Yu and Lee [1989]).
The primary focus of this paper is to help test the second claim: that the Oval user interface lets users create and modify a surprisingly wide range of applications. It would, of course, be no surprise to say that we could implement all these applications in a general purpose programming language or that primitives like objects, views, agents, and links were helpful in doing so. The surprising thing, we believe, is that all these applications can be implemented using only the extremely restricted and simplified tailoring language provided by Oval.
A secondary contribution of this paper is to articulate more clearly than we have before how the specific approach used in Oval illustrates a more general approach to designing systems that are modifiable by end users. We now call this approach "radical tailorability", and we believe that this approach may be useful in other domains, too. For instance, we suspect that it would be useful in many application domains to try to identify building blocks that (a) are meaningful in the users' world, and (b) can be easily changed while they are being used.
Oval is based upon four key building blocks (see Lai, Malone and Yu [1988] and Malone, Yu and Lee [1989] for much more detailed descriptions):
(l) Semistructured objects represent things in the world such as people, tasks, messages, and meetings. Each object includes a collection of fields and field values and a set of actions that can be performed upon it. The object types are arranged in a hierarchy of increasingly specialized types with each object type inheriting fields, actions, and other properties from its parents in the hierarchy. The objects are semistructured in the sense that users can fill in as much or as little information in different fields as they desire and the information in a field is not necessarily of any specific type (e.g., it may be free text, a link to another object, or a combination of text and links). Users see and manipulate these objects via a particularly natural form of template-based interfaces.
(2) User customizable views summarize collections of objects and allow users to edit individual objects. For instance, users can select the fields to be shown in a table display of a collection of objects, or they can select the links to be used to create a network display of the relationships between objects. A calendar display can be used to summarize objects with dates in one of their fields. Any appropriate display format (e.g., table, network, or calendar) can be used to show any collection of objects.
(3) Rule-based agents perform active tasks for people without requiring the direct attention of their users. Agents can be triggered by events such as the arrival of new mail, the appearance of a new object in a folder, or the arrival of a pre-specified time. When an agent is triggered it applies a set of rules to a collection of objects. Rules contain descriptions of the objects to which they apply and actions to be performed on those objects. Actions include general actions such as moving, mailing, and deleting objects or object-specific actions such as loading files or responding to messages.
(4) Links represent relationships between objects. For example, by inserting in the fields of some objects links (or "pointers") to other objects, users can represent relationships between messages and their replies, between people and their supervisors, or between different parts of a complex product. Users can then follow these hypertext links by clicking on them. In addition to this "manual" navigation using links, the knowledge represented by the links can also be tested by rules and used in creating displays that summarize relationships.
The primary user level modifications to the system include: (1) defining new object types, (2) adding fields to existing object types, (3) selecting views for objects and collections of objects (from a prespecified set of display formats), (4) specifying parameters for a given view (such as which fields to show), (5) creating new agents and rules, and (6) inserting new links.
Even though the "low level" systems issues involved in data sharing were not the primary focus of this project, we implemented three primary ways for people to save and share information in Oval:
(1) Mailing objects. Users can mail any collection of objects back and forth to each other in messages. For instance, all the objects linked (directly or indirectly) to a given object can be automatically collected and mailed. This is done by inserting a link to the object in a message and then choosing the option of mailing "all levels" of other objects linked to the first object.
When users receive a message containing objects, the identity of the objects is preserved (i.e., pre-existing links will point to the newest versions of the objects and the previous versions will be stored as "previous versions"). Users are notified of these changes, and if they desire, can undo them in specific cases.
This method of explicitly mailing objects is sometimes more awkward than having a shared database. However, many applications can be supported quite satisfactorily in this way for groups of people who are connected only by email gateways, without the necessity of shared databases.
(2) Sharing databases. We have also implemented a rudimentary version of "live" sharing of objects stored on remote databases. To do this, we used a remote relational database and mapping functions to translate between Oval objects and records in the relational database. Even though we have not done so, it would also be quite consistent with the overall Oval framework to use an object-oriented database for data storage and sharing.
(3) Sharing files. Finally, users can save any collection of Oval objects in a file which they (or other people) can load later. These files can, of course, be shared in all the ways other files can be shared: on a file server, on floppy disks, etc. This is, in many ways, the least interesting way of sharing objects, but it is, in practice, the way we have used most often so far.
A key issue that arises when people share information in Oval is how to share definitions of new object types. Lee and Malone [1990] discuss this issue in detail and propose a general solution called "partially shared views" which involves grouping type definitions into "views", explicitly sharing these views, and automatically translating unknown types into the nearest "ancestor" type in a view shared by both the sender and the receiver. In the current version of the system, we implemented the following special case of this general solution: When users save or mail objects not defined in the basic system, the type definitions are saved or mailed along with the objects themselves.
This special case would not be suitable for situations in which a large number of partially overlapping groups of people are defining and sharing large numbers of object types. In complex situations like these, for instance, different groups might often create conflicting definitions for types with the same name. However, in the situations for which we used the system, the simple solution we adopted was satisfactory.
Oval as an object-oriented system
One way of viewing Oval is as a way of exposing the key concepts of object-oriented programming (e.g., Stefik & Bobrow [1986], Wegner [1987], Brachman & Levesque [1985]) in a way that end users can understand and use. In the past, object-oriented programming languages have often been used to implement systems intended to be easy for non-programmers to use. But nearly all object-oriented programming languages themselves (e.g., C++, Smalltalk-80) are clearly designed for use by skilled programmers, not novices. While not attempting to be a general-purpose programming language, Oval exposes several of the key concepts of object-oriented programming in a highly simplified form that is intended to be understandable by people without any experience in conventional programming. For instance, Oval uses objects of different types, and each type of object has a set of associated attributes (called "fields") and methods (called "actions"). The object types are arranged in an inheritance hierarchy, and the objects have a form of polymorphism in the sense that different types of objects respond to actions with the same names.
Relationship between Oval and Object Lens
As noted above, Oval is based strongly upon the Object Lens system (Lai, Malone and Yu [1988], Malone, Yu and Lee [1989], which should not be confused with the more limited Information Lens system [Malone, et al. 1987b]). Most of the features of Oval described in this paper were already present in Object Lens.
The primary differences between Oval and Object Lens are the following: (1) Oval is implemented in Macintosh Common Lisp on Macintoshes; Object Lens was implemented in Interlisp-D on Xerox 1100 workstations. (2) Oval includes two new kind of views that were not implemented in Object Lens: calendars and matrices. (3) Oval includes the capabilities described above for mailing objects around in a way that preserves instance identity. These capabilities were not present in Object Lens. (4) Oval includes several "user convenience" features which were not present in Object Lens. For instance, in Oval, type operations can be performed on instances, and the default expected type for a field is set automatically based on the type of the first object inserted in the field (see more detailed descriptions of these features below).
Oval is currently implemented as a proof-of-concept prototype in Macintosh Common Lisp on networked Apple Macintoshes. Several versions of this system have been used intermittently by up to six people in our research group over a period of approximately 3 years, and by numerous other people for shorter periods.
We do not believe that this implementation of Oval
is robust enough for daily use in most environments. For instance,
the system becomes unacceptably slow with large numbers of objects,
and display bugs sometimes require users to explicitly refresh
windows. More generally, the systems infrastructure for persistent
and shared databases is quite limited. The limitations of which
we are aware, however, are primarily limitations of speed and
reliability in the system infrastructure, rather than of the basic
user interface approach upon which this paper focuses. We believe
that if the Oval system and its infrastructure were robustly implemented,
many of the applications we describe here would be quite usable.
We have also already found the system sufficiently robust for rapid prototyping and demonstration of many applications. Over 100 copies of the software have been distributed to other researchers and developers for demonstration purposes. [2]
To test our hypothesis that Oval is radically tailorable, we used the system to try to implement the functionality of a variety of cooperative work applications for which descriptions have been previously published. In this section, we will describe briefly how we implemented the major features of each application and what features of the original applications we did not implement. The first application is described in somewhat more detail than the others to illustrate how the system works. More detailed examples of how new applications are created can be found in Lai, Malone and Yu [1988] and Malone, Yu and Lee [1989].
For each application, we were concerned primarily with whether the overall user interface paradigm and user-level capabilities provided by Oval could accommodate in a "natural" way the primary functionality of the application. We did not attempt to mimic exact details of screen layout and command names. Similarly, since our system is only a research prototype, we did not attempt to replicate the level of attention to robustness, speed, access controls, and so forth present in the commercial products we analyzed. These attributes are clearly essential in creating widely usable software systems, but they were not the primary focus of our work.
In all cases, we tried to be faithful to the "spirit" of the original systems. Our judgements about which features were central to the spirit of the original systems were necessarily subjective, but our descriptions of the applications below will allow readers to judge for themselves how much of the interesting functionality provided by the original systems we were able to emulate.
It is important to realize that these applications provide a kind of "stress test" for the tailorability of the system. We would not expect beginning users of a system like Oval to be immediately able do all the tailoring needed for these applications. For instance, some of the applications require the use of tailoring features (such as defining new object types) that we would expect only of experienced users. Furthermore, one of these applications (the Coordinator) required the creation of a large number of object types, agents, and folders. The sophistication required to develop complex applications like this one, we expect, would be roughly equivalent to that required to develop a very complex spreadsheet. In general, we had, as a rough goal, the notion that the kinds of people who could use spreadsheets should be able to use Oval.
Also, just as spreadsheets are used by people at many different levels of sophistication, we expect that radically tailorable systems like Oval will be used in very different ways by end users, by power users, and by programmers (Nardi and Miller [1990], Mackay [1990]). Since the system provides a wide spectrum of tailoring options, we believe that many users would make only minimal changes to applications developed by others, while some power users would develop applications for other people, and programmers would use the system to dramatically reduce the time and effort required to develop completely new applications.
gIBIS [Conklin and Begeman 1988] is a tool for helping a group explore and capture the qualitative factors that go into making decisions. Elements of a policy analysis in gIBIS are represented as a network containing three types of nodes: Issues, Positions, and Arguments. Each Issue may have several Positions that "Respond to" it, and each Position, in turn, may have various Arguments that "Support" or "Object to" it. Users can create new nodes of any type, and they can browse through a network by following the hypertext links between nodes or by looking at summary views that graphically display the different kinds of nodes and their relationships.
Defining new object types and creating examples of them
To emulate gIBIS in Oval, we first defined the three types of objects used by gIBIS: Issues, Positions, and Arguments. For instance, to define the new type of object called "Argument", we performed the actions illustrated in Figure 1. First, we selected the basic object type called "Thing" and then chose the "Create Subtype" action (Figure 1(a)). To create individual examples of this type, we selected the new type and chose the "New object" action. The new Arguments have the fields "Name", "Keywords", and "Text" by default, since these fields are present in all Things. To add the fields (like "Supports", "Objects to", and "Entered by") that are present in Argument objects but not in all Things, we used the "Add Field" action on one of the new Argument objects (Figure 1(b)). Finally, we filled in the fields of this (and other objects) by typing and by adding links (Figure 1(c)).
As an example of the kind of "shortcuts" that Oval includes to enhance the convenience of users, consider how new fields were added in Figure 1(b). In designing a way for users to add fields to an object type, a common reaction for programmers who have worked with object-oriented systems would be to have an operation that is performed on a "type definition" somewhere in the system. In some early versions of the Oval system, this is exactly what we did. However, in working with Oval, we realized that nearly every time a user wants to perform a "type operation" (such as adding fields, setting default values for a field, and so forth) the user is already in the context of a specific instance of the type. Therefore, we made all these type operations accessible from the instances themselves. This seems to significantly enhance the "immediacy" of using the system; instead of making changes indirectly to an abstract type definition, users are directly changing a specific object that is of interest to them.
The square brackets in Figure 1(c) indicate "live" links to other objects that can be traversed by clicking on them. To add these links in the first place, the user selects the "Add link" action in a field and then points to the object to which the link goes. It is also possible to use the "Add New Object" action on a field as a shortcut to both create a new object and insert a link to that object into the field.
As another useful shortcut, when the first object is linked into a field, Oval automatically sets the "expected type" of the field to be the type of that first object. Then, when the user selects the "Add New Object" action on that field in the future, a new object of the same type will automatically be created and linked into the field. Since it is quite common to have all the objects in a field be of the same type, this implicit way of setting the type of a field often turns out to be useful. It is also possible, of course, for users to manually insert objects of different types into a field (using the "Add Link" action). Similarly, if users want to explicitly change the "expected type" for a field, they can do so by using the "Set Type" action on the field.
Viewing collections of objects
When a field in an Oval object contains links to other objects, users can tailor views to specify how they wish to have these objects displayed. For instance, in Figure 2, the objects in the "Contents" field of the Folder are initially displayed in a "Table" view, with the "Name" and "Entered by" fields shown in the table.
In the original gIBIS system, users can also view the relationships between the nodes in an argument network graphically. To do this with Oval, we selected the "Change View" action for a field containing the nodes and then chose the "Network" display format (see Figures 2 and 3). This format allows us to choose the fields from which links will be shown in the network. For example, in Figure 2, we chose to show links from three fields,"Supports", "Objects to" and "Responds to." We also chose to display in each node the "Name" and "Object Type" fields. The result is shown in Figure 3.
Note that this simple method of tailoring a nework view can be used for any collection of objects whose relationships to each other are represented by links (e.g., organization charts, PERT charts, and software module calling relationships).
Another common kind of view--a calendar--can be used to display any collection objects in a calendar format, with each object placed on the date contained in one of its fields. To use this view, users simply select (using a dialogue like the one if Figure 2) which field should be used to determine the date on which the object should be displayed. (If Oval does not find a date in that field, in a format it can recognize, then the object is displayed in a cell on the calendar labeled "No date.")
In one sense, of course, there is nothing new about this notion of using general display formats for many kinds of objects. We have been genuinely suprised, however, at how widely useful and powerful this feature is when users can apply it themselves to create new applications. For instance, it makes it possible for end users to create in seconds specialized displays like organization charts, PERT charts, and part explosion graphs that might otherwise require days or weeks of programming.
Features of the original system not included in our application
We omitted one feature of the original gIBIS system for aesthetic reasons: The original system included a distinction between primary and secondary links of each type. We could have implemented this simply by defining additional fields (e.g., "Supports (primary)" and "Supports (secondary)"), but we chose not to, in order to reduce the complexity of the system.
In addition to a shared "live" database, gIBIS has two other features which would have required new system level programming to implement: (1) aggregate nodes (the ability to automatically collapse a group of nodes into one aggregate node), and (2) a node index that shows nodes in outline format (with indentations indicating their relations). These features did not seem essential to the main point of the application, and we did not include them in our implementation. However, they would both have been quite consistent with the overall Oval paradigm. Aggregate nodes could be implemented with two new actions on folders (one to create aggregates and one to break them apart). An outline display format would be reusable in many other applications as well and would, therefore, be a useful addition to the current display formats for collections of objects (tables, networks, calendars, and matrices).
Coordinator - Conversation structuring and task tracking
The Coordinator is an electronic mail-based system that helps people structure conversations and track tasks (Winograd & Flores [1986], Action Technologies [1988]). For instance, a typical "Conversation for Action" begins with a "Request" message from person A to person B, explicitly requesting person B to do something by a certain date. Person B is then prompted to respond with a "Promise" message (promising to perform the action), with a "Decline" message (declining to perform the action), or with a "Counteroffer" message (offering to perform the action by a different date or to perform a different action). If B promises to do the action, then a typical conversation might continue with B eventually sending a "Report completion" message (indicating that the action has been performed) and A replying with a "Close" message (indicating that the action was performed satisfactorily).
In addition to this prototypical conversational sequence, a variety of other message sequences are possible when, for instance, A is not satisfied with the B's performance or when the conversation begins with B "offering" to do something rather than with A "requesting" something. In all these cases, the system automatically groups all messages for a single conversational "thread" together, and allows users to easily see the status of various conversations. For example, users can easily see all the outstanding requests they have made to other people or all the things they have promised to do for others (along with their due dates).
Before attempting to emulate the functionality of the Coordinator in Oval, we enhanced the basic Oval infrastructure to automatically group a series of messages into "Conversation" folders (see Figure 4), as follows: (1) When users create a new message (without it being a reply to an old one), a new conversation folder is automatically created. This folder contains the new message, and the conversation field of the new message is also linked to this folder. (2) When users reply to a message of a given type, they are presented with a choice of message types for their reply. (The choices to be presented are specified in a user-modifiable field called "Reply Types", which is not shown in the view used in Figure 4.) (3) After users select a reply type, the Conversation field in the reply message is automatically linked to the Conversation folder specified in the original message, and the reply is inserted in the Conversation folder.
These modifications required system-level programming in the underlying Oval system, and are not the kind of changes we would ever expect end users to make. Therefore, the fact that we needed to make these modifications indicates a limitation of the Oval infrastructure as it existed before our experiments began. We believe it is reasonable, however, to say that these capabilities are now part of the general system-level support for electronic mail in Oval (along with capabilities like mail transport and address parsing). Attempting to emulate the Coordinator pointed out to us their importance, but they could in fact be useful in any mail-based application.
After these general system-level enhancements to mail are made, the other main functionality of the Coordinator can be added by user-level tailoring. For instance, we added 15 new message types and defined their reply types to provide the same conversational sequences (such as Conversations for Action) used in the Coordinator. The Request message type, for example, has reply types like Counteroffer, Promise, and Decline.
To provide the various kinds of summary displays in the Coordinator we created 23 folders (such as "Open Matters" and "My promises"), and 14 agents with 47 rules that move messages into and out of these folders. For instance, Figure 5 shows an agent that moves conversations into the folders for various kinds of promises. To create an agent like this one, users fill in the fields shown in Figure 5: a folder to which the agent applies, one or more triggering conditions, and a set of rules. Then, when the agent is triggered, it will apply the rules to the objects in the "Apply to" folder.
Rules, like agents, are created with a straighforward sequence of menu-picks and form filling. For instance, users indicate the type of object to which a rule should apply by selecting from a pop-up menu of object types on the "If" field of the rule. Then users specify the "If" conditions for the rule, by filling in fields of the object type they selected. The "Then" actions are specified in a similar way, by selecting an action from a pop-up menu on the "Then" field and then filling in fields to specify any required parameters for that action. Typical rule actions include: copying or moving an object to another folder, deleting an object from its current folder, or mailing an object to another user. The rule shown in Figure 5, for example, moves conversations with promises from the user into two folders: "My Promises" and "All Open Promises and Offers".
In addition to selecting predefined actions for the "Then" part of a rule, the current prototype also makes it possible for users to define new actions using the underlying general purpose programming language (Lisp). Even though we do not consider this programming capability as part of the "tailorable" aspect of the system, the inclusion of scripting languages (like HyperTalk) for defining new actions would provide very sophisticated users with a more powerful way of modifying the system.
Some of the agents make use of "all-objects-of-a-type" folders in Oval. An all-objects-of-a-type folder is one which is maintained by the system so that it always contains all objects of a specified type. For example, the "All Coordinator messages" folder is dynamically maintained so that it always contains all the Coordinator messages in Oval.
Features of the original system not included in our application
Unlike the original Coordinator, our application does not provide explicit support for delegation. Instead, someone who has received a request can delegate it to someone else manually by sending a new request that contains a link to the original one.
There are also several detailed features of the Coordinator not included in our application. For instance, unlike the Coordinator, our application does not enforce the restriction that people who are only copied (cc:'ed) in a conversation cannot change its state. Furthermore, there are some cases where users of our application would need to do minor things manually that are done automatically in the Coordinator. For instance, if someone wants to cancel a request before having received a reply to it, they would have to manually address the cancel message and insert it in the original conversation.
Notes - Semistructured information sharing
Of the other systems analyzed here, Lotus Notes [Lotus 1989] is the most similar to Oval. It was developed independently and announced soon after the basic ideas of Oval were first published [Lai, Malone and Yu 1988]. Notes is also similar to earlier computer conferencing systems with the important additions that (1) the documents in a database are semistructured templates (with optional "hot links" to other documents) and (2) the documents in a database can be filtered and summarized according to various user-definable views.
For example, a typical Notes application might help a company keep track of information, gleaned from various sources, about it's competitors. Such an application might include a template that includes fields for which competitor the information is about, which customer(s) are involved (if any), and how important the creator of the item feels the information is. The template could also include a field for unstructured text describing the information in detail. The application might also include customized views of the data that, for example, show only high priority reports or sort reports by what competitors and customers are involved.
As this example illustrates, Notes--like Oval--can be used to create many different applications. Thus, we did not literally tailor Oval to emulate Notes itself, but rather we can tailor Oval in different ways to emulate different Notes applications. For instance, Figure 6 shows a simple application for competitive information tracking like the one just described. It requires the definition of a new object type ("Competitive Information Report") and a table view for a folder containing objects of this type.
In general, the primitives that Notes provides for creating applications have equivalents in Oval, and thus the kinds of applications that can be created in Notes can also be emulated in Oval. For instance, the templates in Notes are equivalent to object types in Oval; the databases in Notes are equivalent to folders in Oval; and the views in Notes are equivalent to views of collections of objects in Oval. Notes views are all variations of a kind of "outline" display format that does not currently exist in Oval, but is similar to the table format display that does exist (see Figure 6).
In certain ways, however, Notes is significantly more limited than Oval. For instance, Notes does not include any of the other folder display formats in Oval such as networks and calendars, nor does Notes have active agents like those in Oval. Similarly, even though Notes allows very knowledgeable users to do certain kinds of sorting and filtering using views, it does not appear to be designed to make this easy for end users. Thus, even though Notes is very "modifiable", it does not appear to be "tailorable" in the sense we mean, because this modification cannot be done easily by end users. One useful way of thinking about the relationship between Oval and Notes, therefore, is to view Oval as illustrating an integrated user interface paradigm and a number of additional features that Notes could, in principle, be extended to include.
Notes also has several very important features not present in Oval. Most importantly, the Notes product includes a comprehensive database replication algorithm which approximates "live sharing" of documents. Also, as a commercial product, Notes includes many features such as access controls, "rich text" fields, and calculated fields. Even though these features are not currently part of the prototype implementation of Oval, they would be quite consistent with its overall user interface paradigm which is the focus of this paper.
Information Lens -- Intelligent mail sorting
Information Lens (Malone, et al. [1987b], Malone, et al. [1987a]) helps users by automatically filtering and sorting incoming electronic messages. For example, users can create rule-based "intelligent agents" that sort messages from particular people into an "Urgent" folder, that sort messages about specific projects into the appropriate project folders, and that delete certain kinds of unimportant messages altogether. The system also helps users create new messages using a set of (optional) semistructured message templates. For example, a template for "Meeting announcement messages" might include fields, not only for sender, receiver, date, and subject of the message, but also for the time, place, and topic of the meeting. When they are used, these additional fields make it possible to have more powerful rules, without requiring any specialized natural language understanding or other content analysis capabilities in the intelligent agents.
Implementing Information Lens in Oval is quite straightforward. For instance, users can define new message types as subtypes of Message in the object type hierarchy and create rules to filter and sort messages (see Figure 7).
In addition to the local mail sorting agents, the original Information Lens included a second kind of agent that ran on servers and selected potentially interesting messages for a given user from a stream of messages addressed to "Anyone." Implementing remote agents like these would require some additional systems level programming which we have not yet done in Oval but which would be consistent with the overall user interface paradigm of Oval and useful in other applications.
Table 1 summarizes the results of the four application experiments described above. In three of the cases (gIBIS, Notes, and Information Lens), some of the features of the previous systems were not included in our emulations. It appears, however, that the functionality omitted in these cases was not essential to the main point of the applications. Also, in all three cases, the functionality omitted would fit naturally within the user interface paradigm provided by Oval and would be reusable in other applications. In the other case (Coordinator), we performed modest amounts of system level programming and believe we emulated all of the major functionality of the original system. The new system level functionality implemented in this case (Conversation folders) should also be generally useful in other Oval applications. Overall, therefore, the primary functionality of the previous systems seems to be captured reasonably well by user-level modifications within the user interface paradigm provided by Oval.
Table 1. A summary of the modifications required
to emulate the systems described in each experiment.
(* = Application specific. ** = "Optional" feature;
not implemented. Ü = Implementation in progress)
In addition to the applications described in detail above, we have developed a number of other applications using the Oval system. The range of these applications provides a further demonstration of the tailorability of Oval, and this section briefly summarizes a sample of these other applications.
Applications requiring some system-level programming
Sibyl (Lee [1990a], Lee [1990b], Lee [1991]), like gIBIS, is designed to capture the qualitative rationales that go into making decisions. Sibyl goes further than previous systems, however, in its representation of goals for decisions, and in its facilities for finding previous similar decisions. Sibyl was implemented from the beginning in Oval, and primarily required the addition of a new folder display format--a decision matrix--for displaying the relationships between alternatives and goals.
Answer Garden [Ackerman & Malone 1990] helps an organization develop a database of commonly asked questions (such as those faced by a "help desk") that grows "organically" as new questions arise and are answered. The system includes a branching network of diagnostic questions that helps users find the answers they want. The primary version of this system was implemented in C and Unix, but we were able to emulate it in Oval using three new types of objects: diagnostic question nodes, user questions, and expert answers. This application required a small amount of system level programming to implement a new action that allows users to automatically send new questions from any node in the diagnostic network.
Applications requiring only user-level tailoring
The following demonstration applications have been developed in Oval using only the user-level tailoring facilities described earlier in this paper (All of these applications, except (3), are included with the demonstration version of Oval that is available to other researchers. They are described further in documentation that accompanies that system [Lee 1992].):
(1) a personal database of people (created by defining a new type of object called "Employee" with fields for "Name", "Address", "Job title", "Supervisor", etc.).
(2) an organization chart (created by viewing a folder of employees using a network view that summarizes the links in the "Supervisor" fields).
(3) a project management system that tracks the tasks to be done, people responsible, prerequisites, overdue tasks, etc. This system was created by defining a new type of object called "Task" and viewing collections of these tasks using different views. For instance, a network view is used to summarize the links in the "prerequisite" fields (thus creating a PERT chart) and a calendar view is used to display objects according to the date in their "Due date" field. An agent finds overdue tasks (using a rule that looks for tasks whose "Due date" is less than today) and moves them to a special folder. It is also possible for people to mail tasks back and forth to each other. For example, a project manager can mail new tasks to people responsible for performing them, and they can then mail back new versions of the tasks as the status of the tasks changes.
(4) a system for tracking software bug reports and automatically routing them to appropriate people. For instance, the demonstration includes agents that route bug reports to the programmers responsible for modules in which the bugs occur. Other agents route bug reports to programmers responsible for modules that call the ones containing bugs (on the theory that programmers may be interested in knowing about bugs in modules they use, even if they are not responsible for fixing them). This system is based, in part, on field studies of support "hot lines" in software companies (Pentland [1991], Pentland [1992]) and of engineering change processes in manufacturing organizations [Crowston 1991].
(5) a system for supporting marketing decision making. This demonstration includes tables displaying the kind of data that might come from field sales reports and linked networks of comments that managers might make in interpreting and deciding what to do about this data. The demonstration also includes project management facilities (like those described in (3) above) to help implement the decisions made based on the data. This demonstration was based upon extensive field studies of a senior management team in a consumer products company [Osborn 1992].
(6) a system for supporting quality management processes in manufacturing. This demonstration includes facilities to track the dependencies between engineering attributes of a product and the attributes of the product that matter to customers. These attributes are represented as objects. Their relationships are represented using links and "Relationship" objects and summarized in table displays. The demonstration also includes a decision matrix for helping to evaluate alternative vendors for a part. This demonstration is based upon extensive field studies in a large electronics manufacturing firm (see Kiegler [1992] for a description of the field studies and the demonstration applications).
(7) a workflow system for order approval. This application is not a complete workflow system, but it demonstrates how rule-based agents can be used to route forms to appropriate people. For instance, the demonstration includes an agent with rules that route purchase requests to different managers for approval depending on the dollar amount of the purchase request.
Before proceeding, it is important to note several limitations of our experiments. First, even though the experiments establish that the range of applicability of systems like Oval is large, they do not allow us to characterize its limits. It is easy to give specific examples of things that Oval cannot do. For instance, unless Oval is extended with some kind of scripting language (like HyperTalk) or other special purpose programming, it cannot do arithmetic operations or any kind of iteration not explicitly built into the views and agents. It is also possible to say, in very loose terms, that Oval seems to be well-suited for applications that use forms, databases, and/or hypertext-like functionality. However, we suspect that it is difficult, in principle, to characterize in general terms the limits of radically tailorable tools. In part, this is because ingenious users will always be able to think of unexpected new uses for them.
Second, we have not formally studied the usefulness of the applications that could be created with systems like Oval. Instead, since we emulated other systems that are widely believed to be useful, we assume that systems like Oval would be at least as useful as these previous systems are individually. We do not yet know how much additional benefit will come from combining these and other applications that can be created with the system.
Finally, and perhaps most importantly, we have not formally tested the usability of this system. That is, we tested whether the system made it possible for knowledgeable users to implement the applications using only the user level tailoring facilities. As the descriptions above indicate, the user level tailoring facilities have "face validity" as being simple and easy to use. Another important kind of test, however, would be to examine how well typical users at various levels of sophistication could actually create such applications for themselves.
What can we learn from these experiments? We believe that two of the most important lessons have to do with the power of the four primitives with which we started:
(1) Objects, views, agents, and links provide a kind of elementary "tailoring language" for user interfaces to information management and cooperative work applications. All of the previous systems we analyzed had some form of semistructured objects and some form of summary displays analogous to our views. Most of the systems also had some of the functionality provided by our agents and links. With the exception of Notes, however, the systems were built to handle only specialized kinds of objects (e.g., messages or argumentation nodes) and certain display formats (e.g., tables). By generalizing to the abstract level of semistructured objects, customizable views, rule-based agents, and links, we achieve a great increase in scope of applications with only a relatively modest increase in complexity. For instance, by implementing views (such as tables, networks, matrices, and calendars) once in a way that end users can then apply to any kind of information, a vast amount of programming effort is avoided and the end users' power is significantly increased. We were genuinely surprised at the power of this approach, and we believe that the generality of these basic primitives and their combination methods is not yet widely appreciated.
(2) Radical tailorability facilitates integration. In addition to the versatility that a radically tailorable system provides, there is another important benefit of constructing a variety of different applications within the same system: It is much easier to integrate the different applications. For instance, discussions facilitated by systems like gIBIS often lead to action items, the status of which a group might want to track with systems like Notes or the Coordinator. In an integrated system like Oval, it is a straightforward matter to link these action items to the discussions that generated them and vice versa.
Issues in tailoring multi-user applications
One set of questions that our experiments raise, but do not answer, involves how to manage the process of tailoring applications for groups of people. When people tailor applications for their own individual use (e.g., with spreadsheets), they do not have to agree with anyone else about what the applications will do or how to use them. But when a group of people all use the same application, they must have shared understandings about how to use the application. For example, to use applications like gIBIS or the Coordinator, a group of people needs to agree--at least at some level--on the meanings of different types of objects (such as Positions, Arguments, Requests, and Promises) and how they are used.
Systems like Oval can significantly reduce the effort needed to implement new multi-user applications. However, developing the shared understandings needed to use a multi-person application successfully is also critical. Radically tailorable tools like Oval can help in the process of developing these shared understandings by (a) removing the need for a skilled programmer as an intermediary in the process, (b) making it easier to rapidly try many iterations of an application until agreement is reached, and (c) helping to manage the communication and decision-making needed to reach agreement.
Even though systems like Oval can already be helpful in these processes, we believe future research should focus on better understanding the social processes needed to tailor successful shared applications. We can obtain some insight into how these social processes might work by observing what has already happened with spreadsheets. Even though spreadsheets were initially intended as single-user tools, a number of people are often involved in the development of a single spreadsheet application, and the same application may also be used by many people [Nardi and Miller 1990]. Furthermore, many organizations now use spreadsheets as an integral part of multi-person activities such as formal budgetting and accounting procedures. In these cases, social processes usually manage the interactions between different spreadsheet users. For instance, an organization may decide on a standard spreadsheet template that all its business units are required to fill in with their budget projections. Then the spreadsheets from multiple business units are consolidated by a partly manual process.
Specific tools. In addition to these social processes, the process of tailoring multi-user applications can also be directly supported by specific software tools. For instance, the Chronicle system [Greif 1992], can automatically keep track of and merge pieces of spreadsheets from multiple sources into a single spreadsheet in flexible ways. As another example, the Egret system [Johnson 1992] supports the process of gradually evolving a consensus among a community of users about what type definitions should be included in the shared applications.
In general, the concerns discussed in this paper are related to work in end-user programming (e.g., MacLean, et al. [1990], Fischer and Girgensohn [1990], Nardi and Miller [1990], Mackay [1990]), and, as mentioned above, this paper illustrates one approach to the problems of end-user programming. The Oval system also has some similarities to systems that provide graphical interfaces to object-oriented programming systems (e.g., KEE and Kappa from Intellicorp and Nexpert from Neuron Data, Inc.). However, by providing what are essentially general purpose programming environments, these other systems expose far more complexity to their users than Oval does, and they do not appear to be intended for unaided use by non-programmers.
More specifically, in addition, to the systems described above, there are a number of other extensible CSCW systems that share some of the goals of the Oval system. In all of these cases, however, the primary emphasis appears to be on building systems that are extensible by programmers, not by end users. For instance, several systems, such as AtomicMail [Borenstein 1992], and ActiveMail [Goldberg, et al. 1992] include programmer-extensible frameworks built on top of an electronic mail infrastructure. Other systems, such as Suite [Dewan & Choudhary 1992], Rendezvous [Patterson, et al. 1990], ABC [Jeffay, et al. 1992], GroupKit [Roseman & Greenberg 1992], and the system described by Bentley et al [1992] provide frameworks for programmers to define applications that include real-time (i.e., synchronous) sharing of information in windows (a capability not included at all in Oval). Still other systems, such as Strudel [Shepherd, et al. 1990] and ConversationBuilder [Kaplan, et al. 1992] focus on supporting programmer-defined action sequences (or "protocols") involving multiple users. Since these protocols can be defined with general purpose programming languages, they can presumably be much more complex than the simple action sequences users can define in Oval (as in the Coordinator example above). ConversationBuilder also includes support for hypertext structures like those in the gIBIS example above. In all these systems, however, the frameworks allow programmers to create complex applications, but they do not appear to be intended for use by "ordinary" end users.
A few extensible cooperative work systems explicitly aim at being modifiable by end users. For instance, the Polymer system (Lefkowitz & Croft [1990], Bhandaru & Croft [1990]) supports the planning and execution of complex action sequences involving objects and actions defined by users. This system provides much more computational support than Oval does for planning and managing tasks. However, it appears to be much more limited in the flexibility it provides users for displaying collections of objects, linking objects to each other, and specifying active agents. For instance, it does not appear that the applications described in this paper could have been created by user actions in Polymer. Similarly, the ActionWorkflow approach to workflow management Medina-Mora, et al. [1992] allows users to graphically specify action and communication sequences ("workflows") that are then automatically supported by the system. This system provides significantly more built-in support for such workflows than Oval does, but it provides much less flexibility for creating other applications like those described in this paper.
While there have been numerous empirical studies of the use of cooperative work tools (e.g., Galegher, Kraut and Egido [1990], Sproull and Kiesler [1991], Olson and Olson [1991]), we are not aware of any other studies that use the "benchmarking" approach we have adopted here. We suspect that this approach of identifying a set of "benchmark" applications and then attempting to emulate them may be a useful methodology to apply in future evaluations of systems that claim to be highly extensible, modifiable, or tailorable.
Even though the primitives of objects, views, agents,
and links provide a powerful basis for constructing information
management and cooperative work applications, there are many difficult
problems to be solved before the full promise of this approach
is realized. For instance, numerous difficult issues arise in
trying to manage large numbers of linked objects in a shared,
distributed network. One particularly important aspect of this
problem involves how to manage the evolution of partially shared
object type definitions (e.g., Lee and Malone [1990]). Finally,
even if the approach described here were successful in completely
eliminating the programming effort needed to create applications,
the task of imagining new and useful things for computers to do
is a far from trivial one.
A previous version of this paper appeared in the Proceedings of the ACM 1992 Conference on Computer-Supported Cooperative Work (CSCW 92), Toronto, Canada, October 31 - November 4.
This research was supported by Digital Equipment Corporation, the National Science Foundation (Grant No. IRI-8903034), Matsushita Electric Industrial Co., Boeing, Information Resources, Inc., Electronic Data Systems, Apple Computer Company, and the corporate members of the MIT International Financial Services Research Center.
We are indebted to Terry Winograd for suggesting the acronym "Oval" after hearing about the four components of our system and to John McDermott for suggesting the term "radically tailorable" as a description of the Oval system. The Oval system has benefitted from the suggestions and work of numerous people over many years, including most recently: Mark Ackerman, Geoffrey Bock, Kevin Crowston, Randall Davis, Troy Jordan, Jintae Lee, Charley Osborne, Dave Park, Mike Plusch, and Paul Resnick.
The Coordinator is a trademark of Action Technologies, Inc.
ACKERMAN, M. S. and MALONE, T. W. 1990. Answer Garden: A tool for growing organizational memory. In Proceedings of COIS '90 Conference on Office Information Systems, Cambridge, MA, 12-13.
ACTION TECHNOLOGIES. 1988. The Coordinator, Version II, User's Guide . Action Technologies, Inc.
BENTLEY, R., RODDEN, T., SAWYER, P. and SOMMERVILLE, I. 1992. An architecture for tailoring cooperative multi-user displays. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), 187-194.
BHANDARU, N. and CROFT, W. B. 1990. In Multi-User Interfaces and Applications, S. Gibbs and A. A. Verrijin-Stuart, Eds. Elsevier (North Holland), Amsterdam, 337-354.
BORENSTEIN, N. S. 1992. Computational mail as network infrastructure for computer-supported cooperative work. In Proceedings of the ACM 1992 Conference on Computer-Supported Cooperative Work (CSCW 92), Toronto, Canada, 67-74.
BRACHMAN, R. J. and LEVESQUE, H. J., (Eds.). 1985. Readings in Knowledge Representation, Morgan Kaufmann, Los Altos, CA.
CONKLIN, J. and BEGEMAN, M. 1988. gIBIS: A tool for exploratory policy discussion. ACM Transactions on Office Information Systems. 6, 4 (October).
CROWSTON, K. 1991. Towards a Coordination Cookbook: Recipes for Multi-Agent Action. Ph.D. Dissertation, MIT Sloan School of Management.
DEWAN, P. and CHOUDHARY, R. 1992. A high-level and flexible framework for implementing multiuser user interfaces. ACM Transactions on Information Systems. 10, 4 (October), 345-380.
DISESSA, A. A. 1985. A principled design for an integrated computational environment. Human Computer Interaction. 1, , 1-47.
FISCHER, G. and GIRGENSOHN, A. 1990. End-user modifiability in design environments. In Proceedings of CHI '90 Conference on Human Factors in Computer Systems, 183-191.
GALEGHER, J., KRAUT, R. E. and EGIDO, C. (Eds.). 1990. Intellectual Teamwork: Social and Technological Foundations of Cooperative Work, Lawrence Erlbaum, Hillsdale, N. J.
GOLDBERG, Y., SAFRAN, M. and SHAPIRO, E. 1992. Active Mail - A framework for implementing groupware. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), Toronto, Canada, 75-83.
GREENBAUM, J. and KYNG, M. (Eds.). 1991. Design at Work: Cooperative Design of Computer Systems, Lawerence Erlbaum, Hillsdale, N. J.
GREIF, I. 1992. Designing group-enabled applications: A spreadsheet example. In GroupWare 92, San Jose, CA, 515-525.
HUTCHINS, E. L., HOLLAN, J. D. and NORMAN, D. A. 1986. In User-Centered System Design, D. Norman and S. Draper, Eds. Lawrence Erlbaum, Hillsdale, N. J., 87-124.
JEFFAY, K., LIN, J. K., MENGES, J., SMITH, F. D. and SMITH, J. B. 1992. Architecture of the Artifact-Based Collaboration system matrix. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), Toronto, Canada, 195-202.
JOHNSON, P. 1992. Supporting exploratory CSCW with the EGRET framework. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), Toronto, Canada.
KAPLAN, S. M., TOLONE, W. J., BOGIA, D. P. and BIGNOLI, C. 1992. Flexible, active support for collaborative work with ConversationBuilder. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), Toronto, Canada, 378-385.
KIEGLER, A. L. 1992. Improving Performance in Product Deployment by Improving Coordination. M.S. thesis, Dept. of Mechanical Engineering and Sloan School of Management, MIT.
KYNG, M. 1991. Designing for cooperation: Cooperating in design. Communications of the ACM.. 34, 12, 65-73.
LAI, K. Y., MALONE, T. and YU, K.-C. 1988. Object Lens: A spreadsheet for cooperative work. ACM Transactions on Office Information Systems. 6, 4, 332-353.
LEE, G. 1992. Oval Applications Catalog Technical Report. MIT Center for Coordination Science.
LEE, J. 1990a. In Artificial Intelligence at MIT: Expanding Frontiers, P. Winston, Ed. MIT Press, Cambridge, MA,
LEE, J. 1990b. Sibyl: A tool for managing group decision rationale. In ACM Conference on Computer-Supported Cooperative Work (CSCW '90), Los Angeles, CA,
LEE, J. 1991. A Decision Rationale Management System: Capturing, Managing, and Reusing the Reasons for Decisions. Ph. D. thesis, Department of Electrical Engineering and Computer Science, MIT.
LEE, J. and MALONE, T. W. 1990. Partially shared views: A scheme for communicating among groups that use different type hierarchies. ACM Transactions on Information Systems. 8, 1, 1-26.
LEFKOWITZ, L. S. and CROFT, W. B. 1990. Interactive planning for knowledge-based task management Technical report. University of Massachusetts, Dept. of Computer and Information Science, Collaborative Systems Laboratory.
LOTUS 1989. Lotus Notes Users Guide. Lotus Development Corp., Cambridge, MA.
MACKAY, W. E. 1990. Patterns of sharing customizable software. In Proceedings of CSCW '90 Conference on Computer-Supported Cooperative Work, Los Angeles, CA, 209-222.
MACLEAN, A., Carter, K., Lovstrand, L. and Moran, T. 1990. User-tailorable systems: Pressing the issues with buttons. In CHI '90 Conference on Human Factors in Computer Systems, Seattle, WA, 175-182.
MALONE, T., YU, K.-C. and Lee, J. 1989. What good are semistructured objects? Adding semiformal structure to hypertext Technical report #102. Center for Coordination Science, Massachusetts Institute of Technology.
MALONE, T. W., GRANT, K. R., LAI, K.-Y., RAO, R. and ROSENBLITT, D. 1987a. Semistructured messages are surprisingly useful for computer-supported coordination. ACM TOOIS. 5, 115-131.
MALONE, T. W., GRANT, K. R., TURBAK, F. A., BROBST, S. A. and COHEN, M. D. 1987b. Intelligent information-sharing systems. CACM.. 30, 390-402.
MEDINA-MORA, R., WINOGRAD, T., FLORES, R. and FLORES, F. 1992. The Action Workflow approach to workflow management technology. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), Toronto, Canada, 281-288.
NARDI, B. A. and MILLER, J. R. 1990. An ethnographic study of distributed problem solving in spreadsheet development. In Proceedings of CSCW '90 Conference on Computer-Supported Cooperative Work, Los Angeles, CA, 197-208.
OLSON, G. M. and OLSON, J. R. 1991. User-centered design of collaboration technology. Journal of Organizational Computing. 1, 61-83.
OSBORN, C. S. 1992. Management Support Systems, Interactive Management Controls, and Strategic Adaptation. Unpublished doctoral thesis, Harvard Business School.
PATTERSON, J. F., HILL, R. D., ROHALL, S. L. and MEEKS, W. S. 1990. Rendezvous: An architecture for synchronous multi-user applications. In Proceedinsg of the 1990 ACM Conference on Computer-Supported Cooperative Work (CSCW 90), Los Angeles, CA, 317-328.
PENTLAND, B. 1991. Making the right moves: Toward a social grammar of software support hot lines. Ph.D. thesis, Sloan School of Management, Massachusetts Institute of Technology.
PENTLAND, B. 1992. Organizing moves in software support hotlines. Administrative Science Quarterly. 37, 4, 527-548.
ROSEMAN, M. and GREENBERG, S. 1992. GroupKit: A groupware toolkit for building real-time conferencing applications. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92), Toronto, Canada, 43-50.
SCHULER, D. and NAMIOKA, A. (Eds.). 1993. Participatory Design: Principles and Practices, Lawrence Erlbaum, Hillsdale, N. J.
SHEPHERD, A., MAYER, N. and KUCHINSKY, A. 1990. Strudel: An extensible electronic conversation toolkit. In Proceedings of the ACM Conference on Computer Supported Cooperative Work (CSCW 90), Los Angeles, CA, 93-104.
SPROULL, L. and KIESLER, S. 1991. Computers, Networks, and Work. Scientific American. 265, 3, 84-91.
STEFIK, M. and BOBROW, D. G. 1986. Object-oriented programming: Themes and variations, AI Magazine, Spring, 40-62.
WEGNER, P. 1987. Dimensions of object-based language design. In Proceedings of the Conference on Object-Oriented Systems, Languages, and Applications (OOPSLA '87), Orlando, Fla., 168-182.
WINOGRAD, T. 1987. A language/action perspective on the design of cooperative work. HCI. 3, 3-30.
WINOGRAD, T. and FLORES, F. 1986. Understanding computers and cognition: A new foundation for design. Ablex, Norwood, NJ.
YOURDON, E. 1989. Modern Structured Analysis. Yourdon, Englewood Cliffs, NJ.
[1] Oval is based upon the Object Lens system (Lai, et al. [1988], Malone, et al. [1989]). However, we picked a new name to reduce the widespread confusion between Information Lens and Object Lens. Information Lens Malone, et al. [1987b] was a system for intelligent mail sorting. Oval, as this paper describes, is a much more general system in which Information Lens is only one possible application.
[2] For information on how to obtain a copy of the software for research purposes at no charge, contact Heather Mapstone, MIT Technology Licensing Office, E32-300, 28 Carleton Street, Cambridge, MA 02139 (Telephone: (617) 253-6966. Fax: (617) 258-6790. Email: mapstone@mit.edu.)