Scratch Logo, courtesy of MIT Media LabLiteracy from Scratch

Materials by Teachers in English - Primary

Bookworm Project (Amy Cozens and Eloise Green)

Using Scratch at KS1

Bookworm This program is designed to introduce KS1 children to Scratch, with a view to working towards creating their own projects. In particular, there is opportunity for children to create their own animated sprites. This requires them to draw their character from several angles and would be best supported through having a model to copy or by giving the children an outline to work with. We were also mindful of creating opportunities for children to read from the board. (Note the speeds for the speech are currently very quick, simply change the timings within the code to suite your purpose.)

Rather than explain how to make this project I have outlined some of the things I have learnt by doing it. To any teacher setting out to use a program such as this with their class I would recommend allowing themselves time to explore the possibilities of the software.

If you do want to know how we overcame some of the many problems we faced there are project notes with the program. Copy the code in isolated chunks and have a play to see what you can do with it.

Working in pairs

From the outset, we chose to work as pair, which proved highly effective for us. This has several benefits: less computers required; opportunity to discuss ideas and someone to help you solve problems. Scratch also has the benefit that you can import projects. For example our program has an introduction that we worked on collaboratively as we learnt the program, the player then has the opportunity to choose a path. We then programmed the games independently - follow the spooky path to the gingerbread house and you will be able to play two KS1 Science games produced by myself. These games are interactive and I tried to incorporate board control. I can see this creating opportunities for whole class projects that the teacher can combine.

Approach as a teacher

During an early presentation of our Scratch project I said, ‘Our imaginations are greater than our skill set’. Which I think will be true for many pupils as they set out to program and animate their own ideas. We had only just started working with the program, though we new what we wanted to achieve we had to work hard to understand how to do it. Importantly we were able to achieve most of what we set out to do. This is something I hope to pass on to young learners, to push Scratch and explore its full potential.

When working with children using Scratch it made a big difference to them when they realised I knew what I was doing. This realisation gave confidence to those starting out and gained respect from those attaining at a higher level. Teaching with confidence makes using a Program such as Scratch a lot less daunting. I also think that if the teacher has taken time to explore the program they will be familiar with common issues and how to solve them. This will help the teacher steer their class away from tasks which will prove frustrating and encourage them to overcome problems that will have rewarding solutions. Having some skills in the program also means a teacher can orchestrate learning opportunities, such as a program containing a problem that the class need to de-bug.

Introducing your class’s artwork

One of my favourite features is the ability to draw your own backgrounds and sprites. I think this makes any project more personalised. The action of drawing on the computer also helps children to develop their mouse control. When developing our program I was responsible for all the artwork and I think this has given our work cohesion and personality. This is also a more tangible link from their own design work and planning to working on a computer. In this respect I think it is important to allow children time to plan their work, how it will look and work. This will give them something to aspire to and help them to evaluate whether they have achieved their goals.

When considering the artwork for our project I chose to keep it simple. I think it is worth looking at artwork on a computer as part of art lessons. An understanding of simplifying images will make children more successful in creating readable images. For example exploring collage or reducing images to geometric shapes.

Break through moments

I would identify three moments that helped us to make this program successful:

  1. Using ‘broadcasting’ meant we did not have to rely on timing. It meant once one sprite had finished, it could tell the next one to start. This was key to producing such a long program with so many sprites.
  2. Changing the costumes of the sprites rather than a whole new sprite. This kept it more simple, reducing our use of broadcasts and avoiding conflicting instructions.
  3. Creating an ‘invisible’ costume for the children. This was a costume made up of a single pixel, to prevent conflicting messages. Once you have told a sprite to ‘appear’ once it causes problems if you repeat the instruction again later.

How we tackled the ‘choose to be a boy or a girl’ problem

When trying to allow the user to choose an avatar/Sprite from a boy or girl choice, it was difficult to see how to set the parameters of the question. I grasped the "If" your answer is "this" part, but couldn't work out how to make the question/answer have an effect. E.g. typing girl hides the boy avatar and keeps the girl avatar throughout the project.

After a lot of investigation and trial and error, we decided to add the Sprites first and have THEM ask the question "Are you a boy or a girl?" and indicate to the user, what they need to do next to make the choice. It helped that when you right click on the various jigsaw pieces that make up your algorithm, a help option comes up for you to get an idea of how it might be used.

This was how we decided to change from "asking" a question to having the Sprites "say" the question. Having realised the difficulties and limitations of the project, we decided to put the "what is your name?" option on a back burner until we have gained some ground on the rest of the project.

Ground gained! We worked out that we can add the Operators into the Say box and join a sentence with the previous answer to the question, e.g. If you ask the child their name, the answer can be input at any stage of the project to address them directly. This worked well when we had the bookworm read the story, using the "answer" to address the user with whatever they typed as their name.

Having played with timings, we considered the best way to get an answer from the user was not to ask two questions and they answer yes or no to both questions. There had to be an easier way to do this so we continued to investigate!

Found an easier way! We avoided yes/no questions and asked an open question, which we can set the answer for a specific term, e.g. Type your name. And instead of asking "Are you a boy or are you a girl?" we told the user to click on the character they want to play as, so they set the next action in motion.

We have managed to work out how to remove the speech bubbles by clicking on the help option as it suggests that you need a blank "say" instruction to clear it. This we have timed to disappear when the mouse moves over the character.

Building the child's name into the display

We wanted the child's name to come up later when they have typed it in, but couldn’t seem to get it to appear with the pre-written text in the same speech bubble. This was an issue until we thought about using variables. We set a variable to be the answer to the question and called it the username, then every time we wanted to have the user’s name in a sentence we "joined" username and the speech like this:

Scratch Coding Sample

Using Operators you can join several chunks of speech together by including an "……. And……….." inside the join function.

We decided to make the arrows change colour when the child puts their mouse cursor over it to show where they are on the page, as this is nice and visual, but when adding the sensor "touching mouse pointer" we couldn't work out why the arrow was NOT changing colour when the cursor moved over it. After trying several different sensors, such as "Touching colour" and "distance to mouse pointer = 0", we realised that we needed to repeat the sensing "forever" as the arrow was checking where the mouse pointer positions was instantly and, finding it was not in contact with the arrow, did not change colour. It needed to continually make this check to make the arrow sense all the time. This is vital for other sensor coding as you will rarely want a sprite to just sense something the once!

We have solved a problem we hit that was very frustrating! We had separate Sprites for the boy and girl both standing still and walking, then changed the costumes of the walking Sprites to animate their movements. This proved tricky to change when we asked the boy to broadcast "hide girl" and "show boy walking" and vice versa, as the code was competing. My partner worked out that if we changed the costumes of the single boy and girl Sprites, giving them walking costumes instead of separate Sprites, we wouldn't need to get them broadcast hide and show messages, we could just change the costume of both simultaneously and this has made things much simpler!

We couldn't work out how to get the Sprites to walk from different sides of the screen, so we tried pointing them in alternative directions. This didn't work as it only rotated them and didn't flip them horizontally, so we created 2 new costumes and copied the walking code, extending it for the new background and to make them walk in the chosen direction we changed the "move 10 steps" instruction to a move "-10 steps". This worked!

Once we had written our own game, we felt ready to guide the children to write their own. You can adapt our illustrated materials using the links below:

Notes from the Course Tutor

These files are for use in the classroom. They can, of course, be adapted by teachers, with further resources, such as Sprites or Backgrounds, added by pupils.

I have included all the work of my teaching group here. There are many wonderful teaching ideas, and if we did not solve every coding problem effectively (none of us is an expert in Computing, including me!), the creativity of these young teachers more than makes up for it.

The teaching programme covered 30 hours of work at the computer, so if you start with one session of 60 minutes per week, you will become as proficient as they have been well before the end of your teaching year!

The key to success is to work with a partner, share ideas, and problem-solve together.