Making programming easier for children

u

-I -I

I .I. .

interactions.. . September + october 1996

__~ _---__I----- - --IT-- ;‘- : ).. _- .

A conceptual gap exists between the

representations that people use in their

minds when thinking about a problem and

the representations that computers will

accept when they are programmed.

For most people, this gap is

as wide as the Grand Canyon.

interactions.. . September + october 1996

,_-_ -_ _-.

David Canfield Smith,

Allen Cypher,

Kurt Schmucker

Apple Computer, Inc.

1 Infinite Loop

Cupertino, CA 95014

http://wwwatg.apple.

corn/Allen-Cypherl

Cocoa/

Introduction During the past 30 years there have been many attempts to enable ordinary people- people who are not professional programmers-to program computers. Researchers have invented languages such as Logo, Smalltalk, BASIC, Pascal, and HyperTalk. They have developed techniques such as struc- tured programming. They have approached programming from a pedagogical perspective with technology, such as the goal-plan editor, [17] and from an engineering perspective, with CASE tools. Each of these is a brilliant advance in its own right. Today, however, only a small percentage of people program computers, probably less than 1 percent. A single- digit percentile is not success.

We believe that there are at least two rea- sons for this low rate. First, traditional programming forces someone to learn a new language. Learning another language is diffr- cult for most people. Consider the years of effort that it takes to master a foreign language. Second, programming languages are artificial languages rather than natural languages. They have a different epistemology. They deal with the unfamiliar world of computer data structures and algorithms. This makes them even less tractable for novices.

The solution is to make programming more like thinking. In this paper we will show how a research project at Apple Computer has attempted to do this for children’s programming. The key ideas are to use representations in the computer that are analogous to the objects being represented and to allow those representations to be directly manipulated in the process of programming.

The “Grand Canyon” Conceptual Gap We define an “end user” as someone who uses a computer but is not a professional programmer. Most end users have never taken a programming class. They use computer programs written by others.

The central thesis of this paper is that a conceptual gap exists between the representations that people use in their minds when thinking about a problem and the representations that computers will accept when they are programmed. For most, this gap is as wide as

the Grand Canyon. Norman [lo] calls it the “gulfs of execution and evaluation.” He notes that “there are only two ways to . , . bridge the gap between goals and system: move the system closer to the user; move the user closer to the system” (p. 43). For programming, this translates into either teaching people the computer’s epistemology (i.e., teaching them to think like computers) or teaching computers to accept representations that people find con- venient.

People who are not trained programmers have great difficulty in “moving closer to the system.” They have tried a variety of ways to bridge the gap [ 181. The most direct way is formal programming classes. The purpose of a programming class is to teach people to build a mental model of computers. Most people, especially children, don’t enjoy those classes. The biggest problem is that even if they learn the techniques, they don’t like the result. They don’t want to think like computers; they want to control computers. Regardless of the approach, with respect to programming, try- ing to move most people closer to the system has not worked.

Analogical Programming It is time to try the other approach. We need to change the nature of programming to make it more like thinking. To characterize the type of thinking that we want to support, we have come to rely on a remarkable paper by Aaron Sloman [ 141. He draws a distinction between “analogical” and “Fregean” (after Gottlob Frege, the inventor of predicate calculus) representations (p. 273):

In an analogical system, . . . the structure of the representation gives information about the structure of what is represented. As two- dimensional pictures of three-dimensional scenes illustrate, the correspondence need not be simple. . . . By contrast, in a Fregean system there is basically only one type of “expressive” relation between parts of a configuration, namely the relation between “function-signs” and “argument-signs.” . . . The structure of such a configuration need not correspond to the structure of what it represents or denotes.

An example of an analogical representation of San Francisco is a map of San Francisco.

interactions.. . September + October 1996

I .._ ._-- __.-~- . _-__ --. --

‘_ ~ -” _.~ -_

article

From the map, one can tell the relationships 1. By a set of actions appropriate for acbiev- between streets, how far it is between two ing a certain result (enactive representation). We points, and the locations of landmarks. If know many things for which we have no imagev you’re walking the streets, the map can tell you and no won& and they are very bard to teach to which way to turn when you come to an inter- anybody by the use of either words or diagrams section. By contrast, an example of a Fregean and pictures. Ifyou have tried to . . . teach a

go0 Q@@ N

People who are not trained programmers have great difficulty in

“moving closer to the system.” -The biggest problem is that even if they

learn the techniques, they don’t like the result. They don’t want to think

like computers; they want to control computers.

representation of San Francisco is the term “San Francisco.” It bears no relationship to the city. Sloman writes (p. 274),

The generality of Fregean systems may account for the extraordinary richness of human thought (e.g. it seems that there is no analogical system capable of being used to represent the facts of quantum physics). It may also accountfor our ability to think and remon about complex states of afairs involving many different kindr of objects and rehions at once. The price of this genera& is the need to invent complex heuristic procedures for dealing e&cientb with spec;fic problem-domains. It seems, therefore, that for a fiequentb encountered problem-domain, it may be advantageous to use a more specialised mode of representation richer in problem-solving power.

Essentially this is what we propose to do to bridge the conceptual gap between computers and end users: “For a frequently encountered problem-domain, . . . use a more specialised mode of representation richer in problem- solving power.”

Of course, we are not advocating eliminating Fregean representations. Rather we sug- gest supplementing them with analogical ones when dealing with computers in certain domains. Bruner [l] believes that

Any domain of knowledge (or any problem within that domain of knowledge) can be represented in three ways:

child to ride a bike, you will have been struck by the wordlessness and the diagrammatic impo- tence of the teaching process.

2. By a set of summary images or graphics that standfor a concept without defining itjdly (iconic representation). [Children learn what a horse is by seeingpictures ofborses or actual bors- es. That is why we have picture books and zoos.]

3. By a set of symbolic or logical propositions drawn ftom a symbolic ystem that isgoverned by rules or laws for forming and transfoomzing propositions (2ymboh’c representation).

The first two are what Sloman terms analogical representations;:the third is a Fregean representation. Piaget believed that children grow out of their early enactive and iconic mentalities; most adult thinking takes place at the symbolic level. By contrast, Bruner recom- mends that children be taught to use all three of their mentalities when solving problems: enactive, iconic, and symbolic. All three are valuable in creative thinking. Indeed, in a sur- vey of mathematicians Hadamard [Y] found that many mathematicians and physicists think visually and reduce their thoughts to words only to communicate their ideas to other people.

An Example of Fregean Programming To illustrate the difference between analogical and Fregean programming, we will examine the same program-an electric train simula-

interactions.. . September + October 1996 q

Figure 1 A train set in Hyper-

Card with its palette of

elements, shown l/2

actual size

The problem [with the HyperCard program]

comes if we try to change the behavior of the model.

Suppose we want to put two engines on

the track and make them collide,

which is the first thing that occurs to many children.

But there is no engine in the palette of train pieces.

tion-programmed in both ways. First the Fregean approach. Figure 1 shows a stack that is included with every copy of HyperCard.

This representation is a model of an electric train set. If we place the engine on the track and click the Run button, the engine moves around the track making whistle sounds and blowing “‘smoke.” If we change the track layout, the engine follows the new layout. Every- one can do this. The problem comes if we try to change the behavior of the model. Suppose we want to put two engines on the track and make them collide, which is the first thing that occurs to many children. But there is no engine in the palette of train pieces. The simulation has not been programmed with that in mind.

Here is where simulations such as SimCity or SimAnt break down. One can alter the arrangement of the elements in the simulation but not their behavior. For example, in Sim-

City you can control the zoning of tracts of land and the layout of roads and railroads, but you can’t affect the built-in assumptions. If you find that you have a pollution problem from roads, all you have to do is put in a rail- road and the problem goes away. Not too real- istic. That is why many teachers, even those teaching city building, do not use SimCity in their classrooms. In order to change this assumption, the user must descend to a lower level, into the programming itself. This is not allowed in SimCity, but it is in HyperCard,

In the case of the train set, Figure 2 shows a slice of the code relevant to adding a second engine.

This routine continues for another 70 lines. It is one of dozens of routines in the simulation, more than a thousand lines of code in all. Understanding and modifj4ng representations like this is difficult for children of all ages. The authors tried to modify it to add a

interactions _. _ September + October 1996

second engine, and we must confess that we didn’t succeed. There isn’t a single line in the above code that has to do with trains and tracks. Instead it is all about maintaining data structures and inter-routine communica- tion-purely computer concepts. It’s a classic example of a Fregean representation.

The trouble with current programming languages is that they force people to use Fregean representations, even if other representations would be easier for people. We will now show how to program the same simulation analogically in Cocoa.

An Example of Analogical Programming Cocoa [5,15, 16] is an environment designed to allow end users to construct and modify symbolic simulations by programming them. A symbolic simulation is a computer-con- trolled microworld in which objects move around on a display screen interacting with each other. Most video games are examples of symbolic simulations. Cocoa takes a new approach to programming by getting rid of the programming language syntax. Instead, it combines three powerful ideas:

l Programming by demonstration [4] is a

technique that users use to program a computer by operating it just as if they weren’t programming. In the back- ground, the computer records their actions in scripts. The scripts can be re- executed later for new data.

l Graphical rewrite rules provide a visual ‘memory jogger” for the scripts. They remind people what the scripts do. They are a visual version of tbe “if-then’ rules used in production systems. [6] Several other researchers are also using them for programming. [2, 7, 121

l Analogical representations. Cocoa was designed to allow children to apply all their mentalities-enactive, iconic, and symbolic-to programming. To our knowledge, it is the first system to do so. In the remainder of this paper, we will show how combining the three ideas supports these ways of thinking.

Figure 3 shows tbe same model of an electric train set, programmed in Cocoa instead of HyperCard. F&we 2

HyperTalk code to

All of these elements were defined and make the engine drawn by a Cocoa programmer, starting only move

on runTrain global AutoSwitch,BtnIconName,PrevBtnIconName global Dir,PrevDir,LastLoc,PrevLocs,LookAhead,TheNextMove global

LastMoveTime,SoundOff,MoveWait,Staging,TheStage,TheEngine global TheMoves,Choices,Counter,EngineIcon,XLoc - This routine is long. - Most of the code is inline for acceptable speed lock screen setupTrain unlock screen repeat

- check user action often if the mouseclick then checkOnThings the clickLoc - get iconName of current position put iconName(icon of cd btn LookAhead) into BtnIconName if the number of items in BtnIconName > 1 then

Put “True” into Staging if TheStage = 0 then put BtnIconName into PrevBtnIconName if BtnIconName contains “roadxing” then put LookAhead

into XLoc if BtnIconName contains “Rotatetrain” then put 1 into

TheStage end if if the mouseclick then checkOnThings the clickLoc put LastLoc SC return before PrevLocs put LookAhead into LastLoc put Dir & return before PrevDir if the mouseclick then checkOnThings the clickLoc add 1 to Counter . . .

interactions.. . September + ocrober 1996

of track, and there is a horizontal piece of track to its right, and the engine is facing to the right, then move the engine onto the track to the right.”

Children define such rules as follows:

from a system-supplied “lump of clay.” Each element starts out as an inanimate object, with no behavior. The programmer specified the behavior using graphical rewrite rules. Figure 4 shows an example of a rule for the engine.

A graphical rewrite rule replaces one region I. They specify the region of the simula-

in a simulation (the picture on the left) with tion to be dealt with. In this case they’re inter-

another (the picture on the right). Cocoa exe- ested in the piece of track to the right of the

cutes such rules the way other languages exe- engine. This results in an “identity” rule in

cute statements. This rule may be read as which the picture on the left is the same as the

follows: “If the engine is on a horizontal piece one on the right, as shown in Figure 5.

I I 2. This provides a framework for specifying

behavior. Children define the semantics of the rule by editing the picture on the right. They perform actions on the actual objects in the picture. For example, they move the engine by dragging it with the mouse. This is analogical programming; the actions performed are analogous to the desired effects. If they want the train to move to the right, they drag it to the right. If they want it to move to the left, they drag it to the left. If they want it to move twice as fast, they drag it twice as far. If they want it to face in the opposite direction, they drag a different appearance onto it. If they want to change its internal state-say, its fuel level- they display its variables and edit the appropri-

I

F&we 4 I

A graphical rewrite rule to make the engine move to the right

An identity rule

q interactions.. . September + october 1996

7 --- -.- 1,:; -;_ I_- -. ce -,_-_-_ _ _ ‘..

Move engine 1 From m

ate one in place until it contains the desired value. They continue performing actions until the picture on the right looks the way they want it. Cocoa remembers the actions performed and records them in a script. This is programming by demonstration.

In this case, only one action is performed: dragging the engine to the right. The result is the creation of a new rule that adds behavior to the engine.

Notice that dragging objects involves children’s enactive mentality, changing appearances and looking at rules involves their iconic mentality, and editing objects’ variables involves their symbolic mentality. Indeed, we have found that younger children have an easier time with the first two types of actions, and only older children can deal with variables- children who have developed &get’s ‘bpera- tional thinking.”

If children want to see the recorded actions, they can cause them to be displayed. They appear as in Figure 6.

Contrast this representation with the HyperTalk code in Figure 2. Notice that both the actions the child performs and the representations of the actions are in model terms. For example, the action in Figure 6 deals with train engines. Nevertheless, children rarely want to see even this representation for the actions; just seeing the graphical rewrite rule is enough for them to remember what the rule does. We have seen children go down long lists of rules identifying each one. Thus, graphical rewrite rules appear to provide an effective representation for programs. Chil- dren have an easy time understanding them because they are in model or analogical terms.

Programming the train simulation with rules like the one above requires about

(number-of-track-elements)2 = 1G2 = 256 rules, one for each combination of track elements. This is too many to be practical. Com- binatorics can be a problem for rewrite rule systems. However, in Cocoa there are ways to reduce the complexity. For example, Cocoa can associate variables with objects such as track elements. This allows symbolic representations to be mixed with visual ones. If we attach a “Direction” variable to each piece of track, then the engine just needs a rule for what to do when it is going in a legal direction on each piece of track. This reduces the number of rules to about

(2 x number-of-track-elements) = 2 x I6 = 32. In fact, if we make the rules a little more

clever, we can program the engine in just four rules, no matter how many types of track there are. But that is beyond the scope of this paper.

Now let’s see how we can accomplish our earlier goal of putting two engines on the track and making them crash. We get a second engine by dragging it out of the “copy box” in the lower left corner of the window in Figure 3. Every time we do this, Cocoa makes a copy of the item and puts the original back. We drop the new engine on the track, facing the opposite direction from the first one. Now when we run the simulation, the engines race around the track. When they meet, they sim- ply stop facing each other, because they don’t have a rule for what to do in that situation. That’s no fun. Here’s where Cocoa simulations differ from Fregean ones: a child can change the behavior by reprogramming the simulation. For example, a child might add a

Figure G

The actions recorded

for the move-right rule

Figure 7

The crash rule as it

starts out (an identity

rule)

Cocoa is a trademark of

Apple Computer, Inc. It

is available on the

Internet at http:11

www.atg.apple.coml

Allen-CypherlCocoal

interactions.. . September + ocrober 1996

Fipe 8 I The actions recorded

for the crash rule

A To date we have tested Cocoa on more than

300 children between the ages of 5 and 15.

All of them have learned to program in Cocoa,

usually with only 5 to 30 minutes of instruction.

“crash rule.” Figure 7 shows what it might look lie at the beginning.

The engines just sit there facing each other. To make them do something different, the child drags onto each engine a “crashed” appearance that she has previously drawn, thereby changing its appearance. She then drags a “pow” sound into one of the engine’s “Says” variables, thereby playing the sound. Each of these actions is recorded, as shown in Figure 8.

domain that is of interest to our audience of K- S children and their teachers. Furthermore, the logic ofprogramming is just as difficult in Cocoa as it has always been. Children still have to think through all the cases that can arise, handle each one, and debug them when they don’t work, This is inherent in the activity of programming, What Cocoa does is to simplify programming by moving the activity of programming into the tar- get domain of simulations.

Figure 9 shows the final appearance of the crash rule.

Now when the two engines meet, something dramatic happens.

Although Cocoa makes programming easier for novices, it is not a panacea for programming. Cocoa is Turing-equivalent, but it is not a gener- al-purpose programming language since it has few primitives and input-output features. You would not try to implement a text editor in it. It is a special-purpose, domain-specific environment designed for writing simulations-a

To date we have tested Cocoa on more than 300 children between the ages of 5 and 15. All of them have learned to program in Cocoa, usually with only 5 to 30 minutes of instruction. All have been able to create characters, draw appearances for them, and give them rules to make them move and interact with each other. Furthermore, children seem to like it. It is not uncommon for them to stay inside during recess to work on their simulations. Several independent researchers have verified this. [3, 8, 13, 191 These are only small-scale

q interactions.. . september + October 1396

article

tests, but they indicate that children can learn and do enjoy this style of programming.

Summary We feel that Cocoa has made programming simulations easier for children. Cocoa works because it relies on analogical representations for programs, allowing children to think in model terms and eliminating the need to learn a programming language syntax. Program- ming by demonstration lets children directly manipulate the representations, and graphical rewrite rules provide an understandable representation for the recorded programs.

In the next 10 years, end-user programming may become an important theme in human-computer interfaces. It allows the greatest degree of tailorability for ‘agents,”

References 1. Bruner, J. Toward a

Theory of Instruction.

Harvard University Press,

Cambridge, Mass., 1966.

2. Bell, B., and Lewis, C.

ChemTrains: A Language

for Creating Behaving

Pictures. In Proceedings

of IEEE Workshop on

Visual Languages

(Bergen, Norway). 1993,

pp. 188-195.

3. Brand, C., and Rader,

C. How Does a visual

Simulation Program Sup-

port Students Creating

Science Models? In Pro-

ceedings of IEEE Sympo-

sium on Visual Languages

(Seprember 3-6, Boulder,

CO), 1996 (forthcoming).

4. C&her, A, ed. Watch

What I Do: Program-

ming by Demonstration.

MIT Press, Cambridge,

Mass., 1993.

5. Cypher, A, and Smith,

D.C. KidSim: End User

Programming of Siiula-

tions. In Proceedings of

CHI ‘95 (May 7-l 1, Den-

ver, CO). ACM, New

York, 1995, pp. 27-34.

6. Davis, R, and King, J.

An Overview of Produc-

tion Systems. Rep. STAN-

CS-75-524. Computer

Science Department,

Stanford University, Stan-

ford, Calif, 1975.

7. Furnas, G. New

Graphical Reasoning

Models for Understand-

ing Graphical Interfaces.

In Proceedings of CHI

‘91 (April 27-May 2,

New Orleans, LA). ACM,

New York, 1991, pp.

71-78.

8. Gilmore, D., Pheasey,

K., Underwood, J., and

Underwood, G. Learning

Graphical Programming:

An Evaluation of KidSim.

In Proceedings of Interact

‘95 (June 25-30, Lille-

hammer, Norway). Chap-

man and Hail, London,

1995, pp. 145-150.

“MUDS” and “MOOS,” games, and educa- tional software. We predict that end-user programming will require many domain-specific programming environments, all supporting analogical representations, possibly programming by demonstration, and perhaps graphical rewrite rules. Repenning [ll] provides a glimpse into this future. Each environment will have a special purpose. That seems to us to be the only approach that will succeed in practice. If we rely only on Fregean approach-

es, then we will lose nearly everyone. Although it is a long way from controlling trains to calculating spreadsheets or programming agents, we believe that the basic approach is widely applicable. We encourage researchers interested in this topic to contact us for the purpose of collaboration. @

9. Hadamard, J. The Psy-

chology of Invention in

the Mathematical Field.

Dover, New York, 1945.

10. Norman, D. Cogni-

tive engineering. In User

Centered System Design,

New Perspectives on

Human-Computer Inter-

action. Lawrence Erl-

baum, Hillsdaie, N.J.,

1986.

11. Repenning, A.

AgentSheets: A Tool for

Building Domain-Orient-

ed Dynamic, Visual Envi-

ronments. Ph.D.

dissertation. Department

of Computer Science,

University of Colorado,

Boulder, 1993.

12. Repenning, A. Bend-

ing the Rules: Steps

Toward Semanticaliy

Enriched Graphical

Rewrite Rules. In Pro-

ceedings of Visual Lan-

guages (Darmstadt,

Germany). 1995, pp.

226-233.

interactions.. . September + October 199G

13. Sharples, M. How Far

Does KidSim Mmeet Its

Designer’s Objectives of

Allowing Children of Ali

Ages To Construct and

Modify Symbolic Simula-

tions? Internal report of

the School of Cognitive

and Computing Sciences,

University of Sussex,

Faimer, Brighton, United

Kingdom, 1996.

14. Sloman, A. Interac-

tions Benveen Philosophy

and Artificial Intelligence:

The Role of Intuition and

Non-logical Reasoning in

Intelligence. In Proceed-

ings of the Second Inter-

national Joint Conference

on Artificial Intelligence

(London), 1971, pp.

270-278.

15. Smith, D.C., Cypher,

A, and Spohrer, J. Rid-

Sim: Programming Agents

Wnbouc a Programming

Language. Communica-

tions of the ACM 37,7

uuly 1994), 54-67.

16. Smith, D.C., and

Cypher, A. KidSim: Child

Constructible Simula-

tions. In Proceedings of

Imagina ‘95 (February

l-3, Monte Carlo), 1995,

pp. 87-99.

17. Soloway, E. Learning

to program equals learn-

ing to construct mecha-

nisms and explanations.

Communications of the

ACM 29,9 (September

1986), 850-858.

18. Spohrer, J. Marcel:

Simulating the Novice

Programmer. Lawrence

Erlbaum, Hillsdale, N.J.,

1992.

19. Underwood, G.,

Underwood, J., Pheasey,

K., and Gilmore, D. Col-

laboration and Discourse

While Programming the

KidSim Microworld Sim-

ulation. In Computers

and Education, 1996

(forthcoming).

_- --- 7. _

Documents

Making programming easier for children