Previous pages of this website demonstrate several points of connection between Computational Thinking and Universal Design for Learning. Based on these links, one can conclude that the addition of CT to the classroom can create a learning space in which more students’ educational needs are served. However, this is a conclusion in theory only. The real test is if CT can have this effect in actual practice. After all, good educational theories have little value if they cannot be applied to the classroom. If students don’t benefit from a pedagogical theory, then it must be discarded for one that will have the intended impact.
With all of this in mind, I set out to study firsthand the extent to which CT could support UDL in the classroom. As a setting for my research, I chose a grade 6 classroom in a mid-sized southeastern Ontario city. Demographically speaking, the school could be described as having average ranges of socioeconomic and cultural diversity. One distinguishing trait of the school’s population is the higher than average percentage of students whose families are affiliated with the Canadian Armed Forces (the school is positioned quite close to a Canadian Forces Base).
With all of this in mind, I set out to study firsthand the extent to which CT could support UDL in the classroom. As a setting for my research, I chose a grade 6 classroom in a mid-sized southeastern Ontario city. Demographically speaking, the school could be described as having average ranges of socioeconomic and cultural diversity. One distinguishing trait of the school’s population is the higher than average percentage of students whose families are affiliated with the Canadian Armed Forces (the school is positioned quite close to a Canadian Forces Base).
The study occurred from January to March 2017. Over the course of ten weeks, I spent fifteen one-hour sessions with 24 grade 6 students and their teacher. These sessions were, for a variety of reasons, more spread out than I would have liked. Most weeks, we were only able to schedule one session; only a few times were we able to schedule computational thinking sessions on concurrent days. Fewer than half the students had done any coding in the past, and none of these had ever used the programming platform that I had chosen, Scratch 2.0.
Our computational thinking and coding activities were largely guided by George Gadanidis’ book, Coding for Young Mathematicians. We started by experimenting with the most basic commands in Scratch in the context of geometrical shapes. Using only the move and turn blocks, we learned how to draw a square on the stage. Once students were comfortable with that, I mused aloud about the possibility of making the code more efficient. One of the students with coding experience brought up the idea of repeat blocks. I took this opportunity to show the students how loops can make a script more efficient.
Our computational thinking and coding activities were largely guided by George Gadanidis’ book, Coding for Young Mathematicians. We started by experimenting with the most basic commands in Scratch in the context of geometrical shapes. Using only the move and turn blocks, we learned how to draw a square on the stage. Once students were comfortable with that, I mused aloud about the possibility of making the code more efficient. One of the students with coding experience brought up the idea of repeat blocks. I took this opportunity to show the students how loops can make a script more efficient.
Seeking greater efficiency, we talked about the possibility of developing one code that could be used to create any polygon, and what such a code would require. This was our first attempt at abstraction. After many attempts and much conversation, we abstracted the idea that the interior angles of regular polygons become larger as the number of sides increases. At the same time, the amount of turn that is required to create the interior angle (i.e., the supplementary angle to the interior angle) becomes smaller, and is always equal to 360 divided by the number of sides in the polygon. As a class, we translated this idea into a code. I took this opportunity to introduce the students to the use of variables in Scratch.
At this point, the students’ general level of proficiency was such that it was appropriate to give them the freedom to explore in different directions. I provided them with several geometric challenges to choose from. Each of these was in the form of a suggested end product (for example, square spiral, Fibonacci spiral, samples of geometric art). The students worked on these over the next two sessions. Most were able to convert their desired outcomes into coded steps. Decomposition of a big task into smaller units came naturally to them in this setting. However, most students created programs that, while accurate, lacked the efficiency we had established in our polygon generation code. One common example involved the square spiral. All students who attempted this challenge wrote long, repetitive programs in which the angle of turn remained the same (90°) while the distance traveled in between turns either grew or shrank by regular intervals (depending on whether the spiral started at the centre and grew outward, or vice versa). The culprit here was a lack of understanding of variables and operators. As I spoke with various pairs, I realized that most students understood the concepts behind the construction of a spiral, but that they did not understand variables and operators well enough to create a streamlined code to achieve their ends. This was a teachable moment. I modelled how these blocks might be used in this situation, taking care to highlight the differences and similarities between the pre- and post-variable-and-operator codes.
At this point, the students’ general level of proficiency was such that it was appropriate to give them the freedom to explore in different directions. I provided them with several geometric challenges to choose from. Each of these was in the form of a suggested end product (for example, square spiral, Fibonacci spiral, samples of geometric art). The students worked on these over the next two sessions. Most were able to convert their desired outcomes into coded steps. Decomposition of a big task into smaller units came naturally to them in this setting. However, most students created programs that, while accurate, lacked the efficiency we had established in our polygon generation code. One common example involved the square spiral. All students who attempted this challenge wrote long, repetitive programs in which the angle of turn remained the same (90°) while the distance traveled in between turns either grew or shrank by regular intervals (depending on whether the spiral started at the centre and grew outward, or vice versa). The culprit here was a lack of understanding of variables and operators. As I spoke with various pairs, I realized that most students understood the concepts behind the construction of a spiral, but that they did not understand variables and operators well enough to create a streamlined code to achieve their ends. This was a teachable moment. I modelled how these blocks might be used in this situation, taking care to highlight the differences and similarities between the pre- and post-variable-and-operator codes.
From geometry, we moved on to patterning, once again using the information from Gadanidis’ book as a guide. I exposed the students to the “use-modify-create” progression of programming by offering them several pre-made patterning codes from which they could start. These programs demonstrated patterns in number lists and in visual form. All students started at the same place by accessing and using the codes I provided. Growth from that point was directed entirely by the individual students. Some made only minor changes to my codes, whereas others, having used and modified mine, went on to create programs that presented patterns in ways that I had not modelled. For example, my codes offered visual representations of numerical patterns in the form of vertical lines of tiles, but one student created a new code that differentiated the constant from the multiplier, and furthermore, presented the multiplier in array form. This particular endeavour into CT and coding featured the low floor, high ceiling, and wide walls that are as characteristic of CT as they are of UDL. All students could enter the task and make progress, and all were able to take it to heights that were appropriate for them.
In consultation with the host teacher, I decided to devote some time to having students develop programs based on self-selected topics. They had, at this point, developed considerable comfort and proficiency with Scratch, and we were interested to see what they might do outside of the constraints of assigned math topics. As the student samples below show, they went in several different directions with their code development. This allowed me to coach working pairs on specific computational concepts and skills to allow them to move further into their projects. One common occurrence was that students envisioned very expansive projects. This tendency created roadblocks for many students. In the context of my assigned (and purposefully smaller) tasks, the students were able to develop algorithms for decomposed parts quite naturally. In many cases, the sheer enormity of the student-generated projects made modularization difficult and algorithmic thinking next to impossible. They simply did not know where to begin with their projects. Again, these were teachable moments. I conferenced with the groups that were having trouble. After learning about their goals, I talked with them about how the task might be decomposed into smaller units. In some cases, students used the conversation to move on with their original plans. In others, students opted to modify their projects to something that was achievable within the allotted time. However, everyone made progress on their projects.
In consultation with the host teacher, I decided to devote some time to having students develop programs based on self-selected topics. They had, at this point, developed considerable comfort and proficiency with Scratch, and we were interested to see what they might do outside of the constraints of assigned math topics. As the student samples below show, they went in several different directions with their code development. This allowed me to coach working pairs on specific computational concepts and skills to allow them to move further into their projects. One common occurrence was that students envisioned very expansive projects. This tendency created roadblocks for many students. In the context of my assigned (and purposefully smaller) tasks, the students were able to develop algorithms for decomposed parts quite naturally. In many cases, the sheer enormity of the student-generated projects made modularization difficult and algorithmic thinking next to impossible. They simply did not know where to begin with their projects. Again, these were teachable moments. I conferenced with the groups that were having trouble. After learning about their goals, I talked with them about how the task might be decomposed into smaller units. In some cases, students used the conversation to move on with their original plans. In others, students opted to modify their projects to something that was achievable within the allotted time. However, everyone made progress on their projects.
Many of the student-created projects required the use of conditional logic. This is something that we had not discussed, and so I took the time to model how “if/else” statements might be used in the context of a math quiz show game. A few groups decided to amend their plans to create a similar type of game. One issue we had concerned the development of a method to ensure that the user, after having given an incorrect answer, was directed to that question again instead of being advanced to the next question. After some dialogue and trial and error, we accomplished this through the use of broadcast blocks. At the end of this module, all students who wanted to share their projects had the opportunity to do so in front of the class.
We finished our time together with four sessions devoted to two mathematics concepts: probability and the conversion of metric units of measurement. For each concept, I developed a sample code from which students could start. For probability, I created a code that captured the results of a single coin flip. The code for the metric system allowed the user to input a number of centimetres and receive conversions in millimetres, decimetres, and metres. In each case, the students were expected to modify the code so that it was more complex. Options explored for probability included programming the outcomes of flipping two coins and switching the flipping of a coin for the rolling of a die. For measurement, some students expanded the conversion of centimetres to units larger than a metre, while others developed programs that would allow the user to choose the starting unit of measurement and convert to any other unit. In keeping with UDL ideals, the use of CT allowed everyone to develop and demonstrate learning, yet at his or her individual pace.
We finished our time together with four sessions devoted to two mathematics concepts: probability and the conversion of metric units of measurement. For each concept, I developed a sample code from which students could start. For probability, I created a code that captured the results of a single coin flip. The code for the metric system allowed the user to input a number of centimetres and receive conversions in millimetres, decimetres, and metres. In each case, the students were expected to modify the code so that it was more complex. Options explored for probability included programming the outcomes of flipping two coins and switching the flipping of a coin for the rolling of a die. For measurement, some students expanded the conversion of centimetres to units larger than a metre, while others developed programs that would allow the user to choose the starting unit of measurement and convert to any other unit. In keeping with UDL ideals, the use of CT allowed everyone to develop and demonstrate learning, yet at his or her individual pace.