MOPed

MOPed [Ohmaye 1992] is a GBS tool that was initially used to build a system for Andersen Consulting called ``Dustin.'' It allowed non-native English speakers to find out what it would really be like to come to the United States for corporate training. Students typed interactions with on-screen people such as customs officers, hotel staff, and waitresses. The people would react in video to whatever the student said, and if the student made mistakes (such as misunderstandings or insults), the tool would provide guidance.

MOPed was based on work in [Schank 1982], where the basic unit of representation is the Memory Organization Packet (MOP). Each MOP is essentially a flowchart for student interaction--it can show a movie, recognize speech, show an expert story, etc. Nodes in the flowchart can be other MOPs, which lets the representation be scalable and flexible.

  

Figure: A typical MOP graph. From [Ohmaye 1992].

64#64

The interaction moves along the lines in the graph in Figure 7.5 roughly from left to right and top to bottom, although that is a convention enforced only by the author. To build each of Dustin's 16 scenarios, authors individually wired each response, teaching point, and question together.

Important points about MOPed relevant to INDIE are:

• MOPed was a response to an author need--before MOPed authors would construct these graphs with Post-It notes on a whiteboard and draw lines between them. Once they had settled on a flowchart, they would translate it into dense LISP representations, much as INDIE 1.0 required authors to construct their interface and critiquing and then translate it into LISP macros in a text editor.

• MOPed forced authors to explicitly link everything in these graphs, which is good because authors were then very sure of the course of the interaction, but bad because it reduced the overall efficiency of the tool--authors' work scaled linearly with the amount of interaction they want to add. We saw in Chapter 6 that this is not the case for INDIE.

• MOPed generated a model for a GBS, but anything more than a simple default interface was left up to programmers. Although it wasn't hard to build these interfaces for programmers, it was still quite time-consuming.

INDIE could use some of the explicitness MOPed provides for constructing interactions that branch little, such as when students are in the process of running a test with a piece of equipment that is somewhat complex. If we could delineate the areas of INDIE that were more procedural (and still pedagogically important, e.g. experimental procedures), a representation in a tool like MOPed might be useful.