[Encore] A Modest Proposal

Kevin Jepson kevijeps at telusplanet.net
Wed Aug 23 23:35:39 MDT 2006

With apologies to Jonathan Swift :-)
I've been watching the discussions of the course we are on with the "EnCore
Learning Environment" (formally known as EnCore MOO) over the last few years
with some interest and, as you've probably noticed :-), I have some strong
opinions about the metaphors that we use when using our systems.
I admit to having felt a bit at a loss to explain my general ennui with
respect to the V5 beta.
Version 5 is a truly wonderful piece of software that has many potential
applications in education. It really does make the term "Learning
Environment" applicable. I in no way want to denigrate all the hard work
being done to make it work.
It is not a MOO, at least not in a form that the users of MOOs from the 90s
would recognize.  Changing the name is certainly appropriate on that basis
alone. :/  
EnCore V5 is a "Web and chat based synchronous/asynchronous communication
system with integrated user management, email and multimedia linking
capabilities".  Magnificently programmed entirely in MOO code to boot, BUT
IT IS NOT A MOO.  In fact I don't think it is possible to make a working MOO
(in the traditional sense) using EnCore unless one is prepared to detune and
modify it a bit.
Hence my "Modest Proposal"...
I think we need to fork Encore development into two streams. One which
supports the current development of the Learning Environment of V5 and V6
(which might not use MOO code at all) and one that supports the system as
implemented in V3 and V4.
Why does it matter?
It matters because the user experience is very different between these two
V3 and V4 MOOs retain some emphasis on text, they still maintain a stream of
information coming from the spatial environment contained within the MOO.
The display has not been entirely subsumed into the WEB.
 It is still possible to create the kind of immersive text based
environments that MOOs are capable of in V3 and V4 systems.  There are
practical examples of this in the existing MOOs with their hundreds, if not
thousands, of hours of creative work. With some more development work I
think the link between the text side of the MOO and the WEB side can be made
to work better with the immersive elements. It may require some radical user
interface changes, but that is doable I believe, in the V3 and V4 systems
because they are programmed using MOO code which is object oriented and
thoroughly debugged and documented.   
V5 and potentially V6 systems are placing the display and user interaction
almost entirely on the WEB side. In order to make the WEB display standards
compliant we have increasingly divorced the generation of the content from
the code used to move or manipulate it in MOO space. V5 and V6 systems will
HAVE LOST FLEXIBILITY because they are much more closely tied to WEB based
programming structures and may, of necessity, abandon traditional MOO code
programming entirely for script based systems like PHP.  This change will be
necessary simply to make the system efficient.
Objects and their WEB representations are already divorced from their MOO
code objects in V3 and V4 but at least the underlying code is amenable to
analysis by any reasonably competent MOO coder. Going forward on our current
development path will make this link harder and harder to maintain.  The
moment we abandon MOO code and its object oriented spatial paradigm we may
become just another WEB based chat system (all be it a good one).  We loose
the ability to harness the creative energy of our students and users because
we are constraining the ease with which THEY CAN CREATE THESE WORLDS WITH
There are just enough "loose ends" in V3 and V4 EnCore to open up the
development.  To make new worlds that are not tied to WEB structures at all
except for display.
We need to keep going with the V5 beta and working towards V6, as they are
systems that formal educational institutions will love to have, and that
agencies with grant money may support.  The very structures and constraints
that hinder, IMHO, the creative use of these systems will make use of them
in formal contexts easier.
However, I think it would be a great loss to not take advantage of the
thousands of hours of work people have put into MOOs, EnCore and other cores
alike, by dropping development of V3 and V4 MOOs.
Another advantage to separating the development efforts is the possibility
of cross pollination from other systems. There are probably other Chat and
WEB systems that have functionality we would like to use in V6 that is
incompatible with the underlying MOO technology. By separating out the MOO
side into a V3 V4 stream we free a V6 from it's legacy handicaps. Similarly
there is a wealth of old MOO code lurking out on the net that can be ported
over to our V3 and V4 MOOs directly, to use as the basis for new objects and
worlds, without having to worry about shoe horning them into a WEB based non
MOO code system.
Lennie made a comment recently that said essentially  "Who programs in MOO
code anymore?" which is a really good question and one I think may have a
surprising answer. 
OUR STUDENTS AND USERS WILL if we give them the tools and environments in
which doing so SUPPORTS their creativity rather than constrains it.
For formal systems where we want to direct, control and evaluate students
and users in formal academic environments, there is V5 and V6 EnCore
Learning Environments(tm).
For games, experiments and worlds where we want to harness the creative
writing skills of our users and students, where we CO-CREATE these virtual
worlds with them, there is V3 and V4 EnCore MOOs.
I believe that we should support BOTH approaches and a formal Fork of the
development streams will help that happen.
Comments, kudos, brickbats and discussion welcome as always :-)
Kevin Jepson R.E.T.
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.5/425 - Release Date: 22/08/2006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/encore_encore-consortium.org/attachments/20060823/7683a38f/attachment.html 

More information about the Encore mailing list