Short Papers
Using Children’s Drawings to Improve a Programming App
Robert Sheehan David Haden
University of Auckland University of Auckland
Auckland, New Zealand Auckland, New Zealand
+64 93737599x88814
r.sheehan@auckland.ac.nz dhad933@aucklanduni.ac.nz
ABSTRACT
After being shown a prototype tablet programming environment,
iFizz, children were asked to draw computer programs, either
games or stories, that they would like to make with such an
environment. The drawings in conjunction with the children’s
descriptions were then inspected to see what functions were
missing from the programming environment in order to make it
easier for children to produce their programs. A small number of
programming functions were extracted from the drawings along
with some changes to the programming environment’s user
interface and tools. These additions and changes are described and
the most common requirements are now being added to the
programming environment.
Categories and Subject Descriptors
H.5.2 [Information Interfaces and Presentation]: User
Interfaces - User-centered design
General Terms
Design, Human Factors, Languages.
Keywords
Children, programming environment, games, drawing.
1. INTRODUCTION
Getting children to program computers is once again a popular
activity and is part of the curricula of schools and national
education establishments [1, 2]. This has been driven partly by the
need to encourage more students into STEM (Science,
Technology, Engineering and Mathematics) degrees and careers
and partly due to the importance placed on Computational
Thinking [3].
Unfortunately, traditional programming languages produce all
sorts of problems for novice programmers and even more so for
children [4]. To ameliorate these problems a number of
programming environments have been produced for novices and
children [5]. The best known recent example of these is the
Scratch environment [6].
We will not argue here with the reasons children should learn how
to program. Our work is concerned with making it easy for
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. Copyrights
for components of this work owned by others than ACM must be
honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee. Request permissions from
Permissions@acm.org.
IDC '15, June 21 - 25, 2015, Medford, MA, USA
© 2015 ACM. ISBN 978-1-4503-3590-4/15/06…$15.00
DOI: http://dx.doi.org/10.1145/2771839.2771902
303
IDC 2015 Medford, MA, USA
Sara Metz
University of Auckland
Auckland, New Zealand
smet015@aucklanduni.ac.nz
children to produce programs that they want to produce -
programs they can have fun with, and can use to express
themselves. The programs produced must be dynamic and
interactive. Dynamic, because that is what differentiates computer
programs from pen and paper. Interactive, because that means the
children can influence and modify the behaviour of the program
as it runs. Because we already knew that games are the most
common type of program children wish to produce [7] we
focussed on simple game development for our programming
environment. The design we chose also allows the app to produce
simulations and to tell stories.
Here we present the functional prototype version of our
programming environment or app before describing the technique
we employed to gather information to improve the app's
suitability and the results we obtained.
2. THE PROGRAMMING APP
Our programming app, iFizz, was originally derived from a
desktop version of a physics-based programming environment for
children (Fizz) [8]. Significant and deep changes were required to
the app in order to make it suitable for use on a tablet [9].
Constructing a game in iFizz requires three steps: creating toys,
putting the toys together in a scene and adding actions to the toys.
These stages are handled by two different modes, the toy and
scene creation modes. A third mode is used to run the iFizz
programs.
The toy creation mode is a drawing mode with traditional drawing
tools such as free form curves, straight lines and circles. Any
drawing made in this mode automatically becomes an iFizz toy.
Toys are similar to sprites in Scratch, or characters in KidSim
[10]. The major difference is that when they are placed in a scene
they have physical properties used by the iFizz 2D physics
simulator. The physics body of a toy is produced from the convex
hull of the drawing. All circles are turned into wheels to facilitate
the production of rolling vehicles. The rationale for the use of
implicit 2D physics was to make it easier to provide realistic
movement to the toys. It also makes actions like explosions more
fun.
The scene creation mode uses the same drawing tools as the toy
creation mode but also allows toys to be dropped into the scene.
When a toy is dropped into a scene it gets reduced in size by a
factor of four to allow multiple toys to occupy the scene. The toy
can then be resized, rotated and positioned. Anything else drawn
in the scene creation mode becomes solid ground or walls. The
toys will collide with the ground and bounce off it when the
program is run but the ground does not move.
Gravity can be varied for a scene or removed entirely. Toys also
have properties such as being stuck or unable to rotate if required.
 Short Papers IDC 2015 Medford, MA, USA

Programming consists of adding behaviours or actions to the toys smart-phone before the study. The iFizz app was presented to
and scenes. Selecting a toy in the scene allows the user to add them by showing the three main steps to create a simple program:
actions to the toy. Actions consist of a cause and an effect. So making toys, making a scene (including dropping toys into the
iFizz is an event based programming environment. The causes are scene) and adding actions to the toys. The program created was a
events such as touching the toy, shaking the iPad, using a timer, Donkey Kong type game where barrels were rolled down
and detecting the collision of a toy with another toy. The effects platforms by a monkey at the top of the screen (see Figure 1). The
are things like, adding a force to the toy, adding to the toy’s score, player had to progress up the platforms avoiding the rolling
moving a toy away from another toy and making the toy explode. barrels. The children were also shown a pinball program.
As one of the effects is a command to transition to a new scene, it
is possible to create games with multiple levels or to present a
narrative.
When adding an action the user is presented with a list of causes.
After the cause is selected a list of effects appears to prompt for
the remaining information. Sometimes a cause or an effect will
prompt for extra information, such as which toy the collision
effect is associated with.
Selecting a toy in the scene creation mode allows the user to
observe the existing actions associated with the toy. Originally
each action was represented by up to four icons, e.g. if a toy car
was to explode after it collided with a toy tree the action was Figure 1 – The demo program.
represented by the collision icon, a tree icon, the explosion icon
and an icon representing the magnitude of the explosion. Each After talking about the app and letting the children play with the
icon associated with a cause or an effect was given a simple text game produced they were each given two paper templates
label. Even though this representation was reasonably well representing the iPad screen when an iFizz created program is
understood it was seen as unwieldy and we realised that the running (see Figure 2). They were told to think about a program
representation could be simplified considerably. By relying on the they would like to make with the app. In particular they were
text labels we could represent each action with only two icons, asked to work out what their program would look like, what it
one for the cause and one for the effect, e.g. the collision action is would do and how it was controlled. Then they were asked to
shown with an icon of the tree, labelled "collision", and an icon draw the program in the templates.
showing the magnitude of the explosion, labelled "explosion".
This of course requires the user to be able to read but as iFizz is
aimed at children eight or older this seems reasonable.
After the actions are added to the toys and scenes the program can
be played in the playing scenes mode. Here the toys react with the
2D physics and the effects run when the causes occur.

3. HOW TO TEST THE FIT?

After developing our improved prototype and before finalising the
capabilities of iFizz we wanted to see how well our design would
cope if children were to imagine games or stories they would like
to produce or tell. Even though we knew that iFizz could certainly
be used to create games as diverse as pinball, Donkey Kong [11]
or Asteroids [12] and could be used to tell simple episodic stories
we were not sure about the wider range of possibilities which
children might want to use iFizz for. To get data on this we
needed to find out what types of games children would produce if
introduced to an event based programming system like iFizz. In
particular we wanted to find holes in our design; were there
causes that children wanted to use or effects they needed for their
games which were not easy to implement with the prototype
version of iFizz.
Collaborating with children as design partners is common in this
field [13]. Part of that process is getting children to make models
and drawings. Usually the drawings are used as a vehicle to start
or progress design [14]. Sometimes the drawings are used to
control programmable objects [15]. In our case we used drawings
to find features missing in our existing prototype.
3.1. Method
A group of 13 children, 6 girls and 7 boys, of different abilities
and aged 9 or 10 were selected from a primary school classroom.
All of the children had used a touch screen device, either tablet or
Figure 2 – A child’s drawing of her program.
The reason each child was given two templates was so that they
could draw two different scenes, either from the same program or
from different programs. They could also request further
templates if they wanted. The use of drawings was chosen to
enable a certain freedom in the programs produced, without
having to take the mechanics of iFizz into account.
When the children had finished drawing they were asked to
describe their programs, and the researcher asked questions to
clarify the intentions the children had for their programs. The
drawings and descriptions were analysed by the researchers to
find functions and mechanisms which would be necessary to
implement the programs, these were then compared with the
existing functions and mechanisms of iFizz.
The study was biased as we presented the children with the
prototype of iFizz before we asked them to produce their
drawings. Although we were aware this could influence the types
of games or stories that the children would produce we allowed
this for several reasons.

304
 Short Papers
We were interested in the programs the children wanted to make
in an iFizz like environment - one which provided built-in 2D
physics and was event based. In particular we were interested in
the variety of programs they would make in such an environment.
We wanted to constrain the thinking of the children as this can
assist with making choices and creativity [16].
We specifically wanted to gather information about the actions -
the causes and effects necessary to add to iFizz to enable the
production of programs the children wished to make.
4. RESULTS
We were pleasantly surprised by the variety of programs drawn by
the children. We had expected a large number of Donkey Kong or
pinball type games as these were the examples the children saw at
the start of the sessions. There was only one pinball type game
drawn and that was far more complicated than the example the
children were shown. There were no Donkey Kong type games
drawn by the children. This showed that the use of the examples
did not greatly affect the choice of programs the children drew.
The 13 children produced images of 18 games. This included two
games which had two different levels drawn.
The drawings and descriptions of the programs produced by the
children were then analysed from the point of view of exactly how
they could be created, both the production of the images and the
behaviours that the program would require. Examples of these are
given in the discussion below. We looked for anything which
would be difficult to do in the prototype version of iFizz, where
difficult meant that it was not immediately obvious from the
interface provided or would require several steps of actions, or
was indeed impossible.
The missing functions were described and we counted how often
the same or similar functions were required in the 18 games.
Some of the programs could be produced without any additions to
the prototype version of iFizz. Other programs could be produced
with slight variations to the design or gameplay.
The changes required to match the requirements of the children’s
programs were in three areas: the actions (causes and effects), the
game playing interface, and the production of scenes and toys.
4.1. Actions
No new causes were needed for any of the programs drawn and
only two new effects were required to match the behaviours in the
children’s drawings: follow the finger and replace the toy with
another.
4.1.1. Follow the Finger
Three of the games showed toys being dragged around the screen
as the game was being played e.g. dragging dirty dishes from a
table and dropping them into a sink. There is an existing cause for
when a toy is touched but the movement effects for toys are either
applying a specific force or moving towards or away from a
particular toy. Toys can also be controlled by using the buttons on
the side of the screen and there was evidence that some of the
children did take the limitations of the prototype into account e.g.
one game had a toy hand which was moved around the scene
using those buttons rather than via direct manipulation.
Adding a follow the finger effect after a toy touch cause would
enable those games to be produced far more easily. This would
also allow a flick type effect to impart a force in a particular
305
IDC 2015 Medford, MA, USA
direction and magnitude to a toy. A football shooting game drawn
by one child would then also be easier to create.
This shows that the use of the touch screen technology is
important from the game design perspective. The children wanted
to be able to interact directly with the toys when a game was
playing. It is possible that they did this because they knew they
were designing games for a touch screen device but it is also
possible the games would have required this even if the children
were asked to design games for a traditional computer.
4.1.2. Replace the Toy
Two of the games required a change of state for toys after
colliding with power-up toys. The toys were to react differently
while the power-up was in effect. This is difficult to implement in
the prototype iFizz because each toy has one set of actions and
properties. A replace the toy effect would allow a toy to be
replaced with the powered up version or indeed any other toy. The
existing timer effect would enable the powered up version to
return to its standard version after a set period of time.
4.2. The Game Playing Interface
There were aspects of game play or the interface which were not
included in the iFizz prototype but were shown to be necessary.
4.2.1. Control Button Interface
The iFizz prototype when in run mode has six buttons to interact
with the game; three down each side of the screen when held in
landscape orientation. When a button is assigned to an action the
button displays a picture of the toy it is associated with (see
Figure 1). Nine of the games drawn by the children used this
concept, which had been demonstrated to them during the session,
but seven of these drawings showed not just the toy connected to
the button but also the effect carried out on the toy (see Figure 3).
This was something we had been considering adding to iFizz and
this was solid evidence that such an addition would be useful.
Figure 3 – The side buttons show the effects.
4.2.2. Show the Time
Four of the games (two from the same child) showed an on-screen
timer. This is simple to add as it would be a property of the scene.
There already exists the ability to limit the game period using the
timer cause but this would make the timer visible.
4.2.3. Discrete Movement
By its nature as a 2D physics-based environment iFizz allows
continuous motion and positioning. Considering the drawings and
game descriptions provided by the children it was difficult to tell
whether any of the games could have benefitted from discrete
changes in position or orientation rather than applying forces to
move or rotate the toys. One of the games was a Tetris like game
and that would be much easier to play with the toys snapping into
orientations and positions as the game is played. Two or three
 Short Papers
other games drawn might also be slightly easier to play with
discrete rather than continuous movements.
Adding discrete movements is currently being considered.
4.2.4. Side-Scrollers
Two of the games drawn were side-scroller type games, both
based on Flappy Bird. Producing side-scrollers is difficult in
iFizz. The current workaround is to produce a number of different
scenes and progress through them as the player reaches the side of
the screen. We have no current plans to add a side-scroller mode
to iFizz but may consider this in the future.
4.3. Scenes and Toys
In the prototype all lines drawn in the scene mode become
physical objects, similar to toys, but they do not move. This
makes them walls, or floors or other obstacles. The scene creator
mode can also load a background image which is only an image
and does not contain any objects with physical properties.
Originally we thought that providing loadable background images
would be enough but seven of the programs drawn by the children
required unique backgrounds which toys could move over without
colliding with them. It thus makes greater sense to provide the
ability to draw backgrounds within the app.
5. PROBLEMS WITH THE METHOD
All of the programs drawn by the children were games even
though they were asked to draw programs of games or to tell
stories. Given the demonstrated examples and the discussion that
accompanied them this was not surprising but it does mean that
any story telling features that may be necessary haven't been
discovered by this approach. The ability to go from one scene to
another which would be essential in telling a story was understood
by the children as several games either had different levels drawn
or levels were mentioned by the children. A similar study
concentrating on story telling is being planned.
In many cases the children had not worked out the control
schemes for their games; how the toys were to be moved and
controlled by the players. When prompted they usually said "by
pushing buttons" or "by touching or dragging the toy". This was a
problem because by asking them to draw a program the children
were focussing on the images rather than the program control.
6. CONCLUSION
In order to make a programming app for children that has the
functions necessary to produce the types of programs that the
children want to make we allowed children to create drawings
depicting their programs. We then examined the drawings and
determined the functional requirements that our app would need
in order to make the production of these programs not only
feasible but simple. Using this technique we discovered a number
of new functions and elements which are being added to our 2D
physics and event based programming app to make it more useful
for children.
7. REFERENCES
[1] Snyder, L. Status update: high school CS internationally.
ACM Inroads, 3, 2 (June 2012), 82-85.
[2] Bell, T., Andreae, P. and Robins, A. A Case Study of the
Introduction of Computer Science in NZ Schools. Trans.
Comput. Educ., 14, 2 (June 2014), 1-31.
306
IDC 2015 Medford, MA, USA
[3] Wing, J. M. Computational thinking. Commun. ACM, 49, 3
(March 2006), 33-35.
[4] Soloway, E. and Spohrer, J. C. Studying the novice
programmer. Psychology Press, 2013.
[5] Kelleher, C. and Pausch, R. Lowering the barriers to
programming: A taxonomy of programming environments
and languages for novice programmers. ACM Comput.
Surv., 37, 2 (June 2005), 83-137.
[6] Maloney, J., Resnick, M., Rusk, N., Silverman, B. and
Eastmond, E. The Scratch Programming Language and
Environment. Trans. Comput. Educ., 10, 4 (November 2010),
1-15.
[7] Sheehan, R. Children's perception of computer programming
as an aid to designing programming environments. In
Proceedings of the Interaction Design and Children
Conference: IDC 2003 (Preston, England, 2003). ACM
Press, New York, NY, 75-83.
[8] Sheehan, R., Hendrickx, J. and Chiu, B. Fizz: A 2D Physics-
Based Programming Environment for Children. In
Proceedings of the World Conference on Educational
Multimedia, Hypermedia and Telecommunications 2010
(Toronto, Canada, 2010). AACE, 1408-1413.
[9] Sheehan, R. J. Moving a Desktop Physics-Based
Programming System to a Tablet. Presented at Interaction
Design and Children 2014 (Aarhus, Denmark, 17 June - 20
June), http://idc2014.org/wp-
content/uploads/2014/09/idc20140_submission_189.pdf
[10] Cypher, A. and Smith, D. C. KIDSIM: end user
programming of simulations. Presented at Human Factors in
Computing Systems, CHI'95 (Denver, CO, USA, 7-11 May).
ACM., 27-34.
[11] Wikipedia Contributors. Donkey Kong. Accessed: 16 March
2015 17:21 UTC.
http://en.wikipedia.org/w/index.php?title=Donkey_Kong&ol
did=650904125
[12] Wikipedia Contributors. Asteroids (video game). Accessed:
16 March 2015 17:39 UTC.
http://en.wikipedia.org/w/index.php?title=Asteroids_(video_
game)&oldid=646230753
[13] Guha, M. L., Druin, A., Chipman, G., Fails, J. A., Simms, S.
and Farber, A. Working with young children as technology
design partners. Commun. ACM, 48, 1 2005), 39-42.
[14] Moser, C. Child-centered game development (CCGD):
developing games with children at school. Personal
Ubiquitous Comput., 17, 8 2013), 1647-1661.
[15] Ryokai, K., Lee, M. J. and Breitbart, J. M. Children's
storytelling and programming with robotic characters. In
Proceedings of the seventh ACM conference on Creativity
and Cognition (Berkeley, California, USA, 2009). ACM,
1640240, 19-28.
[16] Onarheim, B. and Wiltschnig, S. Opening and constraining:
constraints and their role in creative processes. In
Proceedings of the 1st DESIRE Network Conference on
Creativity and Innovation in Design (2010). Desire Network,
83-89.