Michelle Wantuch | MIT Media Lab (Scratch Microworlds)

MIT Media Lab

(Scratch Microworlds)

Project Overview:

I worked with the Scratch team in the Lifelong Kindergarten Lab at the MIT Media Lab on a project called "Microworlds". A Microworld is a Scratch starter environment that contains themed projects on which to build before advancing to the normal Scratch platform. While microworlds are more simplified and scaffolded than Scratch, they still allow for open-ended projects, unlike many other introductory coding platforms in existence today. Additionally, the themes of the projects take into account the existing interests of the users.

The User:

Children (or adults who have never used Scratch before). Ideally, the new users would be females or minority students, as we are trying to encourage these populations to join the technology and computer science community. Currently, the industry is lacking this type of diversity.

The Main Problem:

How do you provide enough scaffolding and simplicity to get students comfortable with Scratch while staying true to the constructivist principles of autonomy and open-endedness?

Wait, what does that mean?

It means that I thought a lot about designing to help a user become comfortable with the Scratch coding language and interface while not helping too much.

The Process:

1. Brainstormed Microworld Themes:

I used MySQL to research themes and interests already present in Scratch. I began looking at studios with the most projects in them and studios with the most followers. However, what proved to be useful was looking at the top tags for projects in Scratch. This led me to conclude that one Microworld theme should be Pokemon.
Next, I brainstormed other topics that would be of interest to minority groups. I thought that picking a topic like the U.S. Women's Gymnastics team would be appealing to females, since there was a lot of social media and news on this topic, proving an already established excitement by young females.

2. Started Creating Microworlds in Scratch:

I created the Dandelion Remix based on a project by Jie Qi from the MIT Media Lab. As I was deconstructing the code I created into a microworld, I realized that this project was not open-ended enough, as the coding was rather complicated and the possible end products were not varied enough.
As I started to create the Pokemon and gymnastics microwords, I had to focus on structure and scaffolding while ensuring that the projects were still open-ended, allowing for user autonomy. While pre-set backgrounds, assets, and blocks of code provided scaffolding, I realized that I needed to change the microworld interface in order to further reduce cognitive load.

Initial Pokemon Microworld Building in Scratch

Dandelion Remix in Scratch

3. Wireframed a New Microworld Interface

I wireframed an entirely new interface for microworlds. The first draft is below.
The new editor groups the coding blocks based on completing an action instead of based on block type. This requires Scratch users to click into at least two sections of the editor to create an action. Instead, the new grouping method provides enough structure and scaffolding to help new users complete an action within only one section of the editor. While the editor simplifies the process of starting to code, it still allows for a multitude of project outcomes, ensuring user autonomy and agency.

4. Prototyped the new editor in Sketch

Due to the limited timeline, I prioritized coding and testing the editor feature. I kept the rest of the microworld interface the same as another prototype.

5. Worked with a software engineer at the Media Lab to code the new design

6. Tested the high-fidelity prototype at the MIT Museum, then wireframed the next iteration

We concluded that the editor helped scaffold the learning while still being fun for the user! Success!
While there were many successes, there were also many improvements that we decided to make based on our conversations and observations at the playtesting session. Here are some highlights:

We noticed that many users were having trouble with the blocks that involved x and y coordinates. We realized that many of our users had not yet learned about x and y in school. Without implementing the functionality relating to x and y that is present in normal Scratch, many users struggled to learn what x and y meant and how they could be used. So, we decided that in our next iteration, we should add x and y under the stage and have x and y automatically update in the block in the editor as the sprite is moved on the stage. While this can help the users interact more with x and y in a meaningful way, we do recognize that there is the possibility of users getting confused after pressing start on their script and not seeing the sprite move. (This is because, if the x and y on the block updates to the position of the sprite, the sprite will “move” to the spot it is already in, making it seem like nothing happened unless the sprite is moved again after grabbing the block from the editor). This is something that will need to be further explored in later playtesting sessions.

Since the hat blocks both are programmed to initially show “when space key pressed”, the users did not realize the need for two hat blocks. But once we tested starting with one hat block as “when left arrow pressed” and “when right arrow pressed”, the users began to understand the possible need for multiple hat blocks and scripts.

In the lower left side of the interface was an animation that showed how to snap blocks together on the workspace. We realized that this needed to be integrated into the actual editor and workspace. When users first entered the microworld, they saw the animation and thought that they needed to grab the block from the animation and drag it into the other side of the animation instead of grabbing blocks from the actual editor and dragging them into the actual workspace. To solve this (as well as the other issues), we wireframed an introductory animation, located within the actual editor and workspace. In this new design, we wanted to make it clear that the principles from the animation were separate from yet generalizable to the microworld projects. So, we chose to not put text in the blocks and use a different color for the blocks (so that users

would not automatically grab the same color block when starting their projects).

We re-ordered the buttons, realizing that “move” included some of the most complicated blocks. Instead, the blocks within “change” seemed easier to start with and were also the most exciting out of the other buttons/categories.

I also decided to have two other introductory animations occur after the first, based on challenges that we viewed in our playtesting sessions. Many users did not understand that the hat blocks meant that they actually needed to click the button designated in the hat block (such as the spacebar) on the keyboard. Also, many others did not know that they could click on the block in the workspace as another option to make the scripts work. These new animations would ideally help the user understand these functionalities.

For more details, check out the full length report here.

Back to Portfolio