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.

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.