Building a Virtual Campus:
Developing the Integration of Web and MOO Environments for Distance Education

Dr. Mark Haas
Dakota State University


ABSTRACT

Working with the Dakota State University Office of Distance Education and two collaborators, one an instructor at Salt Lake Community College in Utah and the other a high school student in Austin, Texas, our project for the summer of 1997 was to produce an environment that integrated the asynchronous benefits of web-based hypertexts (WEB) with the synchronous benefits of telnet-based multi-user domains that are object-oriented (MOO). The goal was to accommodate a wide range of pedagogical styles and delivery methods to enhance the educational environment for distance education, while keeping technical requirements to a minimum. The impetus for the project was to develop on-line undergraduate courses in English, as well as prepare the way for courses in other disciplines such as social and natural sciences. The challenge was to interface the WEB and MOO into something called a WOO, which provides almost the same information regardless of the delivery method. To accomplish this integration, we developed and coded a program on the MOO that functioned as an on-the-fly web-page generator for objects in the MOO environment. The result was a virtual campus with buildings, classrooms, and a variety of teaching tools which implement synchronous, asynchronous, and multimedia capabilities.

The campus was divided into buildings that may be developed according to college (liberal arts, natural sciences, business, computer science), with a central student union. I wished to provide a site for educational and social interaction, and so included a game room, night club, and student dorms. There is also the possibility of incorporating the library and administrative offices of Dakota State University in the future. To overcome the potential ignorance in technology, I developed a manual for the MOO side of campus as well as tutorials for anyone who wished to build and program in the MOO. I created graphics that remained consistent throughout buildings and over the campus to facilitate navigation. With my collaborators, I customized existing MOO objects such as slide projectors and notes to be readable from the WEB, so those who wished to remain on the WEB side without venturing too far into telnet could access what others where doing. In addition, we coded in a password-protected WEB mailing system so students could use the MOO’s built-in mailing system to communicate through discussion boards and mailing lists without having to worry about mail clients and listserv problems. Finally, we added java capability, so users could access the MOO through a java-enabled web browser. In effect, the WOO allows students to access everything needed for a class from the web and/or telnet. Thus, the programming we’ve done results in an environment that is very friendly to both students and future teachers.

Keywords:distance, education, undergraduate, courses, virtual, campus, telnet, internet, moo, web, interface, woo


Over the course of the NAWEB conferences, a theme seems to be developing, which I would like to address--building virtual communites. At NAWEB '95, Robert Domaingue, in his presentation Designing a Virtual Campus, raised several questions about the type of learning that occurs in virtual campuses:

What needs are met for students on a physical campus? How many of these needs can be met in the virtual realm? What are the best ways of doing this? What additional features can be developed in the virtual campus that are lacking on the physical campus? What are some of the tools we can use in our virtual campuses?

Domaingue answered these question by arguing that we must move from mere information transferal to include other levels of learning, including learning for meaning, and emancipatory learning.

The following year, Basia Siedlecki of the University of Northern British Columbia presented Web Courses for Northern B.C.: Building a Virtual Community. In the paper, Siedlecki narrated the development and evolution of a web-based virtual community that considered the needs of students and instructors for access and individuation of course materials. Although I found the paper interesting and progressive in content, the resulting community seemed to fall into what Domaingue termed "technical learning", or learning from information transfer.

Having considered the questions posed by Domaingue and the solution implemented by Siedlecki, I have concluded that the Web itself often becomes a hinderance in the development of various levels of learning beyond information transfer. I have often argued that we are so intrigued with the technology that we let it dictate the direction of our pedagogy, rather than forcing technology to serve our needs as educators. For example, Siedlecki states that one of the goals of the team's project was "to suit the pedagogy to the medium." Statements such as this, though seemingly harmless, may lead to a technologically-driven pedagogy. Shouldn't we rather suit the medium to the pedagogy? Lets start from our pedagogical goals to create a pedagogically-driven technology.

I now ask what we can do to push beyond the limitations of the Web. How can we start from the active, student-centered forms of learning Domaingue articulates, and recent educational research has celebrated? The remainder of my presentation will introduce a solution to the problem, a solution known as a WOO.


For the summer of 1997, I received a grant from the Dakota State University Office of Distance Education for the development of on-line courses. I had taught one course on the internet during the spring semester and wanted to improve and expand on the delivery, while providing resources and opportunities for other faculty members. I had found that I was getting caught up with the excitement of the web, but had lost the values of pedagogy I had learned during my graduate education. Making web pages and writing email was valuable as asynchronous delivery, of course; but these standard methods lacked the interactive style I desired in a transformational, liberatory pedagogy. My primary goal for the summer, then, was to find a medium that would accommodate a wide range of pedagogical styles and delivery methods. I also found that many of the students were looking for ways to interact with other students for both academic and non-academic purposes. Again, homepages and email were starters for this community formation, but were constraining. My secondary goal, then, was to enhance the educational environment for distance education, making it interactive, personal, and synchronous.

After much discussion with colleagues and computer service support, I looked through what seemed a mountain of software that might provide the delivery and pedagogy answers I was looking for. I tested everything from courses in a box to chat programs to bulletin board programs, finding potentially valuable elements in many, but with none catching my attention beyond intrigue. I then decided to look into a possibility I had overlooked, MOOs. A MOO is a Multi-user domain that is Object-Oriented. MOOs are internet accessible, text mediated virtual environments well suited for distance learning. To quote Pavel Curtis, one of the original developers of the MOO:

A MOO "...is a network-accessible, multi-user, programmable, interactive system well-suited to the construction of text-based adventure games, conferencing systems, and other collaborative software. Its most common use, however, is as a multi-participant, low-bandwidth virtual reality..." - excerpted from the LambdaMOO Programmer's Manual, version 1.7.6, written by Pavel Curtis.

The MOO uses a telnet client to connect to the host machine as a terminal emulation. An example screen would look like the following (please forgive the poor quality):

Within the MOO, people can talk with each other (much like an IRC), can walk between rooms, can interact with objects, and can create and program their own objects. The value of the MOO, pedagogically speaking, is that students can interact with other students in real time, work collaboratively, and interact with objects that respond to commands.

The ability to interact with people from anywhere in the world at any time intrigued me, as did the ability to construct a personal environment (I constructed the beginnings of a Scottish highlands) and program objects to accomplish tasks and interact with players (I have a 'minstrel' who will sings songs when asked). At first, I was only able to utilize text for the MOO, as it is text-based as a telnet program. This textual aspect was the reason I had not considered the MOO before. While it is wonderful for composition and rhetoric teachers like myself, it loses its appeal for others who desire a graphical setting. Nevertheless, the MOO provides real-time interaction between students and teachers, and allows them to construct virtual environments that simulate the classroom environment as well as the campus experience.

For my grant, I thought I could use the MOO alongside the Web as a companion application. I set up a Win MOO server on the Office of Distance Education's Windows NT web server, and started to create a web version of the MOO with Microsoft Frontpage. I also began looking at the different MOOs that were available and made a surprising discovery. I found a MOO located in Salt Lake City, Utah called the Virtual Writing Center, managed by Clint Gardner. Working with a high school student out of Austin, Texas named Charles Willgren, Clint had utilized the latest MOO technology for integrating a MOO and the WEB, something called a WOO.

A WOO is an object on a MOO that has functions (called 'verbs' in MOO parlance) written in MOO code (similar to C++) that produce on-the-fly web pages that are sent back to a web browser. The WOO works similar to Microsoft Frontpage Bots: it gathers the necessary information from the object (called 'properties' in MOO parlance); it generates a consistent web page format; then, it sends the html for the page to the browser requesting it. Thus, every object on the MOO can be viewed on the Web, giving people access to the information in either application. An example is the Trojan Center Lobby.

With the WOO, then, I had found a potential answer for how to provide a variety of delivery and pedagogy options within an accessable framework of technology. I did not need to reproduce the information for both applications, but could focus on the MOO which then generated the Web pages for me.


I went to work constructing the Virtual Trojan Center (TC), based on the student union at Dakota State University. After consulting with administrators and the campus internet committee, I decided to recreate the physical space of the TC on the MOO. The main reason for this decision was to give distance students a feeling of belonging at DSU. By visiting the buildings and campus of the virtual campus, students could make a connection with resident students; and, if they ever visited the actual campus, they might have a sense of familiarity. I created the rooms in fairly proper order, and made a building directory using Adobe Photoshop.

The directory contains a listing of the main rooms in the TC. It is also a client-side imagemap on the WOO, so users can click on the room they wish to go to rather than 'walking' through the room/pages.

My intention with the TC was to provide a social space for students, particularly distance education students, to interact and form a community outside of the formal academic setting. I created several non-academic rooms in the TC, including a game room, a nightclub, and a tropical hideaway. The third room brings up another feature of the MOO--it needn't recreate an actual space. I decided to include an imaginary room (there are no tropical beaches in South Dakota) in order to provide students with an opportunity to see the potential for the space beyond the classroom.

Having the basic layout of the TC complete, I began to consider the look of the web pages generated by the WOO. The criteria I considered was consistency of format, visual presentation of information, and ease of navigation. I decided on using headers for the campus, including the name of the particular building. So I made the Trojan Center header, along with others for buildings I planned to construct later.

The url for the header is included on each room/object as a property. (Properties are similar to our hair color, eye color, handedness, gender, etc.)

I added other properties for the WOO to use in constructing the page, including background image, text colors, signs (for room names), picture, and sound. I then programmed the WOO to construct a page that contained all the information in a rhetorically relevant and consistent manner. The page has the header at the top, followed by a table including the picture for the room and the name or sign for the room. Next is the sound for the room as an embedded file. Finally, the WOO would add the description and contents of the room. An example of this set-up is the game room. I should add that if the property is empty on the room, the WOO doesn't add it to the page. With the game room, for example, there is no picture to place next to the sign, and no sound defined for the rooom. The signs and text colors for TC rooms are meant to mimic neon tubing that marks the rooms in the actual TC. I also used background images that seemed to indicate hallways and rooms as bricked and wallpapered. Again, the Hideaway is different in content, with more appropriate background, sign, and sound (ocean surf). By creating a consistent format of information, I provided the user with a quick way to gain the information needed without wondering where it might be. The user knows what will be included on each page after a short time of use, and surprises are kept to a minimum.

To meet the need for ease of navigation, I programmed a footer for WOO pages that is consistent throughout the entire MOO. It includes a navigational bar to main features of the MOO, including a listing of who is on-line, a player directory, an imagemap of campus, and a listing of the administrators (known as 'wizards' in MOO parlance) of the MOO. In addition, there is a quick redirect button with a selection of frequented rooms for easy movement. Again, this footer provides consistency for the WOO, giving users a sense that they are still 'on-site' as they move around.


At this point, the WOO was a nice spatial environment of rooms, similar to the virtual community Siedlecki presented. The next step moved the WOO into another level as I added objects to the rooms. Now there were players, notes, slide projectors, lectures, plug-in embedded objects, etc that could be viewed on the web as well as within the telnet environment. I worked to code verbs that would allow the objects to be used on the WOO similarly to the way the could be used on the MOO. A good example is the slide projector.

The slide projector is a MOO object that allows users to view textual slides in any order. It also has a table of contents (toc) verb so the MOO user can view the title of each slide and choose more easily. On the Web, the table of contents is presented with links to the slides. The slides also have links to previous, next, and back to the table of contents. The WOO generates this page from the object's properties, so there is no need to duplicate information for web and moo. With objects such as this, the ability to teach using the Web interface is increased.

The pedagogical value of these objects can be seen by their use on the MOO side. While it is nice for students to be able to view slides and lectures on the Web, at their leisure, the objects are even more useful for teachers when conducting an on-line class session in real time. S/he will not have to switch between applications to show something, or deliver a lecture. The students would see the slide and read the lecture at the impetus of the teacher. The teacher could also develop other objects that would utilize the synchronous nature of the MOO, objects such as a breeding fishtank to demonstrate aspects of biology, or a calculator for business principles and/or math, and conversational robots that might be guides or perhaps tutors. The possibilities are great, depending on the imagination of the programmer, and the needs of the educator.


The final step in getting the Virtual Campus going was to construct the academic portion with its appropriate rooms and objects. I added buildings and rooms to follow the setup of the campus, and made an imagemap for the campus.

I did not create all the buildings at this point, but only the academic buildings. I chose the liberal arts building, the business building, the science building, and the education building, creating headers for each. The potential for creating administrative buildings and the library is in place; I just need a representative from those areas to assist in the construction.

Within the buildings I constructed an example classroom with several important features. The generic classroom includes a clock, a blackboard, a bulletin board, a course information shelf, and a big table. Each of these features is read by the WOO and translated into an html element. On the MOO side, the most important feature is the big table. This table allows students to have private conversations while in the same room as others. Students sit at the table, and others not at the table cannot hear them. It is a valuable tool for creating small group conferencing within a room. The owner of the room can create as many 'tables' as s/he wishes, allowing the class to break up into groups rather than have a large discussion. The room also has a 'record' verb that allows the owner to have a transcript of all the speaking that goes on. The WOO, of course, is not able to recreate this as it is asynchronous, but it does allow students to access the transcript and read the blackboard and objects on the bulletin board.

Perhaps the most valuable aspect of the classroom is that the owner (who will be a teacher) can make a class for the room. Having made a class, the teacher can register students for the class and can set up the class security for only those registered to enter the room. In addition, when making a class, the MOO also creates several objects for the teacher to use. These include a syllabus, a file page, a links page, and a mailing list. Also, the course is now listed on the courses page of the WOO, complete with links to the classroom, the teacher, the syllabus, and the roster of students registered. My goal for this feature was to simulate a course in the box.

The syllabus has a header and a footer automatically generated. The header is a table with the name of the course, the teacher of the course, and the pertinent information for that teacher. The footer includes navigational links to the two other pages created when making a class. The main body of the syllabus is found in a property that can be edited from the MOO to include the information found on a printed syllabus. I have put up the syllabus for the class I taught last semester.

The other two pages created are the file page and the link page. The file page is a list of links to other objects on the MOO. These objects can be anywhere because they are linked by their object number. This way, teachers can make one object, say an assignment or a comment on a particular topic, and link it to several class file pages. Much as with the slide projector, the files pages include navigational links to the objects and from object to object. I have made such a file page. The links page, on the other hand, contains urls for the class, commonly known as 'related links.' These links take the user off-site usually, but provides the teacher with a place to store important urls of interest to the class. Here is my links page.

Finally, making a class creates a mailing list for the class. The MOO has a mailing system within it, so players can mail each other within the MOO. The mailing list is similar to a listserv, but also has features of a bulletin board. Those subscribed to the mailing list receive notice of new postings, receive copies of the postings, and can send posting to the list. Thus, the class has its own list created. Whenever a student is registered for a class, they are added to those who may use the list. They can then subscribe to the list and read the postings there. Initially, the mailing features of the MOO were only usable from the telnet side, which led me to develop a web mailing system for the WOO.

The web mail system allows people to access their MOOmail from their web browser, including deleting messages and sending messages. The system is password protected so users must have an account on the MOO to access the system (guests can log-in with limited success). This allows teachers to use the common MOOmail system instead of dealing with a variety of mail programs that students often have. (If you are reading this over the web, try using the user id 'naweb' with password '97'.)


I'm sure many of you are wondering how all this translates into learning curves, particularly for the teacher. I realize that a MOO can be daunting at first. I must say that everything I've done has been on the MOO side, and any changes in properties, classes, objects, etc must be done from the MOO. I plan to work on a web editing system so that properties and verbs can be edited from the web, but that will wait until next summer's grant ;-). In order to accommodate the new user ('newbie' in MOO parlance), I edited the help files and the generic descriptions to include information on how to use and manipulate the various objects. For the WOO, I added a link to the help file for each object. More importantly, I have begun work on a MOO manual, including information for accessing the MOO, getting a telnet client, and how to build and edit objects for teaching purposes. I hope the manual is user-friendly and informative. I also plan to work up some tutorials on using the editors, building rooms, and even programming objects. These are currently only available from within the MOO, but I plan to edit them for the WOO to use.


Recently, I have programmed the MOO to be accessable through java-enabled browsers. I have installed an applet named CupOmud, developed by Alex Stewart, which allows users to log-in to the MOO from the web, and places the corresponding web page in a frame above the applet. Thus, users don't need to get a telnet client to gain the synchronous aspects of the MOO. They can view the graphics in the WOO frame, and interact with other players in the applet frame. For those who do not have access to graphical telnet clients such as Pueblo, the java applet provides some access. I am also attempting to add support for other telnet clients which interact with the MOO and the WEB--Juggler, tkview, and MacMOOse. Because my presentation is not focused on MOO clients, I will not pursue that avenue at this time. I would be happy to discuss the issue at another time, however.


In conclusion, I would like to say that I have found the WOO a valuable resource with great potential for development. In this presentation, I have tried to indicate some of the value, but have often only scratched the surface or had to leave aspects out completely. The ability to integrate the synchronous benefits of the MOO with the asynchronous benefits of the the WEB will provide educators with many possibilities for meeting their pedagogical needs. I plan to continue developing objects and documentation that will be usable for both MOO and WEB, and hope to see many of you on-line. The MOO will officially be used for academic purposes Fall Semester 1997. Feel free to visit VTC MOO, and tell them Meshak sent you.


Dr. Mark Haas
Assistant Professor of English
Dakota State University
Madison, SD 57042
haasm@columbia.dsu.edu
http://www.homepages.dsu.edu/haasm


©, 1997. The author, Mark Haas, assigns to the University of New Brunswick and other educational and non-profit institutions a non-exclusive license 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 author also grants a non-exclusive license to the University of New Brunswick 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. Any other usage is prohibited without the express permission of the author.