Social Behavior Processing: Stepping-Stones between the Use and
Design of Behaviors
Alexander Repenning
Center of LifeLong Learning & Design
University of Colorado
Boulder, Colorado, 80309
CONTEXT
Our research is concerned with the exploration of new programming paradigms supporting end-users to build interactive SimCity™-like simulations and export them as Java applets and JavaBeans. In the context of the AgentSheets framework we have designed and implemented a number of programming mechanisms used to process behaviors including:
• Graphical rewrite rules allowing users such as kids to define behaviors by demonstration as before/after rules (AgentSheets, KidSim, Cocoa)
• Programming by analogy allowing users to create behaviors by making simple analogies such as "A car follows a road like a train follows train tracks." Programming by analogy is helpful as behavior reuse mechanism. Analogies avoid some of the problems found in OOP inheritance.
• Rule-based functions (LEGOsheets) allowing users to define the behavior of programmable LEGOs brick by establishing rule-based, functional relations similar to spreadsheets formulas.
• Tactile Programming allowing users to design incrementally, to use, test, modify, package and exchange behaviors as members of a community.
POSITION
Behavior descriptions cannot be entirely reduced to formal models but need to take into account the social context of using and designing behaviors. Social behavior processing requires that behaviors become tangible entities that can comfortably be exchanged, inspected and modified. A crucial issue of social behavior processing is to build stepping-stones between the Use and the Design of behaviors.
Below is a list of products/projects/initiatives that can be viewed as the stepping stones between the Use and the Design of interactive simulations. Level 1 is almost entirely about Use, level 5 is about Design.
1 Shrink-Wrapped Simulations: SimCity
Shrink-wrapped packages such as SimCity™ are highly interactive simulations aimed primarily at entertainment, rather than education. A simulation such as SimCity can be used for a number of reasons. For instance one goal could be to build the largest possible city by balancing taxes, crime rate, pollution and many other factors. However, the general lack of programmability is a major limitation of SimCity and similar packages. That is, there is no end-user design. These simulations have a single format and structure; they cannot be adopted to the needs of individual users.
2 Applet Repositories: EOE
Community repositories are collections of simulations and other interactive educational objects. The Educational Object Economy, EOE (
http://www.eoe.org), is a collection of educational Java applets. We are a founding member of the EOE organization and are a member of the NSF funded East-West Consortium that explored educational authoring tools and models of collaborations between industry, academia and publishers. Educational objects in the EOE are annotated with meta information that categorizes objects in terms of subject domains, and includes information on how to use the object.Use at this level consist of the locating and selection of relevant education objects. Design is very limited. EOE objects include Java source code allowing professional programmers to re-design objects by modifying their program. However, the adaptation of educational objects in the EOE requires the mastery of general Java programming environments; these skills are not common among most students and teachers.
3 Component Repositories: ESCOT
The Educational Software Components of Tomorrow (ESCOT, http://www.escot.org) project can be considered a conceptual extension of the EOE work. We are working with SRI International under the NSF-funded ESCOT project. ESCOT explores technical mechanisms and cognitive models that let people efficiently combine components based on Sun’s JavaBeans technology. In contrast, the educational objects in the EOE were created in isolation; there was no way to combine objects into more meaningful units. As ESCOT proceeds, users will be able to combine simulations built in AgentSheets with other software to obtain, say, the plotting functionality of SimCalc. In the case of an AgentSheets eco-system simulation, students could track the number of individuals of each species in SimCalc to explore issues of Eco system sustainability and other concepts.
Existing tools at the component level of design are crude, but more accessible than EOE programming tools. The ESCOT project focuses on finding new ways to simplify the design process by letting students and teachers assemble components.
4 Sub-Component Repositories: Behavior Exchange
The Behavior Exchange is an AgentSheets specific sub-component repository (
http://www.agentsheets.com/behavior-exchange.html). The Behavior Exchange allows users to exchange individual simulation agents. For instance, in a city simulation people can exchange agents such as cars, roads, trains, and factories. Agents downloaded from the Behavior Exchange are "glass boxes" that can be readily opened up to inspect their rules and modify their behavior. Modified agents can be uploaded again to the Behavior Exchange. This mechanism allows a community of users to build and incrementally improve simulation content.This ability to build simulations by combining and modifying agents makes the agent level ideal for supporting scaffolding.
5 Simulation Component Authoring Tool: AgentSheets
Agentsheets is a simulation-authoring tool that allows non-specialists to build complex interactive simulations. Simulations are based on communicating embodied agents organized in a grid structure. The behaviors of agents are defined as IF/THEN rules mapping agent’s sensory input (including mouse buttons, keyboard, web pages content) to output (animations, sound, speech, MIDI music, color).AgentSheets programming approach supports the design of complex behaviors by end-users such as elementary school kids. Once behaviors have been defined simulations can be turned into complete Java applets or JavaBeans.