ToonTalk in
Kindergartens: field notes
LEONEL MORGADO,
maria gabriel cruz, ken kahn
Department
of Engineering, University of Trás-os-Montes e Alto Douro
Engenharias II, Quinta de Prados, 5000-199 Vila Real, PORTUGAL.
E-mail: leonelm@utad.pt
The
emergence of a fully graphical, animated programming language, such as
ToonTalk, prompted the question: is computer programming a viable educational
activity with kindergarten-aged children? Since May 2000, we have been
conducting ToonTalk sessions with 3- to 5-year old children, trying to
determine what approaches are more successful, what activities are viable, what
issues may arise in the process. From November 2001 to February 2002, the
sessions took place regularly in a normal kindergarten room, where during each
session 2 children would be playing with ToonTalk, the others would be
conducting other kindergarten activities. This paper aims to present the
experience acquired during these sessions.
Computers have a
fundamental presence on our everyday lives, not only as automated elements,
reacting to sensors or situations, but as tools. Tools with a major ability:
they can be adapted to completely different tasks, suiting the needs of their
users. This adaptation, by which we refer to the common term “programming”,
allows the same tool to do tasks with as little in common as word processing
and number crunching, information collection and entertainment, and so on.
But how many
users can use this ability? Most simply use “applications”, programs made by other
people. Many applications allow for customization by the end users, but such
skills that elude most of them.
This amounts to
a huge wasted potential. Among other motives, we may quote Smith & Cypher [5],
referring to the gap between human communication and computer programming
languages as the “
This approach is
mentioned in an ACM paper from 1996 [2], where end-user programming is one of
the strategic research and development areas pointed.
Seeing computer
programming as a communication skill made us launch this consideration: in what
ways could this skill be introduced in pre-school contexts? Modern pre-school
education, rather than focusing on a curriculum, aims to give children basic
skills, allowing them to more easily and fully develop a personal worldview and
self-learning abilities. It seemed to us perfect sense to give children the
possibility to discover and develop programming skills. Skills centred on
learning how to state rules, how others (e.g., a computer) would follow them,
and how different rules would interact. All these things seem to be useful,
education-wise, even out of a computer context. Closer to the computing
context, giving children the ability to understand that a computer can be
tailored, rather than simply used, is an obvious advantage.
The
preschoolers’ limited ability to conceptualize rules and abstractions may be
considered, from a broader perspective, the main issue at stake. But the most
obvious hurdle for the introduction of computer programming concepts in
preschool may be the absence of reading and writing skills. This is a technical
computing hurdle (icons, logographic writing, are means of expressing the child
programmer’s intentions), but we felt that to reach better conclusions we needed
a way to allow children to better express their desires.
Luckily however,
we are not alone in the desire to bridge this gap. Albeit works dealing with
preschool children and programming are limited [4], some methods and tools
being used with older children seemed suitable for the initial research. Two
tools drew our attention: StageCast Creator and ToonTalk [1, 5].
From the very
start, ToonTalk seemed to us to be the most adequate tool for the target age
group (3-5 year olds), for it employs larger control elements and requires a
smaller number of mouse skills. Also, it’s the only one of the two available in
Portuguese. A more detailed discussion of this decision was presented at the
seminar “Playground – novos ambientes de aprendizagem” [6].
ToonTalk is an
implementation of a concurrent constraint programming language [7] as an
animated cartoon, where children control an avatar moving in a city (metaphor
for the entire computation). The city has houses (agents, actors, processes or
objects), where robots (methods) can be programmed. The programming employs
objects such as boxes (tuples, arrays, vectors or messages), scales (comparison
tests), trucks (agent spawning), bombs (agent termination), notebooks (program
storage), text and number pads (constants), and birds and nests (channel
communication). Robots are programmed moving them with the mouse and performing
the required actions (method actions), inside their thought bubbles. After
training a robot the method preconditions are visible as the thought bubble of
the robot.
In May 2000,
upon the release of the European Portuguese version of ToonTalk, three Vila
Real (
These sessions focused mainly on: -
determining if only 10- to 15-minute sessions
were viable, or if the media allowed longer sessions;
testing if children could use ToonTalk’s
generalization, given their limited abstraction skills;
allowing for comparison of results yielded by
a directed approach, against a coached-style approach.
The first issue
was mainly for our organization and definition of goals: longer sessions allow
for more complicated or elaborated activities than shorter ones.
The second issue
was key for further ToonTalk experiments: children’s inability to use
generalization would severely compromise any options of rule programming for
generic circumstances. Two different approaches on the generalization concept
were used: explanation and usefulness.
The third issue
was aimed at determining the strategy for the following year’s sessions: directed (i.e., proposing activities
and conducting children on how they might achieve them) or coached (letting children choose what they want to do and help them
achieve it).
On the
aforementioned paper [6], we presented the activities, data collected and
perceived results.
Briefly, these
can be summarized as: -
20-minute,
30-minute and even 40-minute sessions were viable: the children weren’t bored
at all, as long as they could explore and experiment with new things;
some
use of generalization was achieved within ToonTalk, employing a “usefulness”
approach;
with
the coached approach, children seemed to gain greater control over the ToonTalk
objects and environment, but the programming activities were simpler, compared
to the directed approach.
Directed sessions were based upon a simple activity:
programming an “image-swapping” robot, i.e., one that takes two images and then
exchanges their places, and some variations of this.
This is achieved
by placing two boxes in the ground, thus combined into a two-hole box;
different images are placed in each hole (we used a tree and a flower). A
robot, upon receiving this box, floats into its thought bubble, where we can
command it with the mouse. The robot then is made to pick the flower and drop
it outside the box, then pick up the tree and drop it in the hole previously
occupied by the flower. We conclude by making the robot pick up the flower and drop
it in the hole previously occupied by the tree.
In the coached
sessions, the children could decide what they wanted to do, only
sporadic suggestions were presented. This caused a larger focus on the
interface tools, the most visible elements in ToonTalk. Birds and nests were
also prime attention targets, since they provide a highly animated, amusing
activity.
After the
initial session, where these basic activities were explored, we introduced the
concept of robot programming as “robot teaching”. Their program choices were related
to the tool manipulation activities: a 4-year boy wanted to make a robot to
clean up the room, for instance (we suggested that instead he programmed a box-cleaning
robot), although a 4-year girl did want to make a tree-chopping robot!
In ToonTalk, if
a robot is thinking of a specific picture, number, etc., its thoughts can be
“vacuumed” with an animated vacuuming tool [1, 6], making it accept any object.
A more restricted generalization, limited to objects of the same type, can be specified
by using the same tool to “erase” instead of vacuum.
Two approaches
were used to present this concept: explanation-based,
under which this behaviour was both explained and demonstrated to children, and
then further practiced by means of a theatre play; and usefulness-based, under which the children would program robots
that were similar, but worked on different objects, such as one to swap trees
and flowers, another to swap trucks and bombs, etc. The generalization
behaviour was then introduced as a way to make robots less “picky”.
Each approach
was tried out with two children. The explanation approach didn’t achieve much,
not even after a theatre play was set up (a child as the robot, the other as the
programmer). But the usefulness approach yielded better results, with two children
being able to understand and explain the method [6].
For the second
year, the coached approached was selected: given that children were
enthusiastic about ToonTalk, we assumed this approach might provide greater
insights on their progress and hurdles.
A room at the
University campus was allocated for the weekly sessions with each group of children.
The project was
presented to parents at two kindergartens, involved on the previous year. Afterwards,
the parents organized themselves to drive the children from the kindergartens
to the campus and back. In all, 22 children were involved: 19 were aged 4 or 5,
and the activities were conducted in mixed groups of both ages and genders. Three
of the children were 3-year olds, and those were in two specific groups.
The sessions
were performed with 3 laptops, one for each pair of children, but they were
connected to regular desktop keyboards, monitors and mice.
These sessions
were conducted using the directed approach: we felt it would be best to provide
extra support for younger children, which have also the physical hurdle to
overcome, not just the conceptual one.
Originally, one
of the groups for the sessions was intended to include only two children at
this age, which we will call C and R (both were girls). However, R didn’t enjoy
getting out of the kindergarten at all; she missed the first session and the
third, and the kindergarten teacher considered that she should be replaced. She
was replaced by a 4-year old, which we will call P. Due to calendar
difficulties, only 5 sessions were conducted, from February 12th to
The other group
was composed by a single 3-year old girl, which we will call J. She took part
in 7 sessions, from March 29th to
The first group,
with C and R, performed very simple activities, mainly due to the instability
of the group composition: by the 4th session, a new girl was
involved, and introductory activities were resumed. Even so, it should be noted
this group managed to program and correctly use a robot on the second session,
although no further work was possible along this line, to see how well they had
understood the concept.
However, the
second group, with J, allowed a more consistent set of activities, thus
summarized:
1. Flying
and moving around, playing with toys, letters and numbers.
2. Combining
images to create a painting, place it on the wall (by using a wall sensor and
control).
3. Playing
with the vacuum cleaner and the wall sensor; programming a robot to write her
name.
4. Building
houses; programming a robot to put gifts on the wall. Launching the robot to
new houses.
5. Playing
sounds, teach robots how to play them. Use it on the back pictures, turn
pictures around.
6. Playing
around with birds. Exploring their operation, by hiding and copying nests.
7. Experiences
programming robots to play sounds, using birds to clean up rooms.
It should be pointed out that on both groups,
3-year olds managed to program robots very early on, albeit with assistance: the
first group on second session, the second group on the third session. All children
had previous computer experience, which rendered easier such actions as mouse
and button control. On the second group, references were made by the child,
during later sessions, to previous aspects of the earlier sessions, showing
that details of the activity were not alien to her. For instance, on the 7th
session, she tried to give a nest full of things to a robot, and complained
about it not being accepted because “things were properly tidied up” – this
required explanation that things had to be tidied up inside boxes, not nests,
but it is revealing that in fact some of the previous concepts on programming
were grasped. It should be noted that the variety of robots programmed by J
were suggested to her, and help was supplied, but this took the form of
explanation, not specific instructions. She was able to take decisions on her
own, requiring quite an understanding of the environment, e.g., turn around a
picture to stop the robot playing sounds on its back.
These sessions
were conducted from
Due to space
limitations, a full account of the sessions is not possible here, but key
points can be given.
In terms of the children’s
appreciation of the activity, except for one boy, all the others enjoyed
playing in ToonTalk, from the very start; however, a 4-year old girl later on
would usually prefer typing aimlessly in a word processor (she couldn’t write) –
she considered it “serious work” (sic).
She would only enjoy ToonTalk if a more “serious” activity was chosen, e.g., programming
a robot to write her name endlessly.
Due to the fact
that there were 6 children at each session, two at each computer, and only one
adult, activities were geared towards giving them some ability to use ToonTalk
unattended for some time.
Overall, the children
were able to program several robots, but that wouldn’t be their main activity:
they would copy things, enlarge them, put pictures side by side to construct
scenarios for some story, etc.
Choosing the
adequate situation or proposal for robot programming proved crucial. “Teaching”
a robot could be interesting if the result was considered “funny”. For
instance, creating a huge repetition of their name; building lots of houses,
blowing up houses, producing many birds.
Since only short
amounts of time were possible, to each group in turn, we didn’t manage to work
higher-order concepts such as generalization within these groups. Several children
could follow instructions or execute ideas regarding robot programming, but lower-order
skills such as manipulation and control of objects, or orientation in the city and
notebook were necessary, so that all children would enjoy the activity.
On another hand,
this limited time frame of attention given to each pair of children allowed
them more room for failure, and several events made us became aware of specific
skills, or specific moments in which the ability to complete programming activities
could be compromised:
the
initiation of the programming process (giving a box to the robot) may not be
understood as an example or starting situation, but instead as an “interrupt”
or “switch”, like turning on a toy, therefore lacking the association between
preset conditions and an intended action;
consequentially,
the concept of an activity being taught as something with “in” and “out”
conditions, or as something with a “before” and “after” state, using a box as a
container for acting upon, is not absolutely clear: quite often a child will
start teaching a robot by giving it an empty box (using it like an “on”
switch), and then “teach” with objects taken from the tool box or notebook;
most
children find it hard to grasp the “end of program” concept: after teaching a
robot, they quite often proceed playing around with the objects in the tool
box, regardless of the fact that they are moving them with the robot’s hands,
not the programmer’s hand;
the
concept of sequencing activities taught to robots can be confusing: quite
often, children expect robots to start “playing” the moment they finished
teaching them, forgetting that they had to give them a starting box; but, they
wouldn’t make that assumption for robots intended to be used in a specific
situation, such as, “when it reaches the new house”, or “when the picture is
turned around”;
“debugging”
is an extremely alien concept. Most children assume that a robot learned
exactly what they meant to teach him, to the point of sometimes being satisfied
with the “teaching” per se, not bothering to check if the robot worked; also,
they would be puzzled upon seeing a robot repeat the redundant mistakes they
made while programming it (like dropping a box on the wrong place and picking
it up again), for they would forget about such deviations from the intended
path, remembering only the intended path or goal.
Very young
children can successfully use ToonTalk to program simple robots and use them,
as long as the path to the discovery of the necessary techniques is supported,
encouraging children to explore and try out new situations or approaches.
Logical explanations for abstractions or programming constructs are also
helpful in order to allow them to construct more complex programming
situations, in which they combine more than one robot, combine an expected
event with the execution of a robot, or combine a newly-programmed robot with a
previously used one.
However,
programming requires the acquisition of specific skills, which in turn require
the development of specific teacher strategies and planning. Given only the
rudiments of the operation of a programming system, children will quite often
employ it as a simple non-programmable playground, or use programming as a way
to produce a somewhat chaotic or unpredictable (from their point of view) chain
of events. Again, adequate support is required, so that children can acquire
the power of combining simple pieces (robots) and learn to guess at the likely
result, or be able to decompose a problem into simpler pieces and set about to
create them.
The results from
the original generalization experiences seem to indicate that an approach based
on simple, real-world, everyday explanations and usefulness can be more
fruitful than one based on abstract explanation of a specific behaviour, be it
before or after its observation.
We feel that the
support that children require in order to learn how to program should be given
as several small incentives to trial, experimentation and interpretation by the
child, rather than explanations or sequences of instructions to follow.
References
1. Kahn, Ken ToonTalk™ – An animated programming
environment for children. Journal of
Visual Languages and Computing 7 (1996) pp. 197-217.
2. Myers, B., Hollan, J. and Cruz,
3. Norman, D. Cognitive Engineering. In User centered system design: New
perspectives on human computer interaction. (Lawrence Erlbaum Associates,
Hillsdale, NJ, USA, 1986).
4. Perlman, R. Using computer technology to
provide a creative learning environment for preschool children. MIT AI Lab Memo
360. Logo Memo 24 (1976).
5. Smith, D. C. and Cypher, A. Making Programming
Easier for Children. In DRUIN, A., ed. The
Design of Children's Technology. (Morgan Kaufmann Publishers, San
Francisco, California, USA, 1999).
6. Morgado, Leonel, Cruz, Maria and Kahn, Ken,
Working in ToonTalk with 4- and 5-year olds. Paper presented at the "Playground - novos ambientes de aprendizagem"
Seminar at Casa de Vilar,
7. Saraswat, Vijay,
Concurrent Constraint Programming, MIT Press,