Scratch: Early Design, Testing and Release

Scratch emerged from collaboration between the Lifelong Kindergarten group at the MIT Media Lab and a University of California, Los Angeles team led by Yasmin Kafai. John Maloney, Mitchel Resnick, Natalie Rusk, Brian Silverman and others participated in its early design. The project aimed to enable young people who used computers to make images and music to change how their media behaved through programming.

The original technical paper from 2004 recorded that, after discussing the design during the preceding year, the team began implementing its first prototype in January 2003. In early October that year, students in an MIT and Harvard seminar tried Scratch 0.1. The year 2003 thus refers to development and testing; the software and accompanying website were not publicly launched until May 2007. The two stages should not be conflated as one release.

References: [1] [2] [4]

The early implementation used Squeak, an open implementation of Smalltalk-80. The prototype treated still images, movies and sounds as different object types, and the available blocks changed with the selected object. Testers, however, wanted the same object to support functions such as both rotation and playback. The design team therefore proposed a unified object type to reduce the confusion caused by commands changing with the selection.

Another problem involved objects directly invoking one another's scripts: after a sprite was copied into another project, a second sprite on which it depended might be missing, making the program difficult to use independently. The 2004 paper listed removal of such direct calls as a planned change for the next prototype. Formal Computer Clubhouse trials had not yet begun, so the paper's proposed dissemination plans should be distinguished from student testing already completed.

References: [1]

The later public version placed the stage, sprites, command blocks and scripts in one window. Each sprite kept its own scripts and data, and users could drag actions from a command palette and join them into sequential programs. Tabs, notches and argument-slot shapes restricted how blocks could connect. Loop blocks enclosed the actions to be repeated, making the scope of control directly visible without requiring users first to memorize a textual language's punctuation rules.

Maloney and colleagues explained in 2010 that the environment had no separation between editing and compilation: clicking a single block or a program fragment immediately showed the result, and parameters could be changed while the program ran. Variables could be displayed on the stage to help users observe changing values. These choices reduced the cost of experimentation, but being able to assemble and run blocks did not ensure correct logic; the authors continued to emphasize debugging and thought.

References: [3]

The 2008 study presented a ball-catching game: a ball fell from a random position at the top of the stage, while a paddle followed the mouse's horizontal coordinate and the player tried to catch the ball. Separate scripts controlled the ball and paddle, so their simultaneous movement on screen corresponded to parallel activity in the program. The ball's script also involved loops, conditionals, variables and random numbers.

Sprites could coordinate through broadcasts. For example, one sprite could send a victory message, prompting another to appear and play music on receiving it. The same message could trigger several scripts; a separate broadcast-and-wait form was available when completion of the responses had to be awaited. This connection did not require one sprite to manipulate another's internal actions directly, making sprites easier to move to other projects for reuse.

References: [2] [3]

In January 2005, researchers introduced Scratch to a Computer Clubhouse housed in a storefront in South Los Angeles. Members chose their own projects, mentors provided help as needed, and regular activities included focused making sessions and presentations. Rather than transplanting a uniform course into an extracurricular setting, the program offered programming as an activity that participants could actively choose alongside games, drawing, recording and other pursuits.

Over 18 months, the team collected 536 projects, about 34% of those created at the site during that period. Of these, 425 contained scripts and formed the basis for statistics on programming concepts. Loops and interaction were relatively common, while concepts such as variables initially appeared less frequently. The research showed sustained exploration in the community, but the appearance of a particular block in a project cannot be equated directly with every author's full understanding of it, nor can results from one site establish outcomes for all learners.

References: [2]

After the public release in 2007, sharing became a direct action within the software interface. Resnick and colleagues' 2009 paper described how, once a project was uploaded, others could run it, comment, download it and modify its scripts. What circulated was not only the animated result but also the method of making it, allowing users to treat other people's projects as material they could take apart and inspect.

Remixing also prompted attribution disputes: some creators viewed others' reuse of their work as theft. The team subsequently made remixed projects link automatically to the originals and display their relationships, attempting to turn technical copying into collaboration that acknowledged its sources. A key feature of early Scratch was the combination of immediate experimentation, media expression and project exchange in one environment; these historical design choices should still be distinguished from the functions of later versions.

References: [4]