Ivan Tomek[HREF1], Rebecca Gong, Elhadi Shakshuki[HREF2], Rick Giles[HREF3], Jodrey School of Computer Science[HREF4], Acadia University[HREF5], Wolfville, Nova Scotia, Canada. ivan.tomek@acadiau.ca, 053276g@acadiau.ca, elhadi.shakshuki@acadiau.ca, rick.giles@acadiau.ca
As Internet reaches more and more people and as globalization forces geographical barriers to disappear, Internet support for collaboration is increasingly important. This is reflected in the large number of applications developed to support it. More and more, these applications have the form of integrated environments that integrate functionalities deemed essential for the purpose by their designers. Unfortunately, requirements of all teams and users are not the same even in the same application domain, work needs and available technologies change, and environments thus need evolve as well. As a consequence, hard-coded environments that can be modified only by their developers are not a good solution. Recently, environments programmable by end-users themselves have attracted attention and an important part of our work on a prototypical collaborative environment focuses on this issue. Our paper describes this work and presents experimental tools that we developed to help end-users of our environment to program it to accommodate their needs.
Human interaction during collaboration and in virtual communities is one of the most important uses of networking. Many applications that support it already exist and have been reported in meetings such as CSCW, ECSCW, CRIWG, Group, and COOP, and several products are commercially available and widely used. A variety of conceptual approaches has been employed but our attention in this paper is restricted to a particular kind of such applications known as Collaborative Virtual Environments (CVEs). These environments emulate essential aspects of the physical world on the basis of the conjecture that this familiar metaphor makes them easy to learn and use and provides unlimited power to evolve and adjust to user needs.
CVEs can be subdivided into those that use text-based Graphical User Interfaces (we will call them Text-based Virtual Environments or TVEs), and those that use computer graphics and other media to provide 3D simulations of physical spaces; these are usually referred to as Virtual Reality (VR). TVEs include environments such as Activity Spaces [1], CURE [2], Isabel [3], TeamRooms [4], Jazz [5], Habanero [6], Marratech [7], CommunityBar [8], CVW [9], and others. The VR group includes applications such as There [10], Viras [11] and others. Because both TVEs and VRs have their appropriate uses, it is meaningless to try to prove that one of the two approaches is better than the other. However, TVEs are widely preferred for tasks with largely verbal focus whereas VRs are naturally suited for applications that deal with spatial objects. Because of our interest in supporting text-based work, such as software development, our focus in this paper is on TVEs.
Whether the environment is a TVE or a VR, each application that supports work and interaction is faced with the challenge of evolution. Whereas the physical world is open to change, virtual environments are preprogrammed and essentially closed, unless they provide built-in end-user programmability. Unfortunately, few of the existing environments do. Because we consider end-user customizability and extendibility essential, our work on a prototypical environment called FCVW (Federated Collaborative Virtual Workspace) is based on an end-user programmable environment called CVW (see below). Unfortunately, although CVW is programmable, it does not provide any useful tools for end-user programming, which thus remains more of a theoretical rather than practical option. Because this feature is so essential, we explored how to provide FCVW with useful programming tools and how to support code versioning and ‘sandbox’ code development. A description of our tools and their design is the main subject of this paper.
The rest of this paper is organized as follows: To set the stage, Section 2 summarizes features that we consider essential in a CVE. Section 3 outlines the functionality of CVW and identifies its shortcomings. Section 4 describes CVW architecture and explains how FCVW extends it to achieve its goals. Section 5 describes MOOIDE, our end-user programming interface and illustrates its operation on selected usage scenaria. Section 6 presents MOOIDE architecture and illustrates principles of its operation, and Section 7 summarizes the results presented in this paper, describes our current work, and outlines our goals for the future.
In an earlier contribution [12], we summarized our view of the fundamental requirements on a collaborative environment as follows:
We think that CVEs based on the principle of a virtual implementation of the physical world based loosely on the MOO (Multiuser dialogues Object-Oriented) concept [13] best satisfy these criteria, and the number and variety of existing environments that take a similar approach indicate that we are not alone in this conviction. The following list details some aspects of this approach to explain and support our position:
After reviewing the general features that we consider
essential in a collaborative environment and showing that CVEs
provide an excellent fit, we now have a basis for understanding
the choices that we made. To set the stage, we will now outline
CVW, an environment that provides many of the features listed
above, and describe FCVW, our CVW extension.
CVW (Collaborative Virtual Workspace) is an open-source product of MITRE Inc. Its user interfaces (Figure 1) provide access to a persistent virtual space emulating a physical workplace. In this space people, documents, and applications reside in rooms on floors inside a building and can move around, carrying and sharing documents. Rooms can be used to meet and communicate, and serve as object, document, and tool repositories. Access is controlled by access rights and persistency means that universe state remains unchanged even when users log out.
Figure 1. CVW user interfaces.
Available document types include 'native' specifically designed for CVW, and 'foreign', imported from client machines and created by applications, such as word processors. Foreign documents are managed by a document server and manipulated on the client by a resident application. The document server provides a universal file space through which an imported document is available even if the original owner's file space is not connected; it also tracks document modification, and allows users to summarize changes upon saving.
Besides documents, rooms can contain any objects defined in CVW through the built in LambdaMOO programming language [15], which defines the universe and is interpreted at runtime by an interpreter residing on the server. A ‘find’ facility allows search over objects, rooms, and people. Users can also examine who is currently logged in, how long they have been active, and where they are. Topology and navigation of the virtual space are supported by maps.
CVW has most of the properties listed in the previous section, but MITRE's notes and our tests identified shortcomings including the following:
As a result of these findings, we decided to extend CVW in a program called FCVW (Federated CVW). Its most important new features include a generalized spatial metaphor (unlimited number of transparently connected buildings), increased scalability via federated servers, prototypes of mobile clients [17, 18], a framework for software agents [19], and an interactive LambdaMOO development environment and code management support with on-line help. The last items are the main subject of this paper and to provide a basis for understanding our approach we will now outline CVW and FCVW architectures.
CVW is a client-server application (Figure 2, left)). The server consists of a CVW Server and a Document Server. The CVW Server accepts LambdaMOO commands wrapped in the MCP protocol [20] and interprets them using its database containing a library of built-in and user-defined LambdaMOO objects, and an image of the virtual universe with information about spatial structures, users, documents, and other objects and tools. The Document Server stores documents imported from client machines and document information, such as document description, author ID, and timestamps, and serves them to clients.
Communication between clients and the CVW Server uses a persistent connection whereas communication with the Document Server uses a transient connection. Audio and video conferencing use separate connections.
Figure 2. CVW architecture (left), and its FCVW extension by middleware (right, shaded).
Because the server is old and undocumented, we decided to implement FCVW functionality by modifying the Java client and by adding middleware [21]. The middleware consists of specialized applications that use databases to store the necessary information. Some are shown in Figure 2 and briefly explained below.
After this overview we can now present MOOIDE, our tool for support of end-user programming of FCVW.
As we stressed at the beginning, we consider end-user extendibility an essential feature of collaborative environments. Unfortunately, most CVEs are not end-user programmable and provide only a fixed set of functionalities that can be modified and extended by the producer and nobody else. One of the main reasons why we selected CVW as the basis of our work was the fact that it is end-user programmable.
End-user programmability of CVW depends on the fact that the server reads incoming client commands, transforms them into LambdaMOO messages, and executes them using the stored code base and internal representation of the virtual universe. Because the database is modifiable at runtime, users with ‘programmer’ authorization can augment functionality at runtime by sending special commands that define new types of objects or functions, or edit or delete existing ones. This, in principle, is all that is needed to allow end users to control the environment and extend and modify it without shutting down its operation. Unfortunately, CVW lacks several key features to make this facility truly useful. They are the lack of a suitable Integrated Development Environment (IDE), the lack of support for code versioning, and no protection from programming errors in new code. We will now look at these shortcomings more closely.
Figure 3. CVW programming ‘interface’ in the main window.
In addition, we also had to deal with the federated nature of FCVW and the fact that code is developed, compiled, and stored on the server connected to the client but may need to be propagated to all servers. FCVW addresses all these concerns by a tool called MOOIDE (MOO Integrated Development Environment) and a code versioning system that takes advantage of federated operation. The rest of this section describes their features.
MOOIDE currently provides basic code development features. It allows browsing of code residing on the server, its editing, creation of new objects and verbs, and direct code execution. Because it is an exploratory tool, it does not include more advanced features such as debugging. To provide a better picture of MOOIDE, we will now show and explain several screenshots of its user interface.
Figure 4 shows the three-window user interface. The Launcher allows the user to use most programming operations through the main menu, as well as invoking online help, toggling between active windows, and so on. The Object Browser shows all objects in the database. When the user selects one, it allows viewing properties of the object and their values, and the object’s ‘verbs’ (messages). The Code Editor displays the definition of a selected verb and provides space for code definition and evaluation.
Figure 4. MOOIDE user interface.
To examine an existing object or to create a new one, Object Window in Figure 5 allows specification of the object’s properties including its place in the object hierarchy, object ID, location (all objects are located - LambdaMOO is a prototype-based language), the programmer who controls its access rights, and the comment.
Figure 5. Object properties browser.
Support for code versioning is based on a middleware component called Local Code Repository (LCR). When a user creates a new version of an object or a verb and the server compiles it, the user can add the code to its LCR database. Each server has its own independent LCR and when a user wants to examine or compare existing versions, he can do so using MOOIDE and its ‘Diff’ tool showing version differences. He can then select and make current any of the existing versions.
The last issue that FCVW must deal with is the federated nature of its servers and the fact that code is always compiled and initially stored on a single server. This is addressed by providing another middleware component – a Public Code Repository (PCR) that stores all shared code. The combination of multiple LCRs with one shared PCR makes it possible to develop code safely on a single server and broadcast it to other servers when it is finalized. This broadcast happens through the MOOIDEs on other servers and a notification. When they receive a ‘new code’ notification, administrators can accept the new code and recompile it on their machines. At present, this mechanism does not satisfactorily address all issues related to code propagation. As an example, it is possible that a server contains privately developed code that has not yet been broadcast and that conflicts with the new propagated version. The new code may thus not only have a different effect on this server but may not even compile on it. Issues such as these are essentially logistic and policy issues (defining constraints on sharing code) and have not yet been addressed in our work that focuses on basic functional issues and their technical solution.
After this overview of MOOIDE functionality, we will now explain principles of its implementation and illustrate them on selected events.
Figure 6 shows MOOIDE architecture. The System Module contains client-side definitions of system classes and classes representing universe components, such as LambdaMOO objects, properties, and verbs. The Communication Module uses technologies such as Java pipelines and channels to maintain effective communication with servers and middleware. The GUI Module defines the user interface, and the Code Management Module is responsible for version control and code sharing among multiple CVW servers.
Figure 6. MOOIDE architecture.
The Help Module uses MOOIDE interface to provide programming help. Help text is obtained from the CVW server where it is stored as LambdaMOO objects in the database, which makes the text user-modifiable, although not very easily at the moment – the MOOIDE object browser must be used to modify it as the help object’s property. MOOIDE help facility is a great improvement over help provided in CVW where it is only available through obscure commands and displayed in the main window along with chat and other unrelated information. By facilitating LambdaMOO programming it simplifies and encourages end-user programming.
To illustrate MOOIDE support for coding, we will now give two examples starting with creation of a new verb (Figure 7): To declare a verb on an object, the user selects the object and writes the code. MOOIDE then sends the code and several LambdaMOO commands - the same ones that the user of a CVW client would type and send manually, laboriously and risking mechanical errors. By making coding easier and ensuring correctness of the process, MOOIDE encourages end-user programming.
Figure 7. Adding a verb to an existing object and saving it in LCR.
To illustrate code sharing, Figure 8 shows how MOOIDE helps to propagate code from one server to another. The essence of the operation is that PCR notifies administrators of new code. If they wish to install it, they obtain the code from PCR and initiate its compilation on their server. If compilation succeeds, the code is added to the server’s code repository and to its LCR, and PCR is notified and records success. If compilation fails, there is no change of code on this server and in its LCR, but PCR records this result.
Figure 8. Propagating a verb to other servers.
In the introduction to this paper, we advocated the need for further research into collaborative environments. We also enumerated features that such environments should have and argued that Collaborative Virtual Environments (CVEs) are a paradigm that can satisfy such requirements. We stressed the importance of end-user programming in collaborative applications because the styles and needs of collaboration constantly evolve and supporting this evolution requires can only be ensured by providing users with tools to fine-tune the environment independently of the original developer. We then described the CVW open source environment based on CVE principles and listed some of its shortcomings, and gave an overview of FCVW (Federated CVW), an environment through which we addressed some of CVW shortcomings by modifying the CVW client, generalizing the architecture from one to multiple servers, and adding middleware. FCVW addresses a number of issues and we reported on some of our related work elsewhere; this paper is dedicated to one that we have completed recently and not reported yet – support for end-user programmability.
FCVW support for end-user programmability is mediated by a new tool called MOOIDE which greatly simplifies end-user programming through a code development browser, and makes programming safer and more productive. In doing this, it makes end-user customization and extension of a collaborative environment an attractive and practically possibility for user communities and organizations, and provides a test bed that allows researchers to experiment with new ideas without requiring recourse to original developers of the environment. MOOIDE also provides an interface to a middleware-based code versioning system that allows FCVW programmers to save multiple code versions, compare them, and switch from one to another. The fact that FCVW programming takes place on one of several federated servers also contributes to safer code development. Because programming takes place on one server only requires support for code propagation to other servers, and MOOIDE provides facility as well. After describing essential MOOIDE functionality, we described its internal operation on several representative use scenaria and discussed briefly its internal architecture.
Our work on FCVW has yielded insight into solutions of CVW shortcomings but has not yet addressed all features of an ideal collaborative environment. In fact, even the work described in this paper leaves some questions unanswered. As an example, we have not dealt with the question of reconciling possible clashes between private code bases on different servers and the code in the ‘public’ repository. Issues such as these remain to be addressed but their nature is that of logistic and policy rather than technical. By demonstrating feasibility of effective end-user programming, MOOIDE thus represents a significant advance but not a complete solution.
Our current work is taking several directions. On one hand, we are finishing some exploratory work on FCVW, such as a variety of mobile clients. At the same time, we made major progress towards re-implementing FCVW servers and clients that we undertook because further progress is difficult without complete understanding of the server and full control over it. Although the new server appears identical from the outside and can thus use the existing client, its internal structure has changed completely and allows us to perform further experiments. One of the most interesting possibilities from the point of view of end-user programmability is to allow programming in scripting languages better known than LambdaMOO, such as BeanShell [23], Jython [24] and JRuby [25], and thus open client-based end-user programming to a larger community.
FCVW is currently not a complete groupware product but a test
bed for experimenting with novel ideas that extend traditional
CVEs. Our approaches to important CSCW and CVE issues via FCVW
have been successful and viable. Future work will represent
further steps in this direction and should eventually result in
an application that work teams and the general public will be
able to use easily and effectively. Importantly, they will be
able to tailor the resulting environment to their specific
needs.
The work reported in this paper has been supported, in part, by an IBM Eclipse Innovation Grant and an NSERC (National Science and Engineering Research Council of Canada) grant. Some of the work reported as background was done by students in a CSCW course taught by the first author.
[1] Activity Spaces: Available online
[HREF6].
[2] CURE: Available online [HREF7].
[3] Isabel: Available online [HREF8].
[4] Roseman, M., Greenberg, S.: TeamRooms, Network places for
collaboration. CSCW'96, USA, 1996.
[5] Jazz: Available online
[HREF9].
[6] ChabertA., et al.: Java object-sharing in Habanero, CACM,
June 1998, vol. 41, no. 6.
[7] Quemada J., et al.: Isabel, A CSCW Application for the
Distribution of Events, COST 237 Workshop.
[8] McEwan G., Greenberg S.: Supporting social worlds with the
Community Bar, Group 2005, Sanibel Island.
[9] Brown B., Bell M.: CSCW at Play: 'There' as a Collaborative
Virtual Environment, CSCW, Chicago, 2004.
[10] Prasolova-Forland E., Divitini M.: Collaborative Virtual
Environments for Supporting Learning Communities: An Experience
of Use, Group, Sanibel, Florida, 2003.
[11] CVW Overview: Available online [HREF10].
[12] Tomek I., Shakshuki E., Peng A., Gong R., Koo A., Giles R.:
FCVW - A Federated Collaborative Virtual Workspace, IADIS
Conference on Computer Applications, San Sebastian, Spain,
2006.
[13] Holmevik J. N., Haynes C.: MOOniversity: A Student's Guide
to Online Learning Environments, Longman, 1999.
[14] Wikipedia: Available online [HREF11].
[15] LambdaMOO Programmer's Manual: Available online [HREF12].
[16] Ye Yiming, Churchill E., Agent Supported Cooperative Work,
Kluwer Academic Publishers, 2003.
[17] Madala K., Tomek I., Shakshuki E, Giles R.: A Thin Mobile
Client for a Groupware Application, COOP 2006, Provence, May
2006.
[18] Shakshuki E., Li H., Tomek I.: A Rich Client for CVW, IADIS
Conference on Computer Applications, San Sebastian, Spain,
2006.
[19] Shakshuki E., Tomek I., Prabhu O.: Client Software Agents in
FCVW, International Conference on Web and Mobile Information
Systems, Taipei, Taiwan, 2005.
[20] The MUD Client Protocol, Version 2.1: Available online
[HREF13].
[21] Peng Anita: Federated CVW – FCVW, MSc thesis, Acadia
University, 2005.
[22] enCore Consortium: Available online [HREF14].
[23] BeanShell: Available online [HREF15].
[24] Jython: Available online [HREF16].
[25] JRuby: Available online [HREF17].
Ivan Tomek, Rebecca Gong, Elhadi Shakshuki, Rick Giles, © 2006. The authors assign to Southern Cross University and other educational and non-profit institutions a non-exclusive licence to use this document for personal use and in courses of instruction provided that the article is used in full and this copyright statement is reproduced. The authors also grant a non-exclusive licence to Southern Cross University to publish this document in full on the World Wide Web and on CD-ROM and in printed form with the conference papers and for the document to be published on mirrors on the World Wide Web.