DDR re-make - brainstorming and a gallery walk

I started this lesson by having students brainstorm how they would build the app.  In groups they had to answer the questions:

1. What would the UI include?
2. What variables do you think you will need?
3. What functions will you need?

In my first hour, I had them do this as a table on mini-whiteboards, but inevitably one person did the majority of the writing and the other students couldn't really see what was being written since the board was the opposite direction of them.  SO, I moved to a "Harkness" style method and had students in my next class do their work on the whiteboards around the room which got more students involved in the brainstorming process.  Then we did a gallery walk so they could look at other students's work.  

Here is some of the work:

I actually loved this structure.  All students were up and engaged, they were making sense of eachothers' ideas, and problem solving.   I had created a UI for all students to start with along with comments for what the code should include.  I found this structure useful during the ColorSleuth app so we all had the same ID names while we were programming.  I had also seen this commented out skeleton in some of the MOOCs I have been exploring and found it to be a good way to almost literally put in scaffolding in place.  I didn't show this to students ahead of time, but I almost wish I would have given them a screen shot of the UI so they could focus a bit more on logic during this time.  Here is what the starter document looked like.

Taking time to do the gallery walk was important for the class, too.  Doing this I learned, from a teacher perspective, that the problem needed to be well defined if we were going to do this as a class.  Things like, how scoring would work, does the pattern get longer over time, etc. are all questions for which we needed to agree on answers.    I think the brainstorming may have been even more useful had we developed these answers before going to the whiteboards.  BUT, I also think we could have introduced the big problem of "make a Simon game", had students develop these answers and questions themselves, worked for a few days, and then done a reveal of the different approaches to the problem.  For the stuff we were doing together though, we wanted to have the same vision.

A lot of students also brainstormed things that I had decided we wouldn't focus on together (like score, for example).  It was helpful to write these down as "possible extensions" inside the code so students could work on that extension at the end of our time together.  By the end of two days, this is what our program looked like.

Our possible extension list got quite long too, including:

// - Make it auto-check the solution after you are done hitting the keys

// - Make the "Play Again" button work

// - Make a cooler "you win/lose" screen

// - Make the pattern longer as the game goes on

// - Keep a score

// - Add other possible key presses

// - Add sounds

// - Make the pattern go faster as the game goes on

// - Make it wait for the series to play BEFORE someone can enter arrows

// - Protect against trolls so that they cannot "check your work" BEFORE pressing the "start" button (since both arrays are empty, it will say the won)

I also learned that by brainstorming with other people, students developed some creative and elegant solutions, solutions that I hadn't considered when developing the code myself.  This makes me even more excited to try the "big problem" approach later on in the course.

Next, I want to use this problem we did together as a lens for the writing involved with the Create task for CSP.  We should be able to answer a lot of the questions about abstraction and development with what we have done here.