Dance Dance Computation Coding Activity

Project for Computational Environments for Learning Technology Module
Team: Lauren Totino and Anne Riitho

Summary

Over the course of our 5-week design project, my partner and I designed a scenario-based problem-solving and coding activity that teaches young learners computational thinking (CT) and computer science (CS) in collaborative and social learning environment. The activity, called Dance Dance Computation, has the learners take on the role of coaches of a team performing a routine in a dance competition, which is being scored by a panel of judges. The dance team's goal is to perform a routine that achieves a high enough score from the judges so that the team can move on to finals. The activity involves "unplugged" problem decomposition and logical thinking work in addition to programming work in Scratch, a block-based coding environment, where learners program the dance moves in order to "perform" the routine. The premise of the project was inspired by code.org's Dance Party warm up activity, which proves that dance moves can be "coded"!

Goals - To learn CT/CS concepts through doing a coding activity that solves a problem or challenge:

• Learners will understand that there is a clear goal and purpose to the CT activity

• Learners will engage in problem decomposition through “unplugged” planning

• Learners will learn logical and algorithmic thinking

• Learners will learn specifics related to code construction or reconstruction through block-based coding

• Learners will have the opportunity to engage with CS concepts like loops and sequencing

Context & Learners

• Learners - The target learners are middle school or early high school students in an informal learning environment (i.e., after school program). Some may have basic prior knowledge on block-based coding, but have probably not experienced it through the lens of CT/CS concepts such as problem decomposition, logical thinking, algorithmic thinking, loops, and sequencing. It is assumed the learners will possess the basic math skills required to calculate a total score for the dance routine.

• Resources - Learners, who will be working in pairs, will be given instructional materials before starting:

  • The scenario description and stipulations/instructions

  • The score sheet that is used by the judges in the scenario

  • Paper/pencil to work “unplugged” (decomposing the problem, drawing out logic)

  • Then, computers/iPads for the programming environment

"Unplugged" Component - Using a question guide (below, left), pairs will decompose the problem as presented on the Scenario worksheet, and will use the Score Sheet and some scrap paper to work out the logic of the categories, sub-categories, and point system in order to “solve” the challenge. This is when learners will start figuring out what moves to include in their routine.

Coding Component - Our design seeks to enhance the Scratch environment by adding an agent who would help the learners through the coding part of the activity by giving instructions and feedback. The agent would:

• Give an introductory overview to Scratch

• Walk the learner through existing blocks of code that are relevant to coding a dance routine

• Prompt learners through the process of modifying an existing dance routine (a model to get started) and creating a new routine (for the competition)

• Check for efficiency and effectiveness in the use of code blocks

The learners would additionally receive feedback and a score from the "judges" - also agents that would be added to Scratch - once the routine is finished and "submitted" into the competition. A final dance routine that follows the parameters of the Scenario and Score Sheet may look like this.

Knowledge-Building & Collaboration Component - Learners would maintain a Code Library: a place in Scratch to compile things the learners come across themselves, like the qualifiers for the code blocks that make for the best dances and other tips/help documentation. For example:

• Angles/degrees for “turn” block that look good/resemble a dance

• Optimal amount of times to repeat a move

• Optimal “wait” time to add between sprite's costume switches

Addressing Variation Among Learners

• Positives - The activity provides gentle introductions to coding and sufficient scaffolding for beginners to be successful, which is important in an informal learning environment because learners may be there to try something new in a low-stakes setting. The nature of partner work allows each learner in the pair to take on a role that they are most interested in or feel the most competent in, while the Code Library collaboration element invites learners who figure out tips and tricks quickly to share with learners who may need more help.

• Shortfalls - The current design does not address how all of the collaborative and social elements might actually lead to maladaptive practices. For example, there may be learners who rely solely on their partner to do all the coding work (i.e., not actually taking on a role) or rely on the Code Library a bit too much (i.e., copying ideas before even starting vs. looking for help after trial-and-error)

Offering Invitations to Engage

• Positives - Scratch encourages users to be imaginative and to create whatever they want, but leaving a coding activity that wide open may not lead to learning about CT/CS concepts. The dance competition scenario provides an authentic and challenging problem space to facilitate this learning. It is a narrow enough scope and has enough parameters to feel doable. And while CT/CS concepts may be new to the learners, the experience is grounded in a phenomenon that is, presumably, culturally familiar to them.

• Shortfalls - It is unclear how this activity fits into the broader learning environment, and the project lacks information about the informal learning setting that it would take place in, other than suggesting that it could be an after-school program. Understanding context and venue is important when designing invitations for learners to engage in the activity; it helps determine what resources, affordances, and constraints you have to work with as the designer.

Choosing the Technology - We knew we wanted to incorporate block-based coding into the design of the activity, knowing that our learners are novices at coding and the overhead associated with learning text-based coding is too cognitively demanding for introducing CT. In deciding between Scratch and Alice, we ultimately chose Scratch because of its affordances related to block-based programming, scaffolding, and collaboration and sharing.

Creating an Activity Flow - This helped us flesh out the desired interactions, the sequencing of the activity, and where in the process CT/CS concepts would be most explicit to the learners. Our activity flow is draws from the Use-Modify-Create approach (Lee et al., 2011) to allow learners to first use a dance routine, modify it, then create their own routines to fit the final competition goals. This can help prevent some of the anxieties that may occur if the learner is just jumping into Scratch to create the dance routines.

• A different approach to learning goals - This project was a bit different from the other Technology Module projects because the learning goal was already sort of defined for us: it's specifically about teaching CT/CS concepts. This is a much narrower focus than we were used to compared to other design projects we had worked on, but I could see that also being more realistic to design we will be doing in future jobs for clients and stakeholders who request topics and define parameters. When we already know what concepts to teach, the focus then shifts to how to make those concepts explicit in the design.

• Invitations are important - The idea of the "gentle introduction" for CT/CS activities is something that came up a lot in class readings and discussions. This is because computer science and programming have a reputation of scaring off learners with perceived low self-efficacy in those disciplines. This is a phenomenon for seemingly all of STEM, but especially for computer science. Sufficient, obvious scaffolding and authentic problems are design elements that can make an activity seem inviting rather than intimidating.

• Learning programming vs. learning through programming - I am one of those people with low self-efficacy in computer science! So I was concerned about having to learn how to program for this course and for the project. But instead I discovered that a computational environment for learning is one where students learn CT skills and concepts through programming or physical computing. It is not about learning the nitty-gritty of syntax. Nonetheless, students will still be learning how to think like a computer scientist.