When Code Becomes Play
Appropriation in the Programming of Outdoor Play Spaces
Andreas Bergqvist
Subject: Human-Computer Interaction Corresponds to: 30 hp
Presented: VT 19 Supervisor: Jon Back Examiner: Annika Waern
Department of Informatics and Media
i
Sammanfattning
Barn får färre möjligheter att skapa och utforma sina egna platser att leka på då samhället urbaniseras.
Samtidigt förväntar samhället att de ska lära sig att programmera tidigare i livet. Barn leker oftare i designade lekplatser där man har färre möjlighet att bygga sina egna kojor och gömställen. Detta arbete utforskar hur programmeringsbara artefakter i lekplatser kan approprieras av barn i ett försök att ge barnen mer makt över lekplatserna. En prototyp bestående av tre insektsformade artefakter, ett programmeringsspråk, och en utvecklingsmiljö designades och utvecklades specifikt för denna studie.
Den utvärderades av 20 barn i åldrarna 8–10 år indelade i fem grupper. Studien tog plats utomhus i närheten till platser där deltagarna ofta lekte. Utifrån observationer av när prototypen utforskas och intervjuer med deltagarna gjordes en tematisk analys. Analysen resulterade i fem teman; kontroll över prototyper, fokus på sig själv, fokus på att stödja andra, social hierarki kring enheten, och användning av prototyper. Studiens resultat indikerar att programmeringsspråk och dess utvecklingsmiljöer inte bara är ett verktyg i approprieringen av lekutrymmet, utan även en del av kontexten som ramar in lek och kan där igenom approprieras i sig själv. Genom detta kan programmeringen bli en del av leken. Dessutom, designarbetet och utvärderingen av designen genererade insikter i hur man kan arbeta med och studera programmeringsbara lekplatser.
Abstract
Children get fewer opportunities to create and shape the places they play in due to the urbanization of society. Meanwhile, society has begun expecting them to begin learning to code at earlier ages. As more children play in designed playgrounds, they have fewer chances to build their own treehouses and hideouts. This study attempts to explore how programmable props in playgrounds afford
appropriation by children, in an attempt to give them more power over the playgrounds and their play.
A set of programmable playground props were designed and developed into a prototype. A prototype consisting of three artefacts shaped like insects, a programming language, and a development
environment was designed. The prototype was tested and evaluated by 20 children in the ages eight to ten divided into five groups. The study took place outside close to where the participants normally played. A thematic analysis was done on the observations of the prototype being used and the recorded conversations from group interviews with the participants. The analysis resulted in five themes;
control over the prototype, focus on self, focus on supporting others, social hierarchy around the device, and usages of the prototype. The result of the study suggests that programming languages and development tools are not just tools in the appropriation of play spaces, but also structures that can frame play. Through this, the programming becomes part of the play. Additionally, the design process and study generated insights on how you can work with and study programmable playgrounds.
Keywords
children; outdoor play; appropriation; digitally enhanced play; programming;
ii
Index
Sammanfattning ... i
Abstract ... i
Keywords ... i
Index ... ii
1. Introduction ... 1
1.1. Play IT ... 2
1.2. Research Question ... 2
1.2.1. Sub-questions ... 2
1.2.2. Scope and Limitations ... 2
2. Theoretical Background ... 4
2.1. Play ... 4
2.1.1. Stages and Behaviours in Play ... 5
2.2. Appropriation ... 6
2.2.1. Play in spaces and places ... 6
2.2.2. Sobel’s Approach to Appropriation in Play ... 7
2.3. Children and Programming ... 8
2.3.1. Graspable and Concrete ... 8
2.3.2. Syntax and Semantics ... 9
2.3.3. Relevance and Sociability ... 10
2.3.4. Programmable Toys for Children ... 11
2.3.5. Influences and Differences from Other Work ... 12
3. Method ... 13
3.1. Methodology ... 13
3.2. Design Process ... 14
3.3. Data Gathering ... 15
3.3.1. Participants ... 15
3.3.2. Gathered Data ... 15
3.3.3. Preparations ... 15
3.3.4. Procedure ... 16
3.4. Data Analysis ... 17
3.5. Ethics ... 19
4. Design ... 20
4.1. Design and Development Process ... 20
4.1.1. Conceptual Design Phase ... 20
iii
4.1.1. Concrete Design and Implementation Phase of Playground Objects ... 23
4.1.2. Concrete Design and Implementation Phase of a Programmable State Machine ... 26
4.2. Artefacts ... 27
4.3. Visual Development Environment ... 28
4.3.1. Programming Language ... 29
4.3.2. Example Code Sequences... 30
5. Empirics ... 31
5.1. Observations ... 31
5.2. Interviews ... 33
6. Analysis ... 35
6.1. How was the programmability of the artefacts used? ... 37
6.2. How do the children want the programmability of the artefacts to be used? ... 38
6.3. What appropriation takes place and what is appropriated when children program artefacts in play spaces? ... 39
7. Discussion ... 42
7.1. In relation to Scratch Nodes ... 44
7.2. Based on de Valk’s stages and Back’s modes of play ... 45
7.3. Unforeseen Design Implications ... 46
8. Future Work ... 46
9. Conclusion ... 47
10. Acknowledgements ... 48
11. References ... 48
12. Appendices ... 53
12.1. Information and Consent Handout ... 53
12.2. Information and Consent Handout - English Translation ... 54
12.3. Script for study and interviews ... 55
12.4. Script for study and interviews - English Translation ... 56
1
1. Introduction
In the last few years, urbanization and the structured urban play spaces have limited the number of places that children are able and allowed to appropriate [1]. Sutton-Smith [2, p. 84] describes play as a means towards empowerment and identity, and he raises the concern that children’s allowance to empowerment and identity through play is quelled by adults who experience a need to stay in control [2, pp. 111,124]. At the same time, the question of how to teach children to write code has become a topic of importance as more and more governments are attempting to incorporate programming in their primary school education [3]. While children of today will likely experience both sides, there is a lack of studies exploring the gap between the hustle to teach children to code and their loss of outdoor play spaces that they are allowed to control. During the last three years, works such as programmable toys for outdoor play [4] and teachable robots [5] have begun to explore this gap. Outside of the research done on Scratch Nodes [6, 7, 8], the current field of research is either focused on studying programming done in teaching environments [9] or attempting to turn programming into a mechanic in videogames [10]. It does not help that computer programming is regularly described as the tools and processes that allow us to create programs intended to solve the singular tasks we give them [11].
Maeda [12, p. 101] proposes that this is no longer the case; the use of programming has become an artistic medium with which we can express ourselves. The process of writing code can lead to creative results both in creating a program that is a piece of art [13] or by being an artistic act of improvisation [14]. As such, programming is no longer limited to software and web development, if it ever was.
Since it allows people to gain a sense of control, could programming be an alternative way for children to gain control and express themselves in play spaces? This paper aims to explore how programmable playground artefacts afford children’s appropriation. For the study, a prototype was designed and developed to allow for the exploration of these phenomena. It consisted of three physical artefacts with buttons, lights, and sounds, as well as an application that would be used to program them. The
artefacts were shaped like insects; a bumblebee, a butterfly, and a ladybug. The prototype was tested by 20 participants in the ages 8 to 10 to study how it could be used and how it was appropriated.
Figure 1: The artefacts being displayed at Play - the worlds kindest game festival [15] at Tekniska Museet, Stockholm
2
1.1. Play IT
This study is done within the context of the research project Play IT [16]. The aim of the project is to develop digitally enhanced play spaces based on how Internet of Things (IoT) gives users control over the communication over a network of artefacts. This is done to change public spaces and increase awareness of sustainable development. The project team is currently designing a digitally enhanced playground close to nature in Linköping, Sweden. This study aims to contribute to the project by providing intermediate-level knowledge regarding how programmable playgrounds can be used and how the programmability of them affords appropriation.
1.2. Research Question
This paper aims to explore how the programmability of playground artefacts is used, or more specifically:
• In what ways does programming of physical artefacts in outdoor play spaces afford children’s appropriation?
1.2.1. Sub-questions
To be able to explore the research question, the study will need to observe how the prototypes were used, interpret how they could be used, and identify initial signs of appropriation in the use of the prototypes. These objectives lead to the following sub-questions.
• How is the programmability of the artefacts used?
• How do children want the programmability of the artefacts to be used?
• What appropriation takes place and what is appropriated when children program artefacts in play spaces?
1.2.2. Scope and Limitations
The study will limit itself to study the programmable artefacts from the view of children in the ages of eight to ten. The age span was chosen based on four factors. First, children around those ages should be able to learn to program. This decision was based on Piaget’s stage of concrete operations [17], as by that age, they will have developed an understanding of signs, ordinal relations, and logical thinking.
Second, it is also during that age, that our fluency for play has developed to understand the mutability and how we can shape it. Between the ages of 7 and 11, children go from understanding rules in games as immutable to acting as if they are invented social constructs [18, 19]. During the same age span, children have begun invent and develop rules and continue to become better at it as they grow up [18, 20]. Third, children at that age have begun talking openly about their enjoyment of play spaces which will help in understanding how they experience it [1]. Fourth, Sobel [1] also describes that it is during that age that children shape most of their own places in the spaces they play in, in other words, it is the age when they appropriate play spaces the most. The sample will consist of children that attend a Swedish primary school. Since computer programming has been a part of the Swedish primary school curriculum since 2018 [3], the participants will already have been exposed to
programming to some degree. However, due to the recency of this addition to the curriculum, it is not standardized yet how it should be implemented in the education and different teachers and schools have introduced the subject in different ways. The sampling was done through a combination of self- selection sampling and snowball sampling [21, p. 98]. The self-selection sampling gets parents and representatives for groups of organized youth activities to volunteer and they can refer their kids or the
3 children they work with to the study. The study will have further practical limitations based on
adhering to the sample’s convenience [22, p. 478].
This study will be limited to an outdoors space that exists in close vicinity to spaces the participants already appropriated into their own play spaces. A playground is a place designed to afford and elicit play among children and does so through the physical, social, and technological or digital space [23].
It is a physical space that usually contains props that are designed to be both open for and preventing the appropriation of play. In this study, the props will be placed in a natural space that has not previously been designed for play to make up a simple playground. This was done to not have the results be affected by any previously designed affordances1 of the space which the study is done within. The playgrounds are social places created, structured, and transformed by those who play there and their parents, and if they are enhanced with digital technology, they have an additional layer of digital space [23, 24, 25, pp. 6, 50]. Since the playground will be temporary and built specifically for this study, the existing social structures of the space should not yet be conformant to limit how it is played in. The digital space will be created from and limited by the technology that it exists within.
For this study, it will be a set of custom designed playground props and a digital tool that can be used to program these props.
Physical artefacts refer to the toys or props that make up the playground. The programming of the physical artefacts will be limited in what it can do. While the Play IT project is centred around IoT principles, this study will build the artefacts as part of a state machine as it will simplify the process of designing it and creating a functional prototype. From a technical standpoint, simple IoT-systems and their component can be seen as state machines [26]. Each artefact can be in one state at a time and they have a finite number of states to choose from. A state is a unique combination of outputs. The system transitions from one state to another based on any inputs it has been given. For most state machines, the users are only able to interact with it through the inputs. A reprogrammable state machine, which is how the artefacts in this study will function, gives its user control over how the logic of how the inputs translates into a state. As such, in this study, a state machine will simulate the IoT-environment in order to simplify the development and its role in the study. The reprogrammability of the artefacts will be limited to controlling the logic of these sequences of translations.
Appropriation refers to the act of making something your own. Appropriation is often considered something that happens over longer periods of time as designs are adopted and practices evolves [27].
This study will not be able to examine appropriation over the time it normally requires to take place. It will instead be limited to explore what initial signs of appropriation that can be observed. In other words, it will focus on the indications that can be observed which could be, lead to, or be caused by acts of appropriation.
1 Affordance refers to the possible ways an artefact or design allows us to use it [61]. The importance is not what the design signifies you can do with it but how it allows us to use it. We can use it even if we do not know that it could be used that way. A signified affordance is an openness to be acted on that we can perceive [61]. We can focus our attention on either part by explicitly stating the perceivable signifier or the affordance that can be acted on.
4
2. Theoretical Background
This chapter details three different areas that together shape the context for this study including its design process and discussion. These three areas are play and its framing structures, the appropriation that takes place within play, and the current state of children’s programming.
2.1. Play
While Piaget [28, p. 147] expressed that play is problematic and complicated to define, he have also suggested that play is nothing more than a mode of learning; an act between assimilation and accommodation, through which we experience emotion and learn about the world [17, pp. 94-95].
According to him, assimilation and accommodation are the two processes used when we create and organize structures of knowledge and build upon them [12, p. 30]. When meeting new stimuli in our world we can either try to assimilate it into an existing schema or change or create a new schema to try to accommodate it. Simply put, we cannot learn from nothingness as we need to experience our contexts and we build on what we know. According to Sutton-Smith [29, p. 104], Piaget’s attempts to reduce it into a part of the learning process only manages to describe a single facet of play. Other strict definitions of play have been suggested by, for example, Huizinga [30]:
“Summing up the formal characteristics of play we might call it a free activity standing quite consciously outside “ordinary” life as being “not serious,” but at the same time absorbing the player intensely and utterly. It is an activity connected with no material interest, and no profit can be gained by it. It proceeds within its own proper boundaries of time and space according to fixed rules and in an orderly manner. It promotes the formation of social groupings which tend to surround themselves with secrecy and to stress their difference from the common world by disguise or other means.” [30, p. 13]
Another was given by Caillois [31]:
“[…] it appears to be an activity that is (1) free, (2) separate, (3) uncertain, (4) unproductive, (5) regulated, and (6) fictive, it being understood that the last two characteristics tend to exclude one another.” [31, p. 43]
These two definitions of play are limiting in what they encompass while still being vague. Within these two definitions, play includes a wide group of activities, actions, and phenomena which
encapsulate numerous facets and qualities, and could be experienced from as many viewpoints. These definitions tell us, in the words of Sutton-Smith [2], that play is ambiguous. While being aware of this multilateral definition, this study will use a more actionable definition. As such, it follows how Sicart [25, pp. 1-2] defines that play is situated and is the link between those who play and the structures they play with and within. He further proposes that while objects to some level affords being played with [25, p. 19], designing artefacts for play is simply assuring that the artefact signifies and elicits that it can be played with. Play will then happen and manifest itself when the object is appropriated to be played with [25, pp. 27, 31]. Through this, appropriation is a central aspect in play. In the same way as play cannot be designed and only designed for, we can only design for appropriation and not design appropriation directly [27]. It is up to the person who uses the design how they appropriate it. On the other hand, appropriation is not instant as it takes place over time and it can take many different shapes [27], and Sicart [25] gives little practical insight into how the situated structures that frame play
5 are interacted with. This definition will therefore not be sufficient for this study on its own. To expand on it, the following chapters will detail how we proceed through play and how we interact with the framing structures before providing an actionable approach to understanding appropriation.
2.1.1. Stages and Behaviours in Play
While Sicart’s [25] definition is helpful when designing for situated play, it does not cover how play develops over time nor does it give further details on how play interacts with its framing structures.
Two different studies will be addressed to cover these gap; de Valk’s [32] stages of play for how play develops over time, and Back’s [24] work on transformative play for how play is an interaction with the framing structures. Together they will help in designing the artefacts and application for the study as well as give a foundation for understanding the play that emerges during the study of the design.
De Valk et al. [32] suggest that play can be divided into four ordered stages; invitation, exploration, immersion, and social interaction. Play starts with an invitation to begin playing. This invitation is coming through the signifiers in the framing structures that communicate that they afford being played with. It is described similarly to the invitations that we design according to Sicart [25]. That invitation leads to exploration of what the play and its structures entails [32] and this exploration is often
spearheaded by a curiosity [33]. When the player has developed a self-efficacy and agency2 within the framing structures, they can immerse themselves within those structures. The last stage consists of the social interactions that take place after you are done playing based on the meaning created by play [32].
According to Back et al. [24], play is an ever-changing transformative act that engages with the structures that frame it. This means that play is a continuous balance act between four modes of behaviours; conformant, transgressive, creative, and explorative. Conformant play is play in a traditional sense; the ludic immersion within these structures. Explorative play is the activity of curiously trying to understand the limitations and exceptions of these structures. Creative play is the invention and manipulation of the framing structures. Lastly, transgressive play can be seen in the acts that breach these structures. Therefore, play is situated as it engages with the social, physical, or digital structures that frames it [23, 24, 25, pp. 6, 50]. It takes place in social and physical contexts that can be technically augmented and each of these contexts affect how we play. Through these modes of play, children can become co-designers of their own play as they can design, explore, and break the structures and frames while playing.
This division between the order play goes through and the different modes of interactions within play will help in addressing the play that ensues during this study. As a stage of exploratory play is required before play becomes immersive [32], it can be expected that players will begin with exploring the playground and the artefacts. It is first after the initial stage of exploration that an immersive stage of play has the possibility to ensue. Play is open-ended in how it allows the players to explore and invent their own games, rules, and experiences [32]. It is without predefined rules and allows meaning to be created in the act of playing [34]. Similarly, the modes of transgression, creativity, and exploration build on the idea that play can be curious and open-ended [24]. The design process of this study aims to create a malleable set of artefacts that elicit curious and open-ended play through interaction with the physical and digital structures those artefacts provide within the playground. As these actions of
2 Agency is our ability to act in specific situations, while self-efficacy is the belief that we can successfully do so [32].
6 appropriation occur in creative, explorative, and transgressive modes of play, the ensuing play and framing structures should therefore be designed for transformative play.
2.2. Appropriation
Appropriation is a process of adopting, adapting, incorporating, or controlling an object or context or using it as a means to empowerment, self-expression, mastery, or exploration [1, 25, 35]. While the word appropriation is often seen with a negative connotation [36], it does not need to be [27]. Studies have surveyed how players of live action role-playing games appropriate technology for their own ends [37]. Guerrilla art and graffiti, while often being acts of vandalism, are also seen as appropriation of spaces for self-expression [38].
As previously mentioned, Sicart [25] describes appropriation to be a key component to play. He describes toys as things that elicit playful appropriation of spatial, digital, and social contexts and playgrounds as spaces that both afford this appropriation while also restricting it. As such,
appropriation of framing structures is a common way of playing, and Sicart illuminates that it is this play through appropriation that makes it meaningful to us [25]. Similarly, Piaget [17, pp. 94-95]
argued that play and make believe are simply the appropriation of concrete objects into semantically similar schemas. It is this playful appropriation that brings us emotional stability and helps us find our place in the world. And, Sobel [1] suggests that the appropriation of spaces for play leads to a sense of ownership, of self, and of our place in the world, through experiences of wonder and exploration.
Further, appropriation of the framing structures develops our agency and self-efficacy within those structures and is experienced as a sense of mastery and control [2, p. 185, 24, 39, p. 24].
It is then to be expected that appropriation can lead to conflicts. Social conflicts are part of the structures of human society and while it easy to see them as detrimental, we benefit from them [40].
This does not imply that conflicts are always good; they can both turn us away from trying things again or become dangerous when they escalate [41], or cause long grudges when not properly resolved [42]. That said, without conflicts, we would neither know about the tensions in our relationships, have the means to assess our issues and situations or be able to solve them in constructive ways [40]. The conflicts in our childhood are limited with low stakes [43]. The most important conflicts for children are the fights over the shovel in the sandbox or over who's turn it is to use the swing, and in most cases, they don’t stop play from continuing [43]. Children learn how to resolve conflicts in constructive manners by experiencing them [44]. Further, Kriesberg and Dayton [40] argues that conflict is fundamental to humanity but adds to this that our experiences are based on the conflicts and resolutions within our lives. In similarity to this, Dalsgaard [41] suggests that experiences such as being moved or thrilled require risks that can only be found within conflict. Competitions, while being similar to a conflict, are defined by being solved by one part winning while the other loses [45]. A conflict is open-ended, but competition is often bound by a limited number of end scenarios. That is not to say competitions are bad. It lets users experience and express a sense of mastery and superiority, and a sense of identity to the group in team competitions [2].
2.2.1. Play in spaces and places
We learn about ourselves through the spaces we appropriate, and make into our own places [1, 46].
They give us a social meaning in our lives. The personal ownership of a place and the secret personal knowledge of it also lets that space become a personal sanctuary to escape to [1]. During the concrete operational stage, the expressive acts of shaping, structuring, creating, and being in control of such places makes it a concrete representation of the abstract self by being a place to discover yourself and
7 your place in the world within [1, 47]. One of the first such spaces that we can encounter are our playgrounds.
Playgrounds are places that have been designed to allow certain types of play. They allow for play in how they are designed to afford some types of appropriation and resist others [25]. These resistances and affordances are not designed for singular activities nor to support every kind of activity. There is a sweet spot were the playground truly elicits play and appropriation by signifying what you can and cannot do. The ambiguity created between the affordances and resistances are what makes it worth exploring and appropriating [25]. Play, like most things, affects and is affected by the context it takes place in [25, pp. 6, 50, 48]. The technology, the social interactions, and the physical space all inform the activities in play. This can be seen in how playgrounds and play spaces inspire the play in them.
They signify what we can play in them and we change the spaces and places we play in through the act of playing in them. But the spaces are not free from social contexts as regulations and social
conventions create resistance in them [25, p. 53]. A playground in a city or suburb does not afford the appropriation of building a fort the same way a space in a remote forest or backyard would, but Sobel [1, pp. 89-90] suggests that children find ways to circumvent the lack of affordance and appropriate these spaces anyway. To supplement this, places do not need to be designed to afford and resist appropriation as children find their own spaces to create or appropriate anyway. According to Sobel [1], the first real spaces that we are allowed and able to appropriate are our tree-forts and secret hideouts. It is between the ages of eight and eleven that children build and shape most of these places.
They can either be shared by a group or exists as a private space. Multiple children can have private places that coexist within in the same space without causing conflict or interaction. During these years of their lives, children structure their world by appropriating it in order to make it into a place where they can find themselves [47].
2.2.2. Sobel’s Approach to Appropriation in Play
Sobel [1] does not explicitly define the following structure of approaching appropriation of play spaces nor defines it as a taxonomy. That being said, in his cases studies of appropriation in play spaces, he keeps coming back to three aspects of how children make space theirs. These aspects will help understanding and discussing any appropriation that was found during this study. The three aspects are who is doing the appropriation or sometimes who it is done for, the thing or place that has been appropriated, and the way which the appropriation is done. These three aspects will from here on be denotated as subject, object, and verb. As the subject, Sobel [2] discuss both the individuals and groups that took control over their play spaces. Most of the children that partok in his work either appropriated the spaces for themselves or for the group of children that they were part of. But, he also notes that these actions are not always made for making something yours, but that they could also be vicarious, on the behalf of someone else. This could be seen as a sort of indirect appropriation or appropriation by proxy. The object of appropriation depends on the context. In Sobel’s [1] work, this would be how he primarily describes the spaces and objects that are appropriated. In a more open context of play in play spaces, the object would presumably be a part of the framing physical, social, or digital structures [1, 24]. The verbs are the core of the appropriation and describe how appropriation is done. For example, Sobel [1] discusses how the construction of tree houses are acts of expressing and finding yourself, becoming the owner of something both physically; the space where it is built, and cognitively; our secret knowledge of its existence. But appropriation, as previously seen can include a variety of other actions; most notably finding ways to use the object for the subjects to gain agency and self-efficacy [25, 39], making the object fit to the needs of the subject [1], and exploring or expressing the subject through the object [1]. These types of actions are actions occur in creative,
8 explorative, and transgressive play and they change the structures that frame conformant play [24].
Take the example of two children that are building a tree-fort in their backyard. Through constructing it, they have made that backyard and tree their own. If you apply this denotation on this example, the subject would be the group of children who appropriated the space together. The verb would be in the construction of the tree-fort, but would depend on the intentions of the children. Are they doing it to express themselves, to fit the space to their needs and play, to get a sense of themselves or of ownership over it, or something else? Lastly, the physical space of the backyard and the tree are the objects that has then been appropriated.
2.3. Children and Programming
In addition to play and appropriation, the study explores the programmability in play spaces. In order to give a foundation for it this chapter will detail and describe the current position of children’s programming. While few studies have yet connected it to play, programming aimed at children has been studied for the last fifty or so years. Logo [49] and Smalltalk [50] where two of the first programming languages aimed for children. Since then, multiple programming languages have been designed for the same audience. Every now and then, some of these has found new ways to make the first steps into programming easier. This section will first detail the trends in children’s programming languages and previous research on programmable toys, before detailing how this study will stand in its relation. Many of the trends introduced in the following chapters have become the common way for how later programming languages for children are implemented. A structured understanding of the trends and previous research will be useful during the design process as it can help motivate design choices. It will also be foundational during the discussion as it can help understand how the programming of the design is used in relation to what has been done before.
2.3.1. Graspable and Concrete
The early programming languages for children in the late 60s [49] and early 70s [50] were designed closely to previous programming languages. They build on similar syntaxes and terminologies and Logo [49] was even based on the language Lisp. But according to Papert [49], it is due the lifework of Piaget that he developed Logo. He was inspired by Piaget’s concept of the concrete operational stage.
This stage, around the age of seven to eleven, is when children begin to develop the ability to logically process and think “about objects that do exist and have real properties, and about actions that are possible” [51, p. 6]. Papert [49, p. 187], through this, saw how programming could became concrete through an object the children can relate to; a turtle. He built Logo around the concept of turtle graphics; he phrased programming vector graphics to guiding a turtle that leaves a path after it. At first, he used a physical turtle that rolled around and drew on paper, but with time, this developed to a digital representation of the turtle. He even tested Logo with children as young as four years old and they managed to program simple turtle graphics with their limited vocabulary and literacy [49, p. 229].
Papert [49, p. 7] introduces the idea of learning to acting and exploring when he discussed Logo in relation to Piaget’s developmental theories on constructive learning. While he refers to children as builders of their own knowledge, he describes how we through acting construct the means we have at our disposal [49, p. 173]. Later, when Kay [52] based Smalltalk on the previous work on Logo and Papert’s early studies on teaching children programming, he noted that “[…]we make not just to have, but to know[…]” [52, p. 29].
Furthermore, Piaget [17, p. 162] suggested that children around the age of six to seven, the pre- operational stage, developed an understanding of ordinal relations. This can for example be seen in
9 how a child in that stage is able to order a set of cubes by size. But sorting out the possible subsets from a set, which seems like a similar task, takes a lot longer to develop [49, p. 22]. Papert [49]
suggests that this is due to that type of logic requires knowledges of systematic procedures which are uncommon to meet in our daily lives. But, he continues, for those who write code, this is a trivial task as it is requires a systematic process that they are used to as they know of “nested loops” and “bugs”.
A similar process that would be hard for children to assimilate or accommodate is that of compilation.
Logo and Smalltalk are, based on this and the concept of the concrete operations, are imperative; their code is structured by order of execution. While they have their differences; Logo only uses procedures while Smalltalk is object-oriented which let users factorize the code into smaller, more manageable pieces. neither of the languages were compiled. The language Logo is based on, Lisp, is interpreted.
Smalltalk, on the other hand, uses just-in-time (JIT) compilation. For users of either language, this meant not having to go through compilation before running the code. One step that was normally part of the process of programming was through this ignored. You could go directly from writing the code to see what happen when you run it, instead of having to wait for the code to compile into an
executable application. As compilation often lacked transparency, it provided the user more insight when things went wrong. Another benefit of interpreted languages is that you can modify them while the code is running. Due to this, the development environment does need to have multiple different states which reduces what the programmer would need to learn.
2.3.2. Syntax and Semantics
Smalltalk and Logo have a syntax similar to programming languages not aimed for children; their syntax consists of written text. While this gives the programmer a freedom in how they choose to write the code, it requires a higher understanding of the syntax and the semantics of the code. Later
programming languages have begun turning away from this. AgentSheets [53], a tool for designing games, was initially based on programming by example. Instead of writing the code directly, you recorded actions and the system translated the recorded action into a rule. For example, consider a train that is moving along a track. When it enters a track that is turning, the user could record that the train should turn. The system converts this to a rule that trains turns when the track turns. This system allowed the user to define the logic semantically, and leave the syntax to the system. AgentSheets 3 [53] further innovated on this by constructing the application to be conversational. It helps the user avoid semantical errors by always, non-intrusively, explain the meaning of the current code through a type of conversation with the user.
AgentSheets later began to use drag and drop to construct rules of building block. Each draggable block was similar to a puzzle piece, it had specific ends that could only be attached to the opposite, matching ends. Each also had an icon or a piece of text to describe what it did. This allowed the constructed programs to always be syntaxially correct as it was impossible to have incorrect syntax [54]; you cannot fit a square peg in a round hole. Since the code can only be constructed in ways that are syntaxially correct, it promotes that it should be constructed in semantically meaningful ways [54].
For example, parameters can only be placed in functions that can take them. Concurring with this, there has also been a decrease in the available number of commands which limited the scope of the syntax.
AgentSheets also walked away from the imperative structure of code and is instead declarative. This means that it does not specify order of execution. Instead it is based around a rule-based system where you set the results of specific occurrences. For the previous example, the rule says that when a train enters the turning track, it will turn. Later languages such as Lego Mindstorms [55], Scratch [54], and
10 ScratchJr [56] are instead event-driven. An event-driven programming language can be seen as a combination of the rule-based declarative paradigm and the imperative paradigm. In an event-driven language, you write imperative sequences of code and define on what specific occurrence that sequence will be triggered. The system then sits and listens for these occurrences and triggers the corresponding sequence upon noticing it. The main benefit with event-driven, is in how the user will mostly only need to focus on the parts of their project that they are currently working on [56]. Each sequence is in a way independent as it represents a complete process of actions. In an imperative language, you would need to keep in mind when in the order of execution that the current line of code would trigger. In a rule-based language, you would need to understand how each separate rule would interact.
2.3.3. Relevance and Sociability
The last big trends in programming for children came with Scratch and Scratch Jr. The publicly available guidelines for Scratch [57] and ScratchJr [56] detail the main goals with how they were designed. While parts of them relate to what is done before in the field, they contrast themselves in how they emphasize the social and meaningful aspects of programming. In total, they include seven guidelines; affording and eliciting tinkering, low floors, high ceilings, wide walls, conviviality, meaningful to the user, and elicit social interaction. Some of these are based in the earlier trends in children’s programming. This can be seen in the guideline about tinkering which builds, like Logo [49] and Smalltalk [52], on Piaget’s ideas on constructivist learning. We learn and are inspired to learn through doing. By giving the user an early self-efficacy with the tool, they are able to want and dare to explore and build towards what they don’t know.
The low floors, high ceilings, and wide walls are generalised ways of describing how the
programmable space should be defined. The guideline on low floors builds into the previous ideas of removing the complexities of for example syntax, imperative execution, and compilation. By having to keep track of fewer things that children are not as well versed with [49], they will be able to focus more on what they find meaningful [56]. Additionally, the three guidelines on the programmable space can be seen in the available set of commands in the two languages. The available commands are designed to be limited enough to give a straightforward entry point in to programming, open enough to be used in individually meaningful ways while still providing commands that step up in complexity to elicit tinkering and allow for growth [57, 56]. This can be seen in the division between types of commands available in the languages. ScratchJr has seven blocks for event listening and stopping the process, 18 for meaningful interactions, and only two for abstractly interacting with the flow of code.
Scratch takes this further with its total of 75 types of blocks which includes more abstract pieces of logic such as relational and logical operators, ways of working with strings and variables, and more ways of interacting with the flow of the code. Further, ScratchJr is also designed in order to not require literacy to keep the floor low, as it was shown to increase the initial threshold for young children [56].
Instead of being text-based, it tries to use pictures and icons to represent all blocks in the language.
With the colourful visuals and iconographic blocks, ScratchJr tries to use convivially invite you to want begin tinkering [56]. But the guideline on conviviality reaches beyond that. It is also that the available commands should be apparently meaningful to the user, and that the user should be able to find how to make the programming their own “whether artistic, programmatic, or narrative, and to proceed in ways that suit children’s individual styles of creating and learning” [56, p. 8]. In a way, it is described that programming for children should elicit to be appropriated. While ScratchJr uses the guideline of conviviality, Scratch [57] instead bluntly says that it aims to be meaningful through being
11 usable in diverse ways and that it can be personalized to be made your own. This will allow the user to express themselves and further focus on programming things they care about.
The Scratch guideline for making it social and for supporting social interaction describes how it should be sharable and that they need to provide the infrastructure to provide a social platform around it [57]. They describe the provided social space as a room for discussions and reflection and for remixing and building on what others have done previously. While this guideline is implemented on the systems surrounding the development environment, they do not describe if it has also been applied on the programming language and development environment themselves. This guideline could be implemented on the language through making sure that it is designed to provide a shared social foundation for its user. One way of doing this would be to find intersubjective ways for assimilating each block and piece of the language into the user’s schemas [58].
While the first two groups of trends focused more on the language being accessible and effective for children, these put much more emphasis on the full experience and meaning they provide to the user.
For example, the guideline for conviviality focus on inviting you to program through it being meaningful while the guideline on it being more social instead focuses on the social interaction and reflection that follows usage. Together these two guidelines focus on the user experience outside of the direct usage of the language. Additionally, most of the Scratch [57] and ScratchJr [56] guidelines focused on providing something that can be made your own and that would be meaningful to you.
2.3.4. Programmable Toys for Children
There are few attempts to study the gap between play and children’s programming. While Lego Mindstorms has existed for more than 20 years [55], most research on it relates to how it can be used in the education and how it promotes learning programming [59, 60, 61]. Instead, the most noteworthy research on the gap between programming and play are the studies on the design Scratch Nodes [4, 6, 7, 8]. Scratch Nodes is a design consisting of a development environment based on the programming language Scratch and a physical artefact controlled by the code written in the development
environment. This design solution has been studied multiple times by Hitron et al. [4, 6] and Ofer et al.
[7, 8]. According to Hitron et al. [6], the artefacts inherited a tangible manifestation of the code that was developed. In these studies, the process of rule invention becomes a type of appropriation of the designed artefact. The design process and early evaluations of the prototype Scratch Nodes showed that the prototype should be a platform for game invention and enable playful creation of rules [4].
The effects of programmability on aspects of play were later evaluated, and the study showed that digital structures around play could compromise social interaction, physical activity, and creative thinking [6].
Ofer et al. [7] examined how children interacted when programming artefacts intended for play. They gave children ten minutes to individually explore the prototype, then, in groups of three, the
participants were asked to start coding and exploring the prototype without further direction. The results showed that the coding environment caused two sequences of behaviour; basic exploration to advanced exploration and basic exploration to game invention [7]. They used basic exploration to describe an initial exploratory learning process which resulted in a self-efficacy and agency with the prototypes [32, 39]. Advanced exploration was used to describe the secondary exploratory process after you to some extent know what can be done and it is aimed towards finding the limits of the framing structures. In Ofer et al.’s study, [7] advanced exploration of digital structures resulted in the children beginning to disregard and ignore the physical space and play. Game invention was used to
12 describe a creative modification of the artefacts as part of play [7]. In a later study on Scratch Nodes [8], the researchers introduced the artefacts and gave examples of ways the prototypes could be played with. The participants in groups of three were then given 60 minutes to explore and invent games. This time, all participants managed to switch between “heads up” and “heads down” behaviours without beginning to ignore the physical space or play. Ofer et al. [8] uses the terms “heads down” to describe activities that are focused on a device with a screen and “heads up” to describe the activities were the focus is outside of the device. While these four studies have started exploring how children use programming to take control of their play, they only focused on the processes of programming and inventing games, interactions with the toys, and the interaction between the artefacts and the programming. That being said, this study differed from their work as it focused on the interactions related to appropriation of programmable artefacts that were built into the environment.
2.3.5. Influences and Differences from Other Work
To conclude, programming languages aimed for children have step by step tried to simplify and remove the complex processes which are normally found in programming languages [56]. This has been done in order to reduce the threshold which prevents people from beginning to tinker with code.
First by removing the compilation step and by keeping the subject matter graspable and concrete, then by reducing the risk for syntaxial and semantical error, and lastly by removing the more complex parts of the code base as well as the need for literacy. Even so, the oldest and least forgiving of the
languages aimed at children, Logo and Smalltalk, have been successfully used by the youngest user of the languages looked at here [52, pp. 25-29]. At the core of all these programming languages are, in similarity to in play, the eagerness to tinker and learn which is found in exploration and constructivist learning. The designer’s role is to shape the invitation to elicit you to start and limitations that elicit you to continue, as the act of programming will manifest as it is then tinkered with.
To further contrast this work from the previous work on programming for children, this chapter will detail the similarities and contrasts that was chosen. To begin with, the design in this study was built out from the design guidelines of Scratch [54] and ScratchJr [56]. It, in addition, referred back to Piaget’s [17, 28] theories on learning similarly to how Papert [49] and Kay [52] had done when they began to explore this topic. Beyond the differences and similarites expressed here, both the design and design process are further detailed in chapter 4.
The design centred around physical and concrete objects intended for play, the insect shaped artefacts, similar to the building blocks in Lego Mindstorms and the remotes in Scratch Nodes. The designed artefacts were designed to be able to interact with each other; you programmed a group of them to work together. Since they are spatially separated, you through this get a sort of malleable control of the physical space and not only the artefacts [62]. The main difference in the subject matter is that the artefacts in this study was designed to be stationary to build into the physical space, and could not physically be rebuilt into something else, but where each object were interconnected with the other objects in the design. The toys in Scratch Nodes are mobile remotes that can be thrown and moved around but are not connected to the space they are used in nor to each other. The Lego blocks of Lego Mindstorms is not forced to be in any specific shape or form as it can be built and rebuilt, and is not directly bound to the space even if the space affects how it can effectively be built. This design assumed that multiple different artefacts would coexist and interact in the same programmable space.
This was inspired by how IoT systems assumes that each part of the local system is in a way interconnected [26]. Based on the Scratch guidelines, the artefacts were also visually designed to be
13 meaningful and afford social discussion. In contrast to the artefacts in Scratch Nodes and Lego
Mindstorms, the artefacts in this study aimed to be visually different and to support
Similar to Lego Mindstorms, Scratch, and ScratchJr, the development environment and programming language was designed to be event-driven and interpreted. This is done to keep the initial threshold low when to starting using the design by removing a compilation step, keeping the development environment in the same state during any interaction, as well as allow shaping the code at the same time as the code is running. In the same way as Lego Mindstorms, Scratch, and ScratchJr, the programming language was further designed to use drag and drop interaction to prevent syntaxial errors. It also used blocks with icons instead of text to not require literacy in Swedish or English and keep the floor low, which is similar to ScratchJr and Lego Mindstorms. The main differences in the language are in the depth and complexity it allows. The language created for this study has 21 command blocks; three of which are for starting running a sequence of code, nine are for actions, six are for controlling the flow of the code, and the remaining three are for arithmetic operations. It through this has more commands for controlling flow and arithmetic operations than ScratchJr but fewer choices of actions. The command blocks support interacting between the three artefacts which Scratch Nodes lacks, but otherwise their set of commands are rather similar. It has less commands and complexity overall compared to Lego Mindstorms.
3. Method
In this study, a prototype was designed to allow studying how programming of physical artefacts in outdoor play spaces afford children’s appropriation. The data gathering of the interaction with the designed system consisted of situated observations and interviews. The gathered data was then analysed through a thematic analysis. This chapter will explain the reasoning for the choice of
methods, provide a structural overview of the design process, detailing the data gathering and analysis methods used, as well as the ethical considerations that went into this project.
3.1. Methodology
This study seeks to explore and describe the afforded appropriation that followed the introduction of programmable artefacts into a play space, and as such does not intend to cover the frequency or generalizability of its findings, nor to prove any causal relationships [63]. As such, it aims to
understand what appropriation can happen, but not what appropriation should be expected to happen.
First, a functional programmable prototype is needed for this study. Additionally, it needs to be able to be introduced in the play space. There are currently few development environments for children available that can control physical artefacts. None of the existing solutions would effectively allow studying how they are appropriated. The two noteworthy solutions would either be Lego Mindstorms or Scratch Nodes. Lego Mindstorms is not open source and could therefore not be easily modified for this study, and Scratch Nodes is not publicly available. To allow for the initial appropriation and usage to be studied, a custom prototype was designed for the study with those intentions in mind. Knowledge is created alongside the designed product in the process of designing and developing [64, p. 167]. As such, the design process becomes a way to further learn about the subject at hand. By recording the process, those recordings allow that knowledge to be used and reflected on later [65].
Secondly, the programmable prototype needs to be tested by children to see how it is used in a play space. First, the participants will need to experience the design to learn about it. This is based on
14 Piaget’s [28] concept that we build personal knowledge through assimilating and accommodating what we experience [17]. By doing an experiment in which participants are invited to test and explore the artefacts, they are provided the possibility to create an understanding of the programmable artefacts and the programming language. Second, the study should be done in real context where the
participants can socialize while testing the prototype. This decision builds on the assumption that knowledge and action are social in how they are used and therefore become situated in the social, material, and digital contexts they exist within [17]. In addition, by letting the participants work with people they know in a space they are familiar with, the researcher can limit new stimuli, impressions, and pressure that otherwise comes with taking part in a study [66]. A risk with this is that the
participants existing social structures would accompany the group into the study [66]. Further, letting the prototype be explored by a group in a real environment allows observations of how the artefact affect the social and physical structures of that play space in addition to observations of how the artefact is used. Third, as we act and experience the world through the temporary frames we are given or assign ourselves [67], the participants actions and experiences would be affected by the way the participants’ tasks and role in the study are defined. Through this, their learning of the design is affected by the frame the researcher gives them. The framing was chosen to elicit both playful and transformative behaviours through attempting to frame the participants as co-designers and as someone who knows play [24, 67]. This framing also aimed to communicate to the participants that their effort and contribution was meaningful and important for the project. Since the study builds into the affordance of empowerment in play and it would be contradictory to work for it without embracing it [25, pp. 6, 50], this framing was also chosen to embrace how ethnography and participatory design both allow for communication between the participant and the researcher or designer [64, p. 172, 68].
Fourth and lastly, as the study does not aim to be generalisable, it is not necessary to have a random and representative sample, which means that a non-probability sampling method can be used.
The gathered data will be analysed through a thematic analysis using an inductive approach to coding.
This is due to that the study aims to explore how programmable playground artefacts afford appropriation. While there exist theories on transformative [24], curious [33], and open-ended play [34] as well as playful experiences [32], the explorative nature of the study would be at risk by beginning with a purely deductive analysis since the gathered data would mostly be assimilated into the themes that was constructed from theory [69]. Therefore, the thematic analysis will inductively develop the themes based on the patterns found in the codes instead of deductively fit the codes to predefined themes. As the researcher who performs the analysis will always do it based on their schemata and will in that sense never truly have an open mind, there is a risk that the results will be affected by a subjective bias. While this bias could be limited by having multiple researchers perform the analysis, that won’t be possible with the limited resources of this study. The results of the
inductive thematic analysis will then be addressed based on the structure of subject, object, and verb derived from Sobel’s [1] work on how treehouses are made into the child’s in order to more precisely relate the results to signs of appropriation.
3.2. Design Process
The design process consisted of a conceptual design phase and a concrete design phase. The
conceptual design phase included explorations of the materials, brainstorming on the design space, and reviewing literature on for example play, programming for children, and appropriation of spaces. The concrete design phase included sketching of the physical artefacts and the scripting language, expert interviews regarding the complexity of the scripting language, and implementing and testing the prototype. The steps of these phases were documented and are further detailed in chapter 4.1. The
15 documentation was primarily done through field notes. The notes were taken during the design process to preserve the knowledge created with the design process and to get a better understanding of the process, the designed prototypes, and their properties [64, p. 169]. The notes were taken to cover the steps that were taken, the problems that were encountered, the choices that were made, and the insights gained during the design process. The process resulted in a design that consisted of three physical artefacts that were shaped like insects and a visual development environment and programming language.
3.3. Data Gathering
The designs were explored by letting 20 children in the ages eight to ten test the prototypes and discuss their experience with them.
3.3.1. Participants
The participants were part of a Swedish scout troop. The troop consisted of approximately 30 scouts between eight and ten years old. Of the 21 scouts that attended the meeting that day, 20 had gotten consent from their parents and agreed to partake in the study. Of the 20 participants, there were eight girls and twelve boys. The scout troop was already divided into five patrols with four or five children each as it has been shown to be an effective number for both group interviews and group work [66].
The scout troop was found through a notice asking for participants in the ages of seven to eleven that was passed along through referrals and social networks. The notice contained a description of the study and an approximate span of time in which it could be done. A leader of a scout troop replied to the notice. After further informing them about the study, they agreed to have the troop partake in the study. An email was sent out to the parents of the scouts through the leader. It contained information about the study, contact information, and requested that the parents replied if they gave their consent or did not want their children to partake (see appendix 13.1, 13.2).
3.3.2. Gathered Data
During the tests, four types of data were gathered.
• Log-files were automatically generated on the tablets with the development environment.
They include timestamps of the actions taken in the environment and when the buttons were pressed. Each entry detailed the actions that had been taken.
• Video recordings were captured with a video camera placed to overlook the space in which the artefacts were placed. The recordings captured the sessions in which the participants explored and used the artefacts.
• Audio recordings were captured with a smartphone during the interviews.
• Field notes collected during the exploratory session covering observations and gained insights.
3.3.3. Preparations
The leader was involved in planning the observations and interviews to make the study practically feasible during one of their meetings. The procedure had to be planned to adhere to the structure of their meeting and to prevent any scout from feeling excluded. The scout meeting was structured around a set of activities spread out over different locations around their cabin. The activities were designed by the leader of the troop to take between five to thirty minutes to complete. For the study to
16 be done during the meeting, it needed to be designed to fit as an activity within this structure. This limited the timeframe for the study and the amount of time each participant would have with the prototype.
A rectangular open space of about 100 square meters on the edge of the forest and between the scouting lodge and one of the fireplaces was chosen for the tests. A map over the area can be seen in figure 2. The space was, according to their leader, known to the participants but they preferred playing in other places next to it; a nearby ruin of a root cellar, their own tree-fort, and a large climbable rock.
The open space was deemed preferable since it seemed to be a safer choice as it was free from the undergrowth and rocks that covered the spaces in the nearby forest where they played more. One of the artefacts, the bee, was placed on the trunk of a tree while the other two were placed on wooden tripods (see fig. 2). The artefacts were placed so the buttons faced in towards the triangular space between them. The video camera was placed on a small tripod so that it overlooked the space. The development environment was installed on a Nexus 7 Android tablet that would be used during the evaluations. A set of power banks was placed within reach to be used as reserve batteries if one of the artefacts or the device needed it.
Figure 2. a) map over the area around the scout cabin. b) The placement of the artefacts.
3.3.4. Procedure
The observations and interviews were done as a part of the scout troops’ meeting. The meeting began with an introduction of what the meeting would contain. During the introduction, the researcher presented himself and the project the study was a part of. The scouts were divided into 5 groups of about 4 children each. The study was divided into three parts and was repeated for each group with a few exceptions.
The first part was giving the group a brief introduction into the study, the project and how to use the development environment. The introduction had to be improvised since the script could not be found at the time. The researcher presented the projects and the prototypes and introduced that the
participants were supposed to see themselves as co-designers helping with testing and evaluating how these artefacts could be used on a playground. This was done both to make the participants feel that their participation was valued and to give them a frame of reference when they started exploring the artefacts [22, p. 481]. The group was then asked if they had any experience with programming. The researcher introduced the visual development environment on the tablet. A set of blocks were
connected to show how the programming language could be used to make a button turn a light on and off. They were then told that the study would be recorded, and they were free to say if they did not assent or want to partake. The researcher then informed them that they were free to ask for help during the study and that if something broke, the researcher would attempt to repair it.
a b
17 The participants were then given around 15 minutes in which they were free to explore, use, and play with the artefacts and the development environment in any way they wanted. The video camera was turned on to record the study. During these sessions, the researcher was available for answering questions and repairing things that broke.
Finally, the groups were interviewed. The interviews were done in Swedish, the native language of the participating children. Since the sheet with interview questions and the introduction script was still missing, the questions had to be improvised based on what was recalled at the time. The order of the questions differed between the groups due to this. The questions that were recalled touched upon the participants thoughts on the design and the level of difficulty to use it, the placement of the artefacts, how they would want the design to work and how they would use it if it was available to them otherwise. The questions aimed to be open-ended and semi-structured, and follow-up questions were asked to clarify the participants’ intents and thoughts. If the participants had any questions, the researcher tried to explain and answer them. Throughout the interviews, the researcher responded to and acknowledge the participants’ discussions and opinions with gratefulness and enthusiasm [22, p.
481]. The participants were then thanked for their participation and sent to the next station of the regular meeting.
A few exceptions had to be made during the study. A child in the group had not gotten consent from their parents. To avoid excluding anyone, their patrol got to test the artefacts and the app without it being recorded or used in the study. The other members of that group were then interviewed. The last group did only have time to begin their session of testing and exploring the prototypes. Their session had to be cut short as their meeting was ending. Due to this, they were not interviewed.
3.4. Data Analysis
The gathered data was systematically analysed through a thematic analysis, a process which helps reduce the gathered data into manageable chunks and amounts [22, p. 299]. The analysis was done through four different steps; 1) understanding and familiarization with the data including the transcription, 2) coding, 3) structuring the codes into themes, and 4) relating the themes to the sub- questions. Throughout this process, the field notes during the data gathering were used to aid the analysis through supporting recalling the observations and interviews. The data reduction that the thematic analysis resulted in was structured over four levels of fidelity; codes – groups – categories – themes. A code represents a commonality that is identified in the gathered data, a group is a set of codes that are related, a category is a set of groups which are related, and a theme is a set of groups and categories which showcase a pattern in the data.
First, the video recordings were viewed to get a better understanding of the gathered data. During this process, the researcher took brief notes of what happened to better process it. If something was unclear, that section of the material was viewed again. The video material was then viewed again to improve the understanding of what had happened. In the same way, the recordings of the interviews were listened to multiple times. A few brief notes were taken to capture the thoughts the researcher had during the listening. The log-files were read and compiled to get the number of times the different parts of the programming language were used. The field notes from the design process were read as well. After going through all the gathered data, the recordings of the interviews were transcribed. The quality of the audio-file was varied, it had background noise from other scouts who played and shouted in the background, some distortions due to the windy weather, and a small number of participants had talked away from the microphone. This caused a few of the answers to be
