A web-based learning tool that scaffolds middle school students' transition from block-based to text-based programming, using side-by-side worked examples and generative practice.
Many learners start programming with block-based environments like Scratch, where code is assembled visually and errors are rare. Moving to text-based languages like Python breaks that flow entirely. Students suddenly face cryptic syntax errors, strict formatting rules, and no visual scaffolding to fall back on.
"It takes too long to write and any little mistake can mess up the whole thing." Alice, a middle school student, on transitioning from Scratch to Python
The transition involves more than learning new syntax. It requires a shift in how students think about code: from snapping blocks to composing statements, from seeing execution visually to reasoning about it abstractly.
Discovery
We interviewed middle school students and identified the specific pain points that made text-based coding feel hostile: syntax errors, forgetting command names, and struggling with control structures like if statements and for loops. Typos that silently break programs were especially demoralizing.
The pattern pointed to a clear design principle: learners needed to build confidence through small, frequent wins before tackling open-ended coding challenges.
Learning Design
We built CodingCUSP around three frameworks. Self-efficacy theory shaped our emphasis on scaffolded practice and immediate feedback, since confidence in coding grows through mastery experiences, not just exposure. Constructionist learning informed the trial-and-error philosophy: students understand code better when they can tinker and observe the results. Socio-cultural theory motivated our use of task-specific contexts like art and design to make coding feel personally relevant.
The Theory of Change tied these together: the right combination of structure, context, and feedback would move learners from block-based familiarity to genuine Python competence.
Design
We chose two learning mechanics grounded in cognitive science. Worked examples with block-based equivalents let students see how familiar concepts map to Python syntax, reducing cognitive load during the hardest part of the transition. Generation, where students complete partial code rather than copying it whole, strengthens retrieval and builds the mental models needed for independent coding.
Students could step through code line by line to observe how each command changed the Turtle's behavior, making execution visible rather than abstract.
Fill-in-the-blank problems gave students early mastery experiences without the blank-page anxiety of writing from scratch. Targeted error messages helped them identify and fix bugs instead of feeling lost in the output.
Prototyping
We started with paper prototypes to test one core question: would learners be willing to self-report their confidence alongside their answers? Moving to digital prototypes, we explored how intuitive it was for learners to refer back to worked examples while actively coding. A final click-through prototype tested whether users could navigate the notebook interface independently and discover its features without guidance.
Testers appreciated the simplicity and clarity of the scaffolding. But one piece of feedback stuck: "I wonder how you can make it more playful." The tool was readable and logical, but it felt more like a worksheet than an experience learners would seek out. Scaffolding that reduces cognitive load does not automatically create intrinsic motivation. Those are two separate design problems.
CodingCUSP addressed a gap that no existing competitor fully covered: a side-by-side block/text editor with scaffolded progression and annotated worked examples, all in a contextualized task environment.
| Feature | CodingCUSP | Code.org | MakeCode | Teaspoon |
|---|---|---|---|---|
| Side-by-side blocks and text | Yes | |||
| Built-in scaffolded progression | Yes | Yes | ||
| Step-by-step annotated breakdown | Yes | Yes | Yes | |
| Contextualized topics | Yes | Yes | Yes | Yes |
If I were building it again, I would invest more in the motivational layer from the start: a clearer sense of progression, a project students could feel proud of completing, and feedback that feels encouraging rather than corrective. The cognitive scaffolding was solid. The emotional design was where more work remained.
Want to see the product?
The project has been archived.