My Aquarium
Experience: 1st year, 3rd quarter
Practice: Developing and Using Abstractions, Creating computational artifacts, Testing and refining computational artifacts, and Communicating about computing
Concept: Algorithms and Control
Length: 40+
Overview and Purpose
Coders use a variety of blocks and sprites to create an interactive aquarium. The purpose of this project is to apply previously learned concepts in a new context (e.g., creating or modifying sprites, parallelism, events, etc.).
Lesson plan
Overview videoProject Extensions
Suggested extensions
Indicating a user can interact with a sprite (10+ minutes):
5+ minute demonstration and discussion
Pull up an inanimate sprite that we would find in an aquarium (e.g., a treasure chest, sunken ship, plant, or castle) and ask the class what we want to happen when the user taps it. Put that code on the screen and test it.
Pull up an aquarium background and point out how the sprite blends in with the background. Ask coders to discuss with a neighbor how we might let the user know they can interact with our sprite. After a minute or so, ask what kinds of blocks could be used to subtly indicate to a user a sprite can be interacted with.
Demonstrate making a sprite wait for an extended period, move or change sizes a little, then repeat the sequence forever; for example, this giraffe from another project waits a while, jumps a small amount, then repeats the sequence.
5+ minute application and 1-on-1 facilitating
Encourage coders to try something similar with their sprites. Facilitate by walking around and asking questions about how coders might make it more obvious a user can interact with a sprite.
Resources, suggestions, and connections
Standards reinforced:
- 1A-AP-10 Develop programs with sequences and simple loops, to express ideas or address a problem
Practices reinforced:
- Testing and refining computational artifacts
- Creating computational artifacts
Concepts reinforced:
- Algorithms
- Control
Background information: Some of the sprites in other projects use wait blocks to pause for a period of time before doing a subtle movement. This is used as a way of indicating to the user the sprite can be interacted with (while also preventing the screen from being too busy). This is a great tool to use for sprites that blend into the background (e.g., plant sprites); however, in some instances, such as this project, we can encourage users to explore by pressing everything they see. If you would like to explore user experience design, this can become a mini lesson on how to indicate to a user something can be interacted with.
Suggested questions:
- If a sprite is always moving, do we need to add code to make it obvious someone can tap it? (probably not)
- Do animals or plant sprites blend in with backdrops more than the other? (plants tend to blend in more)
- When would you show a user can interact with a sprite and when would you make it a surprise?
- How might you use sound to indicate a user can interact instead of using a visual?
Adding even more (5+ minutes):
If time permits, encourage coders to explore what else they can create in ScratchJr. Although future lessons will explore different features and blocks, early experimentation should be encouraged.
While facilitating this process, monitor to make sure coders don’t stick with one feature for too long. In particular, coders like to edit their sprites/backgrounds by painting on them or taking photos. It may help to set a timer for creation processes outside of using blocks so coders focus their efforts on coding.
Standards reinforced:
- 1A-AP-10 Develop programs with sequences and simple loops, to express ideas or address a problem
Practices reinforced:
- Testing and refining computational artifacts
- Creating computational artifacts
Concepts reinforced:
- Algorithms
- Control
Suggested questions:
- What else can you do with ScratchJr?
- What do you think the other blocks do?
- Can you make your sprites do ______?
- What other sprites can you add to your project?
- What else might we find in an aquarium?
- What sounds or music might we hear in an aquarium?
- Can you create a new sprite for a plant or fish we haven’t discovered yet?
- What kind of code will they have?
- Can you add yourself as a sprite?
- What kind of sprite will you be (e.g., a fish, a object, a plant, etc.)?
- What will you do inside or outside the aquarium?
Similar projects:
Have coders explore the sample projects built into ScratchJr (or projects from other coders), and ask them to find code similar to what they worked on today.
Standards reinforced:
- 1A-AP-10 Develop programs with sequences and simple loops, to express ideas or address a problem
Practices reinforced:
- Testing and refining computational artifacts
Concepts reinforced:
- Algorithms
Note: Coders may need a gentle reminder we are looking at other projects to get ideas for our own project, not to simply play around. For example, “look for five minutes,” “look at no more than five other projects,” or “find three projects that each do one thing you would like to add to your project.”
Generic questions:
- How is this project similar (or different) to something you worked on today?
- What blocks did they use that you didn’t use?
- What do you think those blocks do?
- What’s something you like about their project that you could add to your project?
- How could you turn this scene into an aquarium?
- What would you have to change about each sprite’s appearance to make them fit the new theme (e.g., add a diving helmet to make a sprite look like a toy diver)?
- How could you trigger multiple algorithms in parallel?
Differentiation
Less experienced coders
ScratchJr is simple enough that it can be picked up relatively quickly by less experienced coders. However, for those who need additional assistance, pair them with another coder who feels comfortable working cooperatively on a project. Once coders appear to get the hang of using ScratchJr, they can begin to work independently.
Coders could also modify their previously created “Under the sea” project in order to turn it into an aquarium. By now, coders should have new ideas for how they might utilize block combinations to create something different.
More experienced coders
Because ScratchJr is not inherently difficult, experienced coders might get bored with simple projects. To help prevent boredom, ask if they would like to be a “peer helper” and have them help out their peers when they have a question. If someone asks for your help, guide them to a peer helper in order to encourage collaborative learning.
Another approach is to encourage experienced coders to experiment with their code or give them an individual challenge or quest to complete within a timeframe.
Debugging Exercises (1-5+ minutes each)
Debugging exercises
Resources and suggestions
Standards reinforced:
- 1A-AP-14 Debug (identify and fix) errors in an algorithm or program that includes sequences and simple loops
Practices reinforced:
- Testing and refining computational artifacts
Concepts reinforced:
- Algorithms
- Control
Display one of the debugging exercises and ask the class what they think we need to fix in our code to get our project to work correctly. Think out loud what might be wrong (e.g., did I use the wrong trigger block, did I forget to repeat something, did I put a block in the wrong place, am I missing blocks, etc.). Ask the class to talk with a neighbor how we might fix the code. Have a volunteer come up to try and debug the code (or demonstrate how). Repeat with each debugging exercise.
Unplugged Lessons and Resources
Standards reinforced:
- 1A-AP-08 Model daily processes by creating and following algorithms (sets of step-by-step instructions) to complete tasks
Although each project lesson includes suggestions for the amount of class time to spend on a project, BootUp encourages coding facilitators to supplement our project lessons with resources created by others. In particular, reinforcing a variety of standards, practices, and concepts through the use of unplugged lessons. Unplugged lessons are coding lessons that teach core computational concepts without computers or tablets. You could start a lesson with a short, unplugged lesson relevant to a project, or use unplugged lessons when coders appear to be struggling with a concept or practice.
Reflection and Sharing
Reflection suggestions
Coders can either discuss some of the following prompts with a neighbor, in a small group, as a class, or respond in a physical or digital journal. If reflecting in smaller groups or individually, walk around and ask questions to encourage deeper responses and assess for understanding. Here is a sample of a digital journal designed for Scratch (source) and here is an example of a printable journal useful for younger coders.
Sample reflection questions or journal prompts:
- How did you use computational thinking when creating your project?
- What’s something we learned while working on this project today?
- What are you proud of in your project?
- How did you work through a bug or difficult challenge today?
- How did you help other coders with their projects?
- What did you learn from other coders today?
- What’s a fun algorithm you created today?
- What’s something you could create next time?
- What questions do you have about coding?
- What was challenging today?
- How did this project differ from the “Under the sea” project you previously created?
- What sprites were similar and what sprites were different?
- What’s something new you added in this project that wasn’t in your “Under the sea” project ?
- What kind of sprites did you modify or create for this project?
- More sample prompts (may need adapting for younger coders)
Sharing suggestions
Standards reinforced:
- 1A-AP-15 Using correct terminology, describe steps taken and choices made during the iterative process of program development
Practices reinforced:
- Communicating about computing
- Fostering an inclusive culture
Concepts reinforced:
- Algorithms
- Control
- Modularity
- Program development
Peer sharing and learning video: Click here (1:33)
At the end of class, coders can share with each other something they learned today. Encourage coders to ask questions about each other’s code or share their journals with each other. When sharing code, encourage coders to discuss something they like about their code as well as a suggestion for something else they might add.
