Application of Frameworks in Groupware | The Iris Group Editor Environment Michael Koch Xerox Research Centre Europe, Grenoble Jurgen Koch Institut fur Informatik, Technische Universitat Munchen The goal of this paper is to present framework technologies from another perspective: Component technology and framework concepts as a solution for providing tailorability at the user level. We introduce and discuss groupware as one application domain where tailorability is a critical issue and present the framework based architecture of our group editor application Iris. Categories and Subject Descriptors: D.1.5 [Software]: Object-oriented Programming General Terms: Frameworks, Tailorability, Component Technology, Groupware, CSCW Additional Key Words and Phrases: group editors, Iris, Java
1. INTRODUCTION Most of the publications on frameworks describe them as tools for optimizing the design and implementation of complex software [Fayad and Schmidt 1997]. This paper presents another point of view: Framework concepts for enabling tailorability through the user of the application. We will use the application domain of Computer Supported Cooperative Work (CSCW) because the need for tailorability can be easily demonstrated here. While tailorability is also an issue outside the scope of CSCW, the special demands of support for cooperative work make it a critical issue for groupware. Thus, tailoring of groupware raises several questions, which in the mainstream adaptability discussion are not (and do not have to be) addressed { at least not to the degree necessary in CSCW [Stiemerling and Cremers 1998]. 2. COMPUTER SUPPORT FOR COOPERATIVE WORK In general, collaborative work involves a group of two or more people working together on a common goal. In contrast to single user software, where one single user already can pro t from the software, software for supporting collaborative work (groupware) needs to reach a critical mass of users to be usefull. Hence, groupware does not only have to be accepted by a single person, but has to be accepted by all members of the group (or at least by a critical mass). This requirement is hardened by the di erent group members usually having di erent preferences and di erent Address: M. Koch, XRCE, 6 chemin de Maupertuis, F-38240 Meylan, France, Email:
[email protected]; J. Koch, TUM, Institut fur Informatik, Arcisstr. 21, D-80290 Munchen, Germany, Email:
[email protected]
2
M. Koch, J. Koch
experience. In addition to di erent requirements from the di erent group memebers, the usage of groupware in di erent projects results in very di erent requirements of functionality of the software. Furthermore, even within one project, one has to distinguish between di erent stages with di erent requirements. Usually collaborative work involves phases of writing and phases of communication. It also involves periods of synchronous activity, where the group works together at the same time, and periods of asynchronous activity, where group members work at di erent times. Requirements for groupware These di erent and changing requirements can only be mapped by software, that is very exible and that can be adopted very easily to individual and situationdependant requirements. One part of this exibility is the support for di erent work strategies, for di erent coordination strategies. The other part is that in order to guarantee the acceptance of a broad range of users groupware has to o er the users themselves as much
exibility as possible in choosing needed functionalities and in con guring the user interfaces. A group writing tool for example has to support all authors in their preferred working styles and working environments1. This includes the fact that di erent authors should be able to use di erent user interfaces (including standard tools or standard-tool-like user interfaces) to access the document. User of groupware need to: |be able to use their favorite user interface or at least to be able to largely customize the standard interface to their needs, |be able to integrate the di erent functionalities needed to accomplish the di erent tasks included in collaboratively writing documents, and |be able to change the tool composition for other group setups or while the project is in progress. All these requirements can be summarized in the words extensibility and con gurability. Implementation of tailorability M rch presents in [M rch 1997] three levels of tailoring: customization, integration, and extension. Customization means to tailor an existing application by changing prede ned settings, integration is to build an application by integrating di erent modules, and extension is to further customize the application by building own modules. To support integration and extension, applications have to be highly modular and dynamically changeable. The state-of-the-art solutions for the corresponding engineering problems are object-oriented concepts and framework technology. In the following section we will brie y describe our group editor application Iris and the underlying framework architecture, to give an example for this. It is possible that authors have to agree on some common procedures for making coordination possible. But the software itself should not force a group member to change his environment or procedures. 1
Application of Frameworks in Groupware { The Iris Group Editor Environment
3
3. THE IRIS APPLICATION Iris is an application for collaboratively editing documents built upon a distributed document storage and awareness service. It provides di erent functionalities (edit/ display document structure, edit/display document content, display awareness information, interfaces to communication tools) that serve di erent information needs.2 The basic features of Iris are: |Iris consists of di erent modules, called `tools'3 , who present themselves to the user in one or more windows or in an applet area in a Web browser. |The tool composition and the assignment of tool user interfaces to windows is changeable during run-time. |The tools combined in one application are able to communicate with each other (inter-tool communication). Figure 1 shows a possible con guration of Iris: The application consists of a navigation area that displays the document structure and additional awareness information (color coded tree nodes for visualizing information on working areas and change history). Beneath the tree widget, a document part is presented in an editing area and at the bottom of the main window a list of the authors is displayed in a user list tool. Additional windows are available on demand for displaying the history of document sub-trees and viewing or editing attributes of document objects. In order to build Iris we developed a component infrastructure framework named ICI (Iris Component Infrastructure). Iris Component Infrastructure framework When building ICI there were two main requirements to the framework: |It should enable the user of the application to do `integration' (see Section 2), i.e. to combine di erent tools and maintain the picture of one application (common windows for the user interfaces of several tools, common user interface styles). |It should support programmers in building components that t into the framework. The ICI framework consists of a core object called `ToolConnector' and two di erent kinds of components: |Tools which implement the functionality needed by the users, and |Services which supply numerous methods to be used by the ToolConnector, tools and other services. The ToolConnector and its attached services manage the collection of tools and services, provide primitives for inter-tool communiction, and manage the user interface. Changes in the tool composition can be requested by tools or by the user using dialogs provided by ICI. Detailed information about Iris and information about the storage and awareness layer can be found in [Koch 1995; Koch 1997b; Koch and Koch 1997; Koch 1997a]. 3 A `tool' is an application that ful lls a speci c task in the context of collaborative document editing. A tool instance is related to exactly one document.
2
4
M. Koch, J. Koch
Fig. 1. Iris user interface application
Tools are running in separate threads but can be controlled by the ToolConnector (they have to be derived from a given framework class that implements the basic managing functionality). Services correspond to dynamic shared libraries and are loaded automatically when needed. Both, tool and service classes have to be derived from basic classes provided in the framework. These stub classes include the functionality for handling the connection between ToolConnector and tool and for accessing the framework services. ICI user interface model The main aim of ICI was to enable the di erent tools to present themselfes as one application and to privide and maintain a central set of perferences. The user of the application can interactively change the tool composition and rearrange the user interfaces of the loaded tools. Therefore, the tools user interfaces are organized in so-called workspaces. One or several of these workspaces can be put into a window or into an applet area. The arrangement can be changed dynamically during run-time. Figure 1 shows such a composition of four workspaces in two windows. The integration of the tools to one application is completed by providing simi-
Application of Frameworks in Groupware { The Iris Group Editor Environment
5
lar menu bars in all windows. These menu bars contain some default menus and the menus of the currently selected tool in that window (active workspace). Default menus cover opening and closing documents, adding and removing tools, invoking communication application, setting user preferences (colors, positions of workspaces), and so on. In addition to the service of managing the windows for the tools workspaces, the part of ICI responsible for managing the user interface (the user interface service) also provides functions to automatically set the properties of user interface elements to given application wide standards (e.g. for colors or fonts). The ICI user interface and the rest of ICI is made possible by requiring the developer to separate functionality and user interface areas of their modules and derive both of them from the given framework classes `Tool' and `Workspace'. These classes are directly connected to the ToolConnector and make the functionalities described before easily accessible to the tool programmer. Iris tools Using the ICI framework we implemented several tools that can be dynamically combined to form a group editor application: |edit document content: We have tools for viewing and editing single content objects of di erent media types and a tool for editing a linearized sub-tree of an hierarchically structured document. The latter tool implements a compound document framework and supports di erent content types. Additionally, we implemented a wrapper tool that supports the editing of text objects or sub-trees of text objects with external editor applications. Finally, we have tools for version control and for con ict noti cation and con ict resolution (merge tools). |navigation in the document: Here we have some tools for displaying document structures enriched with awareness information. One example is the tree display shown in Figure 1. Other tools are a folder display for hierarchical document structures and a graph view for hypertext structures. |display of awareness information: Awareness information is displayed in the editor and navigation tools. Additionally, there are two tools for displaying user and host information (one possible appearance of the user information tool is shown in Figure 1). Our current prototype implementation of Iris is pure Java (JDK 1.1). The software is available to the public via the Iris-web site4 . 4. CONCLUSION We presented the application area of groupware as an example where tailorability is badly needed and showed that framework technologies can help to design applications that can be easily tailored by the end user. In addition to the ease of combining di erent modules, in Iris framework concepts also helped making it more easy for programers to contribute new elements to the set of modules and so to further support the end users in tailoring the system to their needs. 4
http://www11.informatik.tu-muenchen.de/proj/iris/
6
M. Koch, J. Koch
REFERENCES
Fayad, M. E. and Schmidt, D. C. 1997.
Object-oriented application frameworks. Communications of the ACM 40, 10 (Oct.), 32{38. Koch, J. 1997a. Entwurf und implementierung einer komponentenarchitektur fur den mehrbenutzereditor iris. Masters's thesis, Inst. fur Informatik, Techn. Univ. Munchen, Germany. Koch, M. 1995. Design issues for a distributed multi-user editor. Computer Supported Cooperative Work | An International Journal 3, 3-4, 359{378. Koch, M. 1997b. Unterstutzung kooperativer Dokumentenbearbeitung in Weitverkehrsnetzen. Ph. D. thesis, Inst. fur Informatik, Techn. Univ. Munchen, Germany. (also available as: `Kooperation bei der Dokumentenbearbeitung - Entwicklung einer Gruppeneditorumgebung fur das Internet', DUV, Wiesbaden, 1997). Koch, M. and Koch, J. 1997. Using component technology for group editors - the iris group editor environment. In G. H. ter Hofte and H. J. van der Lugt Eds., Proc. Workshop on Object Oriented Groupware Platforms (Sep. 1997), pp. 44{49. Telematics Research Centre, Enschede, NL. M rch, A. 1997. Three Levels of End-User Tailoring: Customization, Integration, and Extension. MIT Press, Cambridge, MA. Stiemerling, O. and Cremers, A. B. 1998. Tailorable component architectures for cscwsystems. In Proc. 6th Euromicro Workshop on Parallel and Distributed Programming (Jan. 1998). IEEE Press.
