1 Introduction

In Sweden, as in other countries, content related to programmed technological solutions (PTS) and programming has been implemented in the curriculum in order to teach pupils about digital technology. The term PTS refers to what are described in the Swedish syllabus for technology as technological solutions that are controlled by programming. In teaching, using design activities is a way to contextualise this content, where pupils design their own PTS by using instructional materials such as the tangible programming materials BBC micro:bit and Arduino, in order to learn technological concepts and processes in relation to PTS. However, many teachers are facing this content with uncertainty (Sentance & Csizmadia, 2017; Webb et al., 2017), as the curriculum indicates the content to be taught, but not how it should be taught, or how to address pupils’ difficulties (Passey, 2017), and there are only a few studies that provide guidance on these issues.

Designing PTS with programming materials enhances pupils’ motivation and creativity (Sentence et al., 2017), and pupils are expected to develop generic skills such as problem-solving skills, cognitive skills and collaborative skills (Nouri et al., 2020). However, in Sweden, PTS and programming have been implemented as part of the subject of technology, which has its own subject-specific content and expected learning outcomes. Thus, designing PTS is also expected to develop the pupils’ subject-specific knowledge, necessary for understanding PTS and how they may be controlled by programming (Skolverket, 2018). Therefore, in the technology classroom, these design activities are directed towards developing pupils’ understanding of technological concepts and processes related to PTS and programming. However, previous studies show that in activities of designing and coding PTS, pupils have difficulties in conceptualising central phenomena, such as the dual nature of PTS and its mechanical structure, as well as feedback control (Barak & Zadok, 2009; Cederqvist, 2020; Mioduser et al., 1996; Slangen et al., 2011a), and that they need a lot of support from the teacher in accomplishing tasks (Mioduser et al., 1996; Slangen et al., 2011a). Accordingly, previous studies indicate that there is a need to better understand teaching and learning of concepts and processes in relation to phenomena involved in the process of designing PTS with a programming material. In order to help pupils conceptualise central phenomena, we need to understand how they experience them in the process of designing PTS. To this end, this study analyses an activity where pupils are designing PTS with the programming material BBC micro:bit. The study takes its starting point from the results of a previous study (Cederqvist, 2020), which identified two central phenomena involved in the process of designing PTS with the BBC micro:bit. The identified phenomena, the dual nature of PTS (structure and function) and the BBC micro:bit material, and their critical aspects (i.e. aspects that it is necessary to discern in order to understand a phenomenon) were used when returning to the same data (pupils’ sketches and video recordings) in order to understand the sequential development of the design process. The aim was to analyse pupils’ sequential discernment of critical aspects of the phenomena in the process of designing a burglar alarm with a BBC micro:bit, and how this affects how the process unfolds. In keeping with the phenomenographic perspective on learning, this study provides in-depth insight into pupils’ process of designing and coding with the BBC micro:bit to solve a real-world task. This insight will inform teachers about how pupils conceptualise phenomena in the process, as well as what is necessary to direct attention to in certain stages of the process, in order to help pupils learn in the process.

2 Theoretical background

2.1 Design activities for contextualising content related to PTS and programming

Design activities are seen as a vehicle for learning, and are considered to provide opportunities for developing conceptual, as well as procedural, knowledge (Kolodner et al., 2003). Furthermore, design activities based on open-ended tasks are considered to place the pupils in the position of producers of knowledge (Kafai, 1995), meaning that pupils are enabled to combine “hands-on” activities with “heads-in” activities, where cognitive concepts are constructed as a result of the pupils designing and making their own solutions (Doppelt et al., 2008). In this way, design activities have the potential to contextualise educational content and goals in a motivating and engaging way (Kolodner et al., 2003). In technology education, the designing and making of technological objects are common activities. The practical work where real-world contexts are connected to technological concepts is expected to facilitate learning of technological knowledge (Koski et al., 2011). In Sweden, as well as in other countries, programming and PTS have become part of the technology syllabus, with the aim of developing pupils’ understanding of technological concepts and processes related to PTS and programming. The aim is bidirectional: pupils should be able to identify and analyse existing PTS from their structure and function, as well as being able to design their own PTS (Skolverket, 2018). It is common to contextualise this content by providing design activities where pupils design PTS with tangible programming materials such as the BBC micro:bit, Lego Mindstorm and Arduino. However, despite the advantages of learning through design activities, the implementation of design projects in the classroom may face challenges that are necessary to consider, both in relation to design activities in general, but also to the designing of PTS specifically.

Doppelt et al. (2008) suggest that the open-ended nature of design activities may feel overwhelming for pupils, since they have difficulties understanding the technological content, as well as managing the whole design process, and Koski et al. (2011) suggest that pupils may have difficulties in connecting concrete experiences in the real-world context to theoretical concepts. Further, technological knowledge in design activities such as designing PTS with a programming material is to some extent context-bound, and may include context-related concepts and processes (McCormick, 2004). Barak and Zadok (2009) provide examples of knowledge related to concepts and processes involved in design activities where the programming material Lego Mindstorms is used, such as understanding when and how to use feedback control or open-loop control, being able to identify factors that influence the mechanical structure, or knowing how changing components in a robotics car affects velocity and power. Slangen et al. (2011b) give examples of relevant concepts and processes when solving technological problems with Lego Mindstorms, such as function, system, control and the Sense-React-Act loop (SRA loop), i.e. feedback loop, which characterises robotics. However, previous studies show that activities where pupils design PTS with a programming material do not necessarily develop their understanding as expected. Mioduser et al. (1996) examined pupils’ understanding of the control process and the system components when pupils were designing an automatically controlled door using Lego, motors and sensors. The results show that pupils had difficulties understanding the chain of control functions in the system and the communication between components. In a similar study, Slangen et al. (2011a) examined pupils’ understanding of the SRA loop when they were designing PTS using Lego Mindstorms. The results show that pupils had difficulties understanding the programming concepts IF–THEN-ELSE, and how the program continuously compares external conditions with programmed conditions, as well as how various components of PTS interact. Slangen et al. suggest that pupils have difficulties in analysing conditions in the real-world context and converting these into a technological solution in terms of an SRA loop.

2.2 The relation between knowledge, context and learning in the design process

Although designing and coding with programming materials to solve real-world tasks provides the opportunity to contextualise central phenomena and concepts regarding PTS and programming, pupils seem to have difficulties in conceptualising the phenomena involved in the process. De Vries (2005) describes the design process as a complex technological activity that is based on the ability to make a fit between factors involved, such as the problem to be solved and the materials to be used. Slangen et al. (2011a) suggest that pupils need to develop an ability to analyse and convert real-world conditions into a technological solution, and Koski et al. (2011) argue for the need for closer attention to concept-context learning in the design process in order to support the learning of concepts in real-world contexts. They suggest the importance of emphasising the dual nature of technological objects (i.e. the structural and functional nature) in relation to evaluation and practical experiences of real-world contexts and to abstract technological concepts, and directing attention to the necessary movement between these domains when learning in the design process. However, in the process of designing PTS with a programming material, there is an additional context to take into account, the context of the programming material. Cederqvist (2020) suggests that during the process of designing a PTS with a programming material such as the BBC micro:bit, pupils face two central phenomena, the dual nature of a PTS and the BBC micro:bit material itself, each of which has certain important aspects that it is necessary for pupils to discern. This means that in order to design the PTS, pupils require not only an understanding of the structural and functional nature of PTS, but also an understanding of the programming material itself and how aspects of it represent the structural and functional nature of PTS. Thus, the programming material can be considered as a representation that provides pupils with access to important aspects of the PTS (see Fredlund et al., 2014). However, the use of an additional context in the design process in terms of representations also presents challenges. Learners may not be able to interpret and use the representations as expected (Airey & Linder, 2009), and teachers are so familiar with the representation that they are not able to see learners’ difficulties with interpreting them (Fredlund et al., 2014). Therefore, in order for a design activity involving a programming material to be fruitful in terms of learning, teachers not only need to be aware of what central phenomena pupils are expected to investigate in the design activity (Slangen et al., 2011b), they also need to be aware of the material’s ability to direct attention to these phenomena (Hmelo et al., 2000).

A design task thus involves concepts and processes that the pupils need to grasp in the relevant contexts in order to accomplish the task, and sometimes teachers neglect to address the need for this knowledge (Koski et al., 2011). As a result, pupils’ existing misconceptions are strengthened, and also transferred into other future contexts where the same concepts exist (Cederqvist, 2019; Koski et al., 2011). Pupils therefore need a scaffolding teacher, who should not only help in overcoming deadlock situations, but who also directs attention towards concepts not yet understood (Slangen, 2016). Koski et al. (2011) suggest the importance for teachers of gaining knowledge about parts that may be unclear to pupils in the design process, and what concepts need attention in certain stages of the process in order for pupils to accomplish tasks, as well as to learn from the design process. They further suggest that in order to gain this knowledge, it is important to direct attention to the ways pupils experience the design process, especially the movement between theory and practice in the process, since the practical work in design activities involves the ability to connect real-world factors to technological concepts and processes that it is necessary to understand in order to accomplish tasks. Therefore, the aim of this study is to take the phenomenographic perspective on learning to investigate pupils’ sequential discernment of critical aspects of the central phenomena in the process of solving a real-world task with the BBC micro:bit, and what effect the way of experiencing the phenomena has on how the process unfolds.

2.3 The phenomenographic perspective on learning

In phenomenography, learning is viewed as a change in the way we understand or experience aspects of a phenomenon. Thus, when we learn, there is a shift in our awareness where we become aware of aspects of a phenomenon not previously discerned, and the phenomenon is understood or experienced in a new way (Marton & Booth, 1997). The “secret of learning” is found in the variation in learners’ experiences of a phenomenon, and in the specific “keys” that constitute the differences in experiencing the phenomenon, the critical aspects (Marton, 2015). Thus, the aim in phenomenographic research is to investigate the variations in learners’ collective experience of a phenomenon, which results in a set of hierarchical categories of description that are internally related. The qualitative differences captured by the categories of description in terms of discerned critical aspects characterise more or less complex ways of experiencing a phenomenon (Marton & Booth, 1997). Marton (2015) argues that discernment is the main mechanism for learning, where discernment implies the act of discerning aspects of a phenomenon that have not been previously discerned (i.e. critical aspects). If the critical aspects are not discerned, it will be difficult to understand the phenomenon. Based on a study by Neuman (1987), Marton (2015) provides the example of what a 6-year-old girl needed to discern in terms of critical aspects, in order to be able to add and subtract in the number range 1 to 20. Marton says that numbers have three necessary aspects to be discerned. These are the ordinal property (1st, 2nd …), the cardinal property (one thing, two things …) and numbers as wholes that can be divided into parts (e.g. 8 can be split into 3 and 5). The 6-year-old girl had only discerned the cardinal property, and hence, handled the situation based on this one aspect which was not sufficient. In order to learn to add and subtract in the number range 1 to 20, she needed to discern the two other not previously discerned necessary aspects, i.e. the critical aspects for her were the ordinal property and numbers as wholes that can be divided into parts. However, a critical aspect may be difficult to discover, and the pupil might need help from the teacher. This implies that teachers need to obtain knowledge of what these critical aspects might be, as well as being able to guide pupils to discern them. Therefore, the results from phenomenographic studies, in terms of critical aspects that are necessary to discern, can inform teachers of what to direct attention to in teaching and learning situations.

According to phenomenography, the discernment of critical aspects related to a phenomenon provides potential for learning, since the necessary “keys” for understanding the phenomenon are present. Booth and Hultén (2003) suggest that during design projects, situations with potential for learning are located in the joint constitution of insights when discussing and solving problems. However, understanding a phenomenon in a powerful way implies experiencing a number of related critical aspects, as parts that carry meaning, which together constitute a whole. In other words, the process of learning can be described as coming to discern a critical aspect, and then relating it to other critical aspects, as well as to the whole, which provides cohesion and detail for a more powerful understanding of the phenomenon as a whole (Ingerman et al., 2009).

In an educational activity such as designing PTS with a programming material, pupils experience specific phenomena as part of the design process. The way pupils understand these phenomena and their critical aspects in these situations, as part of the process, determines what is learned (Marton & Booth, 1997). Hence, it is important for teachers to be aware of what the phenomena and their critical aspects are, and also aware of pupils’ ways of experiencing them in the process of designing PTS, as well as what effect the way of experiencing the phenomena has on how the process unfolds. Therefore, in keeping with phenomenography, this study attempts to analyse and describe pupils’ way of sequentially experiencing central phenomena and their critical aspects, and the effect of this on the process of solving a real-world task, the design and coding of a burglar alarm with the BBC micro:bit. The starting point is the results of a previous study, which identified two central phenomena that it is necessary to understand in the process of designing a burglar alarm with a BBC micro:bit (see Cederqvist, 2020): the dual nature of PTS and the BBC micro:bit material. The study also identified critical aspects of each phenomenon. For the dual nature of PTS, these critical aspects were: the logic in the code in terms of a control function; how the components work; how to organise the components; the interaction between the code and the components that generates a flow of information (that controls the function). For the BBC micro:bit material, these critical aspects were: what the blocks represent in terms of real-world conditions; what the blocks represent in terms of programming concepts; the shape of the blocks; how the blocks are organised in the editor; the need for a control function in the code; how to combine blocks into a code. The present study uses the identified phenomena and critical aspects to analyse the same data as in the previous study (i.e. pupils’ sketches and video recordings), to provide insights into pupils’ sequential discernment of critical aspects of the central phenomena in the process of solving a real-world task with the BBC micro:bit, and what effect the way of experiencing the phenomena has on how the process unfolds. These insights will inform teachers about what to direct attention to in certain stages of the process, in order to help pupils conceptualise phenomena in the process, and to help the pupils to accomplish the task.

3 Methodology

In order to gain insight into pupils’ way of sequentially experiencing phenomena and their critical aspects, and the effect of this on the process of designing PTS with the BBC micro:bit, this study take its point of departure from previously identified critical aspects of the phenomena, in a study where the same group of pupils participated.

3.1 The context and the collection of data

The data was collected in a classroom setting, on one occasion with pupils from Grade 4, and on another occasion with from Grade 8. These groups of pupils were chosen based on that they previously had been introduced to programming by using the BBC micro:bit material. Their teachers had presented a series of lessons based on a paper tutorial, which included instructions on how the BBC micro:bit material is structured, and how to use the material, together with several programming tasks. The pupils in Grade 4 had been given five lessons (about 40–50 min/lesson), and the pupils in Grade 8 had been given three lessons (about 80 min/lesson) (see Cederqvist, 2020). Prior to the collecting of data, the pupils in each grade were informed about the study and how it would be carried out, and also about the self-determination regarding participation and the possibility of withdrawing from the study at any time. In total, eight pupils from Grade 4 and six pupils from Grade 8 decided to participate in the study.

The pupils were introduced to a design activity where they were supposed to solve a real-world task with the BBC micro:bit material – the design and coding of a burglar alarm to be installed in a kitchen cabinet to prevent someone from stealing candy. By working in pairs, the pupils first discussed and sketched a solution, and were given inspiration, by means of a sheet of paper showing different blocks to use in the micro:bit editor. Then, the pupils implemented their solutions by using the BBC micro:bit material, either by coding on computers (Grade 4 pupils) or iPads (Grade 8 pupils). In situations when pupils were not able to proceed in the process, the researcher acted as a facilitator (i.e. teacher), by providing scaffolding queries, in order to help pupils get back on track again.

The whole design activity was video recorded using a GoPro camera attached to the ceiling above each pair of pupils. The screen-capture software recorded their activity on the iPads, while the activity on the computer screens was analysed from what was captured by the GoPro cameras, due to restricted access to screen-capture software. A microphone was placed in front of each pair of pupils to capture pupils’ comments. The audio and video recordings were then processed by synchronising them in iMovie.

Consent was obtained from pupils, parents, teachers and principals, after informing them about the purpose of the study, how data would be collected, the way pupils would participate, and how the collected data would be handled, as well as the possibility of withdrawing from the study at any time. To prevent identification, the pupils have been anonymised in the reported data.

The design task was carried out in the context of the BBC micro:bit material. This material consists of a small programmable microcontroller that includes several components such as an LED display, a compass, an accelerometer, light and temperature sensors, and programmable buttons. External components such as a motor, a sensor, or a speaker may also be added by using crocodile clips connected to the five Input/Output rings on the microcontroller.Footnote 1 The microcontroller may be programmed either in a text-based editor or in a block-based editor, on a computer or an iPad. The pupils in this study used the block-based Microsoft MakeCode micro:bit editor (Fig. 1), where the code is built by snapping together blocks for controlling the function of the PTS. After the code is built, it is transferred to the microcontroller via Bluetooth or a USB connection. The user interface of the editor (Fig. 1) includes tabs where one can find available blocks that can be dragged into the grey working area to the right. When code is built, it can be tested in the simulator to the left, or downloaded to the microcontroller by clicking on the download button.

Fig. 1
figure 1

The user interface of the Microsoft MakeCode Micro:bit editor https://makecode.microbit.org/#editor

Full size image

4 Analysis

The analysis takes its point of departure from a previous study with the same group of pupils. The results from that study show the technological knowledge pupils need, in terms of critical aspects (Fig. 2), to successfully solve a real-world task – the design and coding of a burglar alarm (Cederqvist, 2020). The identified critical aspects, which have been tested and validated in line with the phenomenographic research approach, are in the present study used to analyse the same data as in the previous study, i.e. pupils’ sketches and video recordings. The aim is to analyse pupils’ sequential discernment of critical aspects of the phenomena in the process of designing a burglar alarm with a BBC micro:bit, and how this affects how the process.

Fig. 2
figure 2

Analytical framework: The phenomena involved in the process of designing PTS with a BBC micro:bit and the critical aspects related to the two phenomena (Developed from Cederqvist, 2020)

Full size image

In the analysis, the video material from each pair of pupils were analysed one by one. The focus was initially on identifying and selecting sequences in the material that show the pair of pupils expressing understandings regarding the two phenomena involved during the process. i.e. the dual nature of PTS and the BBC micro:bit material, see Fig. 2. The selected sequences were transcribed verbatim along with descriptions of the pupils’ actions. The sequences were then further analysed in three steps along with the pupils’ sketches, in which the phenomena and their critical aspects, identified in the previous study, worked as an analytical framework (Fig. 2). In order to structure the coding and analysis in a systematic way, the analytical framework was arranged as a table (Fig. 3). The table was used to analyse pupils’ discernment of critical aspects of phenomena, and to analyse the sequential development of the process, in steps as described below.

Fig. 3
figure 3

The analytical framework arranged as a table

Full size image

The first step was to connect the selected sequences, where pupils express understandings regarding the two phenomena, to sequential stages of the process, i.e. the planning and sketching stage in which real-world conditions are analysed in relation to the dual nature of PTS, and the stage where they assemble and code the PTS in the BBC micro:bit context. The second step was to analyse the way pupils experience the phenomena in the various stages of the process, in terms of what critical aspects they discern and whether they recognise the meaning of the discerned critical aspects in relation to each other, as far this could be gleaned from their discussions and actions. In the third step, the sequential development of the process was analysed in terms of the effect the way of experiencing the phenomena and their critical aspects has on how the process unfolds, i.e. whether pupils’ ways of experiencing the phenomena were able to take them further in the process or not, as well as what direction the process took. This was followed by an overall analysis of the results based on all pairs of pupils, in order to find patterns in the sequential development of the process of designing PTS with the BBC micro:bit.

5 Results

The results are presented in two parts. The first part provides two examples that illustrate in detail pupils’ way of sequentially experiencing the critical aspects (in italics) of the two central phenomena (the dual nature of PTS and the BBC micro:bit material), and the effect of this on how the process unfolds when solving a real-world task – the design and coding of a burglar alarm with a BBC micro:bit. The two examples also illustrate how the analysis has been carried out in order to shed light on pupils’ ways of sequentially discerning the two phenomena and their critical aspects, based on their discussions and actions. The two examples include situations when the pupils not were able to proceed in the process, where the facilitator provided scaffolding queries in order to help pupils get back on track again. The second part provides an overview of the results that includes each of the seven pairs of pupils. The process of each pair is presented in a table that illustrates discerned critical aspects regarding the two phenomena and in which parts of the process they have been discerned, without scaffolding from the facilitator. The result from each pair is summarised in relation to their way of sequentially experiencing the phenomena and their critical aspects, and the effect of this on how the process unfolds.

5.1 Two detailed examples of the sequential discernment of the phenomena in the process

5.1.1 Example 1 (Pair 3)

The pair of pupils in the following example plan to use either the change in light level or the change in movement when the cabinet door is opened to activate the alarm. The pupils have sketched a complete suggestion of how components will be assembled, which indicates that they have discerned how to organise components in the PTS (Fig. 4).

Fig. 4
figure 4

Sketch of how to organise components

Full size image

The pupils continue to discuss what blocks to use, and the discussion is guided by the sheet showing different blocks that can be used in the micro:bit editor.

Michael: ON...that one [pointing towards the ON SHAKE block] and then put LIGHT LEVEL inside it

John: Yes.

Michael: No…that doesn’t work because…if you take a look at that block, it is bent in there [clarifying by pointing at the shape of the SHOW STRING block] and then this block fits there [pointing at the shape of the ON SHAKE block].

John: But that one [the LIGHT LEVEL block] doesn’t fit in any one then…

[…]

Michael: But what should the code be then?

John: I don’t know.

Michael: But think, a block like LIGHT LEVEL…

John: We’ll find out that when we start the program…

From the pupils’ discussion, their choice of blocks seems to be based on their analysis of real-world conditions, i.e. they relate real-world conditions to blocks such as LIGHT LEVEL and ON SHAKE. Another aspect is discerned when the pupils problematise the shape of the LIGHT LEVEL block and into what block it may fit. However, neither the ability to see what the blocks represent as real-world conditions, nor the ability to see the shape of the blocks leads on to a suggestion of how to combine blocks into a code at this stage in the process. The pupils decide to get help from the editor to find out how to combine blocks. While waiting for the computer to start up, they assemble the components according to their sketch.

In the following sequence, the pupils search for blocks in the editor. They conclude that the ON SHAKE function will not work and that they should use one of the BASIC blocks such as ON START for activating the alarm. This indicates that they try to recognise the meaning of the blocks in relation to the need for a control function in the code and how to combine blocks into a code. They are now trying to combine the LIGHT LEVEL block with the ON START block (Fig. 5).

John: We’ll need one like this [drags out the ON START block].

Michael: ON START?

John: Yeah and LIGHT LEVEL [drags out the LIGHT LEVEL to the ON START block but it does not fit]…this doesn’t work.

[The pupils search further in the editor for another block to use]

John: There’s nothing…it doesn’t fit into anything.

Michael: No. […]

Michael: Wait, wait there’s a round thing [pointing at the START MELODY DADADUM block in the MUSIC tab]. Look there is a round shape and that one [pointing at the LIGHT LEVEL block] may fit in there.

John: All of these have that, should we choose one or should we…[opens up the BASIC tab in the editor].

Michael: Maybe it’s like you should put that one [the LIGHT LEVEL block] into something, like that [pointing at the SHOW STRING block]

John: [Drags the SHOW STRING block to the code and tries to drag the LIGHT LEVEL block into it] It doesn’t fit in there.

Fig. 5
figure 5

Discerning the shape of the blocks

Full size image

The sequence above shows how the previously discerned aspect, the shape of the blocks, is in focus as they search further for blocks to combine with the LIGHT LEVEL block. However, the sequence also indicates that even if the pupils are aware of the shape of the blocks and how to use it when searching for blocks to combine, they are considering blocks such as START MELODY DADADUM and SHOW STRING, which do not match what they are trying to achieve in their solution. They have difficulties in going further in the process of implementing their idea for the PTS in the micro:bit context, and ask for support. In the following sequence, the facilitator directs pupils’ attention toward the real-world conditions on which their idea is based, the change in light level. In this way, the logic in the code in terms of a control function is brought to the pupils’ awareness in the discussion.

Researcher: If we think then, what is it you want to achieve with this alarm?

John: If it gets brighter, then it will beep.

Researcher: Ok, that’s what you want.

Michael: It should be LIGHT LEVEL…

Researcher: Ok and you’ve found this block [pointing at the LIGHT LEVEL block].

John: …and then there must be something that activates it.

When John describes what they are trying to achieve as “if it’s gets brighter, then it will beep”, the logic in the code in terms of a control function is brought to the table. However, to be able to proceed, the pupils have to have recognise the logic in the code in terms of a control function in relation to other critical aspects such as understanding what the blocks represent in terms of programming concepts and how to combine blocks into a code, in the micro:bit context. In the excerpt below, the pupils try to find and combine blocks into a functional code.

Researcher: What’s going to start the alarm, it must be something ... you said it was either bright or dark?

Michael: Yes.

Researcher: What is it called when you have to choose between the two conditions?

John: It was over here [searching through the tabs on the micro:bit editor and opening the LOGIC tab]

Researcher: You’ll find something there yes.

John: I knew it was here [holding the cursor over the IF/THEN block].

Researcher: Yes and you can use that one.

John: Yeah [chooses the IF/THEN block and drags it to the code] and this is false or true?

The return to the real-world condition of change in light level, and the different states that will control the alarm, makes the pupils aware of what the blocks represent in terms of programming concepts, i.e. a conditional statement that will control the alarm. Further, the systematic search through all the tabs in the editor for a block to combine with the LIGHT LEVEL block has developed their understanding of how the blocks are organised in the editor. In other words, by being able to navigate through the editor, they are able to find the blocks they want to combine. In the following, however, the pupils encounter a problem when trying to combine blocks to create a conditional, as they cannot combine the LIGHT LEVEL block with the IF/THEN block.

John: How do I put it in that one? [Trying to insert the LIGHT LEVEL block into the IF/THEN block]

Researcher: Well, that’s the question, how do you put it in there?

Michael: Then we must have another one like that [point to the blocks in the code]

Researcher: Then you need something else ... because you want…when it reaches a particularly bright light level, you want something to happen...

John: Yes and then it should start beeping.

Researcher: How can the alarm know this is happening?

John: It should sense the light.

Researcher: Well then you have to somehow compare the light level ...

Michael: Yeah with that one [points at the COMPARISON block]

Again, pupils’ attention is directed towards their idea of the PTS based on real-world conditions and how the change in light level will start the alarm. By considering the higher light level, and how that will make something happen, based on comparing states, the pupils’ attention is directed to the need to compare the real-world condition with what is written in the code. They are now trying to solve the issue concerning the conditional (Fig. 6). They combine the LIGHT LEVEL block with the COMPARISON block and then place the combination in the IF/THEN block. This whole combination is then dragged into the ON START block. In the following, they discuss how to make the conditional function.

Michael: I don’t understand how you’re thinking, John, can you tell me how you’re thinking?

John: First, we have this [points at the COMPARISON block], if it gets higher ... eh so that one [>] points to that one [the LIGHT LEVEL], it means that it is higher then, if it is higher than ... can you change LIGHT LEVEL in any way?

Michael: Press LIGHT LEVEL.

John: No, it’s not possible.

Michael: Maybe we can take another LIGHT LEVEL block…maybe…no. No it should be the other way around [pointing at the COMPARISON block and the character >] if it’s lower ... here it’s lower.

John: If there is a higher ... LIGHT LEVEL, it should beep.

Michael: Yes.

John: Or it depends on what the light level is.

Michael: […] if you add two LIGHT LEVELS and then you turn it [>] so LIGHT LEVEL is nothing and then when it gets higher it starts ... and then it beeps. […]

John: Yeah if it gets brighter?

Michael: Yes.

John: Yes, but that’s what I’m trying to do. This [the LIGHT LEVEL] should be that [the value in the COMPARISON block], this [LIGHT LEVEL] eh ... means that if it’s higher than that [the value].

Fig. 6
figure 6

The pupils are trying to solve the issue with the conditional

Full size image

The critical aspects the logic in the code in terms of control function and how to combine blocks into a code, are now in focus in the discussion above. Both aspects are discerned and recognised in relation to each other when John suggests that, by using the COMPARISON block to set a light level, and then based on comparing the value in the COMPARISON block with the light level in the real-world, the alarm will sound if it is brighter than the value in the COMPARISON block. The discussion indicates that several critical aspects are brought together, such as the logic in the code in terms of control function, what the blocks represent in terms of programming concepts, and how to combine blocks into a code. In the end, the pupils decide to use the FOREVER block and add a signal based on PLAY TONE blocks in the final code (Fig. 7). The pupils test the alarm and it seems to work. Thus, with some scaffolding the pupils are able to produce the alarm.

Fig. 7
figure 7

The final code

Full size image

5.1.2 Example 2 (Pair 4)

The pair of pupils in the following example have an idea about using the light sensor to detect the difference in light level if the cabinet door is opened, which will activate the speaker to play a sound. They have sketched out how to assemble their solution, which shows a complete organisation of components (Fig. 8). They are now discussing how to code the alarm.

Annie: Do we start with FOREVER ... [writes down the code on the sketch]

David: IF TRUE THEN ... no.

Annie: ... and then LIGHT LEVEL maybe?

[...]

David: START MELODY play DADADUM ... yes we’ll take that eh ... [points to the block START MELODY DADADUM REPEATING ONCE]

Annie: But...

David: ... LIGHT LEVEL ...

Annie: […] it should be put into something [points to the LIGHT LEVEL block]... Well it should be put into that one I think [points to the ON START block].

David: No, because...

Annie: No, it should be put into something like that one [points at a COMPARATIVE block]

[...]

David: Or in one like this [points at one of the logic blocks], IF LIGHT LEVEL THEN START MELODY...

Annie: Yes.

David: Or?

Annie: Should we take that one ... should we try IF TRUE THEN LIGHT LEVEL ... but it must be put into something like that [points at a COMPARATIVE block].

David: No, it should ... we have to remove TRUE, it should be put there [points at the IF/THEN block], it should be put there!

From the discussion, we understand that at the planning stage, the pupils already discern the need for a control function in the code. Their initial suggestion of what blocks to use, such as the IF/THEN block and the COMPARISON block, indicates that they have discerned aspects such as the logic in the code in terms of a control function, and what the blocks represent in terms of real-world conditions as well as what the blocks represent in terms of programming concepts. By problematising the need to fit the LIGHT LEVEL into another block, they also seem to have discerned the shape of the blocks. From the discussion, it appears that they are close to coming up with an idea for a functional code. However, before continuing to assemble and code the alarm, they decide to use the WHILE TRUE block instead of the IF/THEN. This decision seems to result from the fact that they have not yet discerned how to combine blocks into a code, which in this case would involve combining the COMPARISON block with the LIGHT LEVEL block. This is constraining them with regard to recognising the meaning of the logic in the code in terms of a control function and what the blocks represent in terms of programming concepts, in relation to the process of implementing the PTS in the micro:bit context. Thus, they proceed with the WHILE TRUE block. Below, they describe how their alarm will work.

Annie: Check this out, if it gets this bright then it should sound like this ...

Researcher: Yes.

Annie: ... if we have connected everything correctly.

Researcher: How does it know when it is bright? How is it able to know that?

David: We’ll put that [the LIGHT LEVEL block] in there WHILE ... that one [points at the WHILE TRUE block on the sheet with different blocks].

Researcher: Is it a lot of light or only some light, or is it just that it gets brighter?

David: I don’t know ... maybe a lot [laughs] no but I just think if it gets brighter.

Researcher: Ok, you try and we’ll see how you might solve this.

In the sequence above, the pupils are describing the function of the alarm, and that the components need to be properly assembled. This indicates that the meaning of how to organise the components is now recognised in relation to the function of the alarm. However, in relation to the question about at what light level the alarm will start, the pupils do not have any answer. The pupils assemble the components according to their plan and begin to search through the tabs in the editor for the blocks to use. Under the LOOPS tab, they find the block WHILE TRUE; they drag it out and try to put the LIGHT LEVEL block into it (Fig. 9).

Annie: You have to delete TRUE, press TRUE once.

David: It’s not possible, this is not possible ... it’s not possible ... it’s impossible [...].

Annie: What else can it fit into?

David: LOOPS [searching through the LOOPS tab] ... there FOR ...

Annie: Yes, let’s try it.

David: ... INDEX FROM 0 TO 4 ... FOR ... remove, remove [removes the WHILE TRUE block and drags the new block into the code]

The LIGHT LEVEL block does not fit into the WHILE TRUE block. Instead the pupils try to make space for the LIGHT LEVEL block by removing the TRUE icon. However, this does not work, and they search for another LOOP block and find FOR INDEX FROM 0 TO 4, which they try to combine with the LIGHT LEVEL block (Fig. 10).

Annie: Try it.

David: Wait, this is what we’ll do.

Annie: Can’t we try it ...INDEX...

David: [Trying to insert the LIGHT LEVEL block] You do this, it’s … it doesn’t work.

Annie: Try to press INDEX once ... and then touch, press, just get it away, delete the variable INDEX. Put in LIGHT LEVEL...

David: [tries to click on INDEX in the LOOP block] Why doesn’t it work? ... we are not that good at this.

This combination does not work either. Although the pupils have discerned the shape of the blocks, and use it when searching for blocks to combine, they are not able to recognise the meaning of this discerned aspect in relation to other aspects such as what the blocks represent in terms of programming concepts. This affects the whole process of moving towards the intended control function, since the blocks they are trying to combine do not match their intended PTS. Below, we see that the process is moving towards a more random search for blocks based on the shape of the blocks, instead of following the initial plan.

David: VARIABLES, MATH, FUNCTIONS... [clicks through the tabs in the micro:bit editor]

Annie: Wait there was LED [points at the LED tab]. Open LED again.

David: Oh PLOT … oh my god [points at the round shape in a block].

Annie: AND MUSIC [opens the MUSIC tab].

[…]

Annie: RADIO … [points at the RADIO tab].

David: RADIO …?

Annie: … there is sound, on a radio there is sound …

David: [drags the block RADIO SET GROUP into the code].

Annie: … but why is there no block with light in the same way? […]

David: We can have it like this [drags the LIGHT LEVEL block into RADIO SET GROUP]

In the sequence above, the pupils seem to have gone off-track in the process. In their search for blocks, they have ended up with a code that is rather far away from their initial idea of control function. Although it is possible to snap the block RADIO SET GROUP together with the LIGHT LEVEL block, the combination is not functional (Fig. 11). Scaffolding is provided to get the pupils back on track again. By returning to their initial idea based on the real-world conditions, where their attention shifts back to the intended control function and blocks to use for comparing states such as the changing light level, the pupils are made aware of the need for a conditional. By suggesting the use of an IF/THEN block and the comparison block, and relating these blocks to the real-world conditions, the pupils are now able to combine blocks into a control function, and the alarm seems to work.

Fig. 8
figure 8

Pupils’ sketch of how to assemble and code their solution

Full size image
Fig. 9
figure 9

The pupils try to combine the LIGHT LEVEL block with the WHILE TRUE block

Full size image
Fig. 10
figure 10

The pupils try to combine the block FOR INDEX FROM 0 TO 4 with the LIGHT LEVEL block

Full size image
Fig. 11
figure 11

The random search for blocks based on their shape has ended up producing a non-functional code

Full size image

5.2 Overview of the results including each of the seven pairs of pupils

The process of each pair is presented by a table (Tables 1, 2, 3, 4, 5, 6 and 7) that illustrates discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, without scaffolding from the facilitator. The result from each pair is then summarised in relation to their way of sequentially experiencing the phenomena and their critical aspects, and the effect of this on how the process unfolds.

Table.1 The development of the process as experienced by Pair 1 (Grade 4) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table
Table.2 The development of the process as experienced by Pair 2 (Grade 4) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table
Table.3 The development of the process as experienced by Pair 3 (Grade 4) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table
Table.4 The development of the process as experienced by Pair 4 (Grade 4) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table
Table.5 The development of the process as experienced by Pair 5 (Grade 8) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table
Table.6 The development of the process as experienced by Pair 6 (Grade 8) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table
Table.7 The development of the process as experienced by Pair 7 (Grade 8) in terms of discerned critical aspects regarding the two phenomena and in which stages of the process they have been discerned, and the effect on how the process unfolds
Full size table

5.3 Summary of the results

The overall results, based on the summarized processes of all pairs of pupils, show that the sequential development of the process, from the planning/sketching stage to the assembling/coding stage, can be described in terms of challenging movements. These movements involve being able to move between the real-world context, the dual nature of the PTS (structure and function) and the BBC micro:bit context (Fig. 12). First, the pupils analyse the real-world conditions in relation to the presented problem. All of the pupils come up with an idea for a control function in their intended PTS. In order to implement the control function, the pupils first need to be able to connect the analysed real-world conditions to the structural and functional aspects of their intended PTS (a logical code in terms of a control function, how the components work and how to organise them etc.). If they are only able to connect to some of these aspects, they have difficulties moving forward in the process, i.e. there is not enough cohesion and detail to move forward. However, even among the pairs that are able to connect real-world conditions to most of the structural and functional aspects, some of them have difficulties in connecting these to aspects of the BBC micro:bit context (what the blocks represent in terms of real-word conditions or what the blocks represent in terms of programming concepts, how to combine blocks into a code etc.) which prevents them from moving forward in the process. This indicates that the pupils also need to be able to connect the real-world conditions to the aspects of the BBC micro:bit material, and to be able to make a fit between these and the structural and functional aspects of the PTS, in order to produce the PTS. Thus, how the process unfolds is dependent on the pupils’ ability to discern structural and functional aspects of the PTS in order to have a cohesive understanding of the PTS in relation to the analysed real-world context. Then, to move further in the process, the real-world conditions, understood as structural and functional aspects of the pupils’ intended PTS, need to be connected to discerned aspects of the BBC micro:bit material. This implies that the process also is dependent on pupils having a cohesive understanding of the BBC micro:bit material, in relation to both the analysed real-world context, and the structural and functional aspects of PTS.

Fig. 12
figure 12

The challenging movements between the real-world context, the dual nature of the PTS and the BBC micro:bit context

Full size image

6 Discussion

In line with a phenomenographic perspective on learning, this study provides insights into pupils’ ways of sequentially experiencing the critical aspects of two central phenomena, the dual nature of PTS (the structure and function) and the BBC micro:bit material, in the process of solving a real-world task with the BBC micro:bit, and what effect the way of experiencing the phenomena has on how the process unfolds. The results show that the sequential movements involving the real-world context, the dual nature of the PTS and the BBC micro:bit context are challenging. How the process unfolds is dependent on whether pupils have a cohesive understanding of the structural and functional aspects of the PTS (e.g. a logical code in terms of a control function, how components work and how to organise them) in relation to the analysed real-world context. Then, to move further in the process, the real-world conditions, understood as structural and functional aspects of their intended PTS, need to be connected to discerned aspects of the BBC micro:bit material (e.g. what blocks represent and how to combine them into a code). Thus, the process is dependent on whether the pupils are initially able to discern structural and functional aspects of PTS, and recognise their meaning in relation to each other, as well as in relation to aspects of the BBC micro:bit context when moving between the contexts. The fact pupils have difficulties in moving between the contexts suggests the need to appreciate both the real-world context and the BBC micro:bit context in relation to the dual nature of PTS, with regard to the technological concepts and processes involved.

6.1 The design and coding of PTS—a challenging movement between contexts

The process of designing a PTS with a programming material may be seen as a movement between analysed real-world conditions and the context of the programming material (Cederqvist, 2020), in which pupils need to have an ability to analyse and convert real-world conditions into a technological solution (Slangen et al., 2011a). Koski et al. (2011) suggest that this means being able to consider the dual nature of technological solutions, as well as to connect the evaluation and practical experiences of real-world contexts to abstract technological concepts, which is sometimes difficult for pupils in the design process. Koski et al. suggest directing attention to the necessary movement between these domains when learning in the design process. The conclusions drawn from the present study are in line with these suggestions. The results show that pupils need to be able to connect the structural and functional aspects of their intended PTS to the analysed real-world conditions, experienced in the real-world context. However, these results also suggest that it is necessary to direct attention to an additional domain, or context, the context of the programming material, and develop pupils’ ability to connect analysed real-world conditions to aspects of the programming material. The results show a certain pattern in the development of the process, where the way pupils sequentially experience either the structural and functional aspects of the PTS or the BBC micro:bit material, has an effect on how the process unfolds. The results indicate that some pupils, even at the planning stage, may already have difficulties in discerning structural and functional aspects of PTS in relation to the real-world context. This makes it difficult to move forward in the process since they do not have a complete suggestion for how to achieve the control function in terms of a logical code, for example, or how to organise components in their intended PTS. Furthermore, the results show that even if one of these aspects is discerned, it is not sufficient for being able to proceed in the process. The pupils need to discern most of the structural and functional aspects with regard to the PTS in order to have a cohesive understanding of their PTS, in order to be able to, so to say, have anything to implement in the BBC micro:bit context. However, the results show that even if the pupils have a cohesive understanding of the structural and functional aspects of their intended PTS when moving forward into the BBC micro:bit context, there are still challenges. In the BBC micro:bit context, the pupils need to be able to connect the analysed real-world conditions to aspects of the BBC micro:bit material. This means being able to recognise the meaning of analysed real-world conditions, understood as aspects of their PTS, in relation to aspects of the BBC micro:bit material. The results show that this part of the process is challenging for many of the pupils and some of the pairs go off-track in the process.

The two detailed examples provide insight into pupils’ difficulties in moving between the real-world context, the dual nature of PTS and the BBC micro:bit context. In Example 1, we can see that the pupils, even if they already at the planning/sketching stage know how to organise components and what the blocks represent in terms of real-world conditions, are not able to recognise their meaning in relation to how to combine a control function in terms of a code in the context of the BBC micro:bit editor. Another example is when the pupils discern the shape of the blocks but are not able to recognise the meaning of this in relation to what the blocks represent, which results in a lot of time is being spent on searching for blocks based on their shape, leading the pupils away from what they were initially trying to achieve in the solution. Since the pupils are not able to take into account what the blocks represent (the BBC micro:bit context) in relation to their initial idea, which was based on the real-world context (i.e. a control function based on the change in light level), they end up with non-functional combinations of blocks, based on their shape. What seems to be limiting this pair of pupils is that they are not able to discern the logic in the code in terms of the intended control function, and how this is related to components and programming concepts, as well as how this can be transferred into a code in the editor as a conditional. Similar results have been found in previous studies (Mioduser et al., 1996; Slangen et al., 2011a) which show that pupils have difficulties implementing the control function since they do not understand the related programming concepts and how these interact with components, in order to control the solution. In Example 2, the sketch and the initial discussion indicate that even if pupils discern early in the process the need for a control function based on a conditional statement, the shape of the blocks and what they represent both in relation to real-world conditions and to programming concepts, as well as how the components should be organised, they are not able at this stage to recognise the meaning of these aspects in relation to each other. This means that they are not able to move forward in the process and combine blocks into a code in the BBC micro:bit context. In the same way as Example 1, the pupils leave their initial plan when they encounter problems combining blocks, and instead search through each tab by using the shape of the blocks. In contrast to Example 1, the pupils in Example 2 use the blocks’ significance in relation to real-world conditions. However, at this stage, they also go off-track in the process and end up with a non-functional code which does not represent their initial idea for a solution. The example indicates that even if the pupils are already able to discern several aspects of the phenomena at the planning/sketching stage, their difficulties in recognising the meaning of these aspects, and relating them to each other, has an effect on their ability to move forward in the process by connecting the structural and functional aspects of the intended PTS to aspects of the BBC micro:bit context.

6.2 The necessary appreciation of the contexts

The design and coding with the BBC micro:bit to solve real-world tasks may provide the opportunity to contextualise concepts and process in relation to PTS. However, the results show that pupils are not always able to discern the contextualised concepts and processes, and even if they are able to discern them, they have difficulties in transferring the meaning of them between the real-world context, the dual nature of the PTS and the context of the BBC micro:bit material. In other words, the process is complex and involves a challenging movement between contexts. Koski et al. (2011) have previously argued for the need to emphasise the structural and functional nature of technological solutions in relation to real-world contexts and to abstract concepts, and the necessary movement between these when learning in the design process. What the results from the present study add is that when designing with a programming material, it is also necessary to emphasise the context of the programming material in relation to the real-world context and to the technological concepts involved. This means that there is a need to appreciate the context, both with regard to the programming material and the real-world conditions, in order to help pupils discern structural and functional aspects of their PTS, to be able to move between contexts. This implies that pupils need to be made aware of aspects of the BBC micro:bit material in relation to the real-world context in terms of aspects of the intended PTS. In accordance with what Fredlund et al. (2014) suggest, the BBC micro:bit material, which is used to contextualise technological concepts and processes in relation to PTS, can be seen as a representation of PTS that provides access to certain aspects of PTS, e.g. block-based programming concepts that are combined into a conditional statement to represent the control function in the PTS. However, the results indicate that the use of this representational context in the process presents challenges. Pupils are not always able to interpret aspects of the BBC micro:bit material such as what the blocks represent, which is also in line to what Airey and Linder (2009) have previously suggested regarding difficulties in using representations. The pupils do not always understand the BBC micro:bit material as expected, and hence have difficulties connecting aspects of the material to aspects of the PTS as understood in the real-world context. The reason may be that pupils are not familiar enough with the BBC micro:bit material, but also that the material’s ability to direct attention to aspects of the dual nature of the PTS is not sufficient. Hmelo et al. (2000) suggest that pupils need a scaffolding teacher who is familiar with the material’s abilities to direct attention to central phenomena, and Slangen et al. (2011b) further suggest that the scaffolding teacher should also ask questions and direct attention towards phenomena that are not yet understood. The two examples show how scaffolding queries and explanations directed towards the analysed real-world conditions and the dual nature of the PTS may facilitate pupils’ understanding of the control function as well as what the blocks represent. For instance in Example 1, when the pupils have difficulties in moving forward in the process, the scaffolding queries direct pupils’ attention towards their initial idea of the PTS based on real-world conditions and how the change in light level will start the alarm. By letting them consider the change in light level, and how that will make something happen, based on comparing states, the pupils’ attention is further directed to the need to compare the real-world condition with what is written in the code. This provides the necessary cohesion and detail to move forward in the process of implementing the PTS in the BBC micro:bit context.

6.3 Implications for teaching

When pupils are designing PTS with a BBC micro:bit, technological knowledge is an expected learning outcome. On the other hand, technological knowledge is required to be able to tackle problems during the process (Slangen et al., 2011b). Thus, an important question is what prior knowledge pupils need for taking part in these activities, and what this implies for teaching. The results indicate that pupils first need to have an understanding of the dual nature of PTS to be able to analyse real-world conditions and relate them to the structure and function of the alarm. That involves approaching the PTS as a system in order to understand in detail how the different parts, the structure of the components and the logic in the code, interact, as suggested by Slangen et al. (2011a). Thus, this may be introduced to pupils before they take part in the design activity. Furthermore, appreciation of the contexts is necessary in order to facilitate the movements between contexts. By addressing analysed real-world conditions in relation to structure and function in PTS, and in relation to blocks as representing real-world conditions and programming concepts, the movements between the real-world context and the BBC micro:bit context would be facilitated. Also, structural aspects of the editor should be addressed, such as how the editor is organised, as well as how to use the shape of the blocks as support in interpreting what the blocks represent, to facilitate the search for and the combination of blocks. This is not to say that pupils are not able to learn this on their own during the process, but the results of this study show that difficulties in using the material carry the risk of making the process fragmentary and this may obscure central phenomena, and hence limit the learning.

6.4 Limitations of the study

A limitation of the study may be that the results could be seen as being related only to the participating group of pupils, and to the specific context, i.e. the task and how it was carried out. If the study was conducted in the same way with another group of pupils, we would not necessary have ended up with the same results. Thus, given the limited empirical material in the sample, there are limitations to the results. However, one contribution here is the possibility of showing what can come into focus when pupils are designing PTS with a BBC micro:bit, and the qualitative level of challenge that learning presents, as well as providing indications of how to address the sequential stages of the process in which aspects of phenomena and their interrelations are emphasised. Therefore, the results should be seen as contributing insights on what to direct attention to in learning situations where pupils take part in designing PTS with a BBC micro:bit, which can be further developed by teachers as well as by other researchers in future studies.

The results from this study indicate that more research is need regarding the affordances and constraints of using different programming materials for the teaching of content related to PTS and programming in design activities.

7 Summary

By following seven pairs of pupils during the process of designing and coding a burglar alarm with a BBC micro:bit, this study has provided insights into how pupils sequentially discern critical aspects of central phenomena such as the dual nature of PTS (the structure and function) and the BBC micro:bit. The results show that the movements involving the real-world context, the dual nature of the PTS, and the BBC micro:bit context are challenging, and that pupils’ ability to move between the contexts has an effect on how the process unfolds. The development of the process in terms of these movements is dependent on whether the pupils are able to sequentially discern the structural and functional aspects of the PTS and aspects of the BBC micro:bit material, and recognise their meaning in relation to each other in the process. However, pupils may have difficulties in understanding aspects of the BBC micro:bit material that represent structural and functional aspects of PTS, as well as understanding these in relation to the analysed real-world context. This suggests the need for an emphasis on appreciating both the real-world context and the BBC micro:bit context in relation to the dual nature of PTS, in order to help pupils discern aspects of PTS in the changing contexts during the process, and to help the pupils conceptualise technological concepts and processes involved when designing and coding PTS with the BBC micro:bit.