01 Additional design narrative of tool evolution
Introduction
This technical appendix is included to provide more detail of a practical nature to fellow educators in particular to explain and explore the selection of digital tools used within this study. More contextual information is available in Chapter 5 of the full thesis.
Narrative of getting starting with tools
Getting started with retro games
Before describing technical tool use, the choice of game genre merits some attention. In D1 the decision to work with retro games stemmed from a Home Education consultation event which is described in Chapter 1. This possibility to work with games spurred a return to my own love of arcade games. I became an enthusiastic pirate, scouring the web for emulated versions of the arcade games I played in the late 1970’s and early 1980’s. I was intrigued and impressed by the community of enthusiasts sharing these archives of games, translated into ROMs, and shared online, and creating software to emulate the old arcade machines and home video game consoles.
Exploratory Phase 1
I only introduced the actually tools to undertake text coding in week 5 due to my own hesitancy in supporting coding. This hesitancy led to exploration of diverse use of tools and processes. I even asked participants to create a mock up of their characters and backgrounds within Scratch as its interface was familiar to some, and more user friendly to others. I don’t know why it took me so long to adapt a template from the community and use it as a base given that I had taken this approach in my previous study detailing accelerated coding using a starter template of an HTML and css based meme [@chesterman_webmaking_2015].
In week 5 I introduced a minimal template to remix from based on a phaser tutorial. I used this one from Phaser - and adapted it and hosted it in the Thimble code playground.
Summary of motivations and sources of P2 template
Chapter 5 gives a summary of the motivations of the structure of the P2 starting template. The evolution of the form of the template is taken up in the second technical appendix
On Code Codeplaygrounds in general
Referenced in Chapter 5 - section C1
This section examines the features and characteristics of code playgrounds in general and reflects on differences in those used within this study.
On Mozilla, Thimble and Phaser resources
At this stage I would like to express gratitude to the work of the Mozilla Foundation which has helped guide my work. My dissertation work on using Code playgrounds to script HTML pages at post graduate level used Thimble as a key tool [@chesterman_webmaking_2015]. The pedagogy of remixing existing projects was also guided by Mozilla’s work on Webmaking [@mozilla_foundation_webmaker_2014]. When looking to expand this work on scripting HTML and css into the area of programming using JavaScript, the resources of Mozilla devs on a new (at that time) JavaScript game making library Phaser caught my eye. I then also took part in the Mozilla leadership programme using the process of developing resources for this game making course as the orienting activity.
While working with Mozilla always felt like building on shifting sands, I found the community supportive and inspirational. I appreciate their promotion of some of the core features of Code Playgrounds, a tool type previously used as a technical community, within Thimble as a tool marketed to an educational community.
Technical and Community Features of Code Playgrounds
The following features of code playgrounds were particularly relevant to this study. Each is described in technical terms, followed by brief commentary on its pedagogical significance within the project context.
Side-by-side code and preview panels
Most code playgrounds provide a split interface in which source code is displayed in one pane and the rendered output in another. Changes to the code are reflected immediately or near-immediately in the preview window.
This feature was central to early engagement. The rapid feedback loop reduced the cognitive delay between action and result, supporting experimentation and iterative adjustment. Participants could modify small sections of code and immediately observe consequences, which encouraged exploratory behaviour and lowered the threshold for risk-taking.
Live reloading and auto-refresh
Automatic refresh of the output panel removed the need for manual compilation or server setup. In earlier development environments this process often required multiple configuration steps.
For novice coders, eliminating these friction points reduced technical barriers. The environment foregrounded programming concepts rather than file systems, servers, or build tools.
Asset uploading and management
Many playgrounds allow users to upload images, audio files, and other assets directly into the project environment.
This was pedagogically significant in a game-making context. The ability to personalise sprites, backgrounds, and sound effects supported ownership and identity expression. However, asset management systems varied considerably across platforms, and restrictions in some environments constrained creative flexibility.
Built-in code linting and error highlighting
Code linting, in a nutshell, is an automated process that checks code for mistakes, inconsistencies, or potential problems as it is being written.
Real-time syntax checking and visual error markers helped identify missing brackets, incorrect variables, or malformed structures.
This feature functioned as a form of immediate formative feedback. Rather than waiting for facilitator intervention, learners could identify and attempt to resolve errors independently, supporting the development of debugging practices.
Version history and rewind functionality
Some playgrounds include revision history or snapshot features, allowing users to revert to earlier versions.
Where available, this reduced anxiety about “breaking” projects. It legitimised experimentation by providing a safety net. Not all platforms provided robust version control, and where absent, learners were more cautious in editing core mechanics.
Shareable live URLs
A defining feature of many playgrounds, particularly Thimble and Glitch, was the automatic generation of a public, live URL for each project.
This feature extended activity beyond the immediate session. Learners could share playable games with peers, family members, and wider communities. The public nature of the output positioned participants not only as learners but as creators publishing artefacts online.
Remix and fork functionality
Platforms such as Thimble and Glitch supported cloning or remixing projects.
This functionality aligned strongly with the pedagogical strategy of starting from structured templates. Learners could duplicate a base project, modify selected components, and gradually personalise it. The technical affordance of remixing supported progressive independence without requiring construction from a blank file.
Community feedback mechanisms
Within the Thimble project, commenting systems, featured projects, and remix trails made visible the networked nature of creative coding. Although this study did not systematically analyse online peer interaction, the presence of these affordances contributed to an atmosphere of participation in a wider maker culture.
Forums and support networks
Mozilla’s Webmaker ecosystem provided structured forums with a mix of educators and web technologists. This blended community of practice was valuable during tool adoption and troubleshooting phases. Later platforms including Glitch and Replit offered more developer-centred support, which was less accessible to novice learners.
Platform Reduction and Migration (2025)
By 2025, significant changes in the ecosystem altered the available affordances of code playgrounds. The discontinuation of Glitch’s hosting model and the earlier deprecation of Thimble resulted in the loss of integrated live publishing and seamless remix workflows.
Projects developed during this study were downloaded and migrated to a static hosting model. They are currently archived at:
https://jamm-labs.github.io/ggcp/
While alternative platforms exist, none replicate the combination of immediacy, remixability, and educational orientation previously offered by Thimble and early Glitch.
From 2025 onwards, facilitators must make more explicit decisions about hosting, asset storage, and version control. This reintroduces technical complexity that earlier playgrounds had successfully abstracted away.
References
Chesterman, M. (2015) Webmaking using JavaScript to promote student engagement and constructivist learning approaches at KS3. Available at: https://web.archive.org/web/20180831105358/http://digitalducks.org/blog/project-report-webmaking/ (Accessed: March 19, 2016).
Mozilla Foundation (2014) Webmaker Whitepaper. Available at: https://wiki.mozilla.org/Webmaker/Whitepaper (Accessed: May 9, 2015).