Skip to Content

Student Learning

« Reflections
2 replies [Last post]
David Bernier
Member

I have seen many Scratch projects recently in which students are doing great work, but I am not convinced that the students deeply know the underlying programming concepts. I am afraid that students may "do" but may not really "know."

What should students "know" as a result of playing with and learning Scratch?

How do we know that they know besides looking at a program that they create? Are there other ways to assess their learning? What questions should we be asking/investigating?

I really want students to internalize the powerful programming elements that are available with Scratch and am looking for ways to make that happen. Any ideas or suggestions are welcome!

Replies
Bernd Gärtner
Member

Hi David,

I share your approach; I want the students to understand the concepts. That doesn't mean knowing the "big words", as Karen puts it, but being able to apply the concepts in new situations. Some minimal terminology is still necessary, I think, in order to enable students to help others and explain what they have been doing. Terms such as "conditional statement" are for the teacher, the students could be taught to simply call it "if-block".

Now, how to make sure that they have understood the concepts? I'm currently preparing a course where I will try the following: I'm preparing a game where all sprites except the hero are already fully programmed. The students must program the hero themselves. Every level is clearly associated with one concept, and in order to get through the level, students must program the hero according to this concept. Example: a taxi arrives, and the hero must board it. Solution: go to taxi in a forever loop. The taxi in turn checks whether the hero indeed comes along when the taxi pulls out. The necessary new  concept at this point (forever loop) is learned through a specific handbook chapter which explains it and contains exercises.  The idea is that the "master exercise" (get through the level) acts as a focus: during the regular exercises, students can play and try this and that, but to get through the level, they really need to understand and apply one particular concept, otherwise it's "Game Over".  In order to avoid that students blindly copy their solutions from the regular exercises, there is always a little twist that they discover only when the game goes on. In the taxi case, the taxi stops at some point, the hero must get out and reach a specific entrance area on the stage.  For this, they need to rewrite their forever loop into a repeat-until-key-pressed loop (same handbook chapter), sequenced with a goto x y (previous handbook chapter). 

I have no experience with this setup yet; all I can say already is that the programming effort on my side is rather high (but it's fun...). If it works out well, I will certainly share the resources.   

Karen Randall
Member

Considering your question of when or how to introduce/go deeper with programming ideas, as an elementary teacher without programming background, I appreciate Scratch specifically because it gives me and my students access without requiring the deep knowledge you reference.   In a game-making elective with 4-6th graders last fall, I did go to the Design Team's handout of concepts embedded in Scratch and tried out referencing some of them every so often.  I have to say, I expected the kids to feel cool about using a term like "sequencing,"  or "conditional statment" but instead they weren't terribly interested in the big words, this group any way.  They could do the processes, as shown by their projects and their ability to help others when stuck, and that was what was interesting to them.  You have me thinking more about how naming what they are doing and helping them categorize their processes fits in.

 This topic is close to one a group of us is meeting on-line to discuss on February 7.  If you are interested in joining in, send me a message.