ICE: A Highly Tailorable System for Building Collaboration Spaces on the WWW

Transcription

1 ICE: A Highly Tailorable System for Building Collaboration Spaces on the WWW Babak Amin Farshchian & Monica Divitini IDI, Norwegian University of Science and Technology Trondheim, Norway Abstract This paper reports on ICE (Internet Collaboration Environment), a system for end-user development of collaborative environments on the WWW. The WWW provides an infrastructure that makes it possible for people to easily share various kinds of information. We believe that an additional sensible extension can be provided by actively supporting people in working together. ICE has been built with this goal in mind. It offers to its users the possibility to build "spaces" for collaboration using a set of basic building blocks. 1. Introduction The nature of cooperative activities and the settings in which they take place are various. Internet has made possible the interaction among people who are highly distributed, providing them with possibilities for cooperation that were unforeseeable until only ten years ago. It has become, for example, more and more common for people who belong to different organizations to work together in order to take advantage of specific expertise. At the same time, the facility of getting "connected" encourages people to work together, combining different experiences and knowledge. This arises a new set of challenges for designer of systems supporting cooperation. In particular, it makes it more evident that, as pointed out in (Schmidt and Bannon 1992), cooperative work is highly distributed, not only in term of space, but also in term of competencies and background of the people taking part in it. In the scenarios that we have focused on in our work, the challenge has been to develop a system to help people in establishing a context for their working together. People often share some needs when they cooperate, independently from the specific situation they are in. But at the same time, the varieties of domains where cooperation can take place do not allow us to think about a single system, neither a system allowing only customization at some interface level. In particular, ICE has been developed in order to address some of the main needs of distributed communities working together. It supports communication, information sharing, and knowledge creation. ICE is developed with the view that these activities can be performed across group boundaries, i.e. involving partners who have different background knowledge, goals, and interests. Internet provides a flexible and open infrastructure for connecting people, but it does not support explicitly a group of people working together. In particular, the WWW offers a powerful tool for its users to publish their information, but it too suffers from some strong limitations when it comes to supporting cooperation. More specifically, WWW does not support explicit communication and collaborative knowledge creation. In addition, web documents generally lack context. The latter limitation is particularly important for two reasons: 1) information generated by a user needs some kind of interpretation in order to be understood by other users (Bannon and Schmidt 91), 2) a collaborative task needs only a

2 relevant part of the existing information space, which must be classified and identified in some way (Clement and Wagner 95). ICE has been developed to extend the functionality of the WWW in order to support collaborative work and overcome some of the above mentioned limitations. ICE provides its users with a set of building blocks for constructing various collaboration spaces. Each collaboration space is perceived by its users as an interactive WWW application. The system is highly tailorable because it gives the end-users the possibility of building these applications without any knowledge of WWW programming, requiring not much more that the ability to access the WWW (mainly, filling in forms). As a starting point, the user is assigned an empty Web page that can be used to gradually build (and customize), in a cooperative way, a collaboration space. This space can be used by the group to share information, and it provides basic support for collaborative work, for example by increasing the awareness of the group about who is using (and possibly changing) the information. 2. Using ICE: An example When a community decides to create one or more collaboration spaces, they can start installing ICE on an already running WWW server. The server automatically gets all the functionality of ICE. All the members of the community have access, through a Web page, to an initial space that contains information like online help, users guides, and information about the current status of the information space (which is initially empty). Users can be registered in the server in any moment, reflecting the dynamic nature of the community. (Some of the) members can be assigned the rights to create spaces and subscribe others to them. Figure 1 shows a screen image of the user interface of a collaboration space. This figure illustrates many of the concepts we have implemented, many of which will be described later. Here the focus is on providing an intuitive description of how ICE can be tailored for building a specific collaboration space. A user starts by creating a collaboration space (if she has access rights to do so), or is assigned a space by the administrator. A newly created space is a blank Web page with a simple user interface including a frame and some default buttons for generic functions, e.g., login, home, search. The user can then start sharing this space by giving access to other users if she wishes to cooperate. All the authorized users can then start inserting objects (building blocks) into the space, possibly choosing from objects that have already been created and inserted in the ICE database. Two default mailing list are created for each workspace. These mailing lists are also available via normal SMTP clients. One of the mailing lists is used by the system for sending automatic notifications of the changes taking place in the collaboration space. The other e- mail list is used by the members of the specific collaboration space for discussions. The e- mail lists are archived with the collaboration space, and can be visualized in the user interface in different ways. The users of the space can choose to subscribe to these lists, or just access them via the collaboration space's user interface.

3 Figure 1: a collaboration space built using ICE In the example shown in Figure 1, two course instructors have built a collaboration space for organizing a course for the Aquarius project personnel. This space has been tailored by the two instructors using various building blocks for managing shared information. The information can originate from different databases, the only restriction is that it is accessible to the WWW protocols. The instructors can use this space to collaboratively construct the course. These information objects may not themselves be accessible to other users, but a brief summary can be included in the user interface if desired, maybe to give an account of the progress. The course itself, i.e. the space for the course participants when the course is defined, is created as another tailored collaboration space ( Course in CSCW for project people ), eventually to be used by the participants of the course. The instructors can insert course material, exercises, etc. in this space whenever they want. As mentioned above, two

4 mailing lists are automatically associated to the course space: one makes the participants aware of changes in the information related to the course, while the other constitutes a forum for discussion. The owners of the parent workspace are entitled to delegate access to all the material in their space (and sub-spaces). So when the course is fully defined and a final version of the object Course in CSCW for project people is ready, they can give access to the participants, that are automatically informed by Overall description of the system ICE has been conceived as a self-organizing WWW platform where the users are aware of each other's existence, and where the information put in common can be accessed online by all the users, and can be modified in the WWW environment. The platform provides active support for the collaboration among the users. Users can define new collaboration spaces starting from basic entities and they can customize their user interface to meet their information needs and their mental and technical accessibility. Before describing the basic building blocks that are made available to the user/designer, it is important to introduce two underlying concepts: type handlers and objects. An object is a piece of information stored in the database, while a type handler is a program for manipulating objects. Type handlers are used, for example, to visualize objects in different ways and to connect them together in order to tailor collaboration spaces (Olsrød and Isaksen 1996). Each object, with the associated type handler, is a building block made available to the users of ICE. Mailing list is an example of a building block, where the contents of the mailing list (the messages sent to the mailing list) constitutes the object, and the various methods of viewing the mailing list are part of the type handler. Hereafter, in line with object oriented methodologies, we will refer to the combination of an object and its type handler simply as object. The building blocks made available in ICE can be classified into three categories: information objects, collaboration objects, and user interface objects. 3.1 Information objects All information is entered into the system in form of information objects. These objects contain an arbitrary amount of meta-information which is used for different purposes. This meta-information includes bibliographical data, keywords, different abstracts of the content, executive summary, access rights, visualization information, etc. The amount and content of meta-information is decided by the users of the system, and must reflect the actual usage context of that information. Information objects are important in providing a semantic packaging of information before they are put on the WWW, so that they can be classified and located as easily as possible. These objects also support interaction with the information in order to create knowledge. After being entered into the database, an information object can be accessed by authorized users of the system for using, editing, commenting, and discussing. In this way the social construction of knowledge within the community is supported. Comments and changes to an information object can be absolute (affecting the object directly), or be related to the object in a specific context, i.e., collaboration space.

5 The meta-information is also used to visualize the object in different ways. Each type handler provides a set of different views that can be used in different occasions, according to various factors. These factors can be user preferences, user access rights, group preferences (for objects being used in a group work context), etc. Viewing an information object can also be related to other information objects. As an example of the latter, if the result of a search contains too many objects, it would be a good idea to visualize the result using a wellarranged overall view. By providing information objects, we try to encourage the users to think about the information they are entering into the system. Users are encouraged to think about the fact that the data is going to be used by others, and try to package the information in a proper way (Bannon and Bødker 1997). Traditionally, the information on the WWW is organized into HTML documents with little or no semantic information for categorizing and making effective use of the information. Information objects can also be composite (or derived). Imagine having an object that shows the overall tendencies in the production of a special kind of fish. The result is definitely dependent on raw data about individual fish farmer registered in the database. 3.2 Collaboration objects Collaboration objects have been developed in order to provide active support for collaboration among the users of the system. The basic objects of this type are user, group, and collaboration space. The main idea is to allow the users of the information system be aware of other users they are cooperating with, and to allow the information system support groups of users working with different tasks. The basic object in this group is user. Each user of the system is registered with information that includes biographical information, user preferences, user model, group membership, and other temporal information about the user, such as where the user is now, when she was logged in last time, etc. The object group is used to connect several users in the context of a task or a practice. The information registered for a group includes a list of group members, group model, group preferences, etc. Each user can be a member of several groups, and a group can also be a member of another group. User and group administration is done by creating local administrators for different areas of the information system. These administrators are then entitled to create new users and give various access rights to these users. The main object for supporting group work is collaboration space. An object of this type constructs an area in the information system that a group of users can use for their collaboration and practices. Normally a collaboration space object consists of several other collaboration objects. Some of these objects are concerned with the awareness aspects of the workspace, e.g. the constant status of the group members, the latest activities in the workspace, etc. (Bentley et al (forthcoming)). A collaboration space object also has contents, which are information objects from the database. The layout and the user interface of the collaboration space are constructed using user interface objects (see later).

6 Collaboration space are highly customizable. Each user can have her own preferences for each collaboration space she has access to. These customizations are concerned with the contents of the space, with the viewing of each information object, with the user interface objects used in the collaboration space, etc. The owner of a collaboration space decides a default for the space which includes all the customizable features. Each user can then override the default by defining her own. 3.3 User interface objects User interface objects are used by the end-users to organize and customize the layout and look-and-feel of their collaboration spaces. As an example consider the result of a search in the global database. This result can be represented using several different user interface objects. One object would visualize the result in consecutive lines, while another object can visualize the result in an HTML table format. User interface objects have two other important roles that are more concerned with the internal construction of the system and are not visible to the end-users. Their full description is beyond the scope of this paper, and they are only outlined here. First, user interface objects play an essential role in providing visualization services to all the other objects in the system. For example, they control the actual visualization of the information objects. Recalling the mailing list example above, the mailing list type handler uses various user interface objects to represent its contents in different ways (listed by author, date, subject, etc.). Second, some of the user interface objects are used to provide support for dialogue with the user. One main problem with WWW application development is that the WWW is stateless. This means that the server cannot know what the clients are doing. The problem can be solved to some degree using so-called direct manipulation user interfaces (Shneiderman 1983). Direct manipulation user interfaces eliminate the need for modes in the user interface, but there is still need for holding account of the state of the user interface, e.g. the variables that are manipulated by the user. Some of the user interface objects are used for this purpose. 4. In lieu of conclusions: Towards a more general support for cooperation This paper presented a system for tailoring collaborative WWW applications in form of collaboration spaces. The system was developed trying to provide tailorability both at the functional and interface level. In order to reach a high degree of flexibility the users are offered the possibility to build their applications using different building blocks. This opens for the construction of applications with different behavior. In addition, the system s building blocks allow the users to choose among different alternatives of anticipated behavior (Henderson and Kyng 1991), providing a basic level of tailorability for the building blocks themselves. It is important here to point out that ICE has been built in strict collaboration with a community of users that needed to build an application supporting their distributed collaboration, easing the exchange of information and the process of knowledge creation inside heterogeneous communities. The experience gained during the collaborative design of

7 ICE itself and of the specific applications realized for an by this community (using ICE) seems to show that proceeding along the line sketched above provides a satisfactory combination of tailorability. The extent to which the approach can be successfully exploited in other contexts is the matter for a planned continuation of the study. In any case, it is important to consider that users are different, different are the tasks they perform, and different are the settings where they perform their tasks. Experience, skills, and interests of a user are not something that can be defined once and for ever. These are strictly related to the collaborative effort the users are involved in, and are continuously evolving. The system described above is still under development. Up to now users can create a new space for collaboration, share it with others, insert new objects in it, and decide how to visualize the objects. The owner defines how the different object will be visualized for all the users that have access to the workspace. It is at the moment under development the possibility for the individual users to customize their user-interface. Customization will be possible both at the system level and the single workspace level. As mentioned at the beginning at this chapter, the building blocks of the system can, to a certain extent, be tailored choosing among a predefined set of alternatives, but they cannot be completely re-programmed and new types of objects cannot be inserted into the system without a real programming skill. Research issues that are going to be analyzed in the course of on-going projects at NTNU are the possibility to extend the type of support that can be provided in ICE, for example supporting coordinated activities (Simone and Divitini 1997), as well as to provide a higher degree of adaptivity of the system, through user and group modeling (Divitini and Simone 1994). References Bannon, L. and Bødker, S.: 1997, Constructing Common Information Spaces, in Hughes et al. (1997), pp Bannon, L. J. and Schmidt, K.: 1991, CSCW: Four Characters in Search of a Context, in J. M. Bowers and S. D. Benford (eds), Studies in Com- puter Supported Cooperative Work - Theory, Practice and Design, North- Holland, pp Bentley, R., Horstmann, T. and Trevor, J.: 1997 (forthcoming), The World Wide Web as enabling technology for CSCW: The case of BSCW, Computer Supported Cooperative Work: The Journal of Collaborative Computing 7(2/3), NN. URL: journal.html Clement, A. and Wagner, I.: 1995, Fragmented Exchange: Disarticulation and the Need for Regionalized Communication Spaces, in H. Marmolin, Y. Sundblad and K. Schmidt (eds), Proceedings of the Fourth European Conference on Computer-Supported Cooperative Work, ECSCW'95, Stockholm, Sweden, Kluwer Academic Publisher, pp Divitini, M. and Simone, C.: 1994, Adaptivity in a System Supporting Cooperation, in Proceedings of the Fourth International Conference on User Modeling, pp Henderson, A. and Kyng, M.: 1991, There's No Place Like Home: Continuing Design in Use; in: Greenbaum, J.; Kyng, M.: Design at Work - Cooperative Design of Computer Artifacts, Hillsdale, pp Hughes, J. A., Prinz, W., Rodden, T. and Shmidt, K. (eds): 1997, Proceedings of the Fifth European Conference on Computer Supported Cooperative Work, ECSCW'97, Lancaster, U.K., Kluwer Academic Publishers. Olsrød, S. P. and Isaksen, T.: 1996, ICE - Aquarius Database, Aquarius project report, NTNU, Norwegian University of Science and Technology, Department of Computer and Information Science, N-7034, Trondheim, Norway.

8 Schmidt, K. and Bannon, L. J.: 1992, Taking CSCW Seriously - Supporting Articulation Work, Computer Supported Cooperative Work - An International Journal 1(1/2), Simone, C. and M. Divitini:1997, Ariadne: Supporting Coordination through a Flexible Use of the Knowledge on Work Process, J.UCS ( special issue on "Information Technology and Knowledge Management) 3(8), Shneiderman, B.: 1983, Direct Manipulation: A Step Beyond Programming Languages, IEEE Computer 16(8),