Dr Scratch

Dr Scratch is a free online analytical tool that evaluates Scratch projects. To use the tool, students insert the URL to their Scratch project, or upload their Scratch project file. The tool analyses the presence of Scratch blocks, functionality of scripts and use of sprites.

The tool provides feedback on a variety of computational areas, including: flow control, data representation, abstraction, user interactivity, synchronisation, parallelism and logic, as well as use of best visual programming practice (eg use of sprites attributes and naming, and script performance). It provides a score out of 21 and feedback in the form of a progress status (ie ‘developing’). Students can print a copy of their certificate, which shows the score, allowing them to document progress over time. However, to capture the report, it is recommended that a screen capture is made.

This tool would be suitable to support formative assessment. It can be used to support students’ self-evaluation of their own projects, peer-evaluation or as a support tool for teachers wanting to undertake formative assessment of students’ Scratch projects.

Please note that this tool is in Beta phase. It should not be used as a diagnostic tool, rather as something to support formative assessment and drive discussion and self-reflection.

This analytical tool can be used for formative assessment of Scratch projects. Prior to using the tool in the classroom, we recommend that teachers review the various indicators that the evaluation report analyses and how students might be guided toward designing more effective programs (eg see the Logic page of the Dr Scratch website).

Some recommendations for using this tool are as follows:

• Encourage students to iteratively test their Scratch programs, or plan opportunities throughout a unit for students to evaluate their programs.
• Have students take a screen capture or photo of their evaluation summary so that they can document their progress over time during their project creation.
• Have students compare their first and last reports: What has improved? What has stayed the same? What could they improve next time?
• Record students reflecting on their Scratch progress summary, or ask students to write a reflection piece.
• Prepare for students a blank version of the Scratch evaluation page and have students selfevaluate their projects based on the criteria before using the tool. Invite students to reflect on how accurate their own evaluations were.
• Teachers can use this to guide formative assessment and feedback. Run a student’s project through the tool and provide feedback (using the online guide) about how students can improve their projects.

Data Representation: Information about objects (Sprites) tell the program about what to do with these objects to run properly. This includes information about a Sprite such as their position, direction, size and/or colour. Data is a fundamental consideration, as programs use data to operate. Students use data in programs when they tell a Sprite how to move around the program (e.g. how many steps a Sprite takes) and they can manipulate data in their program to have a different output (e.g. to change the number of steps a Sprite will take).

Students can also store data in their programs using variables. Variables are like containers and can hold data – such as keeping track of a score in a game.

Data for a Sprite

Variable in a program

• Has the student adapted the attributes of their Sprite?
• Can the student identify and classify the types of data in their program?
• Can they identify the attributes of their Sprite?
• Can students predict what will happen if they make a change to some data in their program?
• Has the student used a variable in their program?

Sequence: The program will be made up of a sequence of steps (algorithm) arranged as blocks of code (our “script”) that have a start and an end point. These blocks execute one after the other. Students will test that their code executes in the correct order. The blocks in the brown “Events” block group can be used to tell the computer how/when to execute a sequence of code. Dr Scratch measures this with “Flow Control” (awarded 0 points, as the starting point of their program development).

A more advanced version of sequences could be that students not only have one single script, but that multiple scripts, made up of a sequence of blocks, are executing at the same time. This is referred to as “parallel programming” and is measured in Dr Scratch as “Parallelism”.

Sequences (logical order)

Parallelism (multiple scripts)

• Is there a start-block for the sequence of blocks that indicate when the program should start? E.g. “When [green flag] clicked” or “when [space] key pressed”.
• Does the code execute in the intended order? Do events/actions happen in the program in the expected order? Are the blocks used organised in a logical order?
• How many “scripts” of are present? Can the student add another script to run at the same time?
• The most obvious starting point is when students have users click the green flag to start the program. Can they also consider other ways a script might be prompted to start by using alternative “event” blocks?

Iteration (repetition): As students form their sequential blocks, they can introduce the repeat/loop block to avoid repetition in code as a more advanced aspect of sequences. For example, instead of putting the same single blocks one after the other, we can wrap an iteration (repeat/loop) block around blocks they would like to repeat, to tell the computer to execute the code a certain number of times. This block is used to control our code and can be found in the yellow “control” block section of Scratch. Dr Scratch measures this as an extension of “Flow Control” (awarded 1 point or more).

Iteration

• Has the student used iteration (repeat/loop) blocks in their script?
• Are there existing blocks that are repetitive and could be replaced with an iteration (repeat/loop) block?
• Can the student evaluate their program and think of ways to make their code more efficient?
• Can the student identify code that is repetitive? Can they see a pattern in their code?

Branching/Conditions: We can use branching blocks (also referred to as “logical operators” or “decisions”) to tell our computer what to execute based on a decision or condition in our code. Dr Scratch measures this as “Logic” (awarded 0 points for a simple “IF-THEN” combination and 1 point for an IF/ELSE combination. 2 points awarded for combining “branching blocks”).

IF-THEN combination

IF-ELSE combination

User Input: Programs can be designed to engage the user by having them interact with the program – through some form of user input. For example, a user might click on a Sprite in a game or animation to have make it react in some way, or they could enter their name or a quiz answer when prompted. When we think of input and output, we can characterise the images on the screen and sound as output. Input is anything that provides some information to our program – such as a click of the mouse or a keyboard, or entered text. User input involves students considering the functional requirements of their program.

User input/interactivity

• Is there any level of user interaction with the program beyond clicking the green flag?
• What types of interaction are featured?
• Can the student identify the functional requirements for how the user interacts with their program?

This is measured in Dr Scratch by “User Interactivity” (with 0 points starting with the “when [green flag] clicked” event block). Further points are awarded if the user is invited to engage in further interaction, such as enter their name, use the mouse or click on other Sprites. The highest level of interaction can occur when they use the microphone or webcam abilities to interact with the user. Interactivity blocks are found in the brown “Events”, blue “Sensing” and pink “Sound” sections.

User interface design: This includes: what the user can see, how the user interacts with the program, the information provided to the user and the usability (functionality/ease of use) of the program. Students need to consider their user in their designs and ensure programs meet their needs and intended purposes. For example, it is not enough to make a program interactive, if the user does not know how to interact with the program. The student needs to provide information to the user that helps them to use their program. This could be through Scratch Instructions, an opening scene with information, or prompts throughout the program that help the user. It could even include a “Help” page if users need to be reminded or seek help. User interface design involves students considering the functional requirements of their program.

• Does the user know how to use and interact with the program? E.g. Are instructions or prompts present for which keys to press?
• Is the program usable? How could user engagement be improved?
• Is the design visually engaging and appropriate? E.g. consider fonts, editing, colour contrasts.
• Has the student completed a user-test of their program on their own or with a peer? What did they identify as needing to change?