[Encore] A Modest Proposal

[Kevin Jepson]

Daniel

Thanks for the response, great questions and I hope I can clarify what I'm
getting at a bit better. 
=========
First a little literary diversion...

:-)

 The face of all the MOO is changed, I think,
Since first I heard the keystrokes of thy code
Move still, oh, still, beside me, as they rode
Betwixt me and the dreadful outer link
Of object death, where I, who thought to sink,
Was caught up into space, and taught the whole
Of life in a new rhythm. The cup of code
Pavel gave for baptism, I am fain to drink,
And praise its sweetness, Sweet, with great cheer.
The names of objects, properties, are changed away
For where thou art or shalt be, there or here;
And this . . . this moo and web . . . loved yesterday,
(The singing coders know) are only dear
Because the name moves right in what they say.

==========
 
I think that MOO is as much a context as a formal definition.

You said:
"If you mean by MOO 'a collaborative environment based on spatiality 
(notably room, avatar and object metaphors), enabling real-time 
communications', then you are wrong. This is what we want to preserve, 
and as far as I can see, we have done just that."

Except that as we move away from the clarity of text we are making it more
difficult to maintain that sense of space. The very metaphors of rooms,
avatars and objects that are key to the understanding of the (text)
description of a space are clouded.

The success, such as it was, of MOOs was due to the ease with which users,
especially non-technical ones, could get that sense of space and actively
participate in it's creation.  Users of a MOO are SOMEPLACE.  They aren't so
much looking "at it" as looking "into it" (or even "out from it").

The technology that underpins this metaphorical structure is unimportant
really (my comments about MOO code are more about HOW we deal with the
structure of these spaces), but more on that in a bit.   

You asked for examples of how V5 is less immersive than V4 "in structure"
and I can think of one right off the bat, there is NO practical way to
navigate the space WITHOUT using a mouse. Navigation in V5 (and in V4 as
well but it can be changed fairly easily I think) requires the user to
concentrate on the "link forest" displayed on the WEB side of the interface.


So what? That's the way people do things these days, right?

The test for how this effects the spatial and immersive aspects of our
system is simply to ask the users where they "are" relative to other places
in the world. When I have done that with my users they mention not really
having a feel for where they are. Note these users are my family and friends
so it's not exactly a scientific poll. ;-)

If one wanders around in a complex MOO like VROMA, TTU or even LiguaMOO
itself, WITHOUT logging in, it very quickly becomes difficult to keep a
sense of the space in your head. The change from the use of "direction" in
exits to "destination via links" has seriously disrupted the metaphor of
space that is critical to user navigation, IMHO. Removing the sense that
exits are actual things like doors, corridors, waterfalls or portals etc.
takes away clues that the users need for navigation in a spatial sense.

When someone opens a browser connection to a large website like CNN or MSNBC
most people do not think of "being IN" that site. I believe that they
perceive their actions as being more like the watcher of a TV program or the
reader of a magazine, (that is, being outside looking in) rather than being
the participant in the space and any action that takes place there.    

WEB pages are like the physical pages of a book, they are static, in a sense
they are frozen screenshots.  WEB Links, which essentially bring up the next
page, are NOT perceived as exits "from" somewhere "to" somewhere.

In my V4 MOO I have changed the link display to be "["direction"] to
destination".  So for example, the link to the Widow's Walk on the roof of
my office is displayed as "[UP] to The Widow's Walk". That way when a user
looks at the web display of my office they know that the Widow's Walk
(whatever that is) is UP from where they are.  If they go up then it stands
to reason that the exit/link to my office would be DOWN. 

In the absence of that directional clue each link is equivalent to any
other. 

A real world example is when someone navigates in a town. Do they always go
by street names: main then elm then 4th then center then Ramsgate drive? 

Or do they go: north on main, left on elm, south on 4th to center and then
right onto Ramsgate drive? 

Also the links, as displayed in all versions of EnCore, are visually all the
same. They are arrows pointing to the right, all lined up in an arbitrary
order with very little if any spatial context. On the text side, if the
exits are listed, they are listed with cryptic names not directions.
Builders using the generic dig/create form don't get the option to name the
exits in a meaningful way.

It is relatively easy to "detune" V4 to fix this, change the exits like I
noted above, allow exits to be referenced by look commands (thus retaining
their status as independent objects in the world/space) and keep exit
messages active so users get feedback as the exits are used. It will be
necessary to rework the object creation to add the naming of exits back in
but it looks doable to me. These options don't exist in V5 currently from
what I can see although maybe they can be added. (In which case I'd like to
suggest we look at doing that.)  

WRT the term "object oriented".

I understand your comments and agree that the term "object oriented" is a
bit of a misnomer in a formal sense. However, to me, the advantage of the
object and inheritance hierarchy structure, imposed as it is by the
structure of MOO code (object oriented or otherwise), is that it mimics the
object hierarchy of the real world!

I have no doubt that such things can be accomplished in other languages like
Java, PHP or even C++. It isn't the language it's the metaphor that is
crucial here as far as I'm concerned.

MOO code, as archaic and simple as it is, is a very good tool for
structuring text into hierarchies that can be used to mimic real three
space. It is a way of taking frozen text, like a page from a story, and
"inflating" it into three dimensionality (in an interactive text sense)
while still maintaining the "ease of use" that creative writing has.

This can certainly be done with other languages, and has been by competitors
to MOO like other multi-user systems such as LP and the various MUCKS. It's
interesting though, that Jan and Cynthia choose LambdaMOO as the base for
EnCore not LP or straight C code.  In reading "Traceback" it is quite
apparent to me that Jan realized it was the similarity to real 3 space that
MOO code structures displayed, IN TEXT, that was the key. The simplicity of
building blocks of code/objects that could then be piled up into a coherent
whole. The WEB integration of enCore was a way to AUGMENT the display and
informational richness of the system. The philosophy follows the UNIX mode
of build simple tools and then combine them to do complex things. Hopefully
Jan won't mind my very poor paraphrasing. :-)

It may appear that I think the WEB integration aspect is somehow damaging
the whole system, and in a sense that is true. I don't want to loose the
ability to build, and have non-technical people co-create, the kinds of
complex, beautiful and stimulating environments that any reasonably adept
writer can accomplish with a few carefully chosen lines of text. Whatever
system we use to manipulate THAT TEXT it must not get in the way. It should
support the user rather than constrain them.

If our objective is to harness the creativity of our students and users, to
inform but also challenge them to be creative themselves, we shouldn't force
them to be graphics and web programmers (or MOO code programmers for that
matter) in order to do it.

You said:
"We have been through this discussion a lot of times, without really 
having been "through" it. enCore is composed of two layers, or ideas: 
The virtual world idea with rooms and objects and avatars in the center, 
and the real world idea with student enrollment, internet email and time 
zones. The latter is a layer on top of the first, and both ideas are 
competing. We know that.

But can't we do both?"

I certainly think we can, but I'm afraid that the second priority may make
the first difficult if not impossible to maintain.  That's why I suggest
that we fork the development. If, as Lennie hinted, we might be moving away
from MOO code for practical distribution and maintenance reasons, what
happens to the masses of MOO code that runs our current worlds?  Do we run a
translator/cross compiler of some sort?  What code support do we include?
What parts of the idiosyncratic MOO code do we port over? 
I imagine that project could possibly dwarf the creation of enCore itself!

It's not that I think enCore V5 and it's successors can't do these things. I
think they can, BUT, they are more suited to creating spaces that we then
GIVE TO OTHERS TO USE as opposed to opening spaces in which others HELP US
to create the worlds.

To close on a philosophical note...

The quest for virtual reality has been ongoing for hundreds of years. The
development of computers and extremely powerful, and cheap, processing
capabilities has brought us closer to being able to build convincing
simulacra of real objects.

However, nothing compares with the ability of ordinary text to move us
"elsewhere", IMHO.

Text, creative writing in all its forms, speaks directly to our minds.

A twelve year old can write a description of a place that only they can "see
in their mind" and share it with millions. They can share not only the
description but also how it feels, smells, sounds, moves and even effects
the mind of the viewer. Only the greatest graphics artists of the age can
come close to matching the power that simple text has to inform, illuminate
and effect.

We have an excellent platform on which to build, thanks in great part to all
your hard work, and the two directions you mentioned above can be taken
quite easily. However, I'm not sure that we will be able to do either
justice in a single, "official", system.

Ciao
KJ

=======================================================
Kevin Jepson R.E.T.
President
4K Consulting Inc.                    
An't nanum hearm deth, doth hwaet ye willath.

Email: kevijeps at telusplanet.net
=======================================================

  

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.6/427 - Release Date: 24/08/2006