Opportunities and challenges in technology-rich classrooms:

Using the Scratch software

KATHRIN OTREL-CASS, MICHAEL FORRET and MERILYN TAYLOR

Introduction

Technology-rich learning environments are appearing in many schools across New Zealand. Classrooms equipped with a range of technological tools present a variety of opportunities and challenges for teachers and their students. Information and communications technology (ICT) allows users to perform certain activities in ways that would not be possible otherwise (Loveless, 2002). However, ICT practices vary greatly and are closely related to the technological tools used and the context in which they are placed (Tolmie, 2001; Webb, 2002). Hardware and software create new opportunities for learners to develop skills and knowledge and shape teachers’ ICT-informed pedagogical knowledge (Cox et al., 2004). In the Scratch pilot project we aimed to gain some insights into what the free software program Scratch had to offer to a teacher and her Year 6 students. The class, a digital-learning class of 26 students, had already used software programs like Keynote, Flash, HyperStudio and Pages, and we were interested in finding out what they thought this software had to offer. This article looks at the factors that supported learning with Scratch in this class and provides suggestions for teachers using similar software programs.

What is Scratch?

Scratch is a free-to-download graphical programming language (http://scratch.mit.edu/) that is designed to support and develop technological fluency (Resnick & Silverman, 2005). The software was created at the Media Lab at Massachusetts Institute of Technology (MIT) and has its developmental roots in the ideas and work of Seymour Papert (Harel & Papert, 1991; Papert, 1980), which led to the development of Logo and Technic Logo. Papert’s ideas underpin the design of Scratch, with one of its key aims being to provide “tinkerability” so that child programmers can put together, take apart and recombine programming building blocks to build whatever they wish (Resnick, 2007). The program interface displays three distinct areas on the screen (see Figure 1). In the upper right corner is the “stage” where graphic elements—so-called “sprites”—are placed and then controlled by a program to achieve the desired effect. In the lower right is the scripting, or programming, area where programming “blocks” are combined to provide the instructions that control the sprites.

On the left is the collection of programming blocks, each with its own function, that can be dragged into the scripting area and snapped together to create complete programs. Scratch uses “drag and drop” functionality that eliminates the need to remember codes or understand the syntax. In many programming languages it is possible to unwittingly write two lines of discordant or syntactically incorrect script. Within the Scratch environment, however, this cannot happen, as the command blocks will not physically fit together unless they can run together. This makes it quick and easy to learn how to use Scratch, and allows the child programmer to spend much more time on the logic and creative aspects of what they are trying to build.

The visual building blocks in Scratch are capable of using a variety of media and allow users to create their own interactive stories, animations, games, music and art, and subsequently share their projects online. The program is very versatile and can be used for teaching and learning in virtually any subject area including mathematics, science, music and art. Scratch has been specifically designed with young users in mind and so the features and media used appeal highly to children. Scratch provides a playful learning environment that, although simple and easy to use, is capable of producing complex and sophisticated outcomes. It provides a context within which children can enjoy exploring and being creative with programming.

The importance of the learning context

Learning activities create unique and specific contexts that undoubtedly have an influence on classroom practices and potential learning outcomes. However, a learning context is not predetermined but is framed by the physical environment (physical context), the participants’ sense making (cognitive context) and, on a more abstract level, by the culture of the individual participants and the classroom culture and practices (cultural context) (Arvaja, 2007). This means that a learning context is only relevant to a certain activity, and therefore the same technology or software can result in different learning outcomes, depending on the setting within which it is used (Tolmie, 2001).

The context for this study

This research project was conducted over two weeks in a Year 6 class of 16 boys and 10 girls. Their teacher was also the Year 6 team leader and the school’s ICT co-ordinator. This was a digital-learning class, with each student having access to their own computer and being experienced technology users. The children were, without doubt, confident users of computers, so-called “digital kids” (Hsi, 2007), but neither the teacher nor the children had used Scratch before. For the purpose of this research the classroom was divided into 13 groups of two students. The children selected their own work partners and group name. All 13 groups were single gender, with five groups of girls and eight groups of boys. A weblog (blog) was set up for each group to give them the opportunity to reflect on their own learning on a daily basis. Over the two-week period data were collected from: the student blogs; interviews with students and the teacher; and classroom observations.

During the first week of this project, students explored the basic building blocks of Scratch. The teacher, supported by the researchers, provided some closed and targeted tasks for the students to engage with so that they could familiarise themselves with the Scratch environment. The students were asked to work in groups and invent a group name, which they then had to animate using the program. The task was scaffolded by giving the students simple procedural instruction cards, available through the Scratch website, which allowed them to work on their tasks largely unassisted. In their blogs, the students reflected on their first impressions of using Scratch:

We wonder how you can make all sprite’s move at once with only using one button. (Blog 13, day 1, week 1)

… We can make it move by doing MoveX 10 and it will move 10 steps. (Blog 11, day 1, week 1)

The teacher later reflected on the language that the program used:

The metaphor of blocks works—the children could see what they were doing and then they could take it out and put it in and see how it affects what you are doing. (Final teacher interview)

The nature of the student activities changed from then on. The students were asked to design and build a simple mathematics game that would be suitable for a Year 1 student to use to learn how to practise additions and multiplications. This task encouraged them to experiment with the different features the program had to offer. The students liked the idea that you could create a game:

We are really enjoying scratch, we like making the math game. For our math game we are doing a game where you have to pick what answer fit with the question. (Blog 12, day 5, week 1)

When we asked the teacher at the end of the project to reflect on whether she might change anything in her teaching approach using Scratch, she thought that it took the children some time at the beginning to understand some of the deeper features of the software. She was surprised by the lack of noise in the classroom because the children were all busy trying to figure out how things worked. The teacher thought that it helped her students when she brought the class together and demonstrated some of the key features on the data projector:

What I did the second day—standing at the whiteboard and we watched, and with my ruler I got them to follow along with the script … We took a block out and saw what happened and put it back in and saw what happened. It wasn’t teaching it was just giving them understanding that this was scripting because kids don’t usually see programming as such. (Final teacher interview)

Working on individual projects while sharing and solving problems together

One of the features of the activity for the students was that they were all working on their group projects. Decisions about the types of maths games they designed for the Year 1 students were based on various factors: consultation with the Year 1 teacher about appropriate mathematics concepts that could be explored; talking to the Year 1 students; their own thoughts and ideas about what could be interesting; and inspiration from hardcopy maths resources. At times, the designs for their games were also influenced by identifying features from other students’ games, that they then wanted to incorporate. This level of autonomy raised the sense of value and ownership for one’s own work and for that of other students.

The children were at times prompted by what they had seen from other students and at other times were driven by the “tinkerability” of the software; the ability to make changes and try out their ideas in a playful way, which provided opportunities to be creative.

At the end of the first week one team wrote in their blog:

Today R wanted to play a game when he got to it it gave me an idea for the counting game. (Blog 10, day 5, week 1)

The teacher was surprised that the students were interested to go beyond simple solutions to problems:

The detail and complexity of what they were doing surprised me. I thought they would take the easy option, [but] they were after the harder option. (Final teacher interview)

At the beginning and end of each session the teacher clarified with the class what they set out to do or what had been achieved on the day. Common practice for the sharing at the end of the day was for one of the students to use the data projector to explain to the class what they had done (see Figure 2).

These were often opportunities for the other students to ask how certain features had been achieved, but they also prompted new ideas for their projects. The teacher commented that:

The bonus of the checking was that they were so proud to show—didn’t matter what they had done, they wanted to show it and to me that’s really important—it’s something that we do in our class anyway and is part of our culture. (Final teacher interview)

These were also times where students gave those who were presenting positive feedback. We researchers had the impression that this classroom environment was one where the members of this community valued the strength and expertise of the individual. This was also apparent when students were asked to help or provide some feedback on their peers’ designs.

In one instance (see Figure 3), one of the boys experienced a problem connecting one of the commands. He asked another boy to help him, but he could not solve the problem either. The second boy then asked a third boy. The third boy knew how to solve the problem, but rather than fixing it for the first boy, he stood next to him guiding him through step by step until the problem was solved. It seemed that the software program allowed individuals to engage in creative explorations that were supported by the established collaborative norms in the classroom.

Ownership and the value of feedback

While the students were all given the same challenge (designing a mathematics game for Year 1 students), what sort of game they would make or how they would approach the task was entirely over to them. The students had to develop their own pathways to meet the challenge. These pathways were individualised processes that were shaped by the nature of the feedback the students received. The feedback the students received through the software itself acted as an internally mediating and communally consistent tool in this process. For example, only certain command blocks fit together. The program also provides instructions and “how to” guides for users. While individual games were different, the building blocks and their associated functions were the same for all students and this provided “common ground” for discussion and feedback. Students received feedback from other “expert” students, either in private face-to-face space or in the public domain of class discussion and feedback sessions. The teacher’s role was that of a mentor who had to make sure that information was shared amongst the class, and who steered students along the way in case they got stuck. There was no predetermined pathway or process, but rather a variety of choices. The teacher set opportunities for the students to share those.

Students also had opportunities to report back to the class, and these were times when the teacher received information to conduct her formative assessment. These knowledge-sharing occasions also provided support to the other students and helped the teacher to evaluate, plan ahead and make adjustments to the planned activities if needed. Students were asked what they thought helped them when they were using Scratch. Most students mentioned that working in pairs helped them, but they also referred to the way feedback was provided to them through sharing times and the general classroom discussions with all the groups. The teacher thought that the software provided ways for the students to try things out, test and receive feedback:

Having the gallery and being able to copy a piece of scripting and put it in and see how it affects what you’re doing was pretty easy for the children once they got going. The metaphor of blocks works—the children could see what they were doing and then they could take it out and put another one in and see what the difference was. Flash is very layered and detailed—in Scratch the children very simply could change one aspect and see what the difference was. (Final teacher interview)

The advantage of using ICT tools in general, and Scratch in particular, is that students can try out and test ideas very quickly and easily remove or erase things they do not want to keep. The speed and ease of these processes was an advantage.

The teacher also thought that the students’ learning benefited from the communication between them— questioning, problem solving and sharing ideas that they had not thought of previously:

Having the feedback at the end of each session where they saw what others had done and that [discussion] started them off again. [This] was a really good way of seeing who was where and who needed to be jollied along. (Final teacher interview)

This was a formative-assessment opportunity for the teacher, and for the students it was an opportunity to self-reflect and be stimulated to include new ideas. However, students sometimes found it frustrating that they did not always get an easy answer from the software, so they “had to go and figure it out for themselves” (Final interview, group 12).

Discussion

In this pilot study we set out to explore the potential of Scratch to assist learning and teaching. From our own “playing” with the program we felt that it had the characteristics necessary to appeal to young learners as well as providing challenging opportunities for creative problem solving. The study has shown that, to a large extent, our hunch was correct. It has also provided some initial insights into the characteristics of both the software and the classroom that facilitated student engagement and learning. While the software has its own characteristics and brings a set of particular affordances to the learning situation, the learning context (as discussed earlier) is uniquely formed by physical, cognitive and cultural contexts that interact and combine to create the learning environment. In this study, the learning context was determined by the activities the students were asked to do, the existing and ongoing classroom culture and practices and the nature and design of Scratch.

The students in this project had to create something that actually worked. Bereiter and Scardamalia (2003) describe this sort of work as problem solving using a design approach, which in their opinion presents the fewest contextual constraints for the learning process. The task set was designing and building a simple mathematics game that would be suitable for a younger child to use to learn or practise additions and multiplications. While providing plenty of challenge in terms of game design and using the software, this task did not overburden the students with additional content to learn. That is, the content of the game—simple additions and multiplication—was not something new to be learnt. As relative experts in this area, the students could concentrate on how to design and build their game. The task was specific enough to allow the students to focus and get started quickly while open enough to allow for plenty of creativity and ownership. The students in this study were clearly what Hsi (2007) calls “digital kids”, while their digital teacher established classroom practices and norms that allowed for the individual pursuit of ideas while supporting each other. Feedback from the blogs the students posted and interviews with the children and teacher indicated that the Scratch program offered the students an opportunity to engage deeply with the tasks that were set by the teacher, while also exploring other issues that arose through individual inquiries. One of the challenges for ICT in schools has been described as finding ways to support creativity (Loveless, 2002). Some of the helpful characteristics of the software that supported engagement and creativity were that it was:

•&&&&designed specifically for children, with a child-friendly, graphical interface that does not require learning a new text-based language or syntax

•&&&&simple to use and quick to learn with a “low floor and high ceiling” (i.e., easy to get started building simple projects but with the capability and functionality to create complex, sophisticated programs)

•&&&&designed for “tinkerability” (i.e., intended to encourage playful exploration and experimentation).

The program encourages tinkering because it is tolerant of mistakes. It doesn’t allow blocks to be connected in ways that will not work. Programming “mistakes” do not crash the software; your program simply doesn’t work the way you want or expect and you can continue to tinker and figure out how to fix it.

In this study, Scratch offered the possibility for students to be highly creative and this was supported by established teaching practices and routines. Communication and collaboration between the children, the teacher and the software were crucial factors, as was a classroom environment that supported the ideas of individuals.

Acknowledgements

The authors would like to acknowledge the contributions made by Nigel Calder and Sheena Saunders, who were part of the research team.

References

Arvaja, M. (2007). Contextual resources in meaning negotiations of a student pair in a web-based history project. International Journal of Educational Research, 46, 215–228.

Bereiter, C., & Scardamalia, M. (2003). Learning to work creatively with knowledge. In E. DeCorte, L. Verschaffel, N. J. Entwistle, & J. Van Merrienboer (Eds.), Powerful learning environments: Unravelling basic components and dimensions (pp. 55–68). Oxford: Elsevier Science.

Cox, M., Abbott, C., Webb, M., Blakely, B., Beauchamp, T., & Rhodes, V. (2004). A review of the research literature relating to ICT and attainment. Coventry: British Educational Communications and Technology Agency.

Harel, I., & Papert, S. (Eds.). (1991). Constructionism. Norwood, NJ: Ablex.

Hsi, S. (2007). Conceptualizing learning from the everyday activities of digital kids. International Journal of Science Education, 29(12), 1509–1529.

Loveless, A. M. (2002). literature review in creativity, new technologies and learning (Futurelab Report 4). Bristol, UK: NESLA Futurelab.

Papert, S. (1980). Mindstorms: Children, computers, and powerful ideas. Brighton, UK: The Harvester Press.

Resnick, M. (2007, December/January). Sowing the seeds for a more creative society. learning & leading with Technology, 35(4), 18–22.

Resnick, M., & Silverman, B. (2005). Interaction design and children. In Proceedings of the 2005 conference on interaction design and children (pp. 117–122). New York: Association for Computing Machinery.

Lolmie, A. (2001). Examining learning in relation to the contexts of use of ICT Journal of ‘Computer Assisted learning, 17(3), 235–241.

Webb, M. E. (2002). Pedagogical reasoning: Issues and solutions for the teaching and learning of ICL in secondary schools. Education and Information Technologies, 7(3), 237–255.