Children's perspectives in a game programming discourse.

In the Playground project, we applied a constructionist learning perspective in order to build a computational learning environment in which children could design and build their own video games. In this paper, we present results from a study where children were given semi-structured programming tasks in an adventure game designed to investigate their understanding of program mechanisms. We analyze two children's solutions and approaches to a task as a matter of adaptation of talk and actions to different perspectives involved in the ongoing discourse. The establishment of a common perspective between child and investigator throughout the work sessions proved to be central to how the children approached their work. The analysis showed that in order for children to learn to understand how mechanisms that control a game work, they must learn to adapt their perspective to the expectations of each subtask and to the task as a whole. We show how one child is able to see the expected perspective in each subtask, whereas the other child finds that this is much harder. The support given by the investigators was also of great importance in facilitating these processes.

**********

INTRODUCTION

Constructionist perspectives on learning and education argue that one way to achieve powerful learning is to have children collaboratively build and design their own artifacts, which they share with others, e.g., friends, parents, and teachers. One such construction activity is computer programming, which has been thoroughly researched within the Logo-tradition. Programming in Logo and other languages has proved to help children learn about complex phenomena, for instance, within physics (diSessa, 2000), and fractions in mathematics (Kafai, 1995). Smith and Cypher (1999) argue that the kind of problem solving in which children become engaged through programming tasks, supports them in forming hypotheses about why things happen, adjusting properties of the task, observing the results, and analyzing the outcomes. This is supposed to resemble "scientific" ways of thinking. Furthermore, Bruckman (2000) has argued that if such activities also involve aspects of children's culture, this will be a scaffold for their motivation to dig deeper into topics that are central in domains such as mathematics or mechanics.

In the Playground project, we applied a constructionist learning perspective in order to build a computational learning environment in an animated programming environment called ToonTalk (Kahn, 1999). The Playground environment is designed for children ages six to eight to design and build their own video games. The games work as entry points for children to explore and learn about mechanisms that control formally defined systems such as video games.

The general goal of our research is to develop an understanding of how children learn in technologically rich situations and to develop ways to support children in such situations. In order to achieve our goals, a deeper understanding of how children use complex technology and appropriate it into their learning is required. The particular learning goal of the study presented here was that children, through composition, decomposition, and reprogramming of games and game components, would develop an understanding of the relationship between the programs they build, and the way those programs are played out as behaviors in a game. The ability to understand such relationships and mechanisms is particularly central to thinking within physics and mathematics (Noss and Hoyles, 1996; diSessa 2000), but also in other areas such as history (Hallden, 1997). Our earlier studies show that young children (six to eight years) can build meaningful things in a complex programming environment (Tholander, Kahn, & Jansson, 2002). An important follow-up to those results is to increase our understanding of what children understand and learn from such programming activities. Here, we present results from a study where children were given semi-structured programming tasks designed to investigate their understanding of mechanisms in an adventure game.

Another way to describe what we are studying is through a distinction between surface and deep-level features of computer software. Surface-level features refer to the specific instantiations of programming objects representing characters in a game or in a simulation. Deep-level features refer to the program code that determines the behaviors of the objects. The relationship between these two levels determines the view of a running piece of software. The goal of the work presented in this paper is that the children should develop an understanding of this relationship. The task conducted by the children was based on the deep-level features of a familiar game but the game were instantiated in a novel way, i.e., given new surface level features.

Previous Work on Children's Understanding of Programming

Since the 1970s, attempts to build programming environments for children have been made; these started with Logo and Smalltalk. A substantial amount of research on children's and students' use and learning of programming languages has been conducted (Clements & Meredith, 1992). In these early days, programming was considered a paradigm case of problem solving and, therefore, the ideal arena for "improving the minds" of students (Eisenberg, 1997). Problem solving has traditionally been described as iteration over activities such as problem identification, problem decomposition, solving of sub-problems, and composition of sub-problems to a whole (Polya, 1957). One line of research has focused on studying the validity of those promises by investigating the occurrences of cognitive gains from learning computer programming, and in particular for problem solving and mathematical skills (Hoyles & Noss, 1992; Noss & Hoyles, 1996; Palumbi, 1990). Most of these studies focus on "if and when" programming skills transfer to other domains, such as mathematics or physics, or even problem solving in general. The results of those studies are inconclusive in many respects (see Palumbi, 1990) and do not establish any clear connections between programming and general problem solving skills. Pea & Kurland's (1984) often-cited studies showed no significant indications of cognitive gains from students' Logo programming. Hoyles and Noss (1996) extensively analyze the studies of Pea and Kurland and criticize their interpretation of the Logo-vision as suggesting that Logo programming per se would lead to cognitive gains. From Hoyles' and Noss' point of view, it is quite clear that productive use of Logo always has to be accompanied by a rich culture of learning. If one wants to study students' learning with Logo, one cannot do this without thoroughly considering the culture of learning that surrounds and is created by the Logo activities. Furthermore, Noss & Hoyles find it unfortunate that the major impact of Pea's & Kurland's studies has been their conclusion that programming does not lead to the expected cognitive gains, and should, therefore, not be used in schools for such purposes. What is often left out is that Pea and Kurland also concluded that usages of programming in school settings have beneficial effects given a broad focus not only on the programming tools but also on how to support teachers and students to create a productive culture of learning around the programming activities (Noss & Hoyles, 1996). A related line of research in students' programming concerns the analysis and systematization of students' difficulties and misconceptions in learning to program (see Confrey, 1990). Resnick (1990), as an example, studied 5th grade children's' understanding of concurrency in MultiLogo programs (a precursor to StarLogo). He identified three different "bugs" in the students' reasoning (problem decomposition, synchronization, and object-oriented bugs), and tried to establish how these deviate from an expert's model of these constructs. Similarly, Rader, Brand, & Lewis (1997) studied children's understanding of the programming elements in StageCast Creator. The results suggested that children seldom explored the underlying programming model and mostly performed routine actions. Similar results were found in a study by Gilmore, Pheasey, Underwood, & Underwood (1995) that indicated that the depth of children's understanding of the involved programming concepts was limited. This mirrors a theme of most Logo studies, namely, the goal of using programming as a means to get learning effects that can be transferred to, and used in other domains. Most studies of this kind have adopted a view on transfer that tries to find effects pre-determined by the researcher, such as problem solving or a deeper understanding of programming concepts that go beyond children's actual programming activities (Koschmann, 2002). Even though programming still is often seen as a paradigm case of problem solving in the traditional sense, this paper argues that such an account of children's activities is not sufficient to understand what children in lower age groups learn and understand from programming activities. Moreover, the problem solving and cognitive gains approaches have limited possibilities in providing constructive input to the development of the scaffolding that children might need when learning with programming tools. Clements and Meredith's (1992) review of a considerable amount of the Logo research points to varying results with respect to problem solving. However, a common theme of the successful projects, in terms of children's learning, was that they all had a high degree of teacher involvement; the teachers served as mediators helping children to make connections to other domains and general problem solving principles.

An important aspect with respect to our research is that most of the Logo research rather narrowly focused on children's ability to develop an understanding of programming language terminology such as looping, iteration, or recursion and how such understanding transfers to problem solving in general. Most studies failed to show that children developed an understanding in terms of programming language terminology or any transfer of such understanding to new domains.

Several of the Logo studies (Clements & Meredith, 1992, Clements, 1995) and the KidSim studies (Rader et al., 1997, Gilmore et al., 1995) noted great enthusiasm, enjoyment, and enriched social cultures among the children. However, such issues were seldom focused upon but rather noted as side effects of the phenomena in focus. The theoretical and methodological approaches in the studies discussed above did not provide for any understanding of children's meaning making and their actions in the situations as they unfolded.

Socio-cultural Views on Misconceptions and Transfer

Most of the research on student programming and construction as discussed above focused on identifying the bugs and problems they had in learning to program. Similar work has been conducted in science education where substantial attention has been paid to identifying children's misconceptions (or alternative frameworks or naive theories) in understanding scientific phenomena (Caravita & Hallden, 1994; Chi, Slotta, & de Leeuw, 1994; McCloskey, 1983; Vosniadou, 1994) and in finding ways to overcome these. A common theme of that research is the assumption that children's interpretations of the phenomena under investigation are relatively stable across contexts and situations, and thus only subject to influence by the circumstances of the particular experimental situation (Schoultz, 1998). Schoultz, however, challenges the assumption that it is possible to set up studies, which establish "a neutral ground" (Schoultz, 1998, p. 62) where children's understanding of phenomena can be studied and stipulated. Instead, by replicating well-accepted experiments, Schoultz showed that children's explanation of scientific phenomena was largely determined by discursive circumstances, and can therefore not be used to determine fixed (mis) conceptions (1).

Furthermore, the research on the relationship between cognitive gains, problem solving, programming, and the understanding of science strongly connects to the debate regarding how to understand the notion of transfer (Anderson, Reder, & Simon, 1996; Andersson, Reder, & Simon, 1997; Carraher & Schliemann, 2002; Greeno, 1997; Lave, 1988). The view on transfer taken in this analysis is in line with the socio-cultural viewpoint that although research rarely succeeds in demonstrating the existence of transfer, it is clear that learners draw heavily on prior experience and knowledge when acting in new situations. However, learners do not always utilize the knowledge or the experiences that the researchers expect or wish. Thus, the consequences of the failure of transfer studies is not that transfer does not exist, but rather that we need to conceptualize and study transfer in new ways (Lave, 1988). Carraher & Schliemann (2002) even claim that the study of how people bring knowledge and experiences from different contexts into new situations should not be called transfer due to the theoretical views on cognition and learning that it brings along. Therefore, in order to understand children's learning and construction with constructionist learning tools, an approach that considers these issues is required.

Contexts and Perspectives in Discourse and Problem Solving

The role of context in communication, education, and language studies is often seen as intertwined with the phenomena in focus. In reviewing research on language and context, Goodwin and Duranti (1992) conclude that: "Instead of viewing context as a set of variables that statically surround strips of talk, context and talk are now argued to stand in a mutually reflexive relationship to each other, with talk, and the interpretive work it generates, shaping context as much as context shapes talk." (Goodwin & Duranti, 1992, p. 31). Studies of language and communication have shown how the institutional framing shapes what is brought to the fore in dialogic situations (Goffman 1981; Linell 1998a). In a study of children's theories of other people's minds, Mauritzson and Saljo (2001) showed how children's understanding in such situations largely depended on the child as well as the interviewer, the context, and the interactive support that the children were given. Children can thus not be said to have, or not to have, a representation of other's thinking. Rather, their ability to reason about other people's minds depends upon the situation, the interaction, and the support they are given throughout the discourse. Linell (1998b) describes dialogical situations as involving processes of recontextualization to emphasize that "no thought or intention, exists first without a context, and only then becomes "contextualized." For the human subject, there is always a contextual embedding" (Linell, 1998a, p 155). Hence, in dialogues, participants always re-interpret utterances of others according to the situational circumstances and their individual perspectives. Furthermore, Saljo & Bergqvist (1997) showed how students' abilities to reason about optics phenomena depended upon the kind of resources they were given in order to reason. If students are not set to "see" phenomena from a certain perspective, it is difficult for them to learn about the specific scientific theories of those phenomena. They argued that to only experience different light phenomena was not sufficient for developing a scientific understanding of those phenomena. In order to "see" the scientific properties of light, they must also have access to the theoretical concepts that make these properties salient. Similarly, Goodwin (1994) showed how the ability to "see" phenomena depends on the professional discourse that people are trained to act within. Hence, according to all these theorists, phenomena only become real to people if they have access to a conceptual apparatus that structures their perception.

These issues become especially important in learning environments that bring in software and aspects of children's culture, video games for example, into traditional classroom curricula: such environments increase the number of possible contextual influences, which makes the learning situation more complex for the children. Learning now not only involves solving problems within one domain, such as arithmetic, but also requires skills that involve activities within several domains, such as programming, video games, arithmetic, and reading. Although the intention of this kind of learning environment is to improve the learning situation for the children, it also increases the demands on them to interpret the increasingly complex "matrix or field of contexts" (Linell, 1998b, p. 144), involved in the learning discourse.

Socio-cultural Studies of Constructionist Learning and Technology

Recent studies of children's programming and design have adopted perspectives such as those discussed above that take contextual, social, and cultural aspects into account (Ivarsson, 2002; Lilja & Lindstrom, 2002). Bruckman (2000) for instance, did a detailed analysis of how a 12-year-old girl learned to program in a MOO-environment through online collaboration with a more experienced peer. A key conclusion from that analysis was that the social and cultural scaffolding, provided by other peer learners, and through connections to children's everyday culture, is critical to successful learning in programming and design environments. Roth (1999) analyzed collaborative design projects of fourth and fifth grade children with the purpose of introducing science and engineering concepts. The analysis focused upon the design process and children's use of, and ascription of meaning to, artifacts in the learning environment. The results indicated that children's constructions largely were results of local interpretations of, and negotiations between, the participants in relation to the artifacts that mediated their actions. Children's design can thus not be viewed as a fixation of an understanding of the phenomena under investigation. Furthermore, if the meaning of artifacts, tools, and rules used in a design situation are not viewed as having one specific meaning, teachers can no longer evaluate children's activities as either right or wrong based on that meaning. Instead, in order for children's learning to be productive in such a context, teachers must allow an environment where different interpretations are accepted and appreciated.

Our Approach

In line with the perspective on context and discourse discussed above and based on the results from the research on children's learning of programming, we believe that in order to analyze children's understanding of what they build in construction and programming environments, an expanded view of their learning activities is necessary. Furthermore, the criticisms raised against cognitively oriented approaches towards children's understanding of programming, and against the misconceptions perspective in science education point towards a need to adopt a socio-cultural perspective in the study of children's learning using technology. Such a perspective approaches children's learning in technologically rich situations as a social and discursively constructed phenomenon, rather than as determined by technology and children's cognitive abilities. The present work is an attempt in this direction in trying to understand children's programming as produced in collaboration with peers and teachers, and by the conditions of available technology and the situations as a whole. We believe that this is particularly important when it comes to younger students with less experience in learning within school settings. In the work presented here, we analyzed the children's talk and their actions with respect to the different perspectives, or frames of reference, which seemed to make their work meaningful from their own point of view. The purpose was to show that, in order to analyze how children experience and ascribe meaning to what they construct, we must consider the personal perspectives involved in their interpretation of the situation, and of the programming environment.

CHILDREN'S PERSPECTIVES IN A GAME CONSTRUCTION DISCOURSE

Even though "pure" programming skills make up the core of the learning domain of this work, a lot more is involved in learning to understand how to construct video games in the Playground programming environment. To understand how games are built, children must also reflect on how games are designed and probably also appreciate the playing of games. During the analysis of the children's work, we identified four general perspectives that, shaped by their personal interpretations, influenced the predictions and explanations they made regarding behaviors in a game, as well as their interaction with, and construction of, games. The perspectives are not fixed but served as analytical tools in the interpretation of the children's talk and actions. The perspectives were: player, game designer, programmer, and student perspective.

* Player perspective. Refers to the interpretations of the narrative of the game as it is played out on the screen. This involves, for instance, what the different characters do, good and evil non-player characters, what the objects in the game can be used for, such as keys to unlock doors, or magic shoes to make characters move faster. It also involves influences from popular video games (such as Croc or Lara Croft).

* Game designer perspective. Refers to interpretations and ideas of appropriate ways to extend the game's narrative, e.g., what elements can be used and how to do things in the game. For instance, in a game set in the jungle it might be appropriate to add elements found in jungle settings, such as lions and snakes, rather than objects from science fiction.

* Game programmer perspective. Refers to the programming actions made to make different elements in a game behave in ways that were decided upon in a design. For instance, a mechanism for making an object follow mouse movements can be used to control the player character, or a mechanism that makes an object bounce off other objects can be used to make a character that guards an entrance to a house.

* Student perspective. This perspective sets the overall framework for the school as a communicative situation. It refers to expectations in school situations regarding how children should respond. At school, teachers ask questions in a way that presupposes certain kind of answers from the children. A teacher's expectation of the kind of response a child should give to an arithmetic task is different from the teacher's expectation of the response in a more playful situation. Saljo and Wyndhamn (1990) showed how school practice influences children's approaches to tasks that involve aspects from everyday settings. In tasks that involve arithmetic or examination, the children in their study had learned to answer in a precise manner, and in a way that demonstrated their understanding to the teacher. On the contrary, everyday situations that involve arithmetic are often approached more pragmatically, for instance, as shown in Lave's (1988) studies of grocery shoppers. Similarly, in situations where different practices are mixed, it can be problematic for children to interpret how they should respond.

The perspectives were used as reference points when analyzing the children's answers and solutions. The children's individual interpretation is, of course, also constructed through their personal points of view, but the perspectives were efficient as tools in the interpretation of the children's' talk and actions. In our analysis, we show that in order to achieve the goals of learning about the mechanisms that control game behaviors, children have to adapt their perspective to the expectations as they changed throughout the task. We illustrate how one child is able to "see" the expected perspective in each subtask, whereas another child finds this to be much harder.

TOONTALK AND PLAYGROUND--THE SETTING

ToonTalk is an animated programming environment where computer programs are built by performing actions upon concrete objects. In this environment, real computer programs are built with the special characteristic that the source code is animated; that is, there is no textual code as in traditional programming languages (Kahn, 1999). ToonTalk programs are constructed from robots, which are trained to operate on boxes containing variables such as numbers, letters, or pictures. Robots can be combined into teams to form more complex operations. In order to use ToonTalk to build video games, graphical pictures are used to represent characters and objects in the game. In ToonTalk, pictures are controlled through sensors and remote control, such as screen position, speed, or size. There are also general sensors for detecting mouse movements, mouse clicks, and other system events. ToonTalk robots can be placed on the backside of pictures (flipping over) to operate on its sensors and remote controls. For the user to manipulate the environment a virtual hand is used to control a number of different tools: a magic wand for copying objects, a vacuum cleaner for erasing and removing things (called sucking and spitting), a bicycle pump for changing the size of objects; notebooks are used to store objects.

We use the term behavior to refer to the situation that occurs when a robot, combined with sensors and/or remote controls of a graphical object, is used to form a meaningful element in a video game, such as a movement, or control of a player character with the mouse. In Figure 1, a robot was trained to set the number in the first hole in the box equal to the number in the second hole in the box. A behavior called "move left and right with mouse" is achieved when this robot is combined with the mouse's right position sensor and an object's right speed sensor.

The Playground Project Context

Throughout the three-year project, a total of 40 children participated in game construction activities, mostly at after-school sessions. The children were given ready-made games of different styles to play with, take apart, and rebuild. They also had a range of different pre-built tools to use in their game construction. A group of 12 children had been working regularly with games and game components once a week during an 18-month period to learn about the tools in the programming environment, and how they could be used to program new games. Children worked individually, as well as in pairs. For this particular study, seven children had been working intensely during 10 one-hour sessions to build their own adventure games. They all succeeded in building interesting games of different sophistication and style. At the end to the 10-session period, all children participated in an online games workshop with children from London, England. At the workshop, the children shared, reprogrammed, and discussed each other's games over the Internet using special software and video conferencing.

[FIGURE 1 OMITTED]

Procedure

Following the games workshop, children were interviewed while conducting tasks designed to investigate their understanding of some of the program mechanisms they had used to build their adventure games. The task was a type of "near-transfer task" (Palumbi, 1990). However, the purpose was not to investigate any occurrence of cognitive gains or transfer of problem solving skills. The purpose was to see how the children explained the game mechanisms with which they had been working when these were set in the context of a completely new game.

The Task

The task focused on the mechanisms for changing scenes in an adventure game called Hunt-the-treasure, but in a new form, called the "sun-and-moon" game. The sun-and-moon game involved exactly the same underlying programming mechanisms, that is, the same program code as the original hunt-the-treasure adventure game. However, the appearance of the characters in the game was changed in order to remove any surface resemblance with the game with which they were familiar (see Figures 2 and 3).

The "sun-and-moon" game was designed to be used in tasks that focused on investigating how the children understood and explained the scene-changing mechanisms. The sun-and-moon game used the scene-changing functionality from the hunt-the-treasure game but instantiated in a completely new form. The game consisted of three scenes that a spaceship on which a spaceship could be moved around (Figure 3), and moved between (Figure 4). In each scene, there were one or two suns of different color, some of which triggered a scene change when colliding with the spaceship.

The task consisted of predicting, making changes to, and explaining different aspects of the scene changes in the game. The children worked with the scene changer where the scenes, and the transfer of the player character between the different scenes, are managed. The scene changer involved a player character (a space ship in the new game), portals (suns in the new game), and scene-changer robots. These elements trigger and control scene changes in the game. The portals detect when the player character should be moved to a new scene and keep track of to what scene. The scene changer robots change the current scene and put the player character in the new scene.

[FIGURE 2 OMITTED]

[FIGURE 3 OMITTED]

[FIGURE 4 OMITTED]

A worksheet with the following tasks that the children worked through with one of the researchers was used:

* Play the game and move the spaceship to the sun in each scene and describe what happens.

* Explain how to make the red sun in the second scene behave like the yellow sun in the same scene. Implement that change.

* Try out the game and explain what will happen in the second scene when the space ship is moved to the red sun.

* Play the game and describe what happened when the player character was moved to the red sun in the third scene.

* Change the game so that the red sun in the last scene transfers the space ship to the first scene.

The sessions were video recorded and notes were taken by the researchers throughout the sessions.

RESULTS -- INTERPRETATIONS OF GAMES AND PROGRAMS

In total, seven children completed the task. In the following, we present the results from two of the children. Nathan and Tim (their real names have been changed). Nathan, an eight-year-old, was one of the most skilled children and had participated regularly throughout the duration of the project. He had built some impressive games and demonstrated a surprising understanding when explaining his games. Tim, a seven-year-old, had participated in project activities during three semesters. He knew ToonTalk and Playground fairly well and was always enthusiastic about his work. We choose to present the work of only these two children because the results from their work are representative of the entire group. In addition, by limiting the presentation we are allowed to give rather complete accounts of how they progressed to solve the task, which allows for a richer presentation of the analysis.

The sessions with the two boys were analyzed and contrasted in order to illustrate how their problems and successes depended on how they interpreted and adapted to the perspective involved in the situation at hand. We intend to show that the perspectives that the children took in the ongoing discourse largely shaped their talk and their actions. Throughout the session, the expected answers and solutions to the different sub-tasks varied. Although the worksheet was designed to make the expectations explicit and the investigator also emphasized such issues, the children still struggled with these issues. In the analysis, the establishment of a common perspective regarding each subtask proved to be central to the children's explanations and solutions.

We present six sub-episodes to illustrate how the perspective from which the children interpret a task is highly relevant to how they approach problems of this kind. Each episode maps against each subtask listed above, although these were not always followed strictly.

Excerpts from the two cases are presented under the same headings in order to make the contrast between the two clear. In the transcripts, the boys' names (Nathan and Tim) are abbreviated using the first letter of their names; the interviewer is represented with an 'R' for researcher. Non-verbal actions such as programming are represented in square brackets. In some transcripts, illustrations of the programming tools are included. The illustrations are simplifications of the real program that the children used. It is also important to note that the children and the researchers knew each other well since they had worked together during a fairly long period of time. This explains some of the jargon in the dialogs between the researchers and the children, and that everyone comfortably handled the situation.

Establishing the Situation--Taking on Player Perspectives

In the first subtask, the boys played the game and were asked to describe what happened when the spaceship collided with each of the suns. Both Nathan and Tim related to what occurred from a player's perspective. Both of the boys answered the questions by using phrases and words relating to the game, like a story, by speaking of places and worlds, and that the game was difficult.

Nathan

N1. Nathan -- There is a new place. [Writes 'new place' on the worksheet] [Moves the spaceship to the red sun]

N2. N -- Nothing happens by the red sun!

N3. Researcher -- Why is that do you think?

N4. N -- The game is finished

N5. R -- No

N6. N -- [Reads silently from the worksheet] "Go to the yellow sun." something is going to happen there, isn't it?

N7. R -- What do you think happens?

N8. N -- You come to a new world

N9. R -- Yes, write!

N10. N -- New place [Writes 'new place,' goes to the yellow sun, and the spaceship transferred to the third scene]

N11. R -- So, go to the red sun

N12. N -- Goes to the red sun on the third scene] Uhh, what happens, you get to the middle

In his initial talk and interaction around the game, Nathan mostly referred to the game and the task from a player perspective. In the first turn, he said that the player character came to a new place, using a phrasing indicating a spatial property (place) common in the narratives of most action-style video games. Such an interpretation also seems reasonable considering his answer in turn N4 ("the game is finished") to the researcher's question in turn N3, regarding why he though nothing happened by the red sun. Considering the previous activities in which Nathan had engaged, focusing on programming issues, an explanation more oriented towards programming--for example, by referring to the lack of a programmed behavior--would have been just as reasonable. However, from the researcher's reply (turn N5), that the game was not finished, Nathan realized that his guess was incorrect and went back to the worksheet (turn N6) to find out how to continue. Based on the information in the worksheet, he concluded that something should be happening; to be sure, he sought support from the researcher regarding the conclusion he had drawn. The researcher confirmed by asking him what he though would happen (turn N7) and Nathan concluded that the spaceship will come to a new world. In the last two turns, Nathan was asked to move the spaceship to the red sun and he basically reported what happened on the screen by saying that 'you get to the middle' when you collide with the red sun.

Throughout this extract, Nathan kept interpreting what happened in the game from a player perspective. However, he did not become completely immersed in the game as a video game since he constantly picked up cues from the researcher and the situation as a whole. Nathan knew from previous experiences within the project that the overall purpose of most sessions involved a lot more than just playing a game and concluded that this must be the case in this session as well. This was partly given by the information in the worksheet, but even the sole presence of a worksheet signaled that the main purpose of the session was something beyond just playing the game. The ability to grasp the overall purpose of the session will prove to be important for his work throughout the rest of the session.

Tim on the other hand, immediately became deeply immersed in playing the game and ascribed a lot of 'action' to the game from the beginning, although from a programming point of view the game and the behaviors in the game were quite simple. In contrast, Nathan was initially not as involved in the narrative of the game. Not all of this is apparent from the two transcripts in this section, but was clear from the videotapes and from notes from the session.

Tim

T12. Researcher -- This is the game. It says play the game by using the arrow keys 

T13. R -- And then you should answer the question, "What happens when you come to the sun?" So start playing the game and you'll see

T14. Tim -- [Starts moving the spaceship around with the arrow keys] This is a hard game

T15. R -- Yeah, really hard!

T16. R -- So, what happened when you came to the sun?

T17. T -- You came to a new world

In turn T14, Tim said that the game was hard despite the fact that the only thing he could do was to move a spaceship around on a blue background with a sun at the top. The game was intentionally designed to be simple in that it did not include any bad-guy characters or difficult obstacles. However, for Tim the game was difficult because the spaceship only moved one step at a time in the direction of the arrow button that was pushed. Furthermore, the spaceship could only move horizontally and vertically. These in combination required significant effort from him in order to navigate the spaceship. Although the researcher provided a cue in the second turn (T15) that he was expected to answer a question, Tim did not interpret this as central to the task, in the same way that Nathan did. At this point, Tim related his actions and what happened largely from the point of view of a player of the game.

To initially adopt a player perspective was very much expected and quite natural. However, the difference in the boys' interpretations of the task as a whole turned out to be crucial for their work during the rest of the session. In the next excerpt, when the task shifted to focus on changing the game, we will see how Nathan was able to adapt to this shift. Tim, on the other hand, still interpreted the task as relating to how the game was played and required elaborate interaction and support from the researcher in order to shift the way he viewed his actions.

Adapting Perspectives to Changing Explanatory Goals

In the following excerpts, the task shifted from concerning what happened when the game was played, to concerning the addition of a behavior to one of the suns in the game. In both cases, the researchers tried to be clear about the shifted goal in this subtask. This was signaled to the children by the researchers' first statement in each of the transcripts in this section, saying that the games should now be changed (N16, T53). Nathan quickly adapted to this new goal and proceeded to complete the subtask in accordance with it. For Tim, on the other hand, more elaboration was required between him and the researcher in order for them to start sharing the goals, which at the end were partially achieved.

Nathan immediately picked up the cues signaled by the phrase "change the game," used by the researcher to shift the focus from game playing to game programming. This shift in perspective suggested a way of looking at the situation that involved a different set of discursive concepts than earlier. The phrase "change the game" was intended to indicate that it was now appropriate to speak in a manner that involved programming aspects, such as robots and behaviors, rather than as video game aspects such as places and characters.

Nathan

N16. R -- Now we are going to change the game

N17. N -- [Nathan takes a new copy of the game reads and from the worksheet] "Turn the game over and get the scene called Moon"

N18. N -- There

N19. R -- Take it out and then you have to read

N20. N -- "What do you do in order for the player to get to the scene with the red sun"

N21. R -- What do you think?

N22. N -- To, to get to the last scene. Well. [Flips pages in the notebook and shows that the red sun (see left and middle below) should have the same mechanism as the yellow sun (left and right) that transfers the player to the scene in the notebook called 'last']

[ILLUSTRATION OMITTED]

N23. N -- You make the red sun to also teleport you to the scene 'last'

Here, Nathan and the researcher quickly proceeded towards the core of the task, which was to think about how to make the red sun transfer the player character to the last scene. By flipping to the correct pages in the notebook, Nathan indicated to the researcher that he had an idea for how this could be achieved. Accordingly, the researcher took a more passive role when Nathan (turn N22) showed what must happen on the back of the game in order for the change to take place. Directly afterwards (turn N23), Nathan clarified this by saying that the sun should 'teleport' you to the scene called 'last,' as he showed in the notebook. This style of talking explicitly referred to the program mechanisms that controlled the objects in the game, rather than to the narrative aspects of the game. Particularly interesting is Nathan's choice of the word 'teleport.' He had used this word throughout his previous work with the hunt-the-treasure game to talk about the transfer mechanism and how that mechanism was used to program the connections between the scenes in a game. Furthermore, his explicit use of the words 'teleport' and 'last,' rather than a neutral phrasing such as "you make it also go to that other scene," indicates a deliberate way of designing his utterance (Pomeranz & Fehr, 1997). In order to make the perspective from which he acted clear to the researcher, he adapted his utterance to the situation as a whole as well as to his understanding of the researcher's intentions.

Tim, on the other hand, did not immediately pick up the shift in perspective that the researcher tried to establish. Extensive elaboration between the two was required before Tim came up with a suggestion for how to complete the task.

Tim

T53. R -- Now it says, "How do you change the game so that the player comes to the third scene?" That is the last "when you hit the red sun"

T54. R -- Get the player to come to the next scene here (points to the notebook with scenes)

T55. T -- Can I decide?

T56. T -- Ha, ha (Laughs after thinking for a while without being able to answer)

T57. R -- Do you remember if you look here, how it looks if you were the player? Now, where would you go to come to the next world, where would you go then?

T58. T -- To the yellow sun

T59. R -- And if you want the same thing to happen when you come to the red sun as when you come to the yellow, how do you think we do that, how can that be fixed?

T60. T -- Well, eh, I don't know 

T61. R -- Okay, what were you thinking of?

T62. T -- A special way that nobody can know of

T63. R -- Okay

T64. T -- If I am here, then like this, down here, and then you have to go there and there, there, there, then there, and then you should start here, and there, there, there [points out an imagined path on the screen] (the path the player have to take in order for you to get to the next scene)

In the first two turns, the researcher signaled that the game should be changed; he was trying to indicate to Tim that it was appropriate to look at the game and the task from a programmer's perspective. Tim, however, did not pick up the cues signaling that the focus shifted toward programming. Instead, he replied by asking if he could decide himself how to make the change (turn T55). That Tim was supposed to make the change to the game, and decide in what way the change should be made, was of course obvious from the point of view of the researcher through the set up of the situation as a whole. Tim's question indicates that he was not clear regarding what was expected of him. In turns T57 and T59, when the researcher asked Tim "if you want the same thing to happen when you come to the red sun" he tried to get Tim to take a programmer's perspective by suggesting that he should try to draw an analogy to how the other elements in the game worked. The researcher tried to get Tim to conclude that the same thing should happen when he got to the red sun as when he got to the yellow. Clearly, Tim knew that the yellow sun transferred the player to the last scene (turn T58), but he was still not able to draw the analogy--suggested by the researcher--that the red sun needed the same programming elements (turn T57 and T59).

At this point, Tim's difficulty in grasping the researcher's suggestions could be interpreted as due to a lack of knowledge of the programming concepts that he was expected to use. However, considering his work later in the session it was quite clear that this was only partly the case. Instead, we interpret the source of Tim's difficulties as arising from his interpretation of the whole situation. His talk and the actions he suggested can be understood as arising from difficulties in adopting the perspective that the researcher tried to establish and from difficulties on the part of the researcher to communicate that perspective to Tim. This was further indicated in turns T61-64 when the researcher asked him to explain what he was thinking; he provided a suggestion based on a point of view of game design, rather than of programming of the game. At first, Tim might seem confused by suggesting a completely novel solution that seemingly was quite far off from the expected solution. However, by considering his suggestion from a game designer's viewpoint rather than as a solution to a programming problem, it was quite sensible. Tim talked about how a new aspect could be designed into the game narrative by making up a path in the game that nobody knew (turn T62 and T64). By taking the secret path, the spaceship would magically be transferred to the next scene. This suggestion did not immediately involve changes involving program language elements down at the programming level. Rather, the suggestion connects to Tim's experiences at the beginning of the session when he found the game difficult. This was partly due to the effort required to navigate the spaceship and his present suggestion that would connect the navigation of the spaceship to the scene change. Rather than ascribing a lack of understanding to Tim's suggestion, we believe that his idea is more meaningfully and constructively understood if interpreted as based on a combination of a player's and a game designer's perspectives to the task.

Perspectives in Talking and Perspective in Doing

Nathan continued by changing the game the way he suggested in the previous excerpt. In the following, he was asked to predict how the game would run, and why, when he played it. Nathan made careful use of programming concepts in his answers, supposedly to make it clear to the researcher that he knew what he should do. For Tim, on the other hand, it was more problematic to implement the change that was suggested. However, with guidance and instruction from the researcher, he was able to complete the change of the game without any significant problems. However, his comments regarding the change indicate that he did not fully adopt the programmer's perspective that the researcher had tried to establish. Instead, he partly continued to interpret his actions from the perspective of a player and game-designer.

In the following, Nathan was asked to explain and write on his worksheet what happened when he moved the spaceship to the different suns in the second scene.

Nathan

N38. R -- Wait a little. If you go to the scene with two suns. What will happen if you go to the yellow sun?

N39. N -- You get to the last scene

N40. N -- It is called 'last' so I write that

N41. R -- Then there is another question

N42. N -- What happens if you go to the red sun?

N43. N -- Then you also come to the last

N44. R -- Are you sure

N45. N -- Yes, because I added one of those [points at a yellow sun] in there [points to red sun]

In turn N39, he replied to the researcher that you get to the last scene when you move the player character to the yellow scene. This reply was quite straightforward considering the layout of the game as a three-scene sequence. However, in turn N40, Nathan went on to clarify his reply. He said that he wrote 'last' on the worksheet not only because it was the last scene in the sequence of scenes in the game, but since it was also called 'last' in the scene notebook, that is, in the program code. This is a quite clear example of how he used programming concepts to clearly communicate the rationales behind his solution to the researcher.

Furthermore, this exchange proceeded quickly without much need for clarifications from any of the two. The researcher was aware that Nathan understood and thus stayed passive largely to ensure that Nathan continued to answer all the questions in the worksheet (N38, N 41). In turn N42, Nathan was asked to predict what would happen when the player character went to the red sun that previously was reprogrammed. He correctly predicted that the player character would get to the last scene (N43), and when asked to justify his prediction, he referred to how he had transferred the program mechanisms from the yellow sun to the "inside" of the red sun (N45). Again, as in turns N39 and N40, he justified his thinking to the researcher in relation to a programmer's perspective. He was able to adapt his perspective according to the expectations implicit in the questions and comments from the researcher, and to the task as whole. Moreover, it is important to note that in communicating his understanding, Nathan used the concrete nature of the programming language through pointing (N45) and talking about the spatial properties of the objects such as "in there" (N45). Throughout the excerpt, Nathan repeatedly adapted his way of talking by actively using programming language elements and concepts in order to make sure that he clearly communicated his understanding of the solution to the researcher.

When Tim worked with the task of changing the red sun to behave like the yellow sun, it did not proceed as smoothly as it had for Nathan. However, after guidance from the researcher, and collaborative investigation of the game and its components, he grasped the overall purpose and was able proceed quite independently to complete the changes. However, although he was supported in completing the programming actions, his way of describing the changes was somewhat contradictory to his actions. His descriptions still made most sense when interpreted from a player's perspective.

Tim

T100. R -- So if you copy that one [the yellow sun]

T101. T -- Maggie (the magic wand), come here!

T102. R -- Okay, Maggie good that you remember

T103. T -- If I go then you hit space

T104. R -- Good!

T105. R -- So you take that exit (portal)

T106. T -- [Flips the red sun over and sees the empty back] I get it!

T107. R -- You're getting it.

T108. T -- [Takes the portal, puts it on the back of the red sun, and puts the game back together]

T109. T -- Now we've cheated!

T110. R -- Have we?

In turns T100 through T106, the researcher instructed Tim so that by turn T106 he was set in a position that allowed him to implement the change requested. However, Tim was not a passive recipient of these instructions; on the contrary, he actively interpreted the instructions by starting actions on his own. The instructions were quite detailed and required extensive knowledge from the person being instructed, such as knowing the implicit actions involved in copying an object (T100-104) and choosing to flip the object over (T106) when being asked to just pick it up (T105, T106). In turn T106, Tim exclaims "I get it" after looking at the back of the red sun and realizing that he needed to add a behavior to the back of the red sun. He independently and impressively went on to implement this in turn T108. However, the crux of this excerpt came in turn T109, when Tim suddenly stated that "Now we have cheated." This was surprising after the clear insights he had shown and the impressive piece of programming that he had carried out. The turns leading up to turn T109 quite clearly suggest an understanding of the programming aspects of the task. However, the remark about cheating reveals that he was still puzzled regarding the task as a whole. To claim that he cheated indicates that he still interpreted the task from a player's perspective and that he viewed the manipulations to the game mechanisms as actions that go outside the rules of what is allowed when playing games. He would have preferred to solve the task only through playing the game. Having to change it at the programming level was somewhat of a failure. The whole task became problematic for Tim, not because of a lack of knowledge of the programming environment, but because of his mixed perspectives and interpretations of the task and the situation.

Separating Programming From Game Playing

In the following excerpt, an important issue with respect to the understanding of programming and construction with computational media became salient. This issue involved the ability to separate the programming dimensions of elements in a game from the game play and narrative dimensions of the elements. Such skills are of central importance not only to children's understanding of programming and construction but to programmers of all levels (Repenning & Perrone, 2001). The following two excerpts quite clearly illustrate how the boys' different ways of relating to the task and to the situation influenced their views on the game and the objects that they used to solve the tasks. Since the objects in the game can simultaneously be viewed as programming objects and as game objects, children must learn to distinguish between these two viewpoints. Nathan, who mostly took on a programmer's perspective towards the task, changed the game from a top down view. From such a view, the game is built up of objects; each object is composed of a set of behaviors, and each object can interact with other objects in the game. This suggests a quite clear separation of the role of the objects as programming objects from their role when the game is played.

For Tim, on the other hand, it was still difficult to separate a player's from a programmer's perspective to the task. He took on a sequential view of the game that more closely related to the layout of the game as it is experienced through play. Such a view led him to suggest changes to the game where play and programming aspects were intertwined. For Tim both play and programming could be used to complete a task whereas for Nathan tasks were solved from a programmer's point of view, and the results of changes were evaluated by playing the game.

In the excerpt below, Nathan was asked to change what happened when the player character was moved to the red sun in the last scene. He was asked to explain the behavior of the red sun in the last scene and then change it to trigger a scene change to the first scene in the game, instead of back to the last scene as in the original version.

Nathan

N60. R -- What happened when you came to the red sun?

N61. N -- You came to the middle

N62. R -- Okay, you write

N63. R -- Now the challenge comes. Change it so that you come to the first scene called start.

N64. N -- Okay, first you suck that out [sucks out the red sun and spits it out], then you have to flip it over [flips the red sun over], then you take this out [takes the box the robot works on], and there you have what scene you get to [points to the third hole in the box and takes out the number in the hole]

N65. R -- Yeah

N66. N -- [Changes the current number into the number 'one' and puts it back in the box] That was no challenge!

N67. R -- So, it was no challenge. Are you sure it's working?

N68. N -- [Puts the game together, sucks out the old scene from the scene notebook and puts the new scene there instead, puts the notebook on the back of the game and tries out the game]

Initially, when Nathan was asked what happened when "you came to the red sun," he replied, "you came to the middle," which basically described the behavior as it appeared on the screen. However, in turn N63, the researcher gave Nathan the last task and emphasized the difficulty of it by calling it a challenge. Nathan immediately (turn N64) took on a programmer's perspective and explained the major programming operations required on the objects and attributes involved to make the change to the portal mechanism that controlled the triggering of the scene change. His explanation focused on the programming dimension of the involved objects. At this point, he clearly distinguished the role of the game and its objects as programming objects from their role as objects in the game as it was played. Furthermore, he did not only make the required manipulations of the game to complete the change, he also accompanied his actions with explicit verbalizations and explanations addressed to the researcher in order to make it clear that he understood what he was doing. This not only suggests an understanding of the programming and play dimensions of the game but also that an awareness of the expectations involved in solving this kind of task in a school setting. His explanation in N64 seemed to be deliberately instructive; it was clearly addressed to the researcher, including formulations that served to demonstrate his understanding. This is a typical requirement in the communicative context of schools and other formal educational settings. In such contexts, it is not only sufficient to know how to do something, one must also be able to demonstrate and communicate one's understanding to teachers, something Nathan clearly grasped. Although the situation analyzed here differs from a traditional school setting in many respects, such knowledge was clearly beneficial for Nathan.

In the next excerpt, Tim was about to test out the change he made to the second scene in the previous section. It turned out that something went wrong with the red sun (due to a system error) even though it had been programmed correctly. However, this did not concern Tim since there was still a way to get from the second to the third scene in the game by using the yellow sun. According to Tim, the functional requirement of the subtask and the game was still fulfilled and he could go on to the last scene to make a change to the sun in that scene. The sun in the last scene had an inconsequential behavior in relationship to the rest of the game. Since it only transferred the spaceship back to the same scene, Tim seemed to feel that it was pointless since it did not carry the narrative of the game forward.

Tim

T116. R -- Now let's play and see [Tim plays the game and the red sun which he has changed is not working, so he goes to the yellow sun that is working]

[ILLUSTRATION OMITTED]

T117. R -- What has happened, let's take it out and have a look

T118. T -- Wait [Tim want to try the red sun on the last scene]

T119. T -- You copy the yellow. You copy one of those and then you put it here (on the ToonTalk floor). Then you go on to the next world and put the yellow you just copied here (in the last scene)

T120. T -- Right, then you have two to use (in the last scene)

T121. T -- Because this is not working (the red sun in the last scene).

In turn T117, the researcher wanted Tim to look at why the red sun was not working. This included an implicit suggestion to look at how the problem might be located in any of the programming language elements. Tim, however, did not see this as a problem, and instead wanted to go on in another way. He was not concerned with fulfilling the task as stated in the worksheet since there were other ways to achieve the desired result in the game, that is, there was already a way to get from the second scene to the third scene. The broken red sun the second scene was not a problem to him since there was another way to continue playing within the game. The broken red sun did not disturb the possibility of continuing the game from a player's point of view, which was still Tim's primary focus. Rather, he wanted to fix the red sun in the last scene that only took the player character back to the middle of that scene, something he experienced as a lot more problematic than the broken red sun. Perhaps, this is because it did not fill a meaningful role in the game, but was deliberately designed by the researchers to create the task. Consequently, he went on to suggest (T119) that the red sun in the third scene could be fixed by copying the yellow sun in the second scene and putting it on the floor. Then he would then continue by moving the player character to the yellow sun, which transferred the spaceship to the third scene. When the player character reached the third scene, a new copy of the yellow sun could be added to that scene.

Tim's suggestion involved quite an innovative way of mixing play and programming aspects to implement his solution. It also indicates that Tim had a sequential view of the game and its components rather than the top down view we ascribed to Nathan, which is more functional from a programming point of view. In turns T119 and T121, Tim mixed play and programming actions to suggest how the task could be fulfilled, that is, at the same time he referred to programming concepts, such as copying behaviors and putting them in the new scene, and video game actions such as "going on to the next world." This is interesting since he did not clearly separate his view on the objects in the game as having distinct roles as programming and as game objects. Instead, these two views were intertwined throughout his work. Furthermore, Tim did not make the connection between the programming and the school context the way that Nathan did.

Knowing When as Well as How

The problems that Tim had with parts of the task during the first part of the session, compared to Nathan's problems were, of course, partly due to less knowledge of the programming concepts involved. However, more critical to his problems was that he had trouble in adapting to how the perspectives changed throughout the discourse. The perspectives were largely set by goals defined by the researcher and by the school setting as a communicative situation. These were issues that Tim did not yet fully grasp. However, when having to "repair" the red sun, he realized that it was necessary to actually reprogram it. This helped him to see the task from the same point of view as the researcher. Impressively, he went on to solve the task with only minor support from the researcher.

Tim

T136. R -- We have to do it again. Take a copy of that one

T137. T -- Copy, sure I just have to put this somewhere

T138. R -- Do you remember how you did that?

T139. T -- Excuse me but you happen to be in my way

[copies the sun, flips it over, puts the portal on the back of the red sun, puts the sun back into the game, and replaces the scene in the notebook]

In turn T136, the researcher said that they had to redo some of the previous changes because something was wrong, hence, attempting to signal that current focus should be on repeating the prior programming actions. This was further emphasized when the researcher told him to copy an object, an action indicating that a programmer's perspective is appropriate in the following tasks. Tim now showed that the he knew how to program the expected behavior. The programming required to achieve the desired behavior involved a number of quite detailed steps that he completed without any guidance from the researcher (T139).

The issue for Tim throughout the whole session was primarily not one of knowing, or not knowing the appropriate programming actions and concepts. Rather, the issue for him was largely one of being able to adapt his talk, actions, and interpretations to the perspectives as they changed throughout the ongoing discourse. At the beginning of the session, he was able to make the correct changes with adequate support from the researcher. However, he was not able to frame his actions in ways that let him accompany them with the explanatory concepts expected by the researcher.

Choosing Perspective According to Requirements

At the end of the session, the boys played the games that they had changed and they were asked to predict the different scene changes that would be triggered. In both of the following excerpts, the researchers asked them to clarify their suggestions (turns N84 and T156 respectively). In order to exhibit their understanding, both Tim and Nathan clarify themselves by focusing on programming language elements. When they played the game at first they both used explanations relating to how the game was played. However, when the researcher wanted them to clarify their understanding, they switched their phrasing to focus on the programming elements in the game. The first excerpt comes from Nathan's session.

Nathan

N81. R -- Go to the last scene to check that it still works

N82. R -- Okay, wait now. Where do you come if you go to that?

[ILLUSTRATION OMITTED]

N83. N -- The first scene

N84. R -- Which one is that?

N85. N -- Ah, the start.

In turn N83, he predicted that the sun in the last scene would transfer the spaceship to the first scene in the sequence. Although the answer correctly described how the game was played, the researcher asked (turn N84) for a more specific explanation. Nathan interpreted the question of the researcher as an expectation of him to demonstrate his understanding. He clarified his prediction (turn N85) by referring to 'the start,' which was the labeling in the scenes notebook of the scene-changing mechanism. Here Nathan reformulated his answer to get it to suit what he believed was expected from him. When he was asked to clarify his answer, he knew that references to the programming environment were most appropriate.

At this point, Tim had also adapted his point of view to be in line with the researcher's expectations and to the situation as a whole. Here, he more distinctly than earlier, separated the game as it was played from the game as it was programmed. When he is pushed to give a reason for his explanation, he referred to aspects of the scene changer.

Tim

T153. R -- Do you remember where you come when you go to the red sun?

T154. T -- Nowhere, yes, to that world

[ILLUSTRATION OMITTED]

T155. T -- To that world

T156. R -- Which one do you mean?

T157. T -- The sixth!

Just as with Nathan, the researcher (turn T156) asked Tim to clarify his prediction regarding where the spaceship would be transferred when the player character went to the red sun in the second scene. Now he tried to use programming concepts to clarify his answer. He answered "the sixth," which referred to page six in the notebook of scenes, which was the page number to which the portal mechanism on the back of the red sun transferred the player. Tim seemed to have grasped that, when the researchers asked him to clarify or explain something, it was most suitably done by using programming language concepts and actions.

CONCLUSION

The primary conclusion from this study is that the issue of children's understanding of programming largely was a matter of knowing when to use a particular kind of knowledge and how to demonstrate that to the investigators. Hence, it was something beyond merely knowing the appropriate concepts in the programming environment. Understanding the expectations of the situation at hand turned out to be quite different from knowing the details of this particular content domain. To gain a better understanding of children's programming, the different viewpoints that influence their talk and action must be taken into account. In addition, the communicative conditions of the school setting place particular restrictions on the interaction between children and adults (Saljo & Wyndhamn, 1990). Children are expected to answer in ways defined as meaningful by adults, and adults ask questions that children learn to answer in particular ways. In this study, programming language concepts formed the preferred explanatory concepts. This is something that must be clearly communicated to the children. In our analysis, we tried to illustrate how the ability to take on the roles as student and programmer were crucial to the way the children approached the task. Finding ways to support children in grasping such issues is important not only for designers of computational learning environments, but in any situation of learning.

Since the goal of our research is to further develop ways of supporting children's learning in technologically rich situations, it is of utmost importance to understand how children interpret not only the tools they use in their learning, but also how they interpret the learning situations in which they are using these tools. In line with work on context (Linell, 1998a) and children's frames of reference (Mauritzson & Saljo, 2001), our analysis of the two cases of children's programming focused on how the children interpreted the tasks and the requirements of the situation. We tried to show how a response that is incorrect from the point of view of the investigator arose from difficulties in establishing a shared perspective on the task between the child and the researcher.

In order for children to be successful in a particular learning domain, they require skills in addition to those from the core domain. It is crucial that the children are able to reason from all the different frames of reference involved in a task, and are aware of how those perspectives change throughout the situation as it unfolds. This becomes even more important in technologically rich situations where a number of different frames of reference are involved. Although teachers or, in our case, researchers, try to make their frames of reference explicit to the children through questions and other cues, it might still be difficult for the children to adapt to these perspectives. Moreover, this is not only difficult for the children but also for the teachers who must interpret the responses of the children in the situation as it unfolds. Further research is needed in order to find ways that support children in focusing on the tasks that let them have productive learning experiences.

Future Work

For designers of educational technology, it is important to do additional research to find ways to support children to be able to see the different perspectives in a learning discourse and to learn to adapt their work accordingly. Based on the results presented and used in this paper, we will analyze this with children who have worked during longer periods of time in a variety of situations and educational setups. This will involve identifying when and how children develop the ability to move between the different perspectives, and furthermore, what aspects of the learning environment and what aspects of the scaffolding of the tutor support this development. A central source for this development is found in the scaffolding given by the tutor and, in relation to that, the question of how such support can be systematized.

Note

(1) For example, in one of the studies children were interviewed about the shape of the earth. Many studies have shown that children have a hard time understanding that the earth is spherical. However, when placing a globe of the earth on the table between the child and the interviewer the children did not have any problems in understanding the earth as a spherical object.

References

Anderson, J., Reder, L.M., & Simon, H. A. (1996). Situated learning and education. Educational Researcher, 25(4), 5-11.

Andersson, J. R., Reder, L. M., & Simon, H. A. (1997). Situative versus cognitive perspectives: Form versus substance. Educational Researcher, 26(1), 18-21.

Bruckman, A. (2000). Situated support for learning: Storm's weekend with Rachael. The Journal of the Learning Sciences, 9(3), 329-372.

Caravita, S., & Hallden, O. (1994). Re-framing the problem of conceptual change. Learning and Instruction, 4, 89-111.

Carraher, D. W., & Schliemann, A. D. (2002). The transfer dilemma. The Journal of the Learning Sciences, 11(1), 1-24.

Chi, M. T., Slotta, J. D., & de Leeuw, N. (1994). From things to processes: A theory of conceptual change for learning science concepts. Learning and Instruction, 4, 27-43.

Clements, D. H. (1995). Playing with computers, playing with ideas. Educational Psychology Review, 7(2), 203-207.

Clements, D. H., & Meredith, J. S. (1992). Research on Logo: Effects and efficacy. Logo Foundation, Retrieved March 4, 2005 from http://el.media.mit.edu/logo-foundation/pubs/papers/research_logo.html

Confrey, J. (1990). A review of the research on student conceptions in mathematics, science, and programming. Review of Research in Education, 16, 3-56.

diSessa, A. (2000). Changing minds: computers, learning, and literacy. Cambridge, MA: MIT Press.

Eisenberg, M. (1997). End-user programming. In M. Helander, T. K. Landauer, & P. Prabhu (Eds.), Handbook of human-computer interaction. Amsterdam: Elsevier Science.

Gilmore, D. J., Pheasey, K., Underwood, J., & Underwood, G. (1995). Learning graphical programming: An evaluation of KidSim. Paper presented at the Interact'95, Lillehammer, Norway.

Goffman, E. (1981). Forms of talk. Philadelphia, PA: University of Pennsylvania Press.

Goodwin, C. (1994). Professional vision. American Anthropologist, 96(3), 606-633.

Goodwin, C., & Duranti, A. (1992). Rethinking context: An introduction. In A. Duranti & C. Goodwin (Eds.), Rethinking context: Language as an interactive phenomenon. Cambridge University Press.

Greeno, J. (1997). On claims that answer the wrong questions. Educational Researcher, 26(1), 5-17.

Hallden, O. (1997). Conceptual change and the learning of history. International Journal of Educational Research, 27(10), 201-210.

Hoyles, C., & Noss, R. (Eds.), (1992). Learning mathematics and Logo. Cambridge, MA: MIT Press.

Ivarsson, J. (2002). Tala, peka och lara matematik i datorbaserade miljoer: En kritisk analys. In R. Saljo & J. Linderoth (Eds.), Utmaningar och e-frestelser. IT och skolans larkultur. Stockholm: Prisma.

Kafai, Y. B. (1995). Minds in play: Computer game design as a context for children's learning. Hillsdale, NJ: Lawrence Erlbaum Associates.

Kahn, K. (1999). Helping children learn hard things. In A. Druin (Ed.), The design of children's technology (pp. 223-241). San Francisco: Morgan Kaufmann Publishers.

Koschmann, T. (1997). Logo-as-latin redux. Journal of the Learning Sciences, 6, 409-415.

Lave, J. (1988). Cognition in practice. Mind, mathematics and culture in everyday life. Cambridge University Press.

Lilja, P., & Lindstrom, B. (2002). "Vad ska man ha den till da?" Om konstruktionistisk teknologi och larande i skolans varld. In R. Saljo & J. Linderoth (Eds.), Utmaningar och e-frestelser. It och skolans larkulter (pp. 33-58). Stockholm: Prisma.

Linell, P. (1998a). Approaching dialogue: Talk, interaction and contextsin dialogical perspectives. Amsterdam: John Benjamins Publishing.

Linell, P. (1998b). Discourse across boundaries: On recontextualizations and the blending of voicesin professional discourse. TEXT, 18(2).

Mauritzson, U., & Saljo, R. (2001). Adult questions and children's responses: Coordination of perspectives in studies of children's theories of other minds. Scandinavian Journal of Education, 45(3).

McCloskey, M. (1983). Intuitive physics. Scientific American, 248, 122-130.

Noss, R., & Hoyles, C. (1996). Windows on mathematical meanings. Learning cultures and computers. Dordrecht, The Netherlands: Kluwer Academic Press.

Palumbi, D. B. (1990). Programming language/problem-solving research: A review of relevant issues. Review of Educational Research, 60(1), 65-89.

Pea, R., & Kurland, M. (1984). On the cognitive effects of learning computer programming. New Ideas in Psychology, 2(2), 137-168.

Polya, G. (1957). How to solve it. New Jersey: Princeton University Press.

Pomeranz, A., & Fehr, B. J. (1997). Conversation analysis: An approach to the study of social action as sense making practices. In T. v. Dijk (Ed.), Discourse as social interaction, 2. London: Sage.

Rader, C., Brand, C., & Lewis, C. (1997). Degrees of comprehension: Children's understanding of a visual programming environment. Paper presented at the CHI, Atlanta.

Repenning, A., & Perrone, C. (2001). Programming by analogous example. In H. Lieberman (Ed.), Your wish is my command. Programming by example. San Francisco: Morgan Kaufmann Publishers.

Resnick, M. (1990). MultiLogo: A study of children and concurrent programming. Interactive Learning Environments, 1(3).

Roth, W. M. (1999). Art and artifact of children's designing: a situated cognition perspective. The Journal of the Learning Sciences, 5(2), 129-166.

Saljo, R., & Bergqvist, K. (1997). Seeing the light: Discourse and practice in the optics lab. In L. B. Resnick & R. Saljo & C. Pontecorvo & B. Burge (Eds.), Discourse Tools and Reasoning. Essays on Situated Cognition. Springer 'Verlag.

Saljo, R., & Wyndhamn, J. (1990). Problem-solving, Academic performance and situated reasoning. A study of joint cognitive activity in the formal setting. British Journal of Educational Psychology, 60, 245-254.

Schoultz, J. (1998). Communication, context, and artifact. Studies of student's mastering of scientific discourses. Unpublished Licentiate, Linkoping University, Linkoping.

Smith, D. C., & Cypher, A. (1999). Making programming easier for children. In A. Druin (Ed.), The design of children's technology (pp. 202-221). San Francisco: Morgan Kaufmann Publishers.

Tholander, J., Kahn, K., & Jansson, C.-G. (2002). Real programming of an adventure game by an 8-year-old. Paper presented at the International Conference of the Learning Sciences 2002, Seattle, WA.

Vosniadou, S. (1994). Capturing and modeling the process of conceptual change. Learning and Instruction, 4, 45-69.

JAKOB THOLANDER

Stockholm University, Royal Institute of Technology, Stockholm, Sweden

[e-mail]