skip to main content

Title: Program Comprehension with Physical Computing: A Structure, Function, and Behavior Analysis of Think-Alouds with High School Students.
Comprehending programs is key to learning programming. Previous studies highlight novices’ naive approaches to comprehend ing the structural, functional, and behavioral aspects of programs. And yet, with the majority of them examining on-screen program ming environments, we barely know about program comprehension within physical computing—a common K-12 programming context. In this study, we qualitatively analyzed think-aloud inter view videos of 22 high school students individually comprehending a given text-based Arduino program while interacting with its corresponding functional physical artifact to answer two questions: 1) How do novices comprehend the given text-based Arduino pro gram? And, 2) What role does the physical artifact play in program comprehension? We found that novices mostly approached the program bottom-up, initially comprehending structural and later functional aspects, along different granularities. The artifact provided two distinct modes of engagement, active and interactive, that supported the program’s structural and functional comprehension. However, behavioral comprehension i.e. understanding program execution leading to the observed outcome was inaccessible to many. Our findings extend program comprehension literature in two ways: (a) it provides one of the very few accounts of high school students’ code comprehension in a physical computing con text, and, (b) it highlights the mediating role of physical artifacts more » in program comprehension. Further, they point directions for future pedagogical and tool designs within physical computing to better support students’ distributed program comprehension. « less
Authors:
;
Award ID(s):
1742140
Publication Date:
NSF-PAR ID:
10309426
Journal Name:
Proceedings of the 26th ACM Conference on Innovation and Technology in Computer Science Education
Volume:
1
Sponsoring Org:
National Science Foundation
More Like this
  1. de Vries, E. ; Hod, Y. ; Ahn, J. (Ed.)
    While making physical computational artifacts such as robots or electronic textiles is growing in popularity in CS education, little is known about student informal conceptions of these systems. To study this, we video-recorded think-aloud sessions (~10 minutes each) of 22 novice CS high school students explaining their understanding of everyday physical computing systems and qualitatively analyzed transcripts and student drawings for their structural, behavioral, and functional understanding of these systems. Most students identified the presence of programs in making these systems functional but struggled to account them structurally and behaviorally. A few students pointed out probable programming constructs in shapingmore »underlying mechanisms, drawing from their prior programming experiences. To integrate these systems in computing education, we call for pedagogical designs to address the invisibility of computation—both of structural interconnections and of program execution.« less
  2. Today’s STEM classrooms have expanded the domain of computer science education from a basic two-toned terminal screen to now include helpful Integrated Development Environments(IDE) (BlueJ, Eclipse), block-based programming (MIT Scratch, Greenfoot), and even physical computing with embedded systems (Arduino, LEGO Mindstorm). But no matter which environment a student starts programming in, all students will eventually need help in finding and fixing bugs in their code. While the helpful IDE’s have debugger tools built in (breakpoints for pausing your program, ways to view/modify variable values, and "stepping" through code execution), in many of the other programming environments, students are limited tomore »using print statements to try and "see" what is happening inside their program. Most students who learn to write code for Arduino microcontrollers will start within the Arduino IDE, but the official Arduino IDE does not currently provide any debugging tools. Instead, a student would have to move on to a professional IDE such as Atmel Studio or acquire a hardware debugger in order to add breakpoints or view their program’s variables. But each of these options has a steep learning curve, additional costs, and can require complex configurations. Based on research of student debugging practices[3, 7] and our own classroom observations, we have developed an Arduino software library, called Arduino Debugger, which provides some of these debugging tools (ex. breakpoints) while staying within the official Arduino IDE. This work continues a previous library, (redacted), which focused on features specific to e-textiles development boards. The Arduino Debugger library has been modified to support not only e-textile boards (Lilypad, Adafruit Circuit Playground) but most AVR and ARM based Arduino boards.We are also in the process of testing a set of Debugging Code Templates to see how they might increase student adoption of debugging tools.« less
  3. What knowledge does learning programming require? Prior work has focused on theorizing program writing and problem solving skills. We examine program comprehension and propose a formal theory of program tracing knowledge based on control flow paths through an interpreter program's source code. Because novices cannot understand the interpreter's programming language notation, we transform it into causal relationships from code tokens to instructions to machine state changes. To teach this knowledge, we propose a comprehension-first pedagogy based on causal inference, by showing, explaining, and assessing each path by stepping through concrete examples within many example programs. To assess this pedagogy, wemore »built PLTutor, a tutorial system with a fixed curriculum of example programs. We evaluate learning gains among self-selected CS1 students using a block randomized lab study comparing PLTutor with Codecademy, a writing tutorial. In our small study, we find some evidence of improved learning gains on the SCS1, with average learning gains of PLTutor 60% higher than Codecademy (gain of 3.89 vs. 2.42 out of 27 questions). These gains strongly predicted midterms (R2=.64) only for PLTutor participants, whose grades showed less variation and no failures.« less
  4. Early in the pandemic we gathered a group of educators to create and share at-home educational opportunities for families to design and make STEAM projects while at home. As this effort, CoBuild19, continued, we decided to extend our offerings to include basic computer programming. To accomplish this, we created an offering called the Design with Code Club (DwCC). We structured DwCC to be different from other common coding offerings in that we wanted the main focus to be on kids designing solutions to problems that might include the use of technology and coding. We were purposeful in this decision formore »two main reasons. First, we wanted to make our coding club more interesting to girls, where previous research demonstrates their interest in designing solutions. Second, we wanted this effort to be different from most programming instruction, where coding activities use programming as the core of instruction and application in authentic and student-selected contexts plays a secondary role. DwCC was set up so that each of the first four weeks had a different larger challenge that was COVID-19 related and sessions unfolded with alternating smaller challenges, discussion around design and coding instruction that would develop their skills and knowledge of micro:bit capabilities. We culminated DwCC with an open-ended project where the kids were given the challenge of coming up with their own problem for which they might incorporate micro:bit as part of the solution. Because we were doing all of this online, we used the micro:bit interface through Microsoft MakeCode, which includes a functional simulator. From our experiences we realized that simulations are not as enticing as physical computing with a tangible device, so we set up an incentive where youth who participated in at least three sessions of the club would receive a physical micro:bit. We advertised DwCC through Facebook and twitter and had nearly 200 families register their kids to participate. In the end, a total of 52 micro:bits were sent to youth participants. Based on this success, we sought to expand the effort and increase accessibility for groups that are traditionally underrepresented in STEM. In spring 2021, we offered a Girls DwCC. This was a redesigned version of the club where the focus was even more on problem-solving through design. The club was run by all women, including one from the US, an Industrial Engineer from Mexico and a computer programmer from Albania. More than 50 girls from 17 countries participated in the club! We are working on another version of GDwCC that will be offered in Spanish and focus on Latina girls in the US and Mexico. In the most recent iteration of DwCC we are working with an educator at a school for deaf students to create a version of the club that works for their students. We are doing some modification of activities and recreating videos that involve sign language interpretation. In this presentation we will report on the variants of DwCC, results from participant feedback surveys and plans for future versions.« less
  5. This article describes a sensor-based physical computing system, called the Data Sensor Hub (DaSH), which enables students to process, analyze, and display data streams collected using a variety of sensors. The system is built around the portable and affordable BBC micro:bit microcontroller (expanded with the gator:bit), which students program using a visual, cloud-based programming environment intended for novices. Students connect a variety of sensors (measuring temperature, humidity, carbon dioxide, sound, acceleration, magnetism, etc.) and write programs to analyze and visualize the collected sensor data streams. The article also describes two instructional units intended for middle grade science classes that usemore »this sensor-based system. These inquiry-oriented units engage students in designing the system to collect data from the world around them to investigate scientific phenomena of interest. The units are designed to help students develop the ability to meaningfully integrate computing as they engage in place-based learning activities while using tools that more closely approximate the practices of contemporary scientists as well as other STEM workers. Finally, the article articulates how the DaSH and units have elicited different kinds of teacher practices using student drawn modeling activities, facilitating debugging practices, and developing place-based science practices.« less