Initial experiences

After spending some time in MOOSE Crossing, I "got the fever" and came up with some ideas for some cool objects that I could create. The fun of messing around in a MOO brought back to me the days when I first learned programming (it was BASIC then). Some of us all got really excited about what one could build with the new language and we created games like tic-tac-toe, checkers and Star Trek. My original ideas were along lines like this (except objects now, of course) ó for example, I thought of making a little maze game that you could pick up and move your character through.

When I bounced these ideas off of Amy, she explained that they were far too complicated for the purpose, which was to teach. So, the first transformation I went through was to move from thinking like a learner / constructor to thinking like a teacher. This meant focusing on the programming concept to be taught and "working backwards" to the object to be built. Ultimately, this made for a much simpler object than I would build strictly for my own enjoyment.

The idea for the tutorial

In consultation with Amy, I settled on making a tutorial explaining the use of the "question" commands. In MOOSE Crossing, one creates a script for an object which gets activated in response to a particular command given to the object by another object (usually a character). The question commands allow the script to request a string (or strings) of information before continuing with its execution. There are four major variations: "question", which puts out a prompt and then waits for a string of input; "yes_or_no", which does the same as "question",, but requires a "yes" or a "no"; "input", which waits for a line of input with no prompt; and "input_lines", which takes multiple lines of input.

My goal was to create a tutorial for a simple object that would illustrate the use of these four variations of the "question" command. We came up with the idea of a Potato Head, which would allow the player to change the description of the eyes or the nose or the mouth. Then, the Potato head would change its appearance to display a complete description of the face, filling in the player-supplied descriptions. Clearly, this would make use of the "question" command. In addition, I would make one of the questions of the yes-or-no variety in order to illustrate the second variety of the command.

I couldnít think of a good motivation for the "input" variation, but, for the fourth variation, "input_lines", I thought it would be fun to allow the player to enter a list of emotes which the Potato Head would do when it received the command "tickle". This, of course, is not directly related to the Potato Head concept, but in this virtual world, making a Potato Head emote is a neat thing one can do that is not possible with a physical Potato Head.

Writing the tutorial

My first task, of course, was to program the Potato Head object, which I did pretty easily. This was my first completely working object and I was impressed with how easy it really is to create interesting objects in MOOSE Crossing. The language is simple and the data structures are powerful while not being burdened with complexity.

Then, I began with an explanation of how to create a Potato Head. At the beginning, I directed the person to actually play around with my Potato Head (called "Daves Potato Head") first, in order to give the learner something to compare their results with. Then, I launched into the explanation of how to create a new object and add the script and the properties. I tried to keep the wording simple and to explain everything as if the person had never programmed in MOOSE Crossing before. I also was careful to do the explanations in small pieces, letting the learner see results after adding each "question" statement so that at frequent intervals they could: see results quickly (for motivation); and check the accuracy of their code.

I was surprised by how much explanation it took to really go through everything that was necessary to create the scripts. By the time the tutorial covered just the first two variations ("input" and "yes_or_no"), the tutorial was as long as the other tutorials in the system. So, I decided that the second two variations would have to be done in a second tutorial, maybe at a later date.

Testing the tutorial

Due to bad time management on my part and my less-than-effervescent personality, I was not able to get any kids to test my tutorial. However, a fellow PhD student with no prior exposure to MOOSE Crossing agreed to give it a try. Just watching him go through the process of using the tutorial led to a series of changes. Most of them were of a clarifying nature, not fundamental changes. Several interesting points were:
 

1. I made a series of wording changes where to clarify what was being said.
2. Because I exposed him to using the Potato Head object before he started, he then made the mistake of trying the "look at" command (instead of inspecting the eye_color property directly) too early in the tutorial. After he self-corrected this, then later in the tutorial, after he added the line of code to make the "look at" command work, he forgot to use the "look at" command and thought his code wasnít working.
3. The test run pointed out that I had completely missed a step in creating the final object: I forgot to mention that the rest of the properties needed to be added to the object. Interestingly enough, his suggestion was to allow the error to happen and then say in the tutorial: "If you get errors, thenÖ" Allowing the student to fail is not something I would have thought of at first. My solution was a compromise, i.e. to tell them that the properties need to be created, and then to also put in a section to remind them again if they get errors.
4. Finally, a few User Interface suggestions came out of the test:

a. Since the initial window that appears in response to clicking the Pencil icon is a dialog box, it is impossible to click back to the Tutorial window to see what should be entered.
b. When the Pencil icon is clicked, it might be more convenient to bring up the Object Browser window immediately and then allow adding and deleting new scripts and properties from there.
c. My tester was confused by the fact that he had to both Save and close the script window. Maybe the Save button should close the window too.

Suggestions for MOOSE Crossing

As for suggestions to improve MOOSE Crossing, I donít really have any ideas for improving the programming environment itself (except for the User Interface suggestions just made). Instead, my ideas lie in the direction of enhancing motivation. I am the kind of person who is impatient with chitchat and aimless banter (cocktail parties and the like). I like activities that are more directed, i.e. that give me something interesting and/or challenging to do with other people. Along these lines, my ideas for MOOSE Crossing have to do with introducing some directed-ness into the experience of participating in an Electronic Learning Community (ELC).

Special events

One way to provide more motivation in the MOOSE Crossing world is to hold specific social events planned for specific times. This might increase the sense of community. Also, if a theme for the event was chosen that encouraged people to do some inventive things (e.g. a "Mini-me" party), then programming could be encouraged by providing a specific "show-and-tell" environment with a more specialized programming goal.

One extension of this idea is to hold specific competitions involving design of objects with a specific objective. In order to make this work, it may be necessary to create a part of MOOSE Crossing (or an entirely new "place") where rules are operative which are more specific than a generalized MOO. For example, if community members were challenged to make robots which traverse a maze, then a maze world/object would have to be provided which governed how the robots were allowed to move, and so on.

Specialized Virtual Worlds

Now, Iíll take the idea of creating a specialized place a little further. Again, my main focus here is enhancing motivation. It is well known how much time and effort adolescents (and adults) put into learning role-playing games. These gamesí virtual environments provide a rich context that the player finds appealing, along with some challenges and some (at least implied) goals. So, my first question is whether one could scaffold the experience of learning to program by creating a MOO with a specific environment and objective.

The thing that would differentiate this from existing role-playing games is that progression through the virtual world would lead one to be required to construct programmed objects in order to achieve advanced objectives. For example, in some current role-playing games, there is a progression of levels, each increasing the playing challenge. So, how about using these levels to increase the playerís level of competence at programming. For example, the "Grand Sorceress" would be "grand" because she had actually built a set of effective tools to use in the environment. One challenge here is to maintain the community aspects of the world while balancing it with motivating individual achievement and progress.

Role-playing learning experiences

One final idea that I find interesting as an extension of MOOSE Crossing is that of holding special events in a specialized virtual world. My model here is that of LARP (Live-Action Role-playing) games, in which participants are given a character with a background sheet before the event, along with some loosely defined goals based on the characterís personality. Then, during the game, players role-play their characters, interacting to create an imaginary world in which they can try out different social strategies and experience realities not always immediately available to them in their everyday lives.

Creating a virtual world to house these experiences would add various advantages, including: 1) opening them up to a global audience, 2) more consistent enforcement of the "rules of reality" for the virtual world, 3) the creation of imaginative scenarios for which it would be cost-prohibitive to create physical structures.

How can these experiences facilitate learning? One way to introduce learning into these experiences is to base the scenario on situations that require learning about some possible world. For example, a scenario might involve politics in the court of King Henry VIII, introducing players to historical facts in a very vivid way. Or, another scenario might involve on a space voyage, introducing players to the positions of the stars, the physics of near-light speed, the realities of negotiating with persons from different cultures, and so on.

With respect to the learning of programming specifically, the players could use MOO techniques to create innovative objects to bring into the game. They would need to have the opportunity to "debug" their objects in a test environment before the game started. They could also keep the objects for another game and discuss and/or trade objects with other players. Another possibility, of course, is to introduce programming as an activity in the scenario itself. For example, one has to program the computer to navigate the space vessel through a meteor shower.

Conclusion

In summary, I find the possibilities inherent in an Electronic Learning Community like MOOSE Crossing exciting. Being less of a "messing around" kind of person, however, I would enjoy more directed experiences in a virtual community setting. I have laid out several possibilities for motivating specialized experiences in such a setting, basing my ideas on my observations of what motivates people, both young and old, to use computers today.

My ideas for focusing the experiences in MOOSE Crossing may appear to be at odds with a pure Constructivist approach. However, what I am trying to propose is simply enhancement of the learnerís natural exploratory urges through situating the experience in ways that she might find exciting and motivating.