Introduction

The prevalence of digital systems in our society underscores the need for the skill of computational thinking (CT). Scholars have consistently highlighted its importance (see reviews by Barcelos et al., 2018; Hickmott et al., 2018; Kalelioğlu et al., 2016; Selby & Woollard, 2013; Wang et al., 2022) for individuals to navigate the digitized world competently. Wing (2006) even elevates the status of CT to that of fundamental skills like reading, writing, and arithmetic, emphasizing its relevance to all people.

Computational thinking (CT) involves problem-solving in a manner that a computer could handle (Wing, 2006). However, this does not suggest that humans should mimic computers (Wing, 2006). Rather, computers only execute what humans programmed them to perform. Nonetheless, the capability to use digital systems has resulted in novel approaches for solving otherwise unsolvable problems. Wing (2006, p. 33) states that CT “represents a universally applicable attitude and skill set that everyone, not just computer scientists, would be eager to learn and use”.

Wing's (2006) description of CT is considered a rather vague definition, that should be more clearly defined and operationalized (Selby & Woollard, 2013). Denning (2017) also criticizes that, in his view, the term computational thinking is used in a “vague and confusing” (Denning, 2017, p. 37) way outside of computer science. In his opinion, “the result was a vague definition that targeted not only designers but all users of computational tools, anyone engaging in step-by-step procedures, and anyone engaging in a practice that could potentially be automated” (Denning, 2017, p. 38). He questions whether CT in this sense is really important for everyone. This paper assumes that in order to understand the digital systems in the world around us, it is important to have a basic understanding of these systems. The point is not that people are always engaged in CT just because they perform a task that could also be performed computationally. Instead, what is important are the higher-level CT activities that make it possible to describe a problem in such a way that it can be solved algorithmically.

CT is becoming increasingly important as a learning content in schools worldwide. A review study of Wang et al. (2022) shows that there is increasing interest in the integration of CT in STEM, but that there is still little assessment of integrated CT and STEM. While some countries have already firmly integrated it into their curriculum, Germany has yet to explicitly incorporate it. However, digital literacy is recognized as a vital task for all subjects in Germany (Diethelm & Brinda, 2018; GFD, 2018; KMK, 2017). CT can be seen as part of this digital literacy, which cannot be taken for granted. The ICILS 2018 survey – which included the CT competencies of 8th grade students for the first time – revealed that Germany ranks below average in international comparison of CT competencies (Eickelmann et al., 2019; Labusch & Eickelmann, 2023). Consequently, further research and development are needed in this area.

Thus, the question remains as to how exactly CT can be integrated into the mathematics classroom and which CT activities can be stimulated in learners.

Definition and Framework: Computational Thinking

Computational thinking generally describes a way of thinking that allows a problem to be described in a way that a computer could solve it (Grover & Pea, 2013; Harlow et al., 2016; Kotsopoulos et al., 2017; Wing, 2006). The term originated with Papert (1980), who developed the Logo programming language as a tool to allow learners to explore abstract mathematical concepts in a concrete way, thereby promoting mathematical learning. It is a way of thinking that helps to solve problems by recognizing and using structure.

The term CT is closely related to the notion of problem solving (Selby & Woollard, 2013), where CT is primarily concerned with activities such as abstraction and decomposition to solve problems (Barcelos et al., 2018; Wing, 2006). In problem solving in mathematics, Polya (2004) writes that abstraction and problem decomposition are crucial for successful problem solving. Thus, there are parallels between problem solving in computer science and problem solving in mathematics, even if they are not completely equivalent. To develop a framework for computational thinking, Kalelioğlu et al. (2016) conducted an inductive qualitative content analysis of 125 articles on CT. In their proposed framework, the content of the papers studied is mainly about activities (computarized or unplugged) that promote CT in the curriculum. The target audience was mainly K-12 (47 out of 78, the others were higher education). Because of the similarities that exist, there is much debate about the extent to which CT and mathematical thinking are the same or different (Knuth, 1985) or the extent to which CT and mathematics can influence each other (Lagrange & Laval, 2022; Noss et al., 2020). The aim of this paper is less to specify further the similarities and differences, but rather to specify more precisely what CT can look like in mathematics classrooms.

CT is not the same as programming (Wing, 2006). Wing (2006) distinguishes CT from programming in that CT “requires thinking at multiple levels of abstraction” (Wing, 2006, p. 35). Whereas programming is primarily about implementation, which is the technical conversion of an algorithm into program code, CT is more about the higher-level thinking involved in designing an algorithm to solve the problem (Barr & Stephenson, 2011). In their literature review on teaching and learning CT through programming, Lye and Koh (2014) aptly describe that programming and CT are different skills, but programming requires the use of CT and is also often used to teach CT. However, they do not refer specifically to the teaching of mathematics.

There are differing views on which activities exactly belong to computational thinking (Brennan & Resnick, 2013; Grover & Pea, 2013; Selby & Woollard, 2013). Brennan and Resnick (2013) distinguish computational concepts as “the concepts that designers deal with when programming, such as iteration, parallelism, etc.” (ibid., p. 1), computational practices as "the practices designers develop as they engage with the concepts, such as debugging projects or remixing the work of others" (ibid., p. 1), and computational perspectives as “the perspectives designers form about the world around them and about themselves” (ibid., p. 1). The concepts are important for the creation of program code. The practices and perspectives describe the approaches that learners take.

Selby and Woollard (2013) therefore also speak of thinking skills to characterize computational thinking. However, they describe similar processes: “It is a cognitive or thought process that reflects

  • the ability to think in abstractions,

  • the ability to think in terms of decomposition,

  • the ability to think algorithmically,

  • the ability to think in terms of evaluations, and

  • the ability to think in generalizations.” (Selby & Woollard, 2013, p. 5)

This paper also focuses on learners' approaches. Therefore, based on Brennan and Resnick (2013) and Selby and Woollard (2013), the following CT activities are distinguished:

  • Reusing and Modifying: Reuse and modify existing code as needed

  • Decomposing: Decompose a problem into subproblems

  • Testing and evaluating: Testing and targeted adaptation

  • Algorithmitizing: Plan a step-by-step approach

  • Abstracting: See general properties in special cases

  • Generalizing: Inferring a common aspect from different special cases

Related Research on CT in Mathematics Education

CT in the Mathematics Curriculum

One strand of research on CT in mathematics education is concerned with what content in the mathematics curriculum CT could be linked to. Some potential has already been identified by linking to learning content already present in the curriculum (Stephens, 2018; Weintrop et al., 2016). For example, Stephens (2018, p. 8) promotes that “more explicit attention to algorithmic thinking in school mathematics could help students expand their problem-solving techniques and explain and justify their mathematical reasoning”.

In addition, algorithms are important in many places in mathematics classrooms anyway. However, they are rarely treated as algorithms in their structure. Here, there would be some overlap and points of connection that could be used (Hennessey et al., 2017). One example would be a construction of a quadrilateral using Euclidean geometry. An algorithm could consist of constructing four right angles one after the other using a compass and ruler. In mathematics classrooms, however, the structure of this algorithm is not explicitly discussed. The focus is often on the product at the end and not on the process. Instead, one could also think about which elementary instructions are possible at all, why the algorithm arrives at a solution in a finite number of steps or whether there are more efficient ways. There would also be potential here to address concepts such as incrementality and control structures such as loops and branches, when recurring patterns are recognized and used. Additionally, Barcelos et al. (2018) show in their review study that almost 50% of the articles considered therein deal thematically with plane geometry. Most articles try to comparatively analyze “the competencies, skills and contents that are present in curricula guidelines of math and computation fields” (Barcelos et al., 2018, p. 831). Thus, there are commonalities and, therefore, connecting points to be able to promote CT also in mathematics classrooms.

CT as a Learning Medium: Promoting Mathematics Through CT

Some studies deal with the question of how mathematical ideas can be promoted through CT. In this sense, CT acts as a learning medium in the service of subject learning. Underlying this approach is the assumption that CT and mathematics are different activities.

Misfeldt and Ejsing-Duun (2015) use an instrumental approach to investigate a model for the teaching of mathematics through programming. Their empirical examples of learning mathematics through programming show that learners, with the goal of programming a game, set themselves algebraic tasks to solve (e.g., they need variables to make countdowns or scoring systems) (ibid.). In the case study, it was very important that the teacher was careful to draw the students' attention to explicit and relevant mathematical ideas (Misfeldt & Ejsing-Duun, 2015). Otherwise, there is a risk that superficial playful elements will dominate the process and the mathematical potential will not be realized. This is in line with Noss and Hoyles (1992), as students easily overlook the nuggets of mathematical knowledge in the microworld. Thus, the potential for learning mathematics is not necessarily exploited.

Gueudet et al. (2022) investigate how university students learn to use programming as a tool for mathematical investigation. They also use an instrumental approach to describe in detail a student's learning process in terms of developing schemes in a case study. In some of these programs, mathematics and programming were combined. In particular, this study shows that university students cannot necessarily use programming automatically as a means of exploring mathematical phenomena, but that appropriate learning processes are necessary. Knuth (1985) also describes that the way of thinking is not intuitive for everyone. This is probably true for learners as well, so it would be important to consider programming or CT as a separate learning content.

CT as a Learning Content: Promoting CT through Mathematical Content

CT is becoming recognized as a significant aspect of general education that ought to be promoted in schools. An effective way to encourage CT is through subject-integrated support, such as in mathematics (Hennessey et al., 2017; Lockwood et al., 2016; Sanford & Naidu, 2016; Weintrop et al., 2016). Additionally, CT serves as an object of learning in the following examples. This does not imply that teaching mathematics is no longer the primary objective, but rather that CT can be valuable as a standalone learning content in addition to a learning medium.

Harlow et al. (2016) offer preliminary evidence of how children can develop programming skills by drawing Turtle graphics for example. They also point out the potential to learn something through the feedback, for example if the figure drawn does not yet look as desired (ibid.). This highlights the possibility of integrating programming and mathematical principles in a cohesive manner. However, it is still uncertain to what degree higher-level CT thinking skills can be encouraged.

Benton et al. (2017) report on the ScratchMath project, a design research project that developed curriculum materials and professional development (PD) to support mathematical learning through programming for students aged 9–11. Scratch is a block-based programming language (Resnick, 2012). In particular, Benton et al. (2017) focus on two concepts which they describe as central to the ScratchMath curriculum for Years 5 and 6: the concept of algorithm and 360° total rotation. The relationship between the total turn of 360°, number of sides, and angle of turn is investigated by drawing polygons, providing an initial framework to uncover the correlation between the angle of turning and the frequency of repetition (Benton et al., 2017). The researchers noticed three techniques used by students to calculate values in the move and turn blocks. These were then discussed with teachers during professional development sessions, enabling them to prepare adequately for classes. These strategies include: (1) “Guessing or using incorrect calculations”, (2) “Counting and estimation” and (3) “Correct calculation” (Benton et al., 2017, pp. 129–130). Overall, it has been reported that the concepts of algorithm and the 360° total turn are challenging for both teachers and pupils (ibid., p. 134). Additionally, it has been highlighted that providing pointers such as expressing the number of times to repeat is of utmost importance (ibid., p. 135).

CT can be improved with or without programming (Kalelioğlu et al., 2016; Lye & Koh, 2014; Wang et al., 2022). For instance, in Zindel’s (2022) study, learners created written instructions for Caesar encryption that can be considered as pseudocode. This approach demonstrated that concepts like loops and branches can be reinvented without programming them. Kyriakides et al. (2016) twice visited a group of fifteen 10–11-year-old children, each time carrying out a teaching session that employed the A.L.E.X. app. A.L.E.X. is an app designed for acquiring programming skills by playing games. The study examined how the app can prompt learners' interest in mathematics through instigating problem-solving processes. They found that there were different things happening in the cases. Some learners are able to picture angles of 90, 180, and 360 degrees as rotations in a dynamic way. Others prefer to physically walk through the steps before programming them to get a better understanding. It still needs to be investigated how CT can develop during such processes.

Research Question

There are many calls to integrate CT into STEM. With regard to mathematics education, two roles of CT could be identified in this paper:

  1. 1.

    CT as a learning content: The focus here is on promoting CT in mathematical content.

  2. 2.

    CT as a learning medium: the focus here is on promoting mathematical ideas through CT.

In order for CT to become conductive to mathematics learning, it is important that mathematical content is explicitly addressed so that it is not overlooked. Furthermore, it is important that CT is also seen as a learning content that is not trivial and not necessarily intuitively comprehensible for learners. For this, it must be specified more precisely what is to be understood by the respective CT activities.

In this paper, therefore, the focus is on CT as a learning content. Further research is needed that not only shows the theoretical potentials of CT in mathematics classrooms, but also empirically verifies them by analyzing the actual learning pathways of learners and specifying how CT can look concretely in mathematics education. This paper therefore aims to empirically identify which CT activities can be initiated during programming in geometry classes and which subcategories can be identified. Accordingly, the research question is:

RQ: Which CT activities do learners show when designing an algorithm for drawing plane figures and which differences within CT activities can be identified?

Methods

An exploratory case study was conducted (Yin, 2002) because of the limited knowledge concerning empirically relevant differences in students‘ use of CT. The approach is appropriate for investigating the internal cause-and-effect relationships within individual cases, without the necessity of providing explanations for them. When conducting an exploratory case study, it is crucial to select appropriate cases that are comparable on one hand and diverse enough on the other hand to reveal possible variations in the phenomena. In this study, comparability is ensured by the fact that all learners attend the same school class and, therefore, have had the same learning opportunities. Additionally, all learners complete the same assignments. For this paper, cases were selected that demonstrate the most significant variations in editing processes, facilitating a more comprehensive grasp of the discrepancies within CT activities.

Participants and Data Collection

The study was conducted with 12 learners from a sixth-grade class, all of whom participated in the survey voluntarily and with the consent of their legal guardians. The learners were between 11 and 13 years old and worked in teams of two on the tasks. They had no previous programming experience in their mathematics classes. However, plane figures and their properties had already been discussed. Each team of two participated in two sessions of 60 min each. These were videotaped. Care was taken to ensure that the video showed which code they were writing. In total, about 720 min of video material were created in this way. For this paper, the scenes in which the learners were asked to change the code of the square to a code for a hexagon were completely transcribed according to a standardized transcription manual.

Data Analysis

A qualitative content analysis according to Kuckartz (2019) was conducted to identify the CT activities performed by the learners when designing the algorithm for a regular hexagon. In a first step, the transcripts were each subdivided according to which of the intended processing steps were performed and when. In a second step, each of the sections identified in the first step was analyzed turn-by-turn to determine which of the CT activities occurred. If no CT activities were evident, no code was set and the corresponding utterances were not included in the analysis. Following Brennan and Resnick (2013) and Selby and Woollard (2013), the following CT activities were focused on and the operationalizations listed were used (Table 1).

Table 1 Coding manual for CT activities
Full size table

The next step was to take a closer look at the posts relating to a CT activity and compare them. This revealed differences in the exact design of the CT activities. In an inductive procedure, subcategories were then formed for the CT activities in order to characterize the possible designs (for preliminary results concerning different types of testing and evaluating that occur when programming regular polygons see Büscher, accepted).

Design of the Tasks

The chosen programming environment is Turtlecoder (accessible online for free at code-your-life.org/turtlecoder), available in both visual and text-based variants for flexible switching as necessary during the process. However, in the task of the larger teaching-learning arrangement focused on here, the potential of the text-based variant has not yet been utilized, and only the visual version has been employed initially in order to avoid any syntax issues. At the same time, this approach offers the advantage of providing a range of possible commands and steps for decomposing the problem, allowing for easier selection. The advantage of visual programming languages is that the syntactic requirements are low in order to focus on semantics.

Mathematically, the tasks are about regular polygons, i.e., polygons in which all n angles are equal and all n sides are equal in length. The construction by an algorithm requires a dynamic perspective and thus an explication of both the properties of the sides and the properties of the angles. In particular, the exterior angles are to be interpreted here as rotation angles. In the dynamic perspective it is clear why the sum of the exterior angles is 360°. It corresponds to a rotation around itself.

In this paper, the task of constructing a hexagon is considered as an example. In a previous session, the students had already learned about the commands forward(< length >) and leftTurn(< angle >) or rightTurn(< angle >), which can be used to move the turtle forward by a certain length or to rotate it clockwise or counterclockwise by a certain angle. With this, they independently created a program code for a square (Fig. 1). At the beginning of the second session, the learners had the following task: ‘Change your program code so that a regular hexagon is drawn’. The task is deliberately open-ended to allow for different possible paths.

Fig. 1
figure 1

Example code for a square (left) and a regular hexagon (right) (created with the Turtlecoder at code-your-life.org/turtlecoder, © Helliwood media & education)

Full size image

Figure 1 shows a possible program code for drawing a regular hexagon. Here, the turtle is moved forward six times by 200 pixels each time and then rotated counterclockwise by 60°. The length of the sides was freely selectable. The required rotation angle is 60°, because the sum of the exterior angles in the polygon is always 360° (a full rotation around itself). So, for a regular hexagon, the size of each exterior angle is 360°:6 = 60°. One could have used a loop in the code as an alternative. This concept was not yet known to the learners at this point of time. Rather, they were to discover for themselves the need for a structure that would implement repetitive elements more quickly, before the loop was subsequently introduced. How the learners get to the code is not further specified in the task, so that different ways are conceivable.

In this project, the tasks are set so openly that the problem can first be decomposed and algorithmitized. This means that there is no predefined code at the beginning, which only has to be completed like a cloze text. To solve the given problem, it can be decomposed into subproblems and the individual considerations can be converted into commands in the code. Abstracting is also made possible in the process. That is, the tasks are conceived in such a way that a general mathematical structure is behind it, which can be used for algorithmitizing (for example the knowledge over the external angle sum in the polygon around the necessary rotation angle with the construction of a polygon to determine). In addition, the programming environment allows testing and evaluating and reusing and modifying code. This means that it is possible at any time to execute the code created so far and to see how the programmed figure looks. If necessary, individual commands in the code can be deleted, exchanged or the parameters (such as the specific length of a forward movement or the angle by which it should be rotated) can be changed.

Later on, by comparing and delimiting different planar figures, the activity of generalizing is also possible. Based on the discovery that the sum of exterior angles in the previous examples is always 360°, a general procedure for the general construction of a regular plane figure could be derived. In the task focused in this paper, however, this is not yet the focus.

Empirical Results

In the following, we identify which CT activities the learners perform and differences in the learners’ use of CT activities. Since generalizing by definition is only possible by comparing several situations, this CT activity is not yet examined in this paper. The transcripts are literally translated from German.

Reusing and Modifying

When designing the code for drawing a hexagon, learners could have built on the code for drawing a square as described above. This study’s analysis revealed three different subcategories for this CT activity:

  • No reusing, but complete modification

  • Change of parameters while retaining the command structure

  • Structure modification while retaining the parameters

The case study of Leyla and Milan features two different types of code modification. The corresponding screenshots of the drawn figures after executing the code are shown in Table 2.

47   Leyla   [Leyla changes all angles to 36° and executes the code.]

48   Milan   [Milan tries to draw the hexagon mentally on the table.]

49   Milan   [Milan changes the first two angles to 70°, executes the code. Then he changes all angles to 70° and executes the code.]

50   Leyla   [Leyla changes all angles to 65° and executes the code.]

51   Leyla   [Leyla adds the commands forward(100) and leftTurn(65) two-times and executes the code. The result is an incomplete figure that has six sides.]

Table 2 Screenshots of the programmed figures of Leyla and Milan after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

Leyla and Milan both vary the angle of rotation (#47, 49–50). They initially leave the previous commands and only vary the parameter (change of parameters while retaining the command structure). Leyla then adds two more commands to her code in #51, an additional forward movement and another 65° rotation. Here, the number of executions is adjusted, but not the parameters themselves (structure modification while retaining the parameters).

However, there are also cases that completely delete their code and start over. Leni (#44, 46, 49) tries to solve the problem similarly to Milan and Leyla by trial and error. The corresponding screenshots of the drawn figures after executing the code are shown in Table 3.

44   Leni   [Deletes the code of the square. She adds one back(100) and two forward(100) commands and one leftTurn(90) and one rightTurn(90) commands in between. She does not execute the code.]

(…)

46   Leni   [adds five forward(100) commands and one leftTurn(100) and four rightTurn(100) commands in between and executes the code]

(…)

49   Leni   This looks interesting.. [deletes the code [5sec.] adds five forward(100) commands and five rightTurn(80) commands in between and executes the code]

Table 3 Screenshots of the programmed figures of Leni after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

In contrast to Milan and Leyla, Leni does not reuse the code, but deletes the entire code at the beginning and after each failed attempt and starts again from the beginning (No reusing, but complete modification).

Decomposing

To solve the problem as a whole, the problem could be decomposed into subproblems. This study’s analysis revealed two different subcategories for this CT activity: goal-directed decomposing in which sub-problems are identified that are viable for solving the larger problem at hand, and non-goal-directed decomposing in which sub-problems are identified that focus on more superficial features of the situation rather than the actual problem.

A corresponding decomposing can be identified in all cases studied, since all learners at some point focus on the subproblem of determining the rotation angle, and then complete the code (such as Leyla and Milan in the example above). Clarifying the appropriate rotation angle is also goal-directed, since the rotation angle is needed to construct the planar figure. The example of Daniel and Inga shows that this does not necessarily happen immediately. The corresponding screenshots of the drawn figures after executing the code are shown in Table 4.

33   Daniel   [Daniel deletes the square code.]

34   Inga   [Inga deletes the square code.]

35   Daniel   A hexagon.

36   Inga   A hexagon, you don't even know what a hexagon is.

37   Daniel   But I know what a hexagon is, Inga.

38   Inga   It has six corners.

39   Daniel   I know Inga. I am not as stupid as you think.

40   Inga   Really not?

41   Daniel   Really not. .. [He adds the commands: penUp; leftTurn(90)]

42   Inga   A hundred, right? [She adds the command forward(100)]

43   Teacher   One hundred, yes.

44   Daniel   Yes, ah, I have to rotate them first, otherwise it won't work ... turtle, I'll make forward hundred pixels and then. [He adds the command forward(100) and executes the code.]

45   Inga   [She adds the command leftTurn()] How many degrees was that?

Table 4 Screenshots of the programmed figures of Daniel after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

Daniel (#33) and Inga (#34) both delete their code from the square and start over. Thereupon they first clarify what a hexagon is and note that it has six corners. Daniel then starts – as before with the square – with a forward movement and a left turn of 90° (#41). In #44, Daniel realizes that he has to "turn them first". This is probably meant is the starting point of the turtle, as can be interpreted from the later course of the process. Daniel seems to think of a regular hexagon that ‘stands on its tip’, so to speak. This kind of decomposing is non-goal-directed, since the position of the hexagon on the screen is actually irrelevant. Inga also starts with a forward movement (#42). In #45, she also inserts the command for a left turn, but does not yet enter a concrete angle of rotation. Instead, she asks the teacher how many degrees that was (#45). Inga realizes – similar to Milan, Leyla, Anna and Ben – that the turn angle would have to be adjusted. However, she seems to have no idea how to determine the rotation angle herself.

Testing & Evaluating

The CT activity testing and evaluating is particularly useful for determining the specific angle of rotation required. This study’s analysis revealed two different subcategories for this CT activity: exploratory or strategic.

Some learners, such as Leyla and Milan, demonstrate testing and evaluating by trying different angles to determine the appropriate angle of rotation. The corresponding screenshots of the drawn figures after executing the code are shown in Table 5.

54   Milan   [changes all five rightTurn to rightTurn(72) and executes the code]

55   Leyla   [changes all five leftTurn to leftTurn(70) and executes the code]

56   Milan   Ah I have it.

57   Teacher   You have it?

58   Milan   A hexagon [5sek.] Oh no, that’s a pentagon .. Oh my god"

59   Leyla   [changes all angles to 60° but deletes the command leftTurn after the second turn and executes the code]

60   Milan   [adds a forward(100) command and a leftTurn()]

61   Leyla   [she reinserts the leftTurn(60) command at the second angle and executes the code]

62   Leyla   Is this correct?

63   Milan   [turns to Leyla]

64   Milan   So you did it with 60?

65   Leyla   Mhm, I first had sixty-five, then I had seventy and then sixty.

66   Milan   I first had fifty, then seventy, then seventy-two and then I had a pentagon.

67   Milan   [He changes all angles to 60° and executes the code. The hexagon that is created still has one side too few. Then he adds a new side that is 100 pixels long and has the path of the turtle drawn again. The result is a complete hexagon.]

Table 5 Screenshots of the programmed figures of Milan and Leyla after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

Leyla and Milan try to solve the problem in an exploratory way by trying out different angles (#54, 55), until Leyla finds the correct solution by trying out the 60° angle (#59). By letting them draw, they get automatic feedback as they try it out, whether the desired figure is drawn and the code is thus correct or not yet.

Other learners like Inga show testing and evaluating in a strategic way by specifically evaluating previously made assumptions. The corresponding screenshots of the drawn figures after executing the code are shown in Table 6.

51   Inga   I think I know [She inserts the 120° angle]

52   Daniel   [Daniel watches Inga trying to solve the problem] Ah, 120 degrees leftTurn?

53   Inga   120? Isn't that 120?

54   Daniel   [incomprehensible]

55   Teacher   Try it out, so you have, so for the task is a little bit more time also planned, so you can just try out how you get on it.

56   Inga   [executes her code] A hundred and twenty is too much, oh well, I also made in the wrong direction.. Oh.

Table 6 Screenshots of the programmed figures of Inga after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

After first saying that she wants to draw it, but before she has done so, in #51 she makes the assumption that the angle of rotation might be 120°. When she tries this, she finds that the angle is too large and she has turned "the wrong way" (#56). She may have determined the size of the interior angle in the regular hexagon here and mistakenly interpreted this as the angle of rotation.

Algorithmitizing

The CT activity of algorithmitizing shows up at different points in the process. This study’s analysis revealed two different subcategories for this CT activity: step-by-step and block-by-block.

After they have correctly determined the necessary rotation angle, Anna and Ben modify the para-meters in the already existing code accordingly. The corresponding screenshots of the drawn figures after executing the code are shown in Table 7.

180   Anna&Ben   [Both change the four angles to 60° and execute the code.]

181   Ben   Oh, I haven't been, I haven't been. erm...

182   Anna&Ben   [Both add two more forward(100) commands and a leftTurn(60) command between them and execute the code]

183   Ben   Then turtle, left turn, 60, then turtle forward and turtle left turn 60.

Table 7 Screenshots of the programmed figures of Anna and Ben after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

After executing the code, Anna and Ben realize that they have each forgotten four program lines for two forward movements and two rotations in between. They add this to their respective program code (#182). Possibly this activity was initiated by the previous evaluating when the learners noticed that there was now a gap between the start and end points.

Also, in the example of Milan and Leyla above (#47–51), it is noticeable that Milan and Leyla both first adjust the angle sizes and do not yet extend the code to include the additional four lines of code needed (by moving forward twice and rotating in between to make it a hexagon). This is not done until #51. Both case studies thus illustrate a block-by-block approach. Also, the case study of Leni above (#44–49) is an example for a block-by-block procedure, because here even everything is changed at once and only then tested.

Klara, on the other hand, takes another approach. The corresponding screenshots of the drawn figures after executing the code are shown in Table 8.

66   Klara   [Klara adds a command forward(100) and executes the code. She adds a command leftTurn(60) and executes the code. She adds a command forward(100) and executes the code, so that a figure looking like a kind of house is created]

Table 8 Screenshots of the programmed figures of Klara after each executing the code (created at code-your-life.org/turtlecoder, © Helliwood media & education)
Full size table

Klara alternately inserts a new command and then executes the code. So, she proceeds step-by-step, and between two new commands she tests and evaluates.

Abstracting

The CT activity abstracting has occurred very rarely in the cases examined so far. Therefore, no subcategories could be formed yet. In the case of Anna and Ben, however, the beginnings of abstracting can be seen. After a previous trial and error, they express mathematical considerations.

168   Anna   There are practically 6 sides.

169   Ben   How to distribute the 6 sides?

170   Anna   12 sides, isn’t it?

171   Ben   6 corners, sides .. Wait one, two, three, four, five, six. One, two,

three, four, five, six.

172   Anna   Yes, you also have a honeycomb.

173   Teacher   How many sides does a quadrilateral have?

174   Anna   Four .. thus six. But here are two sides, one corner. Oh, I counted those, too. Yes you are right.

175   Ben   Erm.

176   Anna   The quadrilateral is 90°, so four times 90 is 360. Maybe we just have to simply divide 360 by 6.

177   Ben   Right, 360 divided by 6. Wait, that's 60. Shall we put in 60?

178   Anna   Yes.

179   Ben   Maybe that works.

180   Both   [Both change the four angles to 60° and execute the code.]

181   Ben   Oh, I haven't been, I haven't been. Erm...

182   Both   [Both add two more forward(100) commands and a leftTurn(60) command between them and execute the code]

183   Ben   Then turtle, left turn, 60, then turtle forward and turtle left turn 60

184   Anna   If that is correct now, it is not so difficult.

185   Ben   Yes, yes, I think that's right. Yes, that's how I know it too, yes. We have it.

Anna recognizes the pattern in the exterior angle sum of a polygon and transfers this pattern to the hexagon (#176). Here, abstracting from the square code to the hexagon code takes place. The CT activity abstracting can be shown in concrete terms, for example, by activating the general knowledge about the sum of exterior angles in a polygon as well as the knowledge that all angles are equal in a regular hexagon.

Summary of the Results

When programming code to draw the hexagon, different CT activities could be identified in the machining processes. In total, all five focused CT activities could be observed. This made it possible to break down in more detail how the CT activities can be specified when designing an algorithm for drawing a regular hexagon (Table 9).

Table 9 Empirically identified subcategories of CT activities
Full size table

The empirical results show that various CT activities were initiated, with differences within the CT activities. The subcategories formed show the possible manifestations of CT activities when developing code to draw regular polygons. Thus, there is not one single sequence or one single form of a CT activity that is triggered by the task.

Discussion

Efforts to promote CT in schools, especially STEM, are on the rise (Hennessey et al., 2017; Lockwood et al., 2016; Sanford & Naidu, 2016; Wang et al., 2022; Weintrop et al., 2016). The goal of this article was to explore ways to integrate the promotion of CT into mathematics classrooms. Some studies indicate that CT is not intuitive for everyone (Gueudet et al., 2022; Knuth, 1985). The conducted study confirms that learners face challenges and need suitable learning opportunities. Empirical results not only demonstrate the possibility of introducing CT in math classrooms but also shed light on the varying nature of CT activities. The analysis revealed that different CT activities can be initiated for the same task. This observation has consequences for the assessment of CT. When measuring CT, it should therefore be kept in mind that certain tasks do not necessarily trigger the intended CT activities. The question of how CT can be measured is therefore still a current challenge (Denning, 2017). The category system presented here is an attempt to make CT detectable in learners' processes in mathematics classrooms.

Many studies on CT in mathematics education focus on the content of geometry (Barcelos et al., 2018). This study also showed that there is potential to stimulate CT in this topic. The analysis reveals that CT activities can be distinguished in different subcategories. Other observations also indicate that CT activities do not occur independently but are intertwined and can influence each other (Büscher, 2023). For example, after testing and evaluation, further activities such as reusing and modifying or algorithmitizing often occur. How the learners’ CT activities develop in the further course of learning is the subject of further investigations. Furthermore, it has to be investigated to what extent the results can be transferred to other mathematical topics.

In this article, the focus was on CT as a learning content. However, the same tasks also have the theoretical potential to support mathematical learning in two ways. On the one hand, activities such as decomposing and abstracting are also relevant for mathematical problem solving (Polya, 2004). In the future, it would be interesting to investigate the extent to which problem-solving processes in mathematically oriented tasks can be further developed through such CT activities. On the other hand, the activities could also promote mathematical ideas about the exterior angle sum as the empirical observations suggest (similar to what was intended in the ScratchMath project by Benton et al., 2017). Noss and Hoyles (1992) point out that it is important to ensure that mathematical potentials are not overlooked. Therefore, future research will explore what conditions of success exist for mathematical ideas to develop.

Possibly, the CT activities shown also depend on prior knowledge about the problem. Following on from these initial empirical observations, one could now conclude that mathematics is a resource for some and that something could be set in motion in this respect for others. In this sense, programming could provide a new perspective on geometric content. Papert (1980) therefore also speaks of computational geometry as another kind of geometry. This takes a dynamic perspective on geometry. When designing an algorithm for drawing plane figures, it is not sufficient to describe the properties of the figure to be drawn statically (a hexagon has six sides of equal length and six interior angles of equal size a 120°). By programming, these properties must be thought dynamically (I move forward six times the same length and rotate 60° each time in between). The difference is in particular that it is not helpful to consider only the interior angle, but that one must interpret the angle dynamically as a rotational movement. At the same time, spatial imagination and especially spatial orientation can be promoted. Since one must put oneself in the position of the turtle. The automatic feedback seems to play a central role in being able to correct errors independently (similar to Harlow et al., 2016). When executing the code, the learners can immediately see whether the turtle moves in the desired way. If it does not, they can use the specific incorrect movement to consider where exactly the error lies and thus improve their spatial orientation. This will also be investigated in more detail in the future. The extent to which mathematical ideas can actually be promoted in this way should be investigated further in follow-up studies.

Conclusion

Computational thinking is considered an essential twenty-first century skill that would be important for all people (Wing, 2006) to be able to move in the digitalized world in a mature way. Therefore, CT is seen as an increasingly important learning content in schools (Eickelmann et al., 2019). There are differing conceptualizations of which activities belong to CT (Brennan & Resnick, 2013; Grover & Pea, 2013; Selby & Woollard, 2013). This paper presented the results of a study which examined which of the CT activities focused on here (Reusing and modifying, decomposing, testing and evaluating, algorithmitizing, abstracting, generalizing) learners show when designing an algorithm for plotting a hexagon. The empirical analysis made it possible to identify subcategories of these CT activities, which at the same time specify the CT activities more precisely in relation to mathematics instruction (Table 9). This contributes to a more precise understanding of what it might look like to integrate CT into mathematics classrooms. A better understanding of CT activities also allows learning processes to be better described and differentiated.

However, the study presented here is also subject to limitations. So far, the focus has been on the task in which learners are asked to change the code from a square to a hexagon. To what extent the processes of designing algorithms for drawing other plane figures are similar or different is the subject of further analysis. Due to the design as a case study, no statements can be made yet about which CT activities occur particularly frequently. This question will be investigated in a further analysis. The advantage of the qualitative approach followed here is that it allowed the possible differences in CT activities to be investigated in more depth. It also demonstrated the feasibility of stimulating CT docked to a geometric content at all. Furthermore, the different CT activities indicate that it is not possible to predict with certainty how learners will use the programming environment. The consequence for teachers in the classroom is that they should be sensitized to possible different approaches in order to be able to support learners individually if necessary.

The question remains open as to which CT activities are particularly conductive to mathematics learning. In some cases, the case studies suggest the potential that CT activities also taught mathematics (similar to what was intended in the ScratchMath project by Benton et al., 2017). The empirical analyses indicate that some subcategories of CT activities may offer more opportunities for this than others. This needs to be explored further. Noss and Hoyles (1992) also point out that it is important to ensure that mathematical potentials are not overlooked. Therefore, in the future, it will be investigated which conditions for success exist so that mathematical ideas develop during the programming of geometric figures.