MUDs (Multi-User Domains) and MOOs (MUDs Object-Oriented) offer an interesting combination of synchronous and asynchronous communication mechanisms. Users in a MOO can chat with one another, but the database that underlies the MOO is persistent: users can create, modify and manipulate objects, changing the state of the MOO for subsequent users. For example, users can leave messages posted on bulletin board objects. MOOs are fundamentally spatial–the content is organized into "rooms," and users navigate the information structure with directional commands (for example, "go north"). This evokes an experience of immersion and co-presence with other participants (Benford et al. 1996). Although these environments have been used chiefly for fantasy-oriented entertainment and informal social activity (Curtis, 1992), they have also been used for professional meetings (Glusman & Prilusky, 1996) and as learning environments (Haynes & Holmevik, 1998), and as navigational tools (Diebeger, 1996; Kies et al. 1996).

MOOsburg is a community-oriented MOO. It models the geography of the town of Blacksburg, Virginia, and its intended users are the residents of the town and its surrounding area. Thus, MOOsburg is not merely spatial; it is place-based. It is not fantasy or recreation oriented, it is community-oriented. The project goal is to enhance community development by supporting better access to local information and to new kinds of collaborative activities. Thus, MOOsburg supports construction and end-user programming activities that enrich the community’s options for cooperation, commitment, and concerted action (Kies et al. 1996).

MOOsburg developed in the context of the Blacksburg Electronic Village (BEV; http://www.bev.net), an advanced community network in southwest Virginia (Carroll & Rosson, 1996). More than 90 percent of the population, over 30,000 people, have network access in Blacksburg. Public-access kiosks are available at the public library and in some business establishments. All 20 county public schools have high-speed network access, and a variety of network-based projects are underway (Koenemann et al., 1999). Over 150 community groups and more than 400 local businesses maintain Web sites (>75%). There are many unique community-oriented initiatives, such as a senior citizen’s online nostalgia archive . The Town of Blacksburg makes extensive use of the BEV, providing on-line forms for surveys, house check requests, and e-mail to town officials, as well as on-line town chats and electronic dissemination of schedules and other documents.

Our vision of MOOsburg is that it can help to integrate the BEV, to make it a more a coherent environment or system. Many people visiting the BEV wonder "where" it is, since it is the union of otherwise unrelated community-oriented software and information. We also hoped to make the BEV more interactive. The core of the BEV is a distributed hypertext of community information: Lots of reading material. We wanted to emphasize collective local action in support of shared goals as a central aspect of the BEV.

The goal of the MOOsburg architecture design has been to preserve the most useful aspects of traditional MOOs while extending both the client-side user interface and server-side components to take advantage of emerging internet technologies. As with traditional text-based MOOs, the MOOsburg software architecture provides access to a central database of user-created, manipulable objects. Some of these objects represent places such as rooms and buildings, while others represent characters and items that populate the MOO spaces. Also as in traditional MOOs, end-user authoring of objects in the database is a basic feature of the environment.

MOOsburg preserves other fundamental concepts found in traditional MOOs. In particular, support for synchronous text-based communication between users visiting the same place is provided. There is also a seamless integration of synchronous and asynchronous collaborative activities: a user can see the effects of other users’ actions in real time, and can also see the preserved effects of past actions.

However, the MOOsburg architecture reflects two significant departures from traditional MOOs. The first is the use of Java object replication, instead of streams of text, for communication between client and server. The second is support for well-defined hierarchies of places within the MOOsburg environment.

Traditional MOOs rely exclusively on text for user interaction. MOO client software has been written to hide arcane textual commands and provide more graphical user interfaces for displaying MOO output, and interacting with the MOO (http://www.du.org/java/CupOmud/). However, the underlying commitment to text limits the flexibility and sophistication of these enhancements. Perhaps the most significant issue with the text-based interaction of traditional MOOs is the use of a single "stream" for all input and output. Users move from place to place, communicate with each other, and manipulate objects in the MOO by entering commands at the appropriate place. Similarly, output describing the content and inhabitants of the current location, incoming communication from other users, and system-generated messages describing other users’ actions all appear in the same (often quickly-scrolling) stream of text. Expert MOO users adapt to this style of interaction, but novice users can quickly become overwhelmed.

MOOsburg employs a very different approach, relying on Java object replication to provide each user with a lightweight, replicated, Java object for each interesting entity (place, person, or thing) encountered in the environment. A generic object replication package called CORK (Content Object Replication Kit; Isenhour et al., 1999) ensures that, where permissions allow, changes made to any replicated object by any user are reflected in all other object replicas. A master replica of each object also exists on the MOOsburg server, and is saved periodically to non-volatile storage. Where appropriate, distinct user interface components can be provided for interacting directly with each of these replicated objects.

With this flexible object replication scheme, MOOsburg can support a variety of graphical navigation tools. The architecture makes a clean distinction between the semantics of where a user is, what objects are there, and so on, and how the place and its contents are presented and manipulated. Thus, the client-side software retrieves lightweight objects describing the user’s current location as well as nearby locations in the environment. Navigation widgets then provide a user interface for viewing this information and allow the user to move from place to place. Object replication ensures that changes made by any user are reflected in all nearby users’ views and navigation tools.

In our current prototype, the default navigation widget is a simple, 2-dimensional map. When the user enters the system the map shows a view of all of Blacksburg. Buildings and other locations for which content has been built are marked on the map. Users can move to a place by clicking on the map. They can also use the map to specify the locations of new places that they wish to construct. Advanced users can implement additional mechanisms for visualizing and navigating through the spatial database; these enhancements can be added to the MOOsburg client and made available to all users. Support for this kind of user-defined extension is described in more detail below.

MOOsburg’s use of object replication also enables enhanced awareness of people and objects at each location. A user in a traditional MOO can request a textual description of the other inhabitants of any place that they enter, and they received automatic textual updates as people or objects enter or exit. In MOOsburg, lists of co-located people and objects are always displayed and automatically updated. Further, the information about inhabitants and activity at a given location can be used as a basis for even more useful visualization and navigation widgets. For example, a map widget could examine the contents of each location being rendered and then provide visualizations of the number of people or objects present, or of movement into and out of each location.

A second novel feature of MOOsburg is its spatial database. Traditional MOOs support construction of a directed graph of rooms, with very few restrictions. Containment structures, such as rooms within a building, can be defined by convention, but are not enforced by the MOO software. A room’s position in the space is determined solely by the rooms that it is adjacent to (see Haynes & Holmevik, 1998, for more information on room construction in a traditional MOO.) Except again by convention, there is no concept of absolute location, and only a crude concept of distance. This ambiguity allows structures to be created within a MOO that could not exist in the physical world. While potentially interesting, the ability to create "impossible" structures generally limits the types of graphical navigation tools that can be added to a traditional MOO to those that translate mouse actions into textual MOO commands. For example, an earlier version of MOOsburg, based on a traditional MOO architecture, included a compass widget which used JavaScript to generate and send commands like "go north". However, since MOO structures often cannot be mapped onto a Cartesian coordinate system, it is typically not possible to reliably render a map of a space in a traditional MOO.

MOOsburg solves this issue by supporting more structured hierarchies of locations and by allowing assignment of Cartesian coordinates to each location. In our model, a place that contains other places is a space; any location that a user can navigate to is a landmark. A user either navigates "to" a landmark (i.e., position herself next to it), or–if the landmark is itself a space with a substructure–the user can go "into" the landmark. Streets and buildings are typical spaces; street corners and rooms are typical landmarks within these spaces. A room in a building that contains its own subspace (e.g., a gym with a spatial array of science fair exhibits) acts as both a landmark within the building, and a space containing the science exhibits. This model ensures that a map can be rendered for each space, showing the space’s substructure and the location of landmarks within it. The maps provide a way to visualize the space and a means for navigating from landmark to landmark and into or out of subspaces.

As with rooms in a traditional MOO, landmarks in MOOsburg can be occupied by characters and objects. Where permissions allow, characters can create, destroy, and move objects from landmark to landmark. Characters and objects have actions (or "verbs" in traditional MOO terminology) that can be invoked on them. In MOOsburg’s graphical interface, these actions are accessed by selecting items from pop-up menus rather than by entering textual commands.

A fundamental component of MOOs is support for end-user authoring. Like a traditional MOO, MOOsburg supports several levels of authoring. The simplest form is manipulation of existing objects. A landmark can hold shared whiteboards, shared notebooks, or other editable objects that users can modify. Since these objects typically use data replicated with CORK, they support both synchronous and asynchronous collaboration: Changes made to a notebook or whiteboard are visible in real time to others currently viewing or editing the object, and are preserved for users who access the object at a later time.

Users can also create new spaces, landmarks, and instances of existing object types. For example, a user could add a library room to a building and put notebook objects in it. By default, newly-created landmarks contain an object that supports text chat within the room and a toolbox object that allows the instantiation of other objects for use in the room. Users can also populate landmarks with objects brought from other rooms.

Finally, more advanced users can implement new kinds of objects. For example, a book object might be created to present online reference materials. The mechanism for building and deploying user-defined objects resembles the mechanism used to publish and access Java applets: Developers write an implementation of a new kind of MOO object and make it available on the Web. When other MOO users create or use an instance of this object in the MOO, the code that defines the object’s behavior is automatically downloaded as needed. This mechanism supports a wide range of extensions to MOOsburg such as multi-player games, ballot boxes, and enhanced navigation tools.

The current user interface to MOOsburg was motivated by two major concerns. First, we wanted a GUI interface that would be familiar and engaging to a community audience familiar with modern windowing environments, and in particular, with Web browsers as a user interface for navigating and interacting with large information spaces. Second, we wanted to address specific problems that had appeared in our early prototypes of a Web-based MOO.

The earlier prototypes reflected a sometimes awkward combination of a traditional MOO and a graphical user interface to MOO locations, objects, and characters. For example, the "chat" was simply a standard MOO teletype log. This means that everything that happened in terms of location and object interaction was reflected in that text window, and then repeated (sometimes) in the graphical user interface. The result was both redundancy and inconsistency in whether and how information was available in the graphical view of the MOO. There were multiple ways to navigate, either through conventional text commands (e.g., "go north"), by pressing a Java-script widget labeled north, or by following links out of the Web page representing the current location. It was also very easy to "leave" the MOO environment without even realizing it, because a location in the MOO could have links to arbitrary Web pages. If a user did this, they were forced to use standard Web browsing interaction (e.g., the "Back" button) to return to the MOO, then pick up again with the MOO-specific commands.

The prime goal of the MOOsburg user interface is to ensure users’ awareness of location, other participants, and opportunities for action. A secondary goal is to promote consistency throughout the environment, so that users feel they are moving around and interacting within a coherent space. These two goals motivated the standard view exemplified in figure 1.

This view has five basic components: a visual representation of the user’s current location (upper right); a scrollable map showing where the user is currently located along with other navigation options (lower right); a list of other participants currently at the same location (upper left); a list of objects with which the user can interact in this location (middle left); and a chat window for communicating with other participants at this location (lower left).

In addition to a consistent overall layout, the visual representation of each landmark includes a visual "signature" that identifies it as part of the MOOsburg database (Mullet & Sano, 1995): the title of the landmark at the top, followed by a bold horizontal line and the room description. The material displayed in this frame is generated and rendered with HTML, so anything that a landmark designer can create as part of a standard Web page can be included in this depiction.

The map available at each location in the MOO provides a single and direct mechanism for navigation. Users no longer have to know reserved words or room names. They also no longer need to navigate from room to room to get to a destination. The map always available in the bottom right of the interface informs the user of his or her current location, and displays other locations to which he or she can navigate.

Landmarks are indicated as spots on the map. A filled spot means that the user can only go "to" the spot; an open circle means that the user can also go "into" that location (i.e., that there is a substructure and a new map defined for it). To support browsing and feedthrough, we display a location’s name at the bottom of the map when the user positions the mouse over a spot. A single click on a spot will bring the user to that location; the map is updated with an arrow showing "You are here", and the standard MOOsburg depiction of that landmark is shown in the location description frame (e.g., typically containing information that one would find on a "Welcome page" of a Web site). If the landmark also contains a subspace (i.e., is shown as an open circle), a double click will take the user directly into the subspace, and the map will be replaced with the new map, with the user positioned at a pre-defined entry point (the default landmark) in the new space.

The People list indicates who else is co-positioned at the current landmark, encouraging informal interaction among visitors. Group chat takes place in the frame at the bottom left of the screen and is similar to standard Internet-based chat tools. Text is typed into the "Message to send" input field and sent explicitly with the "Send" button, or implicitly by pressing "Enter" on the keyboard. This eliminates the need for the "Say" command used in conventional MOOs, minimizing the typing needed for informal conversation.

By default, messages sent at a landmark will be seen by anyone else also located there. However, one-to-one chat can be initiated by selecting a user’s name from the People list and double clicking. Again, this is a simplification to standard MOO functionality, wherein private chatting was accomplished through the special "Whisper" command. This point-and-click technique for initiating one-to-one chat increases the feeling of a direct link among users, as well as simplifying the request itself.

As with the chat tool, interactive objects "stored" at a landmark are accessed through a point-and-click interface. The user can open objects in the Object list by choosing an appropriate verb from the object's popup menu. An important design decision was to open any such object (whether a whiteboard, a slide projector, a notebook, etc.) in a separate window. This means that users can open and interact with multiple objects at the same time. Although this increases the complexity of window management by the user, it supports multi-threaded activities, for example simultaneous interaction with a whiteboard (for informal drawing) and a notebook (for editing and archiving text). The decision of whether to automatically close an object when a user leaves the landmark is left to the designer of the object. Again, here we have opted for flexibility, allowing for scenarios in which users want to compare and contrast objects associated with different locations.

An important specific consequence of opening objects in separate windows is that there is now a clear distinction between what is "in MOOsburg" versus what is "on the Web". Any URLs stored at a MOOsburg location are opened in a secondary window, a simple Web browser. Recall that these objects are also automatically shared, so Web navigation can be shared, whiteboards used for synchronous communication, and so on.

Objects in MOOsburg can be "picked up" and "moved" from one landmark to another, much as in traditional MOOs. The only significant difference is that these interactions are supported by our general point-and-click interface.

A signature feature of traditional MOOs is compass-based navigation: go north. This "maze metaphor" for space is appropriate when the overarching task for users is exploration, but it is not consistent with more goal-directed tasks, such as "going to the Middle School for a virtual Parent-Teacher meeting".

The maps available in MOOsburg correspond to the hierarchy of locations. At the top level is a street map of the town of Blacksburg. The map indicates landmarks at this highest level–for example buildings or parks–that the user can visit. Subsequent levels are defined by the subspaces created for landmarks. For example if a building is given a substructure, it is presented as a floorplan; if the building has multiple floors, stair widgets provide access to different floors.

We are currently experimenting with fish-eye maps that will facilitate easy viewing and navigation of a large geographic space (Furnas, 1986). Fisheye views employ a focus+context technique that allows users to see the details needed for local interactions and yet provide a view of the overall structure. For MOOsburg, the goal is to display a user’s current location as the focus, with the rest of the town as context. One way to do this is to enlarge the focus location in the center of the map and render the other locations smaller and smaller as you move further away from the focus. In this way, users have a sense of what is nearby them as well as a notion of where they are located in town.

We have experimented with different mathematical mappings that provide this focus+context map view. Using an arc tan function has produced the smoothest and most understandable view, although we found that a zoom function is a desirable feature. We are also exploring a zoomable flat map. In this technique, all locations have the same size and the context is obtained by zooming out.

We are coordinating the development of the MOOsburg infrastructure with development of specific applications and activities within MOOsburg. In some cases, these example activities are merely imported; for example, a Web-forum for community history developed with local senior citizens is an object in the Senior’s Center (Carroll et al., 1999). More ambitiously, we are trying to integrate existing community systems in the MOO, and to develop new applications and activities that exploit the MOO infrastructure and help us to develop appropriate authoring and integration support.

The flagship application for MOOsburg development has been a virtual science fair, conceived as an integration of an existing school-based collaboration system – the Virtual School (Koenemann et al., 1999) – with MOOsburg. Science fairs typically exhibit projects that students have developed outside of class, over a period of weeks or months. The exhibition usually occurs at the school during a single evening toward the end of the school year. We believe that this traditional activity could be enhanced if the projects could involve community members more actively, and if the exhibition of the projects could be carried out over a longer period of time, and more conveniently accessed by community members. In our virtual science fair concept, students use the Virtual School to collaborate with one another and with community members over significant periods of time to carry out projects, which they exhibit to the community using MOOsburg. The exhibit can itself become an extended collaborative activity, since the virtual science fair is not constrained to be a one-time event.

A crucial enabler for the ongoing development of MOOsburg is the support of authoring by end-users. Community groups need to be able to create and manage their own meeting places and projects. This both empowers them with respect to utilizing technology to achieve their own goals, and makes MOOsburg more feasible: It is difficult to imagine how any community could fund central management for a community MOO. But this in turn requires us to develop support for authoring activities and for integrating independent development efforts.

MOOsburg currently supports only a modicum of end-user programming (e.g., a form tool for creating rooms). We are building on these early experiments to provide similar tools for creating other objects (e.g., a slide show, a bulletin board in a classroom, a comment on a student project). Some of this is taking place through group projects under development for a graduate course in computer-supported cooperative work at Virginia Tech. Six MOOsburg activities are being prototyped: an event publicity system, a software engineering room, a Virginia Tech Off-Campus Housing office and fair, advertisement and connectivity for ad-hoc sports activities, and a children’s collaborative story writing at the public library.

These student projects represent a small sample of the diverse software applications that MOOsburg can support. The event publicity system and software engineering room are developing general, reusable objects that can be made available to all MOOsburg users. The Virginia Tech Off-Campus Housing office and fair, along with the children’s collaborative story writing at the Blacksburg Public Library, provide virtual counterparts to current real-life activities that take place in the Blacksburg community. Allowing community members to plan local ad-hoc sports activities or hold a real-time auction online are new types of virtual support for collaborative activities in Blacksburg.

We are very interested in the enhancements to the MOOsburg infrastructure that will enable MOO users with diverse needs, like the student groups, to contribute to the system. In this sense, the student projects are an important source of requirements for end-user authoring support. Some of the key areas we are now exploring include distributed software development and installation; simplified programming of collaboration features; security requirements; and increased options for multi-user awareness.

Our strategy for the near future is to coordinate further development of infrastructure, user interface, and new applications for MOOsburg. We want to develop general tools and techniques that can be useful in a variety of specific contexts. For example, many users of MOOsburg will want to conduct moderated real-time discussions with whiteboard and forum tools for organizing interactions and preserving results. We need especially to support the development and integration of individual MOO-sites by end-users.

Our principal focus in user interface development is on the interactive map. We need to automate the acquisition of map data in order to be able to map larger regions (for example, all of Montgomery County, as opposed to merely downtown Blacksburg). We need to improve map navigation; we plan to experiment with displaying the names of distant landmarks on the horizons of the currently-focal mapped region in order to mitigate the downsides of spatial distortion near the margins.

Our application development work is focussed chiefly on the goal of conducting a virtual science fair activity in spring of 2000. We are also planning further activities with other community groups, including the League of Women Voters, a local natural history museum, and the Town of Blacksburg. For example, we want to help coordinate water quality monitoring stations along the New River, and support public discussions with local political candidates. We also need to develop techniques and perhaps further tools support for assessing the usability, usefulness, and civic impact of MOOsburg software and activities.

Community computing seeks to enhance participation in community life at a time in history when traditional communities appear to be eroding (Putnam, 1996). It investigates and facilitates the development of local social capital –the trust, social interactions, and norms of mutual reciprocity throughout a community . For example, we have hypothesized that educational activities can be more meaningful for children, more valued by their parents, and thereby more effective if those activities are grounded in local people, issues, and events (Carroll & Rosson, 1999).

The MOOsburg project is attempting to bring new technological approaches and applications to community computing. This is not to impugn the pervasive and exciting vision of what McLuhan (1964) anticipated as the "global village." We all participate in a global village of international collaboration, electronic commerce, telework, and so forth, mediated by the Internet. But we live in physical communities, next door to someone, down the street from someone else. We believe that a critical complementary element, one often missing in contemporary visions of information technology and society, is an appreciation of the importance of local commitment, initiative, and cooperation. We believe that environments like MOOsburg may allow networking technology to play a more constructive role in supporting people where they live.

Thanks to Jonathan Kies, Brian Amento, Michael Mellott, and Craig Struble for implementing the original MOOsburg software and activities, and investigating the use of MOOsburg, in 1995. Thanks in particular to Craig Struble for continuing to design and develop MOOsburg during 1996-1998. Thanks also to Cara Struble for developing the original concept and implementation for map-based orientation and navigation in Fall 1998. Thanks finally to Dan Dunlap and Dennis Neale, members of the current MOOsburg team, for suggestions.

The MOOsburg project is supported by the Hitachi Foundation and the Office of Naval Research. The Virtual School project was supported by the National Science Foundation .

Benford, S., Brown, C., Reynard, G., & Greenhalgh, C. (1996). Shared spaces: Transportation, artificiality, and spatiality. Proceedings of CSCW’96 (pp. 77-86). New York: ACM.

Carroll, J.M. & Rosson, M.B. (1996). Developing the Blacksburg Electronic Village. Communications of the ACM, 39(12), 69-74.

Carroll, J.M. & Rosson, M.B. (1999). The neighborhood school in the global village. IEEE Technology and Society, 17(4), 4-9, 44.

Carroll, J.M., Rosson, M.B., VanMetre, C.A., Kengeri, R., & Darshani, M. (1999). Blacksburg Nostalgia: A Community History Archive. Proceedings of Interact'99. Amsterdam: IOS Press/IFIP, pp. 637-647.

Curtis, P. (1992). Mudding: Social phenomena in text-based virtual realities. Proceedings of the 1992 Conference on the Directions and Implications of Advanced Computing Berkeley, CA.

Dieberger, A. (1996). Browsing the WWW by interacting with a textual virtual environment. Proceedings of Hypertetx'96. New York: ACM, pp. 170-179.

Furnas, G.W. (1986). Generalized fisheye views. Proceedings of CHI'86. New York: ACM, pp. 16-23.

Glusman, G. & Prilusky, J. (1996). Real-time, Online Conferencing for Biologists. Conference on Bioinformatics and Structure (Jerusalem, November 17-21).

Haynes, C. & Holmevik, J. R. (Eds.) (1998). High Wired: On the Design, Use, and Theory of Educational MOOs. University of Michigan Press, Ann Arbor.

Isenhour, P., Rosson, M.B. & Carroll, J.M. (1999), submitted. Supporting asynchronous collaboration and late joining in Java groupware. Interacting with Computers

Kies, J.K., Amento, B.S., Mellott, M.E. & Struble, C.A. (1996). MOOsburg: Experiences with a community-based MOO. Technical Report, Center for Human-Computer Interaction, Virginia Tech, Blacksburg, VA.

Koenemann, J., Carroll, J.M., Shaffer, C.A., Rosson, M.B. & Abrams, M. (1999). Designing collaborative applications for classroom use: The LiNC Project. In A. Druin, (Ed.), The design of children’s technology. San Francisco: Morgan-Kaufmann, pp. 99-123.

McLuhan, M. (1964). Understanding media: The extensions of man. New York: McGraw-Hill.

Mullet, K. & Sano, D. 1995. Designing visual interfaces. Englewood Cliffs, NJ: Prentice Hall.

Putnam, R.D. (1996). The strange disappearence of civic America. The American Prospect, 24, Winter.