I'm filling in for Elena Loftus who was unable to make it today, so please forgive me if this presentation seems hastily contrived; it was.
I'm one of the NWE staff, on an appointment for the English department, and I recently agreed to take on the task of digging a new MOO for the NWE. Our old MOO was plagued by tracebacks, lag, and general bloat, so I knew we needed a solution that would provide for easier system administration without reducing functionality.
It was easy to identify some problems with the MOO -- I just asked a few instructors what they thought. I boiled down the real difficulties to three major issues:
1. MOOville needs to provide a MOO environment that allows a wide variety of instructors to teach the way they want.
Historically, our system administrators have taken great pains to enable many teaching possibilities in the Networked Writing Environment. One can use asWe, WordPerfect, NavGold, Pico, or Emacs to create hypertexts or traditional papers -- whatever is compatible with teaching style. Though some classrooms seem to privilege a more traditional model of teaching, others allow a great deal of working space and make collaborative work easy for students and teachers alike. The web, for some, is a research tool; for others, it's the way students share work, perform peer review, and present to the class as a whole.
Likewise, there are many approaches to the MOO. Some teachers use NWE MOO spaces for discussion groups only, and insist on traditional architectural metaphors -- an environment that looks like a classroom, with whiteboards and the usual classroom tools. However, just as many instructors ask their students use the MOO as a writing tool, and require digging and construction of spaces which follow a logic of argument more than one of architecture. For these instructors, the presence of the wrong sort of metaphor can make it difficult to acclimate students to the styles needed for completing assignments for the class.
2. Collaboration needs to be more practical.
If students @dig from one student's room to another, the usual annoying message requesting the addition of exits comes up. Of course, the MOO assumes every room is private, and it does not allow one person to create an entrance and exit in another's room. But it DOES create the room, without connecting it to anything, and assumes that the student will connect it later. Frequently they do not -- in fact, the student will often assume they typed the command wrong, and try it again. And again. Soon there are multiple rooms and exits connected to nothing, creating a technical problem for the 'walk' verb, and frustrating the students.
3. System maintenance can be a nightmare.
The final major problem comes at the end of every semester, when the 1700 student accounts on our Unix system are deleted. Deleting the files from Unix is easy, much easier than reaping the accounts from the MOO. If a teacher wants to save a bit of a student's web work, they can copy it easily -- in fact, our system has commands which automate this process.
But in the MOO, the end of the semester can be hell. Students do manage to link their spaces by digging, which means eliminating a student makes it necessary to check other students to ensure no vestiges of collaboration lead, quite literally, to nowhere, and a navigation problem only a wizard can solve. Teachers want to save some student work, and it's not nearly as easy for a teacher to copy a MOO object as it is for he or she to save a set of web pages to a different directory. Copying a complex installation with integrated descriptions and objects is quite difficult, and certainly it's not easy to find a lot of spare time at the end of the semester to make sure it's done correctly.
So these were the main challenges. I consider the first two the most important. We can talk about agency and the potential of the MOO to redefine boundaries all we want, but that doesn't mean a damn thing if it's broken.
We have recently solved all three of these problems by adding realms to the new MOOville.
I had heard about the realms system from Tari Fanderclai, who manages the MOO Connections, and was intrigued by its possibilities. Realms were developed by Tari and Ken Fox, in order to make Connections more manageable for the diverse group of users there -- teachers and their classes, veteran mudders, people interested in social MOOing, and many with a combination of those interests.
Realms have several functions which answer our list of problems rather nicely. Before I point to those, I'd like to give a short technical introduction to realms since it's a very new thing.
Simply put, and quite literally in a MOO sense, a realm is a container in which one puts rooms connected by entrances and exits. Each realm connects only to nexus realms, which is a special realm used for the creation of new realms.
Here are two illustrations which show nine rooms organized without realms, and the same number and organization of rooms with realms.
Here are the digging rules:
And the rules for ownership:
What does the implementation of realms mean for collaboration?
The realms system imposes a new restriction on every would-be digger: it checks to see if they have permission to dig in the realm before it allows them to dig. However, realms also lift the old rules about exit and entrance restrictions. This is a great enabler for collaboration.
Like any object in the MOO, a realm is owned by one player. Only that player and administrators can build rooms in a freshly created realm. But any player has the ability to add others to their realm-- so one player can pick a group of students, colleagues, or others to collaborate with them.
In the first image linked above, without realms, everyone can dig everywhere, potentially, as long as they get permission from the room owner. So if a student who wants to dig from a classmate's room to her own room has to get permission from the classmate who owns the room. And, if the student tries to dig to a third room, and finds a willing recipient, she can dig a web -- but only if the collaborees assent and @add-entrance or @add-exit.
But with realms, one can just dig. No extra steps are needed -- as long as the student is in her realm (the blue or orange zone on this image she can collaborate, dig, with the group she's assigned to.
An administrator can even assign a nexus to a teacher to allow different realms for student groups, as in this illustration.
Pedagogy and MOO design
For teachers, the implications are great because connections between classroom areas and the rest of the MOO, whether intentional or unintentional, are much more difficult for students to make. The realm subset allows much better definitions of working groups, whether a topology like this is used or not. Instead of the instructor trying to facilitate a group working together and connecting their rooms, adding exits, and other mundane tasks, one can simply establish a realm for each group, make all students in the group builders in that realm, and focus on the content of the assignments.
Because the exits in and out of a realm are restricted, it is much easier for a builder to separate a realm from the rest of the MOO, and differentiate the characteristics of that realm from other metaphors used in other realms. For example, one can make the entrance to their realm a series of rooms that gradually acclimate the exploring digger to the realm as they are entering, and let them know they are leaving if they start to head out. Tari Fanderclai has used this technique at Connections with a great deal of success.
Realms also allow common spaces to be created easily and "firewalled" from the rest of the MOO, and managed by a group of a few selected builders. For example, in MOOville, the central classroom space is managed by the non-wizard characters of the administrators and a few other volunteers. Those people are the only ones allowed to alter that area -- but that's an improvement over past situations, where the permission of one person was required, and it took careful prearrangement to work together. With realms, collaboration can be much more asynchronous.
Does the implementation of realms affect navigation?
To the end user, realms are transparent -- the casual MOO traveler doesn't see anything different when moving from realm to realm, except a "realm_arrive" message if it is set. In fact, even those who are digging need not know the gory details about realms, nexuses, and the like -- they need only know where they can dig, and how to get there.
It would also possible to enact a proposed "pod" topology, with realms in the same MOO not connected to each other, but self-contained units, in effect creating several small MOOs within one MOO. Many instructors at UF have looked for some level of this capability in order to customize their spaces, but I think that if used properly, realms could be used for even more customization, with groups of students attached to one realm and one realm only.
What does realms do for management?
For management purposes, realms make the removal of classrooom spaces very easy because problematic exits are seldom created in a realmed MOO. In the old MOOville, without realms, one of the problems we faced was locating student work spread out over a wide number of objects, and counting on the ownership of the object to be indicative of whether or not it should be recycled.
Copyright © 1998, 2000 C Bradley Dilger.
