%!PS-Adobe-3.0 - Auburn University



Teachers as Simulation Programmers:

Minimalist Learning and Reuse

Mary Beth Rosson and Cheryl Seals

Department of Computer Science

Virginia Tech

Blacksburg, VA 24060 USA

+1 540 231 6470

{rosson, cseals}@cs.vt.edu

ABSTRACT

Five public school teachers were observed during two self-study sessions where they learned to use Visual AgenTalk (VAT). The first session emphasized the basic visual programming skills, while the second introduced ways to reuse existing simulations. Two versions of the reuse tutorial were developed, one offering a concrete example world for reuse, and the second an abstract world. During their learning and reuse sessions, the teachers thought out loud as they worked, enabling a detailed analysis of their goals, reactions, problems, and successes. After each session, the teachers also completed user reaction questionnaires. Although all teachers succeeded in learning the basics of VAT, they varied considerably in their reuse of the example simulations. It appears that the simplified components of the abstract world supported reuse to a greater degree than those of the concrete example world.

Keywords

simulations, visual programming, teacher education

INTRODUCTION

Visual simulation environments provide many opportunities for learning. Even quite young students can create worlds to test hypotheses, or to visualize ideas for sharing with others [5,16]. Older students can analyze, build, and debug sophisticated models that recruit basic laws of science or math [18]. A recent study indicates that students using simulations in math classes achieve more than those using a computer for drill and practice [25].

An assumption hiding behind the enthusiasm for simulation as a learning technology is that educators are able and willing to integrate simulation tools into their pedagogy. However, this assumption is rarely even discussed, much less examined; typically training and support for students doing the simulation programming is provided directly by the research team [9]. In fact, studies of technology adoption in education offer a rather pessimistic prediction; software developers have a long history of providing technology to educators that is never adopted or applied [22,23]. The research reported here examines some prerequisites for adoption of simulation as an educational technology, by investigating teachers’ ability and willingness to learn a modern visual simulation environment.

This research is part of a larger participatory design project developing and evaluating computer support for science education [3]. Our interactions with teachers in this project have made two things very clear: they have little time to spend on learning new technology, and they are unlikely to develop computer-based materials from scratch, preferring instead to adapt content built by others or by themselves in previous efforts. We took this as a strong requirement to provide minimalist self-study instruction [1], and to explore the possibilities for reuse within the simulation environment [8].

AGENTSHEETS AND VISUAL AGENTALK

Our study investigated the learning and reuse of Visual AgenTalk (VAT), the visual language provided by the Agentsheets programming environment [11, 13, 17]. In this environment, users build simulations by creating a set of interacting agents, where each agent has a visual depiction and a set of production rules guiding its behavior. Depictions are created with a simple bit editor, or filled by arbitrary bitmaps obtained from other sources.

VAT agent rules are an enhanced variant of graphical rewrite rules [12]. They are created by dragging in and editing conditions and actions stored in tool palettes. When the simulation is running, a rule fires if its condition is true (e.g., if an agent “sees” a specified agent in a particular position). A rule’s actions may include visible behavior by the agent, modification of internal variables, as well as a few operations on other agents (e.g., construction or destruction). Agents usually have an ordered list of rules; on any tick of the clock, the first rule whose condition is met will fire.

We chose to study VAT for several reasons. It is part of a longstanding research program, and has been shown to have promise in many different educational settings [4]. It supports programming by direct manipulation, which should make it more accessible to novices [13, 21]. It also includes a compiler that can convert VAT simulations to Java applets, enabling convenient sharing over the Web [14, 15]. All of these features make it very appealing as part of a vision in which teachers build and share their own visual simulations.

EXAMPLE-BASED LEARNING AND REUSE

The minimalist model of instruction has been used to guide development of self-paced training materials aimed at rapid progress on meaningful tasks [1]. Textual instructions and explanations are kept at a minimum, forcing learners to make inferences, which helps to connect the learning experience with prior knowledge. Instead of introducing component skills bit by bit, learners are exposed to realistic tasks from the start, but in the context of supportive tools and instruction that guide action, and support error recognition and recovery [7].

For complex learning situations such as programming, example-based materials can be used as the basis of effective minimalist training [20]. The examples are selected to be realistic instances of the concepts and skills being learned. Because of their realism the examples are relatively complex, so learners interact with them in a “spiral” fashion, first analyzing pieces of them, then returning to make modifications of increasing complexity, and finally working by analogy on a related problem. Our earlier work used this example-based approach for teaching Smalltalk; in this work we adapted the approach to build two example-based VAT tutorials, one teaching basic skills, and a second focusing on reuse.

Figure 1: The water cycle model used for learning.

Learning Materials

The learning tutorial is 12 pages long, including a one-page overview of Agentsheets that also reassures learners that programming skills are not required. The tutorial is based on a water cycle simulation (Figure 1), which includes sky as an inert background agent, along with ten other agents. White clouds move across the sky, and absorb water vapor. Water vapor is produced by lakes or puddles when they are hit by sunrays, produced at intervals by the sun. When the moisture level of a white cloud gets to a certain level, it transforms into a black cloud, which creates raindrops, loses moisture, and turns back into a white cloud. Grass loses moisture when hit by a sunray, but adds moisture when hit by raindrops. If it gets dry, grass will turn itself into desert (and vice versa). The transformation from lake to puddle and back is also a function of moisture content.

The learners first simply run the simulation, guided in analyzing what the agents are and what they do. They then examine individual agents. They make several water cycle modifications, first a simple one to change the sun’s depiction, then changing cloud movement. In the course of doing this, they investigate the rather complex behavior of clouds. They create a new agent (a bird), first making its depiction, then making it fly. Finally, they close the water cycle simulation and make their own project, a volcano, first by drawing and identifying component agents, then programming it. In keeping with the minimalist style, this final project is carried out with no explicit instruction, though learners can review material from their earlier work at any time.

The tutorial and the example are aimed directly at the programming concepts the learners must understand. But in any environment there are also interaction issues, for example the procedure for creating an agent, adding it to a worksheet, accessing the rule components, etc. These user interface features are a distraction from the conceptual content, so we moved instruction on these techniques to a two-sided Interaction Guide. This quick reference guide explains the meaning of the icons on the different windows, how to create and test rules, and summarizes the meaning of some of the most common condition and action components.

Reuse Materials

The reuse tutorial is 10 pages long. Learners review the water cycle model, although the nature and extent of this review is left open. It then introduces the concept of reusing material from one simulation to build another, first by asking the learner to think about analogies between a water cycle and a food chain, then asking them to build a food chain (as for the volcano, first by drawing and identifying agents, then building them). More specifically, the tutorial suggests that they create a lion that turns into a big lion after eating a sufficient number of rabbits.

During this task, learners are guided to study how a white cloud transforms into a black cloud in the water cycle, with the hint that the lion might work in the same way. In the water cycle, a white cloud increments its moisture variable each time it absorbs water vapor. After each increment, it does a “moisture check”, and if it has enough moisture, it erases itself and creates a new black cloud agent. Learners were given the additional hint that the lion should use a different variable (we suggested “full”).

Following this guided example of reuse, learners build an ocean world. This world is to have an ocean that produces waves; the waves should roll onto a beach, at which point they should become ripples. As part of this task, they are introduced to another example simulation, and are asked to try to reuse its agents when they work on the ocean world.

Two different versions of the reuse example were created, resulting in two slightly different reuse tutorials. One version offered an ozone simulation (Figure 2): factories produce chemicals which are transformed by sunrays into BrCl. When ozone is hit by BrCl, it loses density, eventually turning itself into a hole.

Figure 2: The concrete ozone world example.

The second example (starter world, see Figure 3) was isomorphic to the ozone world, with the same sorts of agents and functionality. The key difference was that the agents were generic components in an abstract world, and had images and names that evoked their abstract behavior: emitters create movers, which simply move to the right. A transformer converts a mover into a random mover. An eraser deletes a mover. When a mover encounters a changer, it converts itself into an eraser.

Figure 3: The abstract starter world example.

These two reuse examples were developed to explore the relative comprehensibility and usefulness of concrete, contextualized examples versus abstract examples. The former have the advantage of being connected to the real world, illustrating familiar phenomena, and including details of the sort expected in the target model. The latter have the advantage of simplicity, in that the “real world” usage context has been removed; the agents are also named directly for the behavior they exemplify. The developers of Agentsheets have argued that users will not want to work with abstract agents [8], but our prior work on example-based reuse in Smalltalk indicated that the concrete details of realistic usage examples often get in the way [19].

Learning and Reuse Sessions

Middle and high school teachers were participants. They were recruited for two sessions, and paid $25 for each session. We attempted to schedule the two sessions approximately two weeks apart, but in one case by request scheduled a single double period (with rest break).

Participants

Five teachers participated in the studies (henceforth P1-P5). Four had taught for 5-13 years; P3 was a new teacher. P1-P4 were science teachers, P5 taught math. All had some experience with Macintoshes; most also had PC Windows experience. Several had some exposure to programming (e.g., one course in Fortran) but had not programmed in years. Two had used Hypercard as part of their teaching activities. All expressed positive expectations about visual simulation as a teaching aid.

For the reuse sessions, we assigned the two different examples in an alternating order: P1 and P4 were given the ozone model to reuse, P3 and P5 the starter world (P2 was unable to return for a second session).

Procedures

Prior to the first learning session, each teacher completed a background questionnaire asking about teaching and computer experience, as well as expectations about visual simulations. The participant was then seated at a Macintosh computer in an observation room, where the tutorial and Interaction Guide were available. One experimenter sat several feet behind the learner, while another controlled the video equipment and observed through a one-way mirror.

The teachers were asked to think aloud as they worked. We described this as saying out loud what they were thinking, their goals and plans, and their reactions to what happened. We emphasized that the experimenter in the room was taking notes only, and that they should work on their own. The experimenters did intervene at times if a teacher became very confused: we first directed her back to the materials in general; if the problem persisted, we pointed to a specific element of the tutorial or screen that would be of help; finally if she was still confused, we simply told her what action to take.

We captured the Macintosh screen, a video of the teacher working, and think-aloud comments. We also made notes about the teachers’ behavior as they worked. These data and their work products are the sources of the qualitative analysis we present below.

After completing the learning tutorial, the teachers filled out a questionnaire. They described what was difficult or easy to do in VAT, whether and how they might use it in their classes, and how to develop a VAT model. After the reuse session, a similar set of questions were completed, but we also asked about their reuse of material, and what sorts of material they would like to reuse in VAT work.

LEARNING OBSERVATIONS

The participants spent from 55-88 minutes in their first session. All succeeded in making the changes to the water cycle; all of them also produced a volcano model, although volcano functionality varied from user to user (see Table 1). A sample volcano model (from P3) is shown in Figure 4: the lava makes new lava, and moves along the lava tube. If it sees the up tube, it moves into it. If the smoke sees lava, it moves up. The trees and fresh rock are inert.

Table 1: Summary of Learning Sessions

|ID |Time (min) |Volcano Agents Developed |

|P1 |88 |mountain, eruption, volcano |

|P2 |75 |mountain (inert), pressure, smoke, lava, sparks |

|P3 |65 |lava, lava-tube, uptube, fresh-rock (inert), |

| | |smoke, volcano, tree (inert) |

|P4 |80 |volcano, lava (2), smoke, rising-heat, |

| | |ground-level, plates-under-ground |

|P5 |55 |mountain, sparks, pressure, lava |

Figure 4: The volcano model produced by P3.

Many of the teachers’ learning problems can be traced to specific characteristics of VAT; some of these have beenreported in other empirical studies of Agentsheets [9, 10]. For example, all of the teachers had trouble with the direction parameter used in many conditions and actions. The rule snippet in Figure 5 shows how a cloud reacts to water vapor—the water vapor must be below the cloud, and the “cloudcheck” test is made at the current (center dot) position. The learners often forgot that they needed to specify a direction, or neglected to consider this as a problem when a rule failed to work as intended.

Figure 5: Sample rule with directional indicators.

Other VAT-specific problems included the use of the special “empty” condition to specify a contiguous empty cell in the grid (the system cannot “see” an unoccupied cell); forgetting to apply a rule update before trying a new rule; and leaving the simulation running while editing it.

A particularly vexing problem concerned the use of the “change” action, which can be used to alter the appearance of an agent. All of our users were attracted to this action, but for the wrong reason—they believed that they could use it to transform one agent into another. The visual feedback a user receives is consistent with this expectation; the original agent takes on the appearance of the second agent. But in fact the change is in look only; the agent’s identity remains the same and it has the same behaviors. Making the full transformation requires a combination action: first the original agent is erased, then the new one is created at the same grid position.

We observed other learning problems that have more general implications. For example, not all elements in a problem have discrete visual representations. When P1 first speculated about the concept of an agent, she equated it with a “factor”, for example a causal force like wind, gravity, or heat. During her volcano project, P5 said that “agents are objects that you can see”, but then noted “I’m not quite sure how to draw pressure, so I will make a symbol” (she sketched out a letter P). Perhaps a visual environment could encourage the modeling of invisible elements by providing a special “forces” layer of the worksheet, or force-annotations attached to visible agents.

Another problem stemming from the visual character of the simulation language concerns agent composition. In the volcano project, several teachers used a transparent overlay metaphor to model the volcanic eruption—a mountain was drawn, and then pieces of the explosion image were carefully drawn so as to fit “on top”, with lava down the side, and so on (Figure 6). VAT supports this overlay strategy; the unused space in a cell is transparent by default; agents can be superimposed to create a composite image. P2 impressed us with her ability to create such a visual overlay, carefully drawing agent depictions so that they would line up correctly. However, even though the visual display may look right, the rule engine only computes behavior for agents in the “top” layer. Thus although the visual composite seen in Figure 5 can be produced, it is impossible to implement any further interaction among agents occupying the same grid position.

Figure 5: A volcano built up through visual layers.

VAT is an object-oriented language (though without inheritance): agents are autonomous entities, instantiated and operating independently within a worksheet. It follows that each agent is responsible for its own behavior. Some of the teachers had trouble grasping this, for example opening the behavior of one agent when they intended to change aspects of another, or continuing to add rules to one agent’s behavior that were intended to produce the actions of another. This confusion may have been compounded by the fact that VAT agents can have some important effects on other agents, for example, creating or destroying an agent, or taking on its appearance.

During problem analysis and design, it is often unclear how to think about such relationships. For example, it seems quite reasonable for an ocean to create waves. But when the wave and the beach come together, is it the beach that converts the wave into a ripple, or should the wave transform itself? A related problem is the distributed thread of control typical of object-oriented systems. Particularly for the volcano problem, the teachers had a sequential plan, for example, P2 declared “first the lava moves to the right position, then the smoke goes up, ...”. But there was no place where she could write out that plan; instead she had to work agent by agent, and figure out how to get one agent to trigger the appropriate next step by another agent. The problem of designing and understanding distributed control structures is well-known in object-oriented design [25] and has led to the development of sequential design representations such as use cases and interaction diagrams.

In the user reaction questionnaire, all of the teachers were positive about Agentsheets as a learning technology, although several indicated they would need to learn more to feel comfortable with it in the classroom. All were able to provide a written description of how they would use the system to simulate a chemical reaction.

Table 2: Summary of Reuse Sessions

|ID |Time (min) |New Agents Developed |

|P1 |90 |Food chain: wolf, rabbit, big-foot (inert) |

| | |Ocean world: ocean, waves, beachsand, ripples |

| | |(inert) |

|P3 |65 |Food chain: lion, rabbit, sleeping lion (inert) |

| | |Ocean world: ocean, waves, beachsand (inert), |

| | |ripples, water (inert) |

|P4 |60 |Food chain: lion, rabbit (inert), big-lion |

| | |(inert) |

| | |Ocean world: ocean, waves, beachsand, ripples |

| | |(inert) |

|P5 |45 |Food chain: lake (borrowed), lion, rabbit, |

| | |big-lion (inert) |

| | |Ocean world: ocean, waves, beachsand, ripples, |

| | |water (inert) |

REUSE OBSERVATIONS

In general, the teachers worked more smoothly with VAT in their second sessions, having mastered many of the small details (e.g., creating new agents, adding rules) in the learning sessions. They spent from 45-90 minutes on this tutorial; all created both the food chain simulation and the ocean world, although again there was considerable variability in the end results (Table 2).

The teachers’ first reuse task was to build a food chain using the water cycle as a model, and in particular to use the cloud as a model for predator growth (see, e.g., the cloudcheck mechanism in Figure 5). All teachers accepted this as a reasonable goal, but the four individuals (P2 did not participate in this phase) solved the reuse problem in rather different ways.

P1 immediately grasped the conceptual similarities of water cycles and food chains, “both have cycles, both have products going up the chain, decomposition and so on.” But after looking at the cloud as a model for her predator, she dismissed it as too complicated, “OK, I’m just going to work from scratch.” P4 also was unable to reuse the cloud as an example, although she did copy over bits and pieces of the cloud’s rules, in a sort of trial-and-error process. In contrast, P3 and P5 quickly grasped the mechanism for tracking moisture content and were able to see how it mapped to a lion’s “fullness”; both used the cloud as a model. Ultimately, only P5 was successful in this; she took a highly systematic approach, copying the relevant rules over one by one, and adapting them to fit the food chain context. Thus although all four teachers produced a food chain with a lion that “got bigger”, only P5 made this change contingent on an internal variable. In hindsight, this is not surprising—although the teachers had studied the cloud before, this was the first time they had needed to work with variables.

The reuse efforts we observed during the food chain project illustrate five general strategies for reuse (Table 3). Two of the teachers described a high-level domain analogy—that these two “cycles” are similar. One teacher voiced a purely visual analogy, wanting to reuse the depiction for an existing agent for a new one (VAT supports this). Three of the four exhibited direct agent reuse, bringing the water cycle’s sky, grass, sun, clouds, and so on, into the background of their food chain. We found this interesting, because this introduced water cycle functionality into the food chain, even though it was not called for by the food chain problem (i.e.., the clouds produced rain, the grass become desert). One teacher worked in a highly opportunistic fashion, a strategy we have termed ad hoc analogy, browsing the rules of existing agents just to get ideas about conditions or actions that she could try out. This was generally unsuccessful, but did produce a benefit later on, when she recalled something she had seen working earlier. Two teachers worked with the suggested behavior analogy, attempting to adapt the cloud-absorbing-rain mechanism to the lion-eating-rabbits case.

The food chain project included explicit prompts for reuse: use the white cloud as a model for a lion eating rabbits. But for the second reuse task (ocean world), we gave no prompts, just the general advice to reuse material (from ozone or starter world) if useful. The teachers’ responses to this advice are summarized in Table 4, and reflect considerable variation. As the table suggests, the teachers working with starter world showed considerably more reuse than the two using ozone world. P1 did not even want to consider reuse until prompted (recall she had decided earlier to “work from scratch”). P4 did look carefully at the ozone agents, but did not return to them during her work. In contrast, both P3 and P5 used appropriate starter world agents as models for ocean world components.

Table 3: Reuse Strategies Observed During Food Chain Project

|Reuse Strategy |Description |

|Domain analogy |The problem domain is recognized to have a structural similarity to a problem domain for which there is |

| |already a solution, concepts are mapped from domain to domain |

|Visual analogy |A component is recognized as having the same appearance but different behavior as an existing component,|

| |so the depiction is reused to save editing time |

|Agent reuse |An entire agent is co-opted into a new problem as-is, even to the extent of accepting behavior from the |

| |old domain not needed in the new problem |

|Ad hoc analogy |Bits and pieces of rules (individual conditions or actions) are seen in working agents and tried out in |

| |the new problem to see if they might do something useful |

|Behavior analogy |A behavioral mechanism for one agent is used as a model for an analogous mechanism, either as a plan |

| |(the user follows the steps but creates her own code), or more directly by copying and editing the |

| |rules, to adapt them to the new context |

It is tempting to conclude from this that the starter world was more “reusable” than the ozone world. Recall that these models contained the same functions, but ozone illustrated this function within a realistic context. In her questionnaire, one starter-world user emphasized how she liked “seeing a model that was abstract—it opens possibilities for really abstract models”. The other said “I feel that I learned how to transfer behaviors to new modeling situations to build on previous models.” In contrast, the teachers using ozone world remarked “I copied some of the patterns, colors” and “I found it easier to create new ones.”

Table 4: Reuse During Ocean World Project

|User |Individual Approaches to Example Reuse |

|P1: |- examines Ozone agents only after request made |

|Ozone |- developed ocean agents entirely from scratch |

|P3: |- carefully examines Starter agents |

|Starter |- models wave on mover, first models ocean on changer, but |

| |later decides emitter is a better model |

|P4: |- carefully examines Ozone agents |

|Ozone |- but develops Ocean World from scratch, “I found it easier |

| |to create new ones-a bit less confusing” |

|P5: |- never examines Starter agents, able to infer behavior |

|Starter |correctly just from names and testing |

| |- voices relations, “an ocean that makes waves would be |

| |similar...an ocean might be the emitter” |

| |- explicitly models ocean on emitter, wave on mover, and |

| |beach sand on transformer |

However, these findings must be qualified by the small number of teachers studied, and by their individual differences. The teachers who used starter world (we used an alternating assignment heuristic), happened to be the two who seemed to best appreciate the concept of reuse; these were the two who seemed to recognize and benefit from the analogy between the cloud and the lion in the food chain. Thus we see our findings as intriguing but requiring of further study.

DISCUSSION

The teachers were able to learn VAT from the self-study materials—in 55-90 minutes, they analyzed and modified a sample simulation, and created their own from scratch. In a second session, they built two new simulations, reusing sample materials to varying degrees. General reactions to VAT were positive; all agreed that they could imagine a role for VAT in their own classes. Thus in general we are encouraged about the prospect of teachers incorporating visual simulation programming into their pedagogy. However, our results also have a number of implications for how best to support this.

Teachers as Simulation Builders

Teachers possess considerably more science expertise than students; this was quite evident in these teachers’ work. We saw many cases of frustration where a teacher knew exactly what she wanted to model, but couldn’t map this onto the VAT computational model. For example, P1 specializes in Earth Science, and her analysis of the volcano problem was accordingly quite sophisticated. Moving from her rich understanding to a simpler version implemented by a few same-sized interacting agents was hard. Researchers have noted that young science students can use an environment like VAT but often lack domain knowledge about a problem’s elements and interactions. As a result, students may be satisfied to build an animated visual display that simply “looks right” [6]. In contrast, teachers may in a sense know too much—to fully transfer their elaborate mental models, they would need a general-purpose programming language and skills.

One possibility is to address this with instruction. An example-based tutorial could present different simulations of the same phenomenon, but with variation in coverage. This might help to set up the expectation that a range of useful models can be generated from simplified problem analyses. Or the tutorial might attack this issue more directly, describing the sorts of mechanisms that are easily modeled (and not). The problem with the latter approach is its conflict with a minimalist hands-on approach to learning; explanations such as this would need to be crafted to require as little reading as possible.

It was interesting to see that many of the problems the teachers experienced appear to be variants of issues discussed for many years in the literature on object-oriented design and programming [19,20]. Analyzing and assigning responsibilities, determining how the agents should collaborate, developing and implementing an overall thread of control—all of these are general problems when working with networks of interacting objects. It may be that environments like VAT can benefit from the work on design representations and tools developed for professional programmers using more sophisticated and general object-oriented languages and environments [20].

Example-Based Learning of VAT

All of the users were able to understand the water cycle example enough to learn VAT basics—the concepts of agents and rules, what goes into a rule, how to change rule parameters, how actions can be combined, and so on. However, as we observed during the reuse sessions, certain aspects of the cloud’s behavior were simply too complex for some of these new users. The cloud is a rich example; it illustrates many of the concepts we were trying to convey. But this means that it combined a number of different kinds of rules; it was certainly a bit intimidating on first encounter: “this is like a math equation!” (P1).

There is always an inherent tradeoff in providing examples that are complex enough to be realistic, but simple enough for novices to understand [2]. We opted for realism in this case, but perhaps should have included more scaffolding in the example’s presentation. For instance, we presented a comprehensive description of the cloud’s behavior in one spot. We could easily have broken this into sections. In particular, we could have offered an analysis of the moisture-tracking mechanism at the point that users were attempting to use it as a model in their food chain projects.

In some cases we did simplify at the expense of realism: the cloud agent in the water cycle keeps track of its moisture; when moisture gets to a certain level, it transforms itself into a new agent (a black cloud) with new behavior. A more realistic model might be a cloud agent that just changes its appearance as its moisture increases. But such behavior would be more complex, because it would have more rules and checks, and everything it does would be contingent on an internal variable. We elected to modularize the two different sets of behavior (for the cloud as well as for other agents such as grass and water) to make the example code easier to understand. As a side benefit, this departure from the real world situation allowed us to illustrate the general strategy of agent “transformation”.

Other issues for example-based learning might be addressed by changes to the environment. We noted that the teachers had a continuing difficulty in managing the many small windows in VAT (one for each behavior, the depictions, the worksheet, etc.). But a particular problem we saw was a tendency to confuse the programming resources (the condition and action palettes, the example being used as a model), with the project underway. We have seen similar problems in the Smalltalk development environment. In the Smalltalk environment, experts often develop elaborate house-keeping strategies, using screen space as an organizing rubric for multiple related activities. In work on reuse tools, we attempted to ease this problem by creating a special documentation-oriented browser onto resources that was visually distinct from the editing area [19].

Moving the interaction techniques out of the tutorial sequence worked well. Users did not always remember to check the Interaction Guide, but when they did, they usually found what they needed. Nonetheless, learning the details of the VAT direct manipulation techniques consumed considerable time. Although this was not the focus of our research, a study such as this also provides valuable feedback for ongoing enhancements to the VAT environment and interaction techniques.

Reuse in Visual Simulation Programming

Our findings are also quite promising with respect to teachers’ willingness and ability to reuse example code in their own work. Only one teacher rejected the general notion of reuse, and she was the one having most difficulty with VAT in general. Two of the users seemed to understand just what to do, although they succeeded to varying degrees. We believe that with the right kinds of reusable materials, teachers would be able to build a variety of custom simulations with reduced effort.

Our preliminary findings indicate that abstract agents such as in starter world may be more reusable than the concrete agents of realistic simulations like ozone world. This may be due to simplified semantics—a transformer simply sees one agent and converts it to another, whereas a sunray is a catalyst in a chemical reaction. Indeed P3 said directly that it was the abstraction that she liked in the reuse task. But it may also be that the abstract names were more useful in planning. To reuse factory, a teacher must recognize its reusable parts (it sends out things, in this case chemicals), and then map this to her needs (e.g., an ocean making waves). P5 certainly seemed to benefit directly from the abstract names, to the extent that she did not even need to look at each agent’s code to understand its reuse potential.

The usefulness of the abstract agents is particularly interesting in light of previous discussions of reuse in Agentsheets. Perrone and Repenning argue that end-users do not want to worry about abstract classes that might be specialized to create the agents they need [8]. Instead they propose an analogy mechanism, in which a user goes through a dialog of the sort “a on a is like a on a ”, where the train already has rules to run along a track, and the car is given analogous rules for running on the road. Such reasoning is in fact just what the teachers were exhibiting when they reused the cloud rules, or the starter world agents. However, our position is that these analogies can be just as obvious for abstract agents (e.g., “a on a is like a on a ”). As long as the reusable component can be instantiated and tested, making an agent generic may make it more accessible, as well as making it useful in a broader range of problem situations.

More broadly, the reuse study suggests that end-users may benefit from a pool of aptly-named abstract agents, that they can browse and use as models for the concrete behaviors needed in their domains. This is reminiscent of the prototype paradigm for object-oriented programming (e.g., Self [24]). Of course end-users are unlikely to take the time to create abstract agents such as these on their own; this is a challenge for the developers of languages such as VAT. Many questions remain: At what granularity should such components be built? How should the reusable components and interactive environment be organized to facilitate comprehension and application? Can end-users compose simple models (“mover”, “transformer”) into the more complex behavior needed by other problems? We are currently building more extensive libraries of abstract agents that will allow us to answer questions such as these.

ACKNOWLEDGMENTS

This work was supported by NSF REC-9554206. We are grateful to research assistants Nathan Hamblen, Helena Mentis, Stephanie Peppard, the five teachers, and the Agentsheets research group at the University of Colorado.

REFERENCES

[1] Carroll, J.M., The Nurnberg Funnel: Designing Minimalist Instruction for Practical Computer Skill, MIT Press, 1990.

[2] Carroll, J.M., and M.B. Rosson, “Deliberated Evolution: Stalking the View Matcher in Design Space”, Human-Computer Interaction 6, 1991, 281-318.

[3] Carroll, J.M, et al, “The LiNC Project: Learning in Networked Communities” Learning Tech., 2, 2000.

[4] Cherry, G. et al., “Simulations for Lifelong Learning”, paper presented at NECC’99, Atlantic City, NJ, 1999.

[5] Gilmore, D.J., et al., “Learning Graphical Programming: An Evaluation of KidSim”, INTERACT’95: Proceedings of the 5th IFIP Conference on Human-Computer Interaction, Chapman Hall, London, 1995.

[6] Lewis, C., et al., “Models Children Build: Content, Logic and Educational Impact”, National Association for Research in Science Teaching, Chicago, IL, , 1997.

[7] Meij, H. van der, and J.M. Carroll, “Principles and Heuristics for Designing Minimalist”, Technical Communication, 42, 1996, pp. 243-261

[8] Perrone, C., and A. Repenning, “Graphical Rewrite Rule Analogies: Avoiding the Inherit or Copy & Paste Reuse Dilemma”, Proceedings of VL 1998, Nova Scotia, Canada, Computer Society, 1998, pp. 40-46.

[9] Rader, C., C. Brand, and C. Lewis, “Degrees of Comprehension: Children’s Understanding of a Visual Programming Environment”, Proceedings of CHI 97, Atlanta, GA, ACM Press, 1997, pp. 351-358.

[10] Rader, C., et al., “Designing Mixed Textual and Iconic Programming Languages for Novice Users”, Proceedings of VL 1998,, Computer Society, 1998, pp. 187-194.

[11] Repenning, A. “Programming Substrates to Create Interactive Learning Environments”, Journal of Interactive Learning Environments, 4(1), 1994, pp. 45-74.

[12] Repenning, A. “Bending the Rules: Steps toward Semantically Enriched Graphical Rewrite Rules”, Proceedings of VL 1995, Darmstadt, Germany, Computer Society, 1995, pp. 226-233.

[13] Repenning, A., and J. Ambach, “Tactile Programming: A Unified Manipulation Paradigm Supporting Program Comprehension, Composition and Sharing”, Proceedings of VL 1996, Computer Society, 1996, pp. 102-109.

[14] Repenning, A., and J. Ambach, “The Agentsheets Behavior Exchange: Supporting Social Behavior Processing”, CHI 97 Extended Abstracts, ACM, 1997.

[15] Repenning, A., et al., “Using Agents as a Currency of Exchange between End-Users”,Proceedings of WebNET98, AACE, 1998, pp. 762-767.

[16] Repenning, A., A. Ioannidou, and J. Phillips, “Collaborative Use and Design of Interactive Simulations”, CSCL Proceedings, Stanford, CA, 1999.

[17] Repenning, A. and T. Sumner, “Agentsheets: A Medium for Creating Domain-Oriented Visual Languages”, IEEE Computer, 28(3), 1995, pp. 17-25.

[18] Resnick, M., A. Bruckman, and F. Martin, “Constructional Design: Creating New Construction Kits for Kids”, The Design of Children’s Technology, Morgan Kaufmann, 1998, pp. 149-167.

[19] Rosson, M.B., and J.M. Carroll, J.M., “The Reuse of Uses in Smalltalk Programming”, ACM Transactions on Computer-Human Interaction, 3, 1996, pp. 219-253.

[20] Rosson, M.B., J.M. Carroll, and R.K.E. Bellamy, “Smalltalk Scaffolding: A Case Study in Minimalist Instruction”, Proceedings of CHI’90, New York, ACM, 1990, pp. 423-430.

[21] Shneiderman, B., “Direct Manipulation: A Step Beyond Programming Languages”, Computer, 16, 1983.

[22] Soloway, E.,. “Log on Education: No One is Making Money in Educational Software”, Communications of the ACM, 41(2), pp. 11-13, 1998.

[23] Tyack, D., and L. Cuban, Tinkering Toward Utopia: A Century of Public School Reform. Boston, MA, Harvard University Press, 1995.

[24] Ungar, D., and Smith, R.L. “Self: The Power of Simplicity”, Proceedings of OOPSLA’87, Orlando, FL, ACM, 1987, pp. 227-241.

[25] Wirfs-Brock, W. Designing objects and their interactions: A brief look at responsibility-driven design. In Scenario-Based Design: Envisioning Work and Technology in System Development. John Wiley & Sons, New York, 1995, pp. 337--360.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download