Playground Paper

reviewing an experiment in designing a computer programming environment for children within an elementary school

 

 

Playground is a completed project of the Vivarium Program within Apple Computer's Advanced Technology Group.

 

 


Final Draft

March 19, 1993

 


Contents


 

section 1:

describing Playground

 

Acknowledgments & A Short History

 

Preface:

Playground is a ...the idea and our ideals

Introduction & Demo :

Playground is a ..a first time walk through,overview

Chapter 1

Playground is a ...how antecedents such as Spreadsheets and HyperCard were incorporated in a real prototype

section 2:

Playground goes to School

Chapter 2

Evolving New Tools within the Education Institution Tools, Process & Proclivities

Chapter 3

Observations in Yellow Cluster Spring 1990 City Commissions create simulations: example: Smog Fighter

chapter 4

Observations in Blue Cluster spring 1990 examples from the life stories of the fishes

chapter 5

Yellow Cluster Fall 1990 creating characters based on an object selected by children and putting those characters into each other's environments

chapter 6

Chapter on Blue Cluster Spring 1991oceans characters

section 3:

examples of the use of Playground from Playground's designers

chapter 7

Playground Style examples from Playground's Designers

chapter 8

Computer Simulations Progressions, Intersections, Repercussions Ideas & Examples of how to use Playground to recreate Turtle Geometry examples &"Biomorphs" to moving morphs & beyond

afterword

 

chapter 9:

Cultivating Diversity & Convention


 

preface






Playground is a ...Metaphor of a Playground

The playground was chosen as our metaphor for a computer programming environment . It represents the way in which we in the Vivarium Program at Apple Computer initially wanted to investigate computer programming for elementary school children. The playground is a place where rule governed activities have a natural place, involving play, invention, and simulation. On the playground, children assume roles which limit their behavior to that of defined and shared characters.(1) Rules and relationships are endlessly debated and changed. The nature and structure of playground play resembles some of the strategy children might exercise on the computer, to set up computer instructions in construction and play with simulations of multiple players.

A playground viewed from above becomes a gameboard on which the movements of players reveal moves in reaction to one another. Player's states of behavior are manifested by their position. Board games like chess derive from the overhead view of the playing field, or the battlefield, where players are markers whose position describes their relationship to each other, in which every marker is advanced according to simple rules which describe exactly their repertoire of possible "moves" .

A Playground was envisioned for the computer as a playfield or gameboard viewed from above and displayed on the computer screen as a "Playfield". Within the frame of the "Playfield", "Players" are picture markers whose rules of interaction can be programmed. A computer playground could provide the frame, the tools, and some of the structure for the creation of playfields full of players of the user's own devising.


 

What Playground is for:

"Simulations": Models of Behavior and Interaction


Games, with their simple rules and rolls of the dice, are models of behavior and interaction , or "Simulations" . New worlds that lie just outside children's immediate senses in the real world could be brought to their senses in a computer world. We can speed up evolution and global ozone depletion, we can slow down molecular interactions, placing these within the sensory grasp of the computer user. Constructing things with moving parts on the computer should interest children, while exercising their thinking processes in new ways. Simulations which are appropriate for young children need to be engaging in subjects of interest to them. Some examples I describe in later chapters include subjects of Los Angeles Smog, and Mother and Baby Whales.

scripting conditional events in time --extending the Macintosh user interface



The popular success of the Macintosh is attributed to its user interface, which facilitates pointing and doing with graphical representations, in addition to symbols. The Macintosh limits itself to static objects which go through changes only under our specific selection and mandated action. This is referred to as direct manipulation of visual images. Opening and closing a folder, moving a folder, throwing something away in the trash can are all direct actions under event by event control by the user. The kind of programming the user can do in this manner tends to be limited to setting options with menu items, and working on an action by action basis selecting and moving visual objects.

Making the Macintosh more object oriented and dynamic requires departure from Macintosh conventions. Once things start moving, direct manipulation of concrete visual images is too limited a way to specify the computer's actions. The user needs to be able to describe a series of conditional events in time. Our text editor is unified with graphic and spreadsheet editing, so that users can choose what is most comfortable.

We have experimented with different ways of presenting text editing. The same ideas which led to the enactive and visual Macintosh user interface have a parallel in the underlying computer programming which is hidden from most Macintosh users. "Object Oriented Programming" manifests a sensible kind of modularity which makes the programmers task easier. Thinking & working in smaller chunks, not having to envision the whole has become more generally and loosely known as "component programming". Playground is pursuing both ways to represent components visually and iconically, as well as the proposition that a more full blown english language used in writing programs will make programs more easy to read after the fact. This will make it not only easier to use components created by others, but it should make reading what you yourself wrote the day before easier. The sparseness of many popular programming languages is beneficial when writing them, but is often off-putting to read for those who are not familiar with them.

To be successful simulation builders, children need to be capable of making real changes to the underlying rules. We need to actually hand them tools to do their own programming. Otherwise, we fear we do children a disservice not to empower them with "real tools" and knowledge of computer programming which will be universally usable, and will allow them to create simulations we have not thought of.


implications of future networked environments



Very shortly, the nature of authorship will change even more dramatically as it becomes necessary to share our work with others on different computers. It will be impossible to predict the nature of another person's computer environment. And, we expect a lot more than just readers of our future documents. We expect a level of interaction at least equivalent to today's computer game players, and more likely, we will be hoping for collaborators who can participate in co-authoring. These collaborators could be pen-pals at the other end of the earth, but more likely, they might be sitting next to us in our own classroom, or across the hall in our school.

Complicated programming for combining code from different sources, running on differently configured machines, will have to be greatly simplified, to remove the burden from the user. "Playground" was designed with special thought towards this future.


example driven language design:



Playground's design is based on ideas of Dr. Alan Kay, whose seminal career during the '70's led to both the precursor of the Macintosh computer and Smalltalk programming environment. A guiding theme in programming language design espoused by Alan Kay is to find twenty key examples, once you have mastered all of them in your prototype environment, you will finally have enough information to write your language -- or to reject it as inadequate. The examples exercise the abstractions of the programming environment and help to shape them.

A parsimonious and elegant style for handling sequence or linked lists are demonstrated in an example paragraph editor proposed by Alan Kay [in Chapter 7 on Playground Style] A style of "simulation" is discussed in which special use is made of the ability to feed the results of the last calculation into the next to produce ecosystem and evolution models [in Chapter 8 Computer Simulations Progressions, Intersections, Repercussions].

But an elegant language used elegantly by its designers is not our intent. In fact, we seek users who are least like us, and chose to focus on children. As tool makers, we believe we could be better tool makers if we were to include the users of our tools in our efforts. This parallels the Smalltalk development, but Playground takes a significant departure. Instead of bringing special children to a research lab setting, access to children was sought on their own turf. The classroom was selected because it is a structured learning environment . Together with the children we would try out our new tools within their classroom context, through the classroom teacher. An overview of our relationship with The Open School for Individualization, a public magnet school in Los Angeles is presented [described in Chapter 2].

Examples from two years in two classrooms are reviewed. Seeing similar examples from different years and different grades is invaluable for evolving classroom appropriate work as well as evolving the programming environment supportive of such work. We believe that the third/fourth grade is an ideal age of competence appropriate for programming simple computer games, although this is not conventional wisdom [Chapters 3 and 5]. The fourth/fifth grade is more typically the age to introduce computer programming, we explored rather complex programs with this age group [Chapters 4 and 6].

Challenges to conceptions about programming environments of the future are provoked by the experience of this project [Chapter 9: afterword]. This work has no conclusion. Playground as a language is still being used by one teacher, but as an Apple project it is completed. Successful uses of Playground have compelled new work. This author believes it is valuable to examine closely ambiguities, discrepancies, and difficulties also, as a source for new conceptions which we did not expect.



 

Playground is a ..How we demonstrate playground in terms of the Metaphor of a Playground

 

"Playground's a lot like Robert Carr's Framework, or Wingz, but the spreadsheet cells are taken out of a grid, given costumes, inspected like HyperCard buttons, and animated like space war ships " . (2)



Start up your Macintosh computer and double-click on the Playground icon, and expect to see what you expect to see from a Macintosh application: a blank slate ready for your creations, with a tiny band of menu items at the top of the screen. Pull down the familiar File Menu and select New Playfield, now you have a clean white expanse in front of you, like a sheet of paper in macwrite or an empty hypercard.

- next Pull down the Menu again and select New Player. Instantly a nondescript gray rectangle appears on the screen, labeled "player1". Just as you would modify any graphical object, you can use your mouse to pull the handles at the corner of the rectangle. You can duplicate your player. You can continue to search through menu selections to reassign name or costume, but let's move beyond what is familiar to you, to what is new about Playground.

- Double-click on "player1" to reveal player1's value list. Now as you move the player & change graphical characteristics, you will observe the corresponding number values for these graphical characteristics changing. Open up a few value lists for duplicated players and you will see all the values changing simultaneously as you move players on the screen.

- Now, our first step into scripting. Open up the value list window to reveal the full Scriptor with panes that accept lines of code, similar to a spreadsheet. Let's type X + 1. You'll see magic as Playground's incremental addition makes things move and grow, as we can cut and paste our script into other of the player's attributes. We introduce the sentence constructor here to try other short instructions.

Always something is happening in the animation window. A new little piece of code causes immediate change to the animation., which you see side by side with code. Changes made directly to the graphics change the code. Code is written in full english sentences and is assisted by menu selections. Playground's players, like multiple logo turtles, each move independently. Within each player, each subprocedure, or "agent", runs independently and concurrently .

-- Getting this far begs the obvious: how do we retrieve the players which have moved to the edge of the screen. This natural interest moves us to learn about conditional statements. Using a button at the top of the scriptor pane, we can add a condition pane which we can subsequently fill in using the sentence constructor. Now we have got things bouncing back and forth. -- Now that we've got everything moving, something is still lacking. Wouldn't it be more interesting if the movements of the players were not isolated, but in reaction to each other. Let us add a condition of proximity to another player. To do this we have to introduce another new thing which is part of Playground which is unique and essential. First let us show how to add a new attribute -- or "agent", which we will name "Otherguy". Now let us set the value of "Otherguy" by clicking in the value list, this turns our mouse cursor into the image of a hand with which we point and click at the player we want to keep tract of, the value of "Otherguy" appears "player2". Creating another new "agent" which we call "Mover", we fill in code to move away from the player we call "Otherguy" when we are within 50 pixels. Now we can have fun chasing our players around the screen as we catch and hold them with our mouse.

-- Next we fill in code by copying and pasting our new agents into all the players, and by duplicating new players, until we have a lot of interesting looking movement and activity.

Interactive animation "behaves" and surprises, unlike frame by frame animation.

-- From here we might continue our demonstration by building one of the examples from the following chapters.


 

acknowledgments:




Playground's design team & short history



Playground is a completed project of the Vivarium Program within Apple Computer's Advanced Technology Group. It had a life of three or so years and as many major versions of prototypes which were used by 4 teachers and 120 children.

Playground's design is based on ideas of Dr. Alan Kay. Playground's design is a response to a list of features Alan Kay has wanted to explore which got left out of Smalltalk, or seemed to be at odds with Smalltalk. These ideas were described in a paper distributed internally at Apple in 1986 at the outset of this project (3). The resulting implementations represent how the group of people involved interpreted and knit these ideas together. As the ideas often seemed to be pulling in different directions, there was considerable disagreement among constituencies over priorities and unifying vision.

Our first implementation, which I have not described in this paper, but has been addressed elsewhere (4), was by Jay Fenton, a videogame programmer who was the principal programmer of Macromind's VideoWorks (5) and Tom DeFanti's Z-Grass (6). Both are real-time animation languages which are "object oriented" in their use. Jay implemented Playground 1 as a real-time animation world hosting simultaneous multiple users on a network all in the"C" programming language. This demonstration was quite effective and influential within Apple, spawning more experimentation with applications for networks which led to some features of Apple's new system 7.

However, Alan objected to the limited programmability of the animated objects in Playground 1, and insisted Jay reimplement Playground 2 in an alpha version of Digitalk's SmalltalkV (7). Alan's hope was that the greater modifiability of Smalltalk as a development language would allow himself as a designer and teachers as users to incrementally make small changes. Although this was not Jay's style of working, he produced Playground 2.64a which was used with 5th graders in the spring of 1989. Most of the key features were implemented in some way in this version, together with a first approximation of Playground's language.

Playground 2.64a became the basis for Playground 3.0 with the addition of Jay's natural language parser. Then Playground was taken over by Scott Wallace with the assistance of Kent Beck. Both these programmers were serious object oriented Smalltalkers, and they rapidly undertook to clean up the shortcomings of Digitalk's SmalltalkV, particularly for change management that we required, and Jay's ad hoc smalltalk style. Scott Wallace became the project leader and primary programmer, bringing consistency, completeness, and strong object oriented design. Scott brought in various other Smalltalkers for design critiques including Larry Tesler, Dave Canfield Smith, Josh Susser, Kevin Tiene, as well as short term implementations including Yu-Ying Chow.

It is the two years of Scott Wallace's Playgrounds 3.0 and 3.5 which are described in this paper. These versions were robust and complete, had their own clear identity. Scott spent many hours working along side of teachers and children who were Playground's users, taking copious and detailed notes which would lead to real changes in the next version. Sometimes we had a new version every week, in response to user requests. The changes Scott adopted he tried always to filter through his own strong sense of design -- although he felt badgered into permitting some features which were unnecessary or counterproductive when users insisted, and it seemed something could be learned from it. Scott's deep experience from this two years are now being carried forward to a brand new design project.

Playground's story is rich in its many details of design and use and we hope that we can share what we have learned. This paper is written in great detail in the hopes of capturing our experience -- if you readers get bogged down in it, please skip on to a later section which might hold more interest for you. We would also be pleased to provide the software and examples, or a demonstration, to anyone who is interested within Apple's research community.



 

Acknowledgments:


 

Scott Wallace , project leader 1989-1991

Jay Fenton , project leader first prototype 1987-89

contributing programmers:



advisor/design guidelines: Alan Kay

team member, user, and general pain in the neck
Ann Marion

teacher-liaison, team-member, user
Dave Mintz

Playground's users & members of the team (teachers at the Open School):

 

B.J. Allen-Conn

1988-1992(4 years in 4/5 classroom) and continuing...

Dolores Patton

1989-1991(2 years in 3/4 classroom)

Leslie Barclay

1989-1991 (2 years in 3/4 classroom)

Donna DiBernardo

1989-90 (1 year in 4/5 classroom)



others who have contributed ideas or guidance:

·  Larry Tesler

 

·  Mike Travers (MIT)

 

·  Prof. Richard Dawkins, Blind Watchmaker author




classroom tutors:
Gloria Pearson, Dave Jones, Karen Rodney, Mark Loparco, Lori Weiss,many Apple staff members who made recurring visits, including Dave Canfield Smith and others; and the Open School classroom aides who pitched in

project coordinator:

·  Kim Rose

 

·  the creators of SmalltalkV at Digitalk,

 

·  & many friendly members of the Smalltalk community




special thanks to Herb Kohl for useful insights
and reading many drafts of this paper


References for Citations above:

1

Vivian Paley, Molly is Three

2

Larry Tesler memo to Alan Kay

3

It would help my readers to understand a lot about the history of computers, about Apple Computer, and even about the Vivarium Project. They should try to get hold of, and read at least this one lengthy document by Dr. Alan Kay which lays out the grand plan and the design of "Playground": "Vivarium Essays" & "Playground Essays", April 1988 were distributed at Apple's Advanced Technology Group Open House.

4

Fenton, Jay & Beck, Kent, "Playground: An Object Oriented Simulation System with Agent Rules for Children of All Ages" OOPSLA proceedings 1989?

5

Macromind's VideoWorks I

6

Tom DeFanti's Z-Grass, Chicago

7

Digitalk's SmalltalkV




Copyright 1993 Apple Computer, Inc.