Coexistence and Transformation of Informal and Formal Structures: Requirements for More Flexible Hypermedia Systems

Transcription

1 Coexistence and Transformation of Informal and Formal Structures: Requirements for More Flexible Hypermedia Systems Jörg M. Haake, * Christine M. Neuwirth, ** Norbert A. Streitz * *IPSI - Integrated Publication and Information Systems Institute GMD - German National Research Center for Computer Science Dolivostr. 15, D Darmstadt, Germany, {haake,streitz}@darmstadt.gmd.de **Carnegie Mellon University, Pittsburgh, PA USA, cmn@cmu.edu ABSTRACT In this paper, we argue that some tasks (e.g., meeting support) require more flexible hypermedia systems and we describe a prototype hypermedia system, DOLPHIN, that implements more flexibility. As part of the argument, we present a theoretical design space for information structuring systems and locate existing hypertext systems within it. The dimensions of the space highlight a system's internal representation of structure and the user's actions in creating structure. Second, we describe an empirically derived range of activities connected to conducting group meetings, including the pre- and postpreparation phases, and argue that hypertext systems need to be more flexible in order to support this range of activities. Finally, we describe a hypermedia prototype, DOLPHIN, which implements this kind of flexible support for meetings. DOLPHIN supports different degrees of formality (e.g., handwriting and sketches as well as typed nodes and links are supported), coexistence of different structures (e.g., handwriting and nodes can exist on the same page) and mutual transformations between them (e.g., handwriting can be turned into nodes and vice versa). KEYWORDS: hypermedia interface, information structures, meeting support, design space for hypermedia systems, flexibility 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 copyright is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission ACM xxx-x/xx/xxxx... 1 INTRODUCTION The traditional view of hypertext is very closely related to by some authors even identified with the idea of freedom to associate. On this view, hypertext provides opportunities to deviate from linear, prescribed structures and to use more informal structures in communicating information ("Well, by 'hypertext' I mean non-sequential writing -text that branches and allows choices to the reader." [17]). For authors, hypertext systems provide a large degree of flexibility for connecting pieces of information and presenting it as an assembled collection in an information network. For readers, hypertext provides tools for navigating in these information networks and for exploring them freely. This way of presenting and exploring information was considered a new and promising development, especially contrasted with traditional information retrieval paradigms, with their highly structured storage requirements and their formal query languages. It was soon realized, however, that the hypertext approach had problems as well. There is the well-known (and too often quoted) disorientation problem of "getting lost in (hyper)space" and the problem of "cognitive overhead:" deciding what to put into a node, how to name it and which links to establish [5]. Related to the problem of cognitive overhead is the problem of "premature organization:" having to decide very early on how to segment the information and how to structure it [6]. After a phase of experimenting with the "free association and exploration" approach, the research and development community turned to the idea of typed nodes and links (to name a few: NoteCards, gibis, IDE, SEPIA, MacWeb and others). The rationale was twofold. First, it was argued, providing additional information to the reader/user by expressing more "semantics" would support communicative goals more effectively. Second, representing more semantic knowledge explicitly and formally would allow the system to process the information in ways that were not possible before. This approach related hypertext structures to knowledge representations as they had been developed in the AI-community (e.g., typed, slotted entities; reference-based

2 network structures) and led to increased research involving computation over hypertext networks (e.g., constraint checking). But with a larger variety of typed nodes and links, the problems of cognitive overhead and premature organization became even more of an issue. Presented with a more differentiated formalism and thus more options, users had to make even more decisions on names and types of nodes and links and structuring. These two phases first, emphasizing very informal and less structured approaches and second, capturing and presenting more structural properties were followed by a third one. Now it was argued that people do not like and, in some cases, do not need to use rigid structural representations. Rather, they prefer to organize their knowledge in a more flexible way, without being restricted to particular types of nodes and links, types which are often already preexisting and defined by the system. For example, Parunak [19] proposed a set-based approach which abandoned the idea of links to express relationships among pieces of information. Likewise, in his keynote address at Hypertext'91, Halasz [10] even argued for "ending the tyranny of the link." Finally, Marshall & Rogers [13] report that users relied upon simple spatial layout of text to express relationships among items in preference to using Aquanet's relational model for semantically and graphically expressing them. This latest phase leads naturally to the question of whether there is a need for a hypertext system at all or is, in some situations, using a standard drawing tool sufficient to support information structuring tasks? Although such tools have no internal knowledge about relationships, they also allow users to express and communicate relationships in a structured way. Compared to paper or traditional whiteboards, they have the advantage that users can edit and reuse elements, store the results, and so forth. In this paper, we present a proposal aimed at reconciling these different possibilities for information structuring systems, arguing for more flexible systems that span some of these differences. First, we present a theoretical design space for information structuring systems and locate existing hypertext systems within it. The dimensions of the space highlight a system's internal representation of structure and the user's actions in creating structure. Second, we describe an empirically derived range of activities connected to conducting group meetings, including the pre- and post-preparation phases, and argue that hypertext systems need to be more flexible in order to support this range of activities. Then we describe a hypermedia prototype, DOLPHIN, which we designed and built in order to provide this kind of flexible support for meetings. We then take these theoretical and empirical considerations as well as the system building experiences as sources of input for a set of requirements for more flexible hypermedia systems. Finally, we conclude with a discussion of our approach in terms of related research and plans for the future. 2 A DESIGN SPACE FOR INFORMATION STRUCTURING SYSTEMS Our basic claim and starting point is that people use a variety of ways to express their ideas and communicate them to other people, depending on the situation and task. Sometimes they use very informal elements for structuring information (e.g., handwriting; sketches; informal graphical elements, such as circles, arrows and exclamation marks; and annotations). Sometimes they create more formal structures, explicitly indicating the properties of and the relationships between the elements (e.g., typed links and nodes) and perhaps a more formal appearance (e.g., using boxes or circles for nodes and straight arrows for links), where differences in appearance may indicate different types of elements that communicate additional meaning (e.g., organization charts, flow charts). Asking for this range of ways to express information via a computer system (from very informal and unrestricted to very formal and adhering to explicit rules prescribed by the system) leads to the question: "How much of this structure is interpreted only by another human perceiving it and how much can be interpreted by the system in order to be used for further processing and even actively supporting the human user?" Addressing this question leads to a classification of information structuring systems described in the next section Dimensions for Information Structuring Situations and Systems Information structuring systems can be characterized on the following two dimensions: Degree to which a user explicitly identifies to the system (u dimension) In an object-oriented drawing program, for example, while the user can draw objects "free-hand," the user may also explicitly identify (e.g., circles, squares, etc.) to the system, often by selecting these objects from a menu or a palette. This dimension has a scale ranging from "not at all" to "all." Degree to which the system represents internally (s dimension) In a pixel-oriented drawing program, for example, the user may draw "objects" (e.g., circles, squares, etc.) which the user interprets as types, but from the system point of view, the input is simply pixels the system has no internal representation of the types of objects. This dimension also has a scale ranging from "not at all" to "all." "All" means that there would be a one-toone mapping between the types of objects that the user assigns mentally and is able to express in the system, and an internal representation of the. Of course, internal representations of are often used to provide some sort of functionality (e.g., if the user

3 has drawn a circle and wants it to be larger, the system provides a function that allows the user to resize the circle instead of erasing and redrawing it). "Free hand" drawing, however, also occupies a valuable niche in the design space because systems need to match users and tasks. For example, young children can operate a pixel-oriented paint program more easily than an object-oriented drawing program and rough sketches are easier to do with a pixeloriented drawing program than with an object-oriented drawing program. Thus, the dimensions should not be interpreted as implying a value judgement, with "more" being represented as "better" than fewer object types. For each application, the dimensions need to be matched to users and tasks. Together, these dimensions represent a design space of information structuring systems (see Figure 1). Since systems located on the extreme point "all" are rare, we will look at systems located at four points in the space defined by "not at all" and "very much." system represents internally s furniture) to the system, but the system represents these objects internally as pixmaps. 4 (u: "Very much," s: "Very much"): The user explicitly identifies to the system, which the system maps to internal representations of those. Examples are object-oriented drawing programs. An interesting example in the light of the example in "3" is an architectural-design tool that maintains an internal representation of various objects and can critique the design (e.g., if there are rooms with no doors, the system can critique the user's design). In this subsection we have defined a design space based on two dimensions and illustrated the dimensions by locating general information structuring systems along extreme points. From the user's point of view these systems differ with respect to the degree of informal and formal structures they can maintain. On the one hand, the user views sets of untyped objects (that have a specific semantics only in the head of the user) as rather informal structures. On the other hand, typed objects are perceived by the user as rather formal structures. In the next subsection we will look at the distribution of existing hypertext systems in the design space. very much Locating Existing Hypertext Systems in the Design Space Figure 2 depicts the location of existing hypertext systems in the design space. not at all 1 not at all Figure 1: Design Space 3 very much u user identifies 1 (u: "Not at all," s: "Not at all"): The user identifies no to the system and the system has no internal representation of the types of objects the user creates. Examples are pixel-oriented paint programs. 2 (u: "Not at all," s: "Very much"): The user identifies no to the system, but the system infers object types from the user's input (e.g., by interpreting the shapes of objects, their layout, etc.). Examples are handwriting recognition programs, which interpret pixel strokes as ASCII characters. 3 (u: "Very much," s: "Not at all"): The user explicitly identifies to the system, but the system maintains no internal representation of those object types. An example would be a palette-based "architectural design" program in which the user specifies various objects (e.g., doors, windows, system represents internally s very much not at all 2 e.g., PREP 1 not at all e.g., VIKI V II I IV 4 3 III very much e.g., Aquanet, gibis, IDE, MacWeb, SEPIA e.g., NoteCards e.g., Guide, HyperCard, Intermedia, KMS, Storyspace, VNS, WE u Figure 2: Existing systems in the design space user identifies Existing hypertext systems form two clusters of points, labeled "I" and "IV." Those systems forming the cluster labeled "I" (Guide [4], HyperCard [2], Intermedia [28], KMS [1; 28], Storyspace [3], VNS [22], WE [23], etc.) are those in which the user is only able explicitly to identify two types of objects, "nodes" and "links," and the system

4 Figure 3: Range of application scenarios currently supported by DOLPHIN represents these internally. While users can create labels for nodes and links which are meaningful to them, these labels do not constitute node or link types the system represents such labels as uninterpreted byte strings. Those systems forming the cluster labeled "IV" (Aquanet [12;13], gibis [6], IDE [11], MacWeb [16], SEPIA [25]) are those in which in addition to identifying nodes and links users explicitly identify node and link types which the system represents internally. Like their drawing program counterparts, systems typically use the type information to provide functionality. Aquanet [13], for example, provides system-maintained constraints for various types even for user-defined types; SEPIA [25] provides particular node and link types and activity spaces, making subsets of types available to users for parts of the authoring process in which they will be most useful; gibis [6] provides specific node and link types for representing IBIS structures and capturing design rationale. We have located a couple systems at intermediate points between the two large "I" and "IV" clusters. We have located the PREP Editor [18] at point "II," a little to the left of "I" and "IV" on the u-axis and between "I" and "IV" on the s-axis, because, while the system maintains an internal representation of link types (e.g., "path" links within a composite node and "annotation" links between nodes in different composites), the user does not identify those types explicitly the system infers the types based on the user identifying links between composite nodes and the location of the users' input in relation to the composites. We have located NoteCards [9] between "I" and "IV" on the s-axis because the user can define types of nodes which the system then represents internally. An interesting point in the space is "V," hypertext systems that are able to infer structure (i.e., links between nodes and types of composite nodes) based on spatial layout. For example, VIKI [15] incorporates structure finding algorithms which are able to infer structure by examining the spatial arrangement of the objects, their types, and their occurrence in collections. This analysis highlights the fact that existing hypertext systems are located relatively far to the right along the dimension of the user explicitly identifying to the system. In the next section, we will argue that there is a need for systems which provide users with more flexibility along both the dimensions. 3 DOLPHIN DOLPHIN is a hypermedia prototype designed to provide support for face-to-face and distributed meetings. Observations of meetings show that people use a range of structures from informal to very formal. Spontaneously created informal scribbles and sketches on a whiteboard to capture rapidly produced, highly interactive ideas (e.g., idea generation or recording important aspects of a discussion) are just as essential as more formal, prepared structures to present the results of work carried on primarily outside the actual meeting (e.g., a draft of a paper distributed beforehand to the members of the group or an analysis of design alternatives and rationale). DOLPHIN is designed to support both the informal and formal aspects of meetings. The basic scenario of DOLPHIN is a group of meeting participants sitting around a table with a large interactive, electronic whiteboard in front of them. But the goal and the

5 functionality of DOLPHIN is not restricted to this setting. The current implementation of DOLPHIN supports the following four application scenarios (see Figure 3): 1. a pen-based single user system on an electronic whiteboard. 2. a multi-user application shared between an electronic whiteboard and a number of local networked personal computers situated in the meeting room (e.g. on the table). 3. a multi-user application shared between an electronic whiteboard, the local networked computers, and remote desktop-based workstations connected by Ethernet and/or FDDI. 4. a multi-user application shared between one meeting room and a corresponding setup of an electronic whiteboard and computers in a second meeting room. DOLPHIN's user interface by walking through a hypothetical scenario derived from our observations of this group. Pre-meeting preparation. Using DOLPHIN with keyboard and mouse input from a private workstation, the manager of the editorial board prepares the topic of the meeting and initial agenda items prior to the actual meeting. At the beginning of the meeting, the manager displays the agenda on the public workspace on the Liveboard. Figure 4 shows a screen dump of the display on the Liveboard at the start of the hypothetical meeting. At the top of Figure 4, the text object "JANUARY ISSUE" indicates the overall topic of the meeting. There are two subtopics contributing to it, each represented by a node (with grey background). The node "WWW Workshop (III)" deals with the third part of a sequence of articles on the World Wide Web. The node "next issue" is a folder the manager created in advance for storing ideas that may come up in the meeting but which will not be dealt with in the January issue. To provide this range of application scenarios required addressing issues of interaction modes on large, interactive displays, connectivity between public displays and local computers, and connectivity between meeting room and remote participants. Those aspects of DOLPHIN are reported in Streitz, et al. [26]. We are using two SUN-based Xerox Liveboards [7] in order to realize interactive electronic whiteboards. In order to provide the group members with computers, we currently use SUN SPARCstations and compatible Tadpole SPARCbooks. The Liveboard is placed in front of the meeting table so that each meeting participant can see it. In addition, each participant can have access to a personal computer mounted in the table, while still being able to see and talk to the other participants. The public display on the Liveboard can also be presented on the personal computers. For such public displays, we provide WYSIWIS functionality (What You See Is What I See; see, e.g., [24]). But the provision of personal computers to group members also allows each member to work in parallel in a "private workspace" (similar to taking individual notes on paper, looking at documents, etc.) Functionality and User Interface In order to make general observations about meetings concrete and to gain further insight into how to support groups that required both informal and more formal structures, we observed staff meetings of the editorial board of an interactive hypermedia-based electronic newspaper, consisting of articles, calendar of events, news from the scientific community, notices of new publications, trip reports, and so forth [26]. 1 In the following, we describe 1 We studied the group's activities and interaction behavior by observing and videotaping their meetings and interviewing Figure 4: Pre-meeting preparation with DOLPHIN displayed on the Liveboard Capturing ideas. The manager asks participants for additional agenda items and records them on the fly by standing next to the Liveboard and using its pen-based input device to record them by hand. Figure 5 depicts the Liveboard screen. The handwritten item "server breakdown" was created on the fly to put a technical problem with the group's server on the agenda of this meeting. Other handwritings ("staff news," "InterCHI'93" and "page them about their pre- and post-meeting activities. The group size in the meetings varied between 5-9 persons. The group members were primarily non-computer scientists. Our observations involved two kinds of meetings. First, most of the regular meetings took place in a room with no computer support. Second, we asked the group also to meet in our CSCW lab. The latter meetings took place after the meetings without using computers.

6 layout") denote additional topics to be discussed in the meeting. Organizing ideas. The manager rearranges the agenda items by selecting them and dragging. The object "InterCHI'93" is dropped into the "next issue" box. By using a boxing gesture, the manager turns the item "staff news," into a node, so that it will be possible to associate other information with it (e.g., who is going to work on that, etc.). The item "staff news" becomes the label of the new node. Figure 6: Scribblings, drawings and annotations in DOLPHIN displayed on the Liveboard. Figure 5: Screen dump of DOLPHIN displayed on the Liveboard. Integration of external information. During the discussion of "page layout," one of the participants imports a graphic object (the node labeled "Klaus' proposal" and displays its content (a graphic designer's sketch for a new design of the newspaper's front page). DOLPHIN allows users to import text, images, and SEPIA structures [25]. Allowing users to use prepared documents by importing standard text and image files and even hypermedia documents in private or public workspaces during the meeting creates an open environment that facilitates the integration of external information into the meeting process. Sketching. While discussing the proposal for the new page layout, one participant moves to the Liveboard and draws a schematic view of an alternative layout. This drawing is subsequently annotated by scribbles (lines, exclamation mark), highlighting important elements during the discussion (see Figure 6). Post-meeting follow-up. The manager asks one participant to analyze the two proposals and present the results at the next meeting. After the meeting, the person decides to analyze the two proposals using the IBIS issue-position methodology, a method of organizing design decisions into "issues," "positions," and so forth [6]. (Of course, such an analysis could also have been done during the meeting.) Working at a workstation, the person opens the DOLPHIN document (see Figure 7), copies the informal DOLPHIN structure into SEPIA, and transforms it into a node of type "issue," then connects it to two subissues, "keep old" and "create new," via links of type "serve." There are also two positions to the subissue "create new": "Klaus' proposal" and "Ingrid's design". These position nodes are connected to the issue by using links of type "answer." Thus, the previously informal structure is elaborated and transformed into a more formal structure. Because SEPIA supports synchronous and asynchronous work of members in distributed groups [8; 25], working groups established in a meeting are able to collaborate after the meeting. It is this tight integration that blurs the traditional border between meetings and the individual workplace and is a first step towards distributed virtual meetings in a very general sense. Since a meeting requires the reuse of documents and decisions in subsequent activities, it is useful that users can transform DOLPHIN documents (or parts of them) in their regular work environment. As this scenario illustrates, documents of very different character can emerge during meetings, depending on the stage of the overall process. Participants may start with the topic of the meeting, build agendas, start and keep notes of (sub)discussions, capture decisions, incorporate information from previous meetings or external sources, and reorganize the structure of the meeting document.

7 Any kind of atomic content object (e.g., scribble, text image) can be used as a node's label. Content of Nodes. Nodes always have a compound content. The content may present nodes, links, scribbles, text, and images concurrently. The content of a node is displayed in the open DOLPHIN window (i.e., replacing the old content). In DOLPHIN, the content of a node may be viewed as a complete page (i.e., drawing area). Figure 7: Post-meeting follow-up in SEPIA at the workplace DOLPHIN's Data Model Support for such cooperation and communication in groups requires a meeting system to provide objects and operations that allow users to express their ideas, plan further actions, discuss them, incorporate existing material, and so forth. Taking into account that different tasks and phases in the meeting process require different kinds of objects and structures leads to the definition of a corresponding set of objects and operations for creating these structures. To provide as much freedom as possible to create different types of content and to create explicit relationships between them as well as between parts of them, we adopted a general hypermedia approach. This means that all objects and relationships are realized as hypermedia objects and links with varying degrees of complexity (e.g., layered and embedded composite objects) as well as having multimedia content. At the same time, we consider hypermedia not only as the content of cooperation, but also as a medium for cooperation and coordination [25]. As a medium, hypertext supports different types of annotations and clustering of objects according to task, domain or group characteristics. The current implementation of the DOLPHIN prototype supports the following objects: Scribble. A scribble is some writing or drawing. Scribbles may have multiple forms: handwritten text, exclamation marks, figures such as boxes, circles, arrows, tables, etc. Nodes. A node may be described as an object consisting of other objects. Its content may be displayed as a drawing area presenting other objects. As illustrated in the scenario, nodes can be used to organize material presented or constructed in a meeting. Nodes present themselves as distinguished items on a drawing area (e.g., a boxed item). Links. A link connects nodes within the content of a node (i.e., nodes presented on the same drawing area). Together with the concept of a node, they enable users to organize their material in multiple hierarchical structures, using nested nodes or folders, and to relate nodes by using links. Links present themselves as arrows with a handle. Text. A text is an ASCII text object placed on a page. It can be imported from outside DOLPHIN and can be edited. Image. An image is a pixmap drawing object placed on a page. It can be imported from outside DOLPHIN and can also be edited (if DOLPHIN provided the appropriate editor). These objects are mapped on a hypermedia data model provided by an underlying hypermedia engine. Nodes and links are realized as hypermedia nodes and links. Hypermedia nodes carry a composite content containing references to other nodes and links as well as to atomic content objects like text, images and scribbles. Each content object includes the atomic content and additional presentation attributes (e.g., size, color, position). Together with operations for creating, deleting, editing, selecting and moving, these objects facilitate the flexible structuring of information. The emerging structure can be regarded as a document organized by nodes and links, where nodes carry information items. Thus, a DOLPHIN document can be described as a nested hypermedia document. The top level of this hyperdocument is a node representing the top level drawing area (page). Here, users can create further nodes providing new drawing areas (pages). Note that the resulting hyperdocument structure is not restricted to hierarchical organizations. Including the same node in the content of multiple nodes may result in non-hierarchical network structures The General Data Model The implementation of DOLPHIN is based on the Cooperative Hypermedia Server (CHS) [21]. CHS was originally developed as a basis for the persistent storage and collaborative use of hypermedia documents in SEPIA. Thus, the original CHS data model can be regarded as the kernel hypermedia data model. The specific needs of DOLPHIN (i.e., persistent scribbles and compound contents to implement pages) led to the development of an extended data model. These extensions include additional for contents and composite nodes as well as a unified presentation mechanism.

8 DOLPHIN and SEPIA browsers have been modified to allow the presentation of instances of any object type in the extended CHS data model (e.g., DOLPHIN can display typed nodes and links, and SEPIA can display scribbled node titles). Both tools can be viewed as separate clients of an extended CHS server (see figure 8). create & edit DOLPHIN browser extended CHS display CHS Figure 8: Conceptual architecture SEPIA browser create & edit Due to the special tasks of DOLPHIN and SEPIA, the respective browsers are restricted to create and manipulate only objects from a part of the extended CHS data model. Whereas SEPIA allows the creation and editing of typed hypermedia structures, DOLPHIN supports the creation and editing of compound contents (pages) containing scribbles, text and graphics, as well as networks consisting of instances of the DOLPHIN node and link types. Because SEPIA uses the common extended CHS, SEPIA can be used to access hypermedia structures created in DOLPHIN and to change the type of DOLPHIN nodes and links to more strict SEPIA types. Due to the unified presentation mechanism, both tools are able to present hypermedia structures consisting of objects of DOLPHIN and SEPIA types Coexistence of Informal and Formal Structures DOLPHIN allows users to create structures corresponding to the three extreme points of the design space described earlier (see points 1, 3, and 4, Figure 9). First, DOLPHIN allows users to sketch and draw, using pen strokes; create and edit ASCII text; and import images. These objects are not typed and thus this part of DOLPHIN's functionality corresponds to objects created in situation "1." Second, users can group objects together and reuse them by copy and paste operations. The user can use grouped objects to express types explicitly, though the system does not represent those types internally. Thus, DOLPHIN includes functionality of situation "3." Third, DOLPHIN provides a node type and a link type as basic hypertext. In addition, DOLPHIN can import and export objects to/from SEPIA. In SEPIA, users can explicitly assign more elaborated types to nodes and links created in DOLPHIN and import them again into DOLPHIN. Thus, the combination of DOLPHIN with SEPIA provides functionality of situation "4." In sum, DOLPHIN allows the coexistence of several kinds of objects on a single page. Scribbles, text objects, nodes and links can coexist and be related to each other using graphical means (i.e., annotations, arrows, spatial layout), hypertext nodes (e.g., for clustering substructures), or hypertext links (for relating hypertext nodes on a page) Transformation of Structures The ability to transform already created objects provides users with a crucial flexibility to focus on the creation of objects without the cognitive overhead of deciding their types during their creation. Research suggests that such a flexibility can be crucial to facilitating those cognitive processes which are of primary importance, for example, for idea generation as part of brainstorming activities. For example, the research on generating ideas suggests that it is important to focus on getting thoughts down on the page rapidly, without regard to their quality or organization. Decisions about quality or relationships among ideas can be made later, after idea capture. system represents internally s very much not at all 2 1 not at all very much Figure 9: Structure transformations in DOLPHIN a b 4 3 c u user identifies DOLPHIN also supports transformations of existing objects. While Figures 1 and 2 show only the situation with respect to creating objects, Figure 9 shows object transformations users can perform after creation (see the double-headed arrows labeled "a," "b" and "c"). Every transformation includes two directed transformation functions: one for identifying type information, the other for removing type information. (a) Transformation "a" (from "1" to "3") provides the user with a way to specify that an already created object or set of objects is of a particular type (though the system does not represent the type internally). For example, in objectoriented drawing programs users are provided with a "group"-operation. Or a system might allow users to create individual objects, later define a palette representative, and replace the individual objects with the representative. The

9 reverse transformation strips this type representative information from the objects, thus leading to plain basic objects again. For example, in object-oriented drawing programs users are provided with a "ungroup"-operation. In DOLPHIN, a similar group/ungroup functionality is provided. (b) Transformation "b" (from point "1" to "4") provides the user with a way to associate types with previously created but not explicitly typed objects by identifying the corresponding system type. For example, in DOLPHIN users can turn groups of strokes into nodes, in which the strokes function as the node label. The reverse operation strips the associated internal object type and leads to the original basic again. For example, a DOLPHIN node that has been constructed from some strokes can be turned back into a collection of strokes. (c) Transformation "c" (from point "3" to "4") is similar to transformation "a," except that "c" provides the user with a way to associate an entire set of objects with an internal object type. This can be done because the user created the objects by explicitly identifying their type (e.g., from a palette or by defining a "group"), even though the system did not maintain an internal representation of that type (though the system must represent that the objects are all instances of the same category). The reverse operation strips the associated internal object type and leads to the original again. In DOLPHIN, users are able to create nodes based on groups of objects. 4 REQUIREMENTS FOR FLEXIBLE HYPERTEXT SYSTEMS Our theoretical analysis of information structuring systems, combined with requirements we derived from the research literature on meetings as well as from observing and interviewing actual meeting participants, builds a case for the following general requirements for more flexible hypermedia systems: 1) The system should provide objects with different degrees of formality to users. The objects should differ in their degree of expressiveness for explicit type information. 2) The user should be able to determine which degree of formality is needed in a given application situation. 3) It should be possible for objects with different degrees of formality to co-exist and be related to each other. 4) The system should be able to build up automatically a semantically valid internal representation of the information objects created by the users. 5) Users should be able to transform different types of structures into each other in a flexible way. system represents internally s very much not at all d 2 1 not at all very much Figure 10: General transformations e f a b 4 3 c u user identifies When looking at Figure 9, it is immediately obvious that there are some transformations missing which, from a theoretical point of view, should exist. Thus, the general and complete design space looks like Figure 10. Besides the transformations a - c, discussed in the previous section, three more transformations of already created objects are desirable (d - f): Transformation "d" (from "1" to "2") provides the user with a way to let the system recognize in the set of objects created by the user upon user demand rather than upon creation. For example, a handwriting recognition component may transform pen strokes into ASCII characters upon user demand rather than upon creation. The reverse transformation strips this type information and turns the objects back into their initial state. For example, recognized ASCII characters may be turned back into their initial strokes. Transformation "e" (from "3" to "2") provides the user with a way to let the system recognize in the set of objects which are instances of categories created by the user, again on demand rather than upon creation. For example, a structure recognition program might use the category information to consistently map instances of the category to a derived unique internal object type. The reverse operation would strip the associated internal object type and leads to the original basic again. Transformation "f" (from "2" to "4") provides the user with a way to associate internal explicitly with objects already having an automatically derived object type. The reverse operation lets users train the system so that new can be derived on demand. For example, a handwriting recognition system that provides the user with a way to train it to recognize new pen strokes as particular ASCII characters would belong into this category.

10 A perfectly flexible hypertext system would provide all these transformations (a - f) and support a full range of structures between the end points. This would make it possible for such a system to accommodate situations requiring new combinations of informal and formal structures. 5 CONCLUSIONS AND FUTURE WORK In this paper, we have argued that particular tasks require more flexible hypermedia systems and we have described a prototype hypermedia system, DOLPHIN, that implements more flexibility. Particular tasks require different degrees of formality, coexistence of different structures and mutual transformations between them. Meetings are one example of such tasks. Systems such as Tivoli [20] support meetings by providing a stroke-based, interactive electronic whiteboard that allows meeting participants to draw and scribble on the Xerox Liveboard. Still, such systems lack support for more formal structures, coexistence and transformations. Previous hypertext systems aimed at supporting tasks that did not require such flexibility (but which, of course, had other requirements). We are now at a phase where it is possible to support a more complete range of tasks that require more flexibility and coexistence of different kind of structures. Hypermedia architectures are especially well-suited for representing structures with different degrees of formality. As DOLPHIN shows, hypermedia systems can support a whole range of different situations in the design space of information structuring systems. Streitz [27] has argued that flexible hypermedia systems are an especially appropriate basis for building "situation aware" CSCW systems because they can be adapted to the various social and physical conditions that arise in cooperative work. We expect future hypertext systems to support a wider range of tasks and therefore to provide greater flexibility to their users. This includes more or less complete coverage of the design space introduced in this paper. The work has a number of implications for research on the design of more flexible hypermedia systems. First, it raises user interface issues, such as how to make it easy for users to carry out transformations and how to support combinations of different structures in a single interface effectively (e.g., so that users experience consistency in editing operations across different, etc.). Second, it raises user tailorability issues (e.g., support for the definition of user-defined types) and how to support transformations of such types. Third, it raises open systems issues (e.g., allowing users to employ their usual text-editing/drawing tools in the problem-solving process). In such an open architecture, a flexible hypertext system would act as a shell that binds different tools and structures together. The work also raises a number of empirical issues. First, it raises the question of whether more flexible hypermedia systems would help solve some of the problems, such as cognitive overhead and premature organization, reported in the hypermedia literature. It is possible that systems such as DOLPHIN, which allow users to capture ideas first and then decide whether they should be represented as a node, could eliminate or alleviate such problems. More experience with users on a wider variety of tasks will help answer this question. Second, it raises the question of what other task situations, besides meetings, would benefit from more flexible hypermedia systems. Third, it raises the question of how to balance such flexibility with the requirements of working together with a group of people, in which each person may have different background, approaches and preferences. The work presented here can be seen as an initial attempt to theorize a design space that identifies relevant abstractions for building more flexible hypermedia systems. We have used the theory as a basis for guiding the evolution of a hypermedia prototype. Another important source of evolution has been working with users. As the DOLPHIN prototype has evolved, we have conducted informal observations and a more controlled interface study with ourselves and our colleagues. Future research will include more work with users. We plan to put it in the hands of the editorial board of the hypermedia newspaper to use over extended periods of time. We view the interaction with user groups as an important source of design requirements. For example, the editorial board has requested the ability to create lists of "action items." We are currently discussing a design which would implement this request by allowing users to mark handwritten items as nodes of particular types. For example, a user could mark an item as an "action item." The system could put it automatically on a scrollable, list of items (allowing users to reorder the items, associate people who are responsible, etc.) and generate a link of type "reference" to the copy on the list to the original (allow users to recover the original context for the item easily). Other directions of development for DOLPHIN include more complete coverage of the design space. For example, extending DOLPHIN by automatic structure recognition (e.g., identifying templates for action planning and maintaining their graphical relationship, analogous to Marshall & Shipman [14, 15]) would yield a system covering the whole space. The concept of hypertext originated from the ideas of freedom to associate and flexibility. During later phases of hypertext research, there was a move toward more structure, followed by a reaction against structure. With flexible hypertext systems, an integration of different phases of research pursued in the past can be achieved. ACKNOWLEDGEMENTS We thank the members of the WiBAS department for valuable comments and discussions. Special thanks are also due to B. Bokowski, L. Kirchner, J. Schümmer, and C. Schuckmann, who helped us to implement DOLPHIN.

11 The second author wishes to thank the Fulbright Commission for making an extensive stay at GMD-IPSI possible, and members of GMD-IPSI for providing a collegial and stimulating research environment. REFERENCES [1] Aksyn, R. M., McCracken, D. L., & Yoder, E. A. (1988). KMS: a distributed hypermedia system for managing knowledge in organizations. Communications of the ACM, 31(7), , July. [2] Apple Computer. (1989). HyperCard stack design guidelines. Addison-Wesley. [3] Bolter, J. D., & Joyce, M. (1987). Hypertext and creative writing. In Proceedings of the First ACM Workshop on Hypertext (HYPERTEXT'87) (pp ). Chapel Hill, NC, November 13-15, ACM Press. [4] Brown, P. J. (1987). Turning ideas into products: The Guide system. In Proceedings of the First ACM Workshop on Hypertext (HT'87) (pp ). Chapel Hill, NC, November 13-15, ACM Press. [5] Conklin, J. (1987). Hypertext: An introduction and survey. Computer Magazine, September 1987, [6] Conklin, J., & Begeman, M. (1988). gibis: A hypertext tool for exploratory policy discussion. ACM Transactions on Office Information Systems (TOIS), 6 (4), [7] Elrod, S. et al. (1992). Liveboard: a large interactive display supporting group meetings, presentations and remote collaboration. Proceedings of the CHI'92 Conference (pp ). Monterey, CA, USA, May 3-7. [8] Haake, J. M., & Wilson, B. (1992). Supporting collaborative writing of hyperdocuments in SEPIA. In Proceedings of the ACM Conference on Computer-Supported Cooperative Work (CSCW '92) (pp ). Toronto, Canada, October 31 - November 4. [9] Halasz, F. G. (1988) Reflections on Notecards: Seven issues for the next generation of hypermedia systems. Communications of the ACM, 31(7), [10] Halasz, F. G. (1991). Seven issues revisited. Keynote address at the Third ACM Conference on Hypertext (HT'91). San Antonio, Texas, USA, December [11] Jordan, D. S., Russell, D. M., Jensen, A. S. & Rogers, R. A. (1989). Facilitating the development of representations in hypertext with IDE. In Proceedings of the 2nd ACM Conference on Hypertext (Hypertext `89) (pp ), Pittsburgh, PA, November 5-8. [12] Marshall C., Halasz, F., Rogers, R., & Jansen, W. Jr. (1991). Aquanet: A hypertext tool to hold your knowledge in place. In Proceedings of the 3rd ACM Conference on Hypertext (Hypertext '91) (pp ). San Antonio, TX, December ACM Press. [13] Marshall, C., & Rogers, A. (1992). Two years before the mist: Experiences with Aquanet. In Proceedings of the ACM European Conference on Hypertext (ECHT'92) (pp ). Milano, Italy, Nov Dec. 4. [14] Marshall, C., & Shipman, F. (1993). Searching for the missing link: Discovering implicit structure in spatial hypertext. In Proceedings of the ACM Conference on Hypertext (HT'93) (pp ). Seattle, USA. ACM Press. [15] Marshall, C., Shipman, F., & Coombs, J. H. (1994). VIKI: Spatial hypertext supporting emergent structure. In Proceedings of the ACM European Conference on Hypertext (ECHT'94 (this volume). Edinburgh, England. [16] Nanard, J., & Nanard, M. (1991). Using structured types to incorporate knowledge in hypertext. In Proceedings of the 3rd ACM Conference on Hypertext (Hypertext '91) (pp ). San Antonio, TX, December ACM Press. [17] Nelson, T. (1987). Literary machines. Edition 87.1 [18] Neuwirth, C. M., Kaufer, D. S., Chandhok, R., & Morris, J. (1990). Issues in the design of computer support for co-authoring and commenting. In Proceedings of the Conference on Computer Supported Cooperative Work (CSCW '90) (pp ). Los Angeles, California, October ACM Press. [19] Parunak, H., & Van Dyke (1991). Don't link me in: Set-based hypermedia for taxonomic reasoning. Proceedings of the Third ACM Conference on Hypertext (HT'91) (pp ). San Antonio, Texas, USA, December ACM Press. [20] Pederson et al, (1993). Tivoli: An electronic whiteboard for informal workgroup meetings. In Proceedings of the ACM Conference on Human Factors in Computing Systems (InterCHI'93), (pp.

12 ). Amsterdam, The Netherlands, April ACM Press. [21] Schütt, H. & Haake, J. M. (1993). Server support for cooperative hypermedia systems. In H. P. Frei & P. Schäuble (eds.), Hypermedia (Proccedings of the international Hypermedia'93 Conference), (pp ). Zürich, Switzerland, March 2-3. Berlin: Springer. [22] Shipman, F. M., III., Chaney, R. J., & Gorry, G. A. (1989). Distributed hypertext for collaborative research: The Virtual Notebook System. In Proceedings of the 2nd ACM Conference on Hypertext (Hypertext `89) (pp ). Pittsburgh, PA, November 5-8. [23] Smith, J. B., Weiss, S. F., & Ferguson, G. J. (1987). A hypertext writing environment and its cognitive basis. In Proceedings of the First ACM Workshop on Hypertext (HYPERTEXT'87) (pp ). Chapel Hill, NC, November 13-15, ACM Press. [24] Stefik, M. et al. (1987). Beyond the chalkboard: Computer support for collaboration and problem solving in meetings. Communications of the ACM, 30(1), [26] Streitz, N.A., Geißler, J., Haake, J. M., & Hol, J. (1994). DOLPHIN: Integrated meeting support across Liveboards, local and remote desktop environments. To appear in Proceedings of the Conference on Computer Supported Cooperative Work (CSCW '94). Also available as Arbeitsberichte der GMD, No. 829, Sankt Augustin, Bonn. [27] Streitz, N.A. (1994). Putting objects to work: Hypermedia as the subject matter and the medium for computer-supported cooperative work. In M. Tokoro & R. Pareschi (eds.), Proceedings of the 8. European Conference on Object-Oriented Programming (ECOOP'94). Lecture Notes in Computer Science. Berlin: Springer. [28] Yankelovich, N., Haan, B. J. Meyrowitz, N. K. & Drucker, S. M. (1988). Intermedia: The concept and the construction of a seamless information environment. IEEE Computer, 22(1), [29] Yoder, E., Akscyn, R., & McCracken, D. (1989). Collaboration in KMS, a shared hypermedia system. In Proceedings of the SIGCHI Human Factors in Computing Systems (pp ). Austin, Texas, April 30-May 4. ACM Press. [25] Streitz, N.A., Haake, J. M., Hannemann, J., Lemke, A., Schuler, W., Schütt, H., & Thüring, M. (1992). SEPIA: A cooperative hypermedia authoring environment. In Proceedings of the ACM European Conference on Hypertext (ECHT 92) (pp ). Milano, Italy, Nov Dec. 4.