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:
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
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)
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).
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- 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.
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.
© 2017 Education Services Australia Ltd, unless otherwise indicated. Creative Commons BY4.0 licence, unless otherwise indicated.