In November of 1996, Apple Computers released its first version of Cocoa, a simulation program for children.  Now in its second release, Cocoa is used by thousands of children across the world.  Although the Cocoa Web site describes the software as a simulation toolkit, it could be described just as well as a microworld.  Simulation environments are very similar, if not identical, to microworlds (Edwards, 1995).  Cocoa, like Logo, provides a limited set of tools for designing a world.  Beside these limited tools, there is simply an empty slate.  Thus, it is the user's responsibility to actively construct a world, as a means for learning about it.

Cocoa provides the following features: the ability to create an object, the ability to change the appearance of an object, the ability to assign a rule to one or more objects, and the ability to simulate the interaction of these rules.  An object is simply an icon, or small picture on the screen, that can be moved by the mouse or according to some rule.

The presence of objects is not unique to Cocoa.  In fact, Cocoa objects are, in a sense, a more restricted version of a Logo turtle.  However, all that Cocoa objects can do is move and interact.  Moreover, Cocoa is limited to objects--the entire microworld is made up of a system of objects.  In contrast, Logo includes features such as buttons, line drawing, imported pictures, and text objects.

Each Cocoa microworld is contained in what is called a board, which is the empty slate on which the world can be created.  The board is simply a grid where each square of the grid corresponds to a possible location of an object.  Objects can move from one cell to another.  To create a microworld, a user starts Cocoa and then selects "New World" from the File menu.  This brings up an empty board.

Cocoa's uniqueness is in the way one tells objects what to do.  In Logo, a turtle can be moved by typing in commands such as "FD 20" to move the turtle forward 20 spaces or "RT 90" to turn the turtle right 90 degrees.  In Cocoa, an object is moved by setting up a scenario and creating a "graphical rewrite rule" for it.

To understand how Cocoa rules work, it is easiest to use the most basic example: making an object move from left to right.  This can be accomplished by the following steps:  After making an object and placing it on the board, the user uses the Rule Record Tool to select an object.  Upon selection, a dialog box appears which shows a graphical representation of a rule for the selected object.  The left-hand side of this dialog box, the "before" situation, is the state of the objects before the rule is applied.  The right-hand side of the dialog box, the "after" situation, notes the state that the objects will be in after the rule is applied.  When the simulation starts, Cocoa matches what is on the board with all of the before cases it knows for that object.  If one of the before cases applies, it will change the board according to the corresponding "after" picture.

When the dialog box first appears, the before picture is the same as the after picture.  This is because the user has not yet modified the after state.  To make an object move right, the user can click on the "handle" on the right side of the object and drag it over one cell.  This action creates an empty cell next to the object to which the object can move.   After dragging the handle over one cell, the before and after picture now show two cells of the board with the left cell containing the object and the right cell being blank.  The after picture must now be changed.  The user can drag the object from the left cell of the after state to the right cell of the after state.  Now the after picture shows two cells with the left cell being blank and the right cell containing the object.  This rule will now be applied every time there is a blank space directly to the right of the object, and will result in the object moving into that blank space.  As long as there is one blank space to the right of the object, the object will continue to move.

Other types of rules are created in a similar fashion.   The above example involved only an object and a blank spot, but it is possible to add a rule for when two different object meet each other.  The user simply needs to set up this scenario by dragging the two objects to adjacent cells, clicking on the cells with the Rule Record Tool, and modifying the after picture to represent an outcome.  It should be noted that rules can have multiple parts.  That is, Cocoa remembers each change the user makes to the after side of the rule.  If you drag the object up and then to the right, Cocoa will simulate both of these moves when applying the rule.

In other words, Cocoa uses the concept of "programming by demonstration."  If a user wants an object to move right, he or she simply drags the object to the right.  The software is able to remember what the user demonstrated and to play it back when necessary.  This is much different from other programming techniques.  In Logo, to make the turtle move, the user must type in a text command.  There is no way to drag the Logo turtle from one place to another and have Logo repeat the drag multiple times, like one can do with an object in Cocoa.

Since this software is based on objects and interaction of objects, it is ideal for modeling systems.  Papert points out that understanding systems, such as biological systems or environmental systems, is very important to learning (Papert 1992).  Modeling an ecosystem with Cocoa is easy.  For example, a sun object and a plant object can be created.  The sun can be programmed to move back and forth.  The plant can be programmed to grow each time the sun moves over the plant.  Further, a frog object and a bug object can be created and programmed to move around in random directions.  When a bug comes in contact with the frog, the frog eats the bug.  There are many other simulations that are easy to do in Cocoa, such as cell systems and kinetic energy.  In fact, there is a limitless number of systems that could be modeled.

Children can learn a lot from creating systems using Cocoa.  However, this type of learning is much different from what takes place in most school settings.  Papert explains that "…rather than stifling the children's creativity, the solution is to create an intellectual environment less dominated than the school's by the criteria of true and false" (Papert 1980, p.133).  Using Cocoa, there is not simply one correct way to make an ecosystem.   It is during the creative process that learning takes place.

Although Logo could probably be programmed to do all the simulations possible with Cocoa, there are many advantages to Cocoa.  The main advantage is that a novice user can program complicated simulations.  Papert pointed out that "the powerful ideas and the intellectual aesthetic of physics is lost in the perpetual learning of 'prerequisites'" (Papert 1980, p. 122).  The same analogy can be made to computer programming.  In order to learn how to program, one must learn to read, write, understand symbolic meanings of special characters, and memorize a set of basic functions.  Cocoa's graphical user interface eliminates many of these prerequisites.   Instead of typing out a program using "if-then" statements, a child can simply create a scenario of what might happen by dragging objects using the mouse.  In this sense, manipulating objects is more like the real world: if one wants an object to be moved, he or she simply moves it.  Papert explains this notion clearly in saying that children "learn to transfer habits of exploration from their personal lives to the formal domain of scientific theory" (Papert 1980, p. 117).

It would take an advanced user to model an ecosystem in Logo or in most other computer languages.  Cocoa is very successful in giving children the tools for creating a complex system of objects without the complexity of programming it.   When the "overhead" of programming is eliminated by making the interface simple, what is left is logical thought.  It is no longer an issue of how to make rules--it becomes a matter of what rules are necessary.  Perkins calls such an environment a "phenomenarium" for just this reason.  He describes an environment like Cocoa as "an area for the specific purpose of presenting phenomena and making them accessible to scrutiny and manipulation" (Perkins 1991, p. 19).  A child must predict all possible situations that might occur.  A younger child may accomplish this by trial-and-error, incrementally adding rules when he or she realizes the need for them.  Older children may be able to conceptualize all scenarios abstractly.  Fischer and Pipp explain that children are able to understand a system, in this case a system of rules, as early as age 6½ or 7, but are not able to understand them in an abstract sense until many years later (Fischer & Pipp, 1984).

Further, for novice programmers, Cocoa introduces the notion of randomization.   Randomization is a fundamental attribute of an ecosystem, since animals move around in unpredictable ways. Children are able to explore what happens when objects move around in random fashion.   The computer may generate a scenario that a child had not yet thought of.  In this sense, Cocoa is successful in being a "phenomenarium" as Perkins describes.  Randomization can be considered a "powerful idea" as Papert describes (Papert, 1980).  Learning about randomization is not about facts, but rather it is a powerful concept that can be applied to many other complex situations.

Another powerful feature of Cocoa is the ability to turn objects into clickable hyperlinks to other boards.  In this sense, Cocoa worlds can be made into a form of hypermedia.  This allows users to interact with the simulation and to move from one simulation to another.  Cocoa provides some advanced tools for doing this, including the ability to add mouse and keyboard events as rules for an object.  For example, Cocoa allows the user to add a rule for when the mouse is clicked on an object.  Such a rule could change the appearance of the object, or in the case of hypermedia, it could cause the program jump to another board.  The interactive nature of hypermedia, along with the ability to use the mouse and keyboard to control objects, make Cocoa a very powerful tool for learning.

Thus, Cocoa can be a very useful tool in classrooms.  There are clearly many things that can be taught better using a simulation toolkit like Cocoa than with a pen and paper.  The best example of this is clearly understanding biological or ecological systems.  However, there are many mathematical applications such as number theory and counting which can be simulated very easily with Cocoa.  Imagine how much easier it would be to learn Roman numerals if one could create a microworld that manipulated and added them?  Further, since computers are becoming more commonplace, it is necessary for children to understand the basics of computer programming and user interfaces.  Cocoa can certainly develop these skills.

Teaching children how to use Cocoa should be done incrementally.  First, children should master being able to add a rule which makes an object move from left to right continuously.  Then, children can learn how to add a rule for the interaction of two objects.  Next, children can introduce a third object and create compound interactions.  Finally, advanced concepts can be added including randomization and mouse and keyboard events.

Cocoa is an ideal supplement to the current school curriculum.  Since there are many different learning styles, reading and writing do not always bring about an understanding of something.  Cocoa would be best suited for a spatial or visual learner, and also for a logical-mathematical learner.  However, the process of creating a microworld using Cocoa can benefit any type of learner.

While Cocoa makes it easy to understand how systems work and helps to develop logical thought, it makes it difficult to understand what is really going on in the computer.  That is, the attractive graphical user interface hides the actual operations and actions that the computer is doing to simulate the system.  This is because Cocoa is conceptually "opaque."  There is a trade-off between usability and transparency.  Papert believes in trying to understand how something functions, children suffer greatly from not being able to see the innards of something. (Papert 1996).

For the most part, it is an advantage of Cocoa that it uses graphical rewrite rules.  However, problems occur when more than one rule applies at a given time--Cocoa applies rules nondeterministicly.  That is, it is not made clear to the user which rule will be applied first if two rules apply.  Consider the example of a Cocoa world which can sort numbers.  Say there are three objects on a board, one representing the number one, one representing the number two, and one representing the number three.  Then say that the objects are placed in reverse order on board.  Assuming that objects can only be interchanged with a neighbor, it is clear that at last three swaps need to be made to sort these numbers into ascending order: the one must be moved before the two, the one must be moved before the three, and the two must be moved before the three.  But in which order do these rules get applied?  In this example it does not really matter which order the rules are applied because the numbers will get sorted regardless.  But what if the simulation depended on a precise order for rules to be applied?  It can often be problematic to not have total control over the simulation.

However, nondeterminism is not the only limitation of Cocoa.  While graphical rewrite rules are more easily created, they are harder to debug.  Papert maintains that errors in computer programs "benefit us because they lead us to study what happened, to understand what went wrong, and, through understanding, to fix it" (Papert 1980, p. 114).  In most computer languages debugging can be a very rewarding experience.  In Cocoa, however, it can be daunting.  In some cases it is easier to erase the rules for a given object and start over.  The difficulty in debugging could be due to several factors: the lack of subroutines to isolate problems, the nondeterministic nature of the rule application, and the inability to "print out" information as a means for feedback.  That said, Cocoa still serves as an introductory tutorial in computer programming.
It is possible that despite Apple's attempt to make Cocoa as easy to use and as user-friendly as possible, some may still find it difficult to use.  The reason for this might just be its uniqueness and originality.  People might have difficulty learning how to use it because it is so different from other software they have used before.  Also, Cocoa might rely too heavily on spatial ability.  Cocoa tried to eliminate the need to use text to program, making it a so-called "language-less" environment.  In fact, there isn't even a tool for adding text to the board.

Cocoa's simple interface and powerful tools make it a very educational environment for children.  Despite its minor limitations, Cocoa succeeds in being a fun and intellectually stimulating environment while also helping children to understand powerful ideas.  Like Logo, Cocoa has many applications beyond computer programming, and can enhance the curriculum in almost any area of learning.  Children are able to "learn by doing" and to think about learning.  In making a simulation, children must learn not only to understand the world for themselves, but also to present the world in such a way that other people can understand it and learn from it.



Bibliography

Edwards, L. (1995). "Microworlds as Representations." Proceedings of the 2nd International NATO Symposium on Advanced Technology and Education.

Fischer, K. & Pipp, S. (1984). "Processes of Cognitive Development: Optimal Level and Skill Acquisition." Mechanisms of Cognitive Development.  Edited by R. Sternberg. Waveland Press.

Papert, S. (1980). Mindstorms. Basic Books.

Papert, S. (1992). The Children's Machine: Rethinking Schools in the Age of the Computer.  Basic Books.

Papert, S. (1996). The Connected Family.  Longstreet Press.

Perkins, D. (1991). "Technology Meets Contructivism: Do They Make a Marriage?" Educational Technology. May 1991.