Scratch and Etoys perfect together

A way to make make multi-player games and build your own Game Consoles.

PETS - People for the Ethical Treatment of Studends

Hello,  I am from PETS (People for the Ethical Treatment of Studends),  PETS is the largest students rights organization in the world, with myself as a member and supporter.

Like PETA, PETS focuses its attention on the four areas in which the largest numbers of students suffer the most intensely for the longest periods of time: on tortured obfuscated word problems, in the computation classes (under the benign name mathematics classes), and in what is commonly called "drill and kill" problems. We also work on a variety of other issues, including the cruel killing of enthusiasm, the spirit of inquiry, the question "why" and other "inappropriate classroom behavior" as well as cruelty to beautiful and powerful ideas. 

PETS works through public education, cruelty investigations, research, student rescue, legislation, special events, celebrity involvement, and protest campaigns.


(Idea spark from Dy/Dan and his post  These People With Their Dogs Wearing Bandanas unfortunately he was more concerned with the dogs, rather than the students, must be one of those PETA people.

             

Well we'd like to do all these things, but right now its only me.  Please join me and show your support by commenting below?
If you can add a link for an idea that can help protect our students.

Scratch Draft Curricullum Guide (Session 3 - Programmed to Dance)

 I used Session #3 from Scratch Curriculum Guide Draft in my class with kids ages 10-16.   This is where kids program other kids to Dance.    The "Bosses" watch a short video of someone dancing and then program the "Bossed" to Dance.  The video's provided by the Scratch team are really well done and thought through.

When I first showed the "Bosses" the videos, the reaction was no way, this is going to be hard.  I must admit I had the same reaction.  I (and I think the kids) figured that the video with Mitch would be possible, but some of the later ones would be too challenging.  Well I was wrong (love when that happens, I learn something new :)

The kids did great and were able to program each other in a relatively short time.

One thing I changed from the Draft is I had the  bosses and bossed switch.  Show I would show the first video and A would program B, then I would have B program A.  So they all got an opportunity to see both sides.

I asked the question, "How is this like programming?"  Which is similar to "How does this activity relate to Scratch?"   Below are some of the comments from the students:

1. We didn't know what was in the mind of the programmer.  
2. We had no idea what they wanted us to do.  
3. We had no "insight" (Note: I also have them taking the Coursera CS101 course on their own in a "flipped classroom" type approach.  One of the early comments in the course was that the computer, unlike a human has know insight into what you mean).
4. We can only use words.

After class I realized one of the questions I should have asked is "How is this NOT like programming?"  I will try this next time.

I also used this a second time and noticed how some of the moves are symmetrical (especially in Dance1).  I pointed this out to the kids (tried to do so through questions) and asked how are these moves the same and different.  Which led to the realization its the same basic move once with the right hand and once with the left hand.  This then lead to a short discussion on how we can have a common set of instructions used by different body parts/costumes/objects.  In a future version of the class I would like to try and point this out immediately after Dance 1 and see how many kids "get the idea" and use it for Dances 2 and 4. Dance 3 doesn't really lend itself to this idea.

For homework, I am having them create a "Dance" program, where they take pictures of themselves in different dance positions, "green screen" their bodies out of the pictures and then program each other to dance.  I am also using Scratch connect and Etoys so they can create a "game controller" in Etoys to control the Dancers and can have a dance party on one screen projected on the wall, each student controlling their own dancer using Etoys (via Remote Sensor Protocol).  Can't wait until Makey Makey comes out so I can try incorporating that.

Note: I had a class before this where we did "How to Train Your Robot"  using Dr. Techniko's hand out and having them program their parents.  Not sure how much this impacted how quickly/easily they were able to program each other.

I really like your approach of having kids "step away from the computer and no one gets hurt" approach.  I try to do this a lot, partly so they can get in touch and reflect upon the knowledge they have in their own bodies and also to give them different context for experiening the same/similar concepts and ideas,

What do I want kids to learn?

Great, talk on Assessing Computational Thinking by the Scratch Ed team. 

I was sorry I missed the live version, but Memorex is just as good

(okay I'm dating myself, see video below if you don't get the reference)

Here are some of my initial notes and thoughts:

How do you Assess? 

Damn good question and I LOVED Karen's line: 

"Some of the things that are easiest to evaluate are not the things we care about."  

The problem is that the things that are easy (ie: quick and inexpensive) and "fair" (standarizable across a wide population) to assess are not what I care about.

What do I want kids to learn:

• Certain Habits of Mind that will serve them well in life and make them better citizens.
• Confidence that they can create things they care about.
• Help others
• How to work with others and build a team
• Explore different ways of Knowing/expressing something
• Write it in Scratch, JavaScript, programming another person, etc.
• Balancing Churchill and Twain
• Never, Never, Never Give Up. - Winston Churchill
• Try, Try again, then give up. There no sense making a damn fool of yourself - Mark Twain
• NOTE: I like giving kids conflicting suggestions.  First it forces them to think.  Second, It requires them to look for appropriate balances and realize things are not always black and white.
• Try understanding “Why it works” (especially after "hunting and pecking" until you get an answer)
• Look for connections
• Things I look for and questions/comments I ask/make toward this end.
• How is these two things the same and how are they different?
• How else could you do this?
• Do the simplest thing possible to make it work. Then you can refine later.
• Its okay to make mistakes.
• I expect mistakes. In fact if you aren’t making mistakes you aren’t trying hard enough.
• What can you learn from that mistake?
• Learn from the mistakes of others. You don't have time to make them all yourself.
• Wow that’s cool, how did you do that?
• How did you come up with that idea?
• What did you try that didn’t work?
• If a student finishes early, ask them to help someone else. Part of this is training them to help in a way, that builds up the other students and tries to question them toward an answer, or provide examples or small pieces of code they can look at and try and figure out. That said, sometimes, doing it for them is appropriate.
• Make mistakes on purpose and see what happens.
• Done with text based languages so they can see the error the compiler produces and get a better understanding and appreciation of the error messages.
• Give them: Wheres the bug problems.
• Read their code out loud to themselves and imagine/visulize/kineticize (move your hands/body to mimic what the code is doing, good for drawing shapes projects).
• I tell them reading it out loud helps you slow down and see what your code is really doing, which is often NOT what you want it to do.  (“Do what I meant, Not what I said”)
• Its okay to copy (re-use and hopefully re-mix)
• Can you make this a re-usable compoment that you can use in other projects? Should you?
• How is this like (fill in the blank) and How is it NOT like (fill in the blank)
• Example 1: Scratch Draft Curricullum comparing programming each other how to Dance with how its like programming in Scratch.
• Example 2: How are these programs, which all do the same thing, but are written in different languages (one in Scratch, one in Java Script and one in Squeak) similar and different?

I also want to comment on the question that came up towards the end

How do you encourage kids to be bold? (and not afraid to ask questions or make mistakes)

But that's another post.

Avalanche - Make your Own Game

In response to an email thread on Natural Math (math game design).  I decided to try and create Avalanche and Galton Box games in Etoys.  The goal being not just another online version of games.  But a tool where kids can build and then play their own games.

Here is the Avalanche version.  I will demonstrate the Galton Box in another post.

Here is a sample game board.  Simply drag and drop a marble above the board and it will start to fall until it gets caught on the triangle shaped end of a gate or hits the bottom of the playfield.















The following is a blank board where you can drag and drop gates onto the playfield. Gridding is turned on to help you align the gates.  You can turn it off when done.  You can also drag in marbles (and color your own).








Here is a demo of the project:

You will need Etoys 5.0 to play them, you can download it here (its free and open source).
The game can be downloaded from here and if you have Etoys 5.0 installed played in your browser here.

Of course the best thing is to get the kids to step away from the computer and truly construct their own versions, using something like the technique below (or any others they can think of)

Now what would be really cool would be to have them construct their own Adding Machine like this:

Dr. Techniko in Spanish

Sample Handout for Workshop in Uruguay

How to Train Your Robot

So I tried using Dr. Techniko's How To Train Your Robot  with about ten kids 10-16 years old.


I have done similar things in the past with kids based on seeing Seymour Papert videos where he has children pretending to be the "turtle" and the other children give the commands.

Besides being a lot of fun, I really think the kids learned a lot and got a feeling of success.


Here is a list of some of the things kids came up with:

1. Created Looping techniques
1. While walk
2. Repeat 4 times: walk 2ft
2. Came up with the idea of using coordinates to program the Robot (ex: goto 1,0 - an actual good use of goto :)
3. Measured the whole path, drew models of the path with measurements and planned out everything on paper before writing the program
4. Came up with various sensors (ex: sense Obstacle)
1. Special thanks to those who improved the sensors and had me stop BEFORE I hit the wall!!!
5. Used the idea of Homing Beacons
6. Had two styles of programs one where you loaded all the instructions into the Robot, then the Robot followed the instructions. The other interactive where you guided the Robot with voice commands.
1. Question, in the above two examples, where was the "intelligence?" In the programmer or in the program?
7. Came up with the idea of functions or methods. Higher level commands (aka abstractions) to get a robot to do something (ex: walk = left foot forward, right foot forward).
8. Not only did folks walk up the ladder of abstraction as in item 7, one of you walked down the ladder of abstraction and created more detailed command for left foot forward, explaining what each part of the leg had to do to "move left leg forward"
9. Last but far from least, you made mistakes!!!! Woohoo!!! Yippeee!!!  If you don't make mistakes, you are not learning. Of course that's only true if you learn from your mistakes.  But the best is to learn from the mistakes of others, you don't have time to make them all yourself.  Feel free to watch me for mistakes, I am a great teacher that way :)

General Techniques for facilitating learning:

• Clap, Clap, Clap - you need this to get their attention and bring a room full of engaged noisy kids to silence and get their attention to make a point or share a really cool thing some kid did.  I generally start my first class by staring at the kids and not saying a word.  I do this until they start to notice, quiet down and are all looking at me. Then I clap my hands three times and wait for them to repeat. If only a few of them do, I shake my head and clap three times again until all the kids do it.  This is usually enough for them to get the idea.  I will then do this again when they are not too distracted to get them in the habit.  Usually only takes a few attempts and they respond each time after that.
• Give the concept the kids come up with a name. Allow the kids to be the teachers.  When a child does something worth noting, do the Clap, Clap, Clap, then say what a great idea had, she ....  Be specific in the praise, not "oh Mr. Steve is wonderful" 
• Catch kids doing things you can compliment them on, ideally in front of the whole class. Once the kids see you complimenting and praising one child they all want it.  Better yet, don't wait for kids to be successful, orchestrate their success. 
• Lower the Rope - If a task is too hard for some children, give them an easier task. The goal is to make them successful, not to frustrate them.
• Raise the Bar - Plan on tasks for kids who finish quickly or get the solution fast, so that they are challenged and not bored.  If appropriate and they could help teach, but you need to train them to teach in a way that builds kids up and helps make them successful.

Things I would do different next time.

• I would spend more time in the beginning letting the kids program me, so I was sure they all got the idea.  
• I would also let them program me "interactively" (responding to each command as they say it, rather than having them tell me a bunch of commands at once).  
• I would have "lowered the rope" for certain kids and had them program me to walk a straight line to get to a wall, while others were working on the more "complex" challenges.
• I also like the idea from Dr. Techniko of asking kids to program their parents to do something silly or funny.

Why Is programming an unnatural activity?

For my P2PU course I have been looking at "Novice" programmers.  And in one of the papers we were asked to read Mark Guzdial asks:

“Why?” Is programming an unnatural activity? 

Could programming be made easier in a different form? 

Could programming be taught in a different way that makes learning easier? 

Or maybe we just have no idea how to actually measure what students know about programming. (1).

My main problem with the Guzdial paper (this was more my problem than a problem with the paper) is I felt it didn't provide enough details or specifics on "Why it is so hard to learn to Program?"  I need specifics and examples to get my head around things.  Roy Pea, was a great find and perhaps not surprisingly (for me at least) the Resnick article was very useful. 

Pea (et al) talked about three classes of bugs:

1. Parallelism Bugs
2. Intentionality Bugs
3. Egocentrism Bugs

Parrallelism Bugs

The Parallelism Bugs, is basically an "assumption of different lines in a program can be active or known by the computer at the same time or in parallel".  For example, look at this code:

If (Size == 10)
    print "Hello"
For Size in range(10):
    print Size
  

When High School students. in their second year of programming course, were asked what they thought the program would print 8 out of 15 predicted "Hello" would print after "10".

Intentionality Bugs

The Intentionality Bugs, is the idea in the child's mind that "the program has goals and knows or sees what will happen elsewhere in itself."

Egocentrism Bugs

The Egocentrism Bugs, stem from the belief that there "is more of their meaning for what they want to accomplish in the program than is actually present in the code."  Funny, I see these kinds of bugs all the time in my code and those of other experience programmers :) 

The Super Bug

He concludes that all these derive from the Super Bug:

The idea that there is a "hidden mind somewhere inside the programming language that has intelligent and interpretive powers."  Not surprising since most of kids experiences are with semi-intelligent beings (aka Parents)

MultiLogo: A Study of Children and Concurrent Programming - Mitchel Resnick

Resnick, noted that: 

"This sequential paradigm does not match the way the real world works: people and animals act in parallel, objects interact in parallel. As a result, many real-world activities can not be modelled in a natural way with sequential programming."

He developed a concurrent or parrallel version of Logo (Multi-Logo), so the kids had a language/environment that more closely matched their view of the world.

SideNote: I used to think and say that Concurrent Programming was really really hard.  I had plenty of evidence to back this up and had heard and read much smarter people than me saying the same thing.  Then I encountered Etoys (and later Scratch) and started teaching these to kids.  And realized that Concurrent Programming is actually easier (although you do have the added complexity of syntonization issues) .  The problem was not the topic/idea, it was the language we use to think about it.

Resnick noted that "In general, students appropriated the idea of agents sending messages to one another quite easily."  Too bad we don't teach more Smalltalk.

He identified three types of bugs specific to concurrent programming:

1. Problem Decomposition Bugs
2. Synchronization Bugs
3. Object Oriented Bugs

Problem Decomposition Bugs

"These bugs arise out of students' difficulties decomposing problems into actions to be performed concurrently by multiple agents."  Here there are two types of decomposition:

1. functional decomposition - dividing a problem in to simpler sub-problems (what needs to be done)
2. agency decomposition - dividing the functional pieces among different agents (who does it) 

Synchronization Bugs

"These bugs arise out of students' difficulties coordinating and orchestrating the activities of multiple agents."

These bugs he divides into two type: Unintended Sequentiality and Unintended Concurrency. In these cases the student expected Sequetiality and got Concurrence (or vice versa).

It seems that in designing Multi-Logo to deal with synchronization he provided two mechanisms: ask and demand.  Where when you "ask" an agent something (ex: flash light -  for 20 seconds) the request is queued up to be executed in the order received. When you "demand" the agent interrupts what is going on to perform the request (or it might simply put it at the head of the queue, I am not sure).  It is interesting, at least to me, that Scratch, developed later by Resnick and his team,  got rid of the ask and demand and went with a "broadcast" "wait" and "do for X seconds" to allow for synchronization.  I believe this simplifies and avoids a number of problems for novice programmers.

Object Oriented Bugs

"These bugs arise out of students' confusion among different types of "objects"  Multi-Logo has multiple types of objects: agents, turtle, and on the Lego Interface box (think early NXT) ports and sensors.  Part of this confusion may have been the overloading of "halt" which for an agent, 

Another quote for Guzial: 

• " our current programming languages do not allow people to program the way that they think about the tasks"
• Section: "Making tools better by shifting to Visual Programming"
• "having students build their own visualizations had significant impact on those students’ learning."

Resnick's Lessons Learned

"It is a good idea for students to "play agent"--that is, act out what each agent is supposed to do. This activity requires a group of students, each playing the role of a different agent."  I really like this approach with novices and often warn students "Step away from the computer and no one will get hurt".  Having them act out the program and program each other is a good way to do this. 

In designing Multi-Logo he realized he did not go far enough in parallelism: "An alternate approach, of course, is to change the design of MultiLogo to match students' preconceptions. For example, I could redesign MultiLogo agents so that each agent could do several things at the same time, in line with students' expectations of "excessive parallelism."  He later did have agents that can do several things at the same time.  

He also discussed the idea of design the environment match the students pre-conceptions. Would be interesting to find out what problems it solves (and those it doesn't) and what new problems it creates.

If you read this far, thank you.  And as a way of thanks, if you haven't already seen this it is a real treat.

Bret Victor - Inventing on Principle from CUSEC on Vimeo.

Lastly if you notice any "bugs" in this posts thinking, please comment and let me know.


References:

NOTE: If you have limited time, I would recommend reading (2) then (5), then for a real treat watch the Brett Victor talk (7)

(1) Why Is It So Hard to Learn to Program - Mark Guzdial 

(2) Children's Mental Models of Recursive LOGO Programs - D. Midian Kurland and Roy D. Pea (1985)

(3) Language Independent Conceptual "Bugs" in Novice Programming - Roy D. Pea (1986)

(4) The Buggy Path to the Development of Programming Expertise - Roy D. Pea and Elliot Soloway (1987)

(5) MultiLogo: A Study of Children and Concurrent Programming - Mitchel Resnick (1990)

(6) Programming Environments for Novices - Mark Guzdial (2002)

(7) Brett Victor - Inventing on Principle (2012)

What Do You Want Your Learners to Learn?

These are the questions for this weeks P2PU class

• Who are you trying to help?

D. Rillin Kill Age: 6 (going on 16)

Always wants to know why.  Finds the worksheets and seemingly arbitrary rules boring.  She does not understand math and why we invert and multiply.  Enjoys drawing and chatting with friends. Likes games and puzzles.  Her friend Sadie is home schooled and she wonders if that would work for here too, but her Mom worries about where she will get the material and books to teach her. 

Grandma Moses is concerned about her grandkids: Bela Bartok who loves music and composing, Ira Caull who loves storytelling and animation and her grandson Horatio Algebra (location unknown, but could be any number of places) who really likes math.  Her village just received a bunch of these new fangled laptops and she is wondering how her kids can use them to learn and better their lives.

I.M. Shirley Wright is a teacher. He is bright and likes to be the one who knows everything.  He now has to adjust to these computers in the classroom, which he has never used before and kids seem to learn faster than he does.  His main fear is that the kids will find out his middle name is Shirley and make fun of him.  He prefers they call him Mr. Wright.

What will they be able to do (or do better)

after learning what you're trying to teach them?

What I want them to learn depends on what I am teaching, but in general I strive for these three habits of mind:

1. Learn to test their ideas (and the ideas of others)
2. Get in the habit of reflection
3. To know (or at least try) things multiple ways

Now Greg asked us to be specific and to describe "the simplest task they care about."  I agree whole heartedly that kids learn best when its about something that matters to them.  The challenge is how can you teach something that matters to a class of 20 to 30 kids?  Perhaps some kind of self selecting set of options where kids learn programming concepts around different topics (art, music, stories and games) or one class where the different topics are taught and then during the class kids will have an opportunity to work on what matters to them.  The Scratch Curriculum Guide Draft seems to take the latter approach. I also like that the guide has "Reflecting" sections in each lesson. I have not used this Guide to teach a class yet, but will try to do so some time this year.

Okay so, Greg also asked us to be specific, so let me try to give a specific example of how I try to teach the three habits listed above.  So ...

1. Learn to test their ideas (and the ideas of others)

I will often say things that are obviously false (like "As we all know Sun rotates around the earth" or "The earth is flat").  Then when I get the stunned look on kids faces, one of them usually corrects me and says the Earth rotates around the sun.  To which I will respond, how do you know?  They will usually tell me their teacher told them or they read it in a book. At which point I will ask do you believe everything you read (or everything a Teacher says?)  I will then point out to them the obvious fact that if they watch the sky, they can see that the Sun is moving or how can the earth be round? Why don't people on the bottom fall off?  This also leads towards lessons on you can't always believe your senses (for which optical illusions are a lot of fun and I have them create some).

Okay, so how does this relate to programming and webcraft. Good question, I diverge a lot when I teach :)

If you read my other posts you will probably know that I use Etoys a lot (I also teach kids python and math).  Later I will try and post a video using Etoys to explain how I would teach the above three habits of mind.

How can you tell during the scope of your teaching that they've learned what you hoped to teach them?

Well I teach mostly homeschoolers and develop "educational" material for OLPC/Etoys.  In the first case when I work with kids directly I do not give final exams (or any exams).  I ask them to work on projects they are interested in and then ask them questions and listen. In these cases the classes are small at most 8 and I can manage it. Of course the problem is this does not scale.

In the case of OLPC users, I never see the kids who use the software, most don't have internet connections and even if they did, I am not sure how I would get feedback on their thinking, other than asking them to write about what they learned.  I could ask them to write two scripts to do the same, thing but that would be BORING.  This is a real challenge.

One potential way to deal with this (at least the reflection part) would be to have them do the Mathematical Shapes challenge and then have a page that shows them the scripts they wrote for each challenge. This would get them to look at what they wrote and I could ask them to what's the same and what's different about these scripts.


One final and I think important point.  Sometimes kids learn things which are NOT what you hoped to teach them but are important lessons anyway.  Its important to be open to different directions kids may take, even if they are not the ones you intended.  If they are going off in a different direction, it is most likely because its something that is more interesting to them, and thus they will learn.