Computer science related topics are increasingly introduced at elementary school level, aiming not only to establish basic knowledge, but also to foster affective aspects such as motivation or self-efficacy. While corrective feedback is helpful to achieve the former, it may negatively impact the latter. This raises the question on how to provide feedback in an encouraging way that makes learners feel competent but also autonomous. To shed light on this question, we conducted a robotics course with 45 children aged nine to eleven years, in which we studied their preferences when given a choice of either solving a problem themselves (with only a hint from the tutor) or being given the solution directly.We find that children like the freedom of choice and slightly prefer solving their problems themselves, which in turn is significantly correlated with a higher improvement in self-efficacy for building and programming robots. Interestingly, however, only girls exhibit a significant correlation with resulting knowledge on building, and only eleven year old children with resulting knowledge on programming. These insights allow us to provide concrete recommendations on how to give feedback and involve elementary school children and their preferences to promote both knowledge and self-efficacy.

Computational thinking is gradually being introduced into elementary school curricula, usually accompanied by some form of programming activity. However, even a creative and hands-on activity such as programming Ozobot robots with color codes requires elementary school teachers to provide adequate help. We therefore developed hint cards based on criteria for effective feedback and common color code mode issues. Based on our experience of using the hint cards in 17 workshops in elementary schools with 328 children and 21 educators, we identify how the hint cards (1) address feedback challenges, (2) support learning, and (3) can be adapted for broader use. We find that hint cards provide benefits at the teacher, learner and organizational level, but also identify possible disadvantageous circumstances. Although the hint cards support learning regarding affective, cognitive and meta-cognitive aspects, strategies for adaptation are needed. We discuss how the hint cards can be used in other contexts, and give recommendations on how to use the knowledge of common issues and hint cards for supporting elementary school teachers with teaching programming.

Scratch is a hugely popular block-based programming environment that is often used in educational settings, and has therefore recently also become a focus for research on programming education. Scratch provides dedicated teacher accounts that make it easy and convenient to handle lessons with school classes. However, once learners join a Scratch classroom, it is challenging to keep track of what they are doing: Both teachers and researchers may be interested in learning analytics to help them monitor students or evaluate teaching material. Researchers may also be interested in understanding how programs are created and how learners use Scratch. Neither use case is supported by Scratch itself currently. In this paper, we introduce ScratchLog, a tool that collects data from learners using Scratch. ScratchLog provides custom user management and makes it easy to set up courses and assignments. Starting from a task description and a starter project, learners transparently use Scratch while ScratchLog collects usage data, such as the history of code edits, or statistics about how the Scratch user interface was used. This data can be viewed on the ScratchLog web interface, or exported for further analysis, for example to inspect the functionality of programs using automated tests.

Introducing computational thinking in primary school curricula implies that teachers have to prepare appropriate lesson material. Typically this includes creating programming tasks, which may overwhelm primary school teachers with lacking programming subject knowledge. Inadequate resulting example code may negatively affect learning, and students might adopt bad programming habits or misconceptions. To avoid this problem, automated program analysis tools have the potential to help scaffolding task creation processes. For example, static program analysis tools can automatically detect both good and bad code patterns, and provide hints on improving the code. To explore how teachers generally proceed when creating programming tasks, whether tool support can help, and how it is perceived by teachers, we performed a pre-study with 26 and a main study with 59 teachers in training and the LitterBox static analysis tool for Scratch. We find that teachers in training (1) often start with brainstorming thematic ideas rather than setting learning objectives, (2) write code before the task text, (3) give more hints in their task texts and create fewer bugs when supported by LitterBox, and (4) mention both positive aspects of the tool and suggestions for improvement. These findings provide an improved understanding of how to inform teacher training with respect to support needed by teachers when creating programming tasks.

Learning basic programming with Scratch can be hard for novices and tutors alike: Students may not know how to advance when solving a task, teachers may face classrooms with many raised hands at a time, and the problem is exacerbated when novices are on their own in online or virtual lessons. It is therefore desirable to generate next-step hints automatically to provide individual feedback for students who are stuck, but current approaches rely on the availability of multiple hand-crafted or hand-selected sample solutions from which to draw valid hints, and have not been adapted for Scratch. Automated testing provides an opportunity to automatically select suitable candidate solutions for hint generation, even from a pool of student solutions using different solution approaches and varying in quality. In this paper we present Catnip, the first nextstep hint generation approach for Scratch, which extends existing data-driven hint generation approaches with automated testing. Evaluation of Catnip on a dataset of student Scratch programs demonstrates that the generated hints point towards functional improvements, and the use of automated tests allows the hints to be better individualized for the chosen solution path.

Bugs in SCRATCH programs can spoil the fun and inhibit learning success. Many common bugs are the result of recurring patterns of bad code. In this paper we present a collection of common code patterns that typically hint at bugs in SCRATCH programs, and the LitterBox tool which can automatically detect them. We empirically evaluate how frequently these patterns occur, and how severe their consequences usually are. While fixing bugs inevitably is part of learning, the possibility to identify the bugs automatically provides the potential to support learners.