Saturday, April 1, 2017

Getting More Students Engaged with Programming

I love the new project that I gave students on this Typing Game.  I love that every student is doing the "same" thing but it is different.  My students who were doing Python can do it, my students who were doing C can do it, and the students using App Lab can do it.  It's awesome.

There are 3 things I did that I think helped with student engagement here:

  1. Shake up the group dynamics.  I forced all students to show their thinking on a white board space first.  It made students formulate a plan, got students off their seats, and ensured that everyone had access to the ideas.  There is something about physically re-arranging spaces that causes a disruption in student's actions.  By making them move, I could shake up the dynamic.
  2. Create a space that promoted collaboration.  I was able to bring in larger monitors.  Thanks to a colleague who wasn't using them, this was HUGE at the end of the project when students are combining code and working out kinks.  I had students who worked on a larger display in the library the whole time which worked for them.  Ideally, I think if every group had that opportunity each day that would have been best, but it worked for now.


  3. The prompt.  Students had so much space to make it their own AND since it was a game, they wanted to make sure they could be fun.  One group got "done" with theirs and then started racing each other for who could get the highest score.  One person in the group said "We could add more words, or make it so that there was sound also, or a high score board, or... There is SO much more we can do with this!".  When two of them were racing, one student said "that's not fair 'remote control' came up like 3 times for me, and you had the word 'kid' and 'hat' pop up a ton, 'remote control' is WAY harder to do".  It's these sort of problems that now students WANT to resolve to make the game better. 
I gave students a week to do this and one thing that has come up is, when do you want students to have a "finished" project and when is it ok to be in more of a prototype format?  Up to now, much of the Apps students have created have been a bit more prototype-y.  I am still trying to figure out what the pros and cons are for each.  What happens to engagement?  How does it help them with programming content knowledge?  How does it change the UI part of the app?  What value is there in making sure that users actually know how to use the app? Etc.

Also, now I need to figure out a way to structure the share-out.  I think I want students to demo it for students and then also play each others and give feedback.

A New Project - typing game

I had an extra week of time for my AP CSP students this year.  I wanted them to explore the Post-AP database unit, but I knew doing more "stages" wasn't the right approach.  The stages are a little too quiet, not enough collaboration, and students aren't always super motivated to get it right.  They are good, but I didn't want to come back from spring break and put them on that.  

Instead, I decided to have students make a game that would have a high scoring screen which would force them to get used to creating and reading a database.   This would get at the database content without forcing all students to do all stages of the database unit.  Realistically, I think most students would need to do the stages to be successful in the task, but by giving them the task first, they had a motivation for wanting to learn how databases work.  Additionally, students LOVE making games.  Games usually have winners or losers, so a winner board screen is a not a "forced" concept.

The difficult piece is that students just finished an independent open-ended project. SO there were TONS of games that students had already made so I needed to find a new type of game that the project revolved around.

After brainstorming with KSTF's POET (Principal Officer of Educational Technology), I decided that a "typing game" would be a good vehicle for students.  Thinking of the "learn to type" games out there, students could design a game that tested how well someone could type and then score that person's abilities. 

I started looking into creating the database, I felt a little unprepared myself and a little concerned that one week wouldn't be enough time for students... SO... this was the prompt I gave students:

To get a C it MUST:
- Be play-able
- Have scoring mechanism
- Have a way to "end" the game (you shouldn't be able to play forever)
- Use two functions that are used to create a third algorithm*

Anything else - is the Razzle Dazzle Factor.  Consider:
- Top scorers screen
- Different ways to check if the input is correct
- Animation of the words
- Using colors to describe if a person got something right or wrong
- Timers
- Different levels

The starred requirement was just so students get a feel for how they need to write up their "Create" task and to force them into using functions a bit more.  

This "rubric" was intentionally designed to give students freedom and encourage divergent thinking between groups.  The "rubric for a C" idea was something I learned from  Rebecca at a code.org conference.  I actually really like it, especially for this class there is no "cap" to student creativity AND it keeps my trolls going.  It ensures that students are constantly working in class and pushing themselves. 

Students needed to work with at least three other people for this project.  I am excited to see how all of their projects will be "the same but different" when we are all done and I think students themselves might be surprised to see how other teams solved the same problem as themselves.