Blog

Articles from members of the Computational Thinking for Life group

Moving from Coding Club to Classroom (Part 1)

Some initial notes on my experiences bringing coding to young learners in a mix of casual, informal, and classroom environments

by Glenn Strong, 1st March 2016

Over the past four years I have been involved in teaching coding and computational thinking to primary school children in the Dublin area. It's been going well enough that we now have most of the 300 students at a Dublin primary school learning programming and creating their own interactive projects in Scratch and Scratch Jr.

Over the past three and a half years we have developed this in three main phases, from casual Sundays around the kitchen table, through an after-school club for coding, to our current model of having one "scratch lesson" per week for every child from first class up. We have relied along the way on a dedicated core group of about six or seven volunteers, and another half dozen or so who have been available to help out occasionally. This group of volunteers have been drawn almost entirely from parents in the school, and we are currently making plans to help this effort grow beyond something that relies on finding enough selfless volunteers.

Casual efforts

In the spring of 2012 a friend of mine invited me to join him in introducing his (then very young) children, and some of their school friends, to Scratch; with some of the youngest kids being about five, having another adult around the kitchen table seemed like a good idea. Over the next eight or nine months, broken up by summer holidays, we would meet up fairly regularly to help the kids develop their ideas for games and animations using Scratch. We had a lot of fun, made some creative projects, and we all became rather enthusiastic about the potential of Scratch. Since the kids all attended the same local primary school is seemed natural to want to take things further.

School clubs

In the spring of 2013 two of the parents, Ben and Pearse, approached the school to offer an after-school activity in programming. The school offers several club activities and we would be able to make use of a classroom for the club. 

As I recall we thought we might get eight or nine kids interested and we could do an hour of Scratch a week with them. We kept the enrolment to fifth and sixth class (In the Irish system this means roughly ages 10 to 12, the last two years of primary school). Fifteen kids signed up, and we asked as many as possible to bring their own laptops. Hopefully we would spark an interest and they might be motivated to continue exploring themselves. 

We were generously donated some old company laptops that were being retired, so we knew that everyone would have a computer. Ben and myself talked through some ideas for a syllabus, and Ben put together some projects to introduce basic concepts in Scratch. As a non-parent in the school I intended to come on board for the term to give some advice and help with the organisation of the lessons.

Over the next two years we ran the club four times (in the Autumn and Spring/Summer terms, following the model that the school uses for club signups). Interest grew so quickly that we found ourselves being prevailed upon to offer more than one club session a week, and we even added an "advanced" class for kids who wanted to push things further, trying our projects in Python, JavaScript/HTML, using robotics kits, and the like. This put quite a bit of pressure on our volunteers, but we were lucky enough to be able to recruit a few more dedicated people who would give up their time to support this.

In the classroom

We had a successful after school activity by now, but it relied completely on the availability of our volunteers. If we wanted this to be sustainable - and we all agreed that in the Irish context where programming and computational thinking are essentially untouched in the syllabus, we did want that - we had to do something. We were also ambitious enough to want to involve the children in the school who had not been able to take part in the coding club but who would still benefit from some time learning computational thinking concepts.

Happily and we had managed to generate quite a bit of goodwill in the school from our activities, and in the spring of 2015 we proposed to the school that we drop our after-school activities (at least for a while) and instead bring what we thought of as a highly successful scheme into the school day.

The school undertook to provide us with 40 minutes a week in each chass, and some hardware support. Not all of our volunteers from teh after-school club were able to make it in during the school day, but enough were. with 8 volunteers we were allowed to run an 8-week pilot that has been extended now to cover the remainder of the school year.

This has run long, so in the next post I will recap some of the more important lessons we learned along the way and provide some of the syllabus material we assembled (some newly written, much of it gathered from material available on the web)

Programmers are Learners too

The thinking behind Scratch is applicable beyond young learners...

by James Crook, 12th December 2015 

Scratch is a programming environment for learners. Its microworld of sprite animation goes a long way towards that. The world of moveable shapes and interaction invites purposeful exploration. The remixable examples inspire and show how.

I’ve enjoyed seeing children learning Scratch become more numerate as they use newish concepts in their own projects. Negative numbers, “move –1”, give the negative numbers purpose beyond “to please the teacher”. I’ve seen children who knew for sure what 0.5 was but were guessing when it came to 0.1. In making their animations run smoothly, a tenth of a second was the natural step. Smaller decimals now had purpose. The students could see the difference. The satisfaction of using “wait 0.1 seconds” to solve a problem seemed to add something that went far beyond looking at a picture of a pie divided into ten slices.

 

Jumping Sprites in Scratch

In Scratch, learners are well supported in their learning by the IDE (Integrated Development Environment). Learners still can make mistakes, but many of the minor trip-ups that can floor a learner can’t happen, by design. Kölling talks of intrinsic and accidental complexities. Scratch avoids many of the accidental barriers to learning, such as the need for semicolons or for matching brackets. Importantly the students still learn the intrinsic content, that the language statements are distinct and in a sequence, that certain structures can be nested.  The IDE makes that structuring clearer.

The affordances of Scratch, particularly its visual block-based drag-and-drop nature, are often singled out as making Scratch suitable for young learners. This diverts attention away from a broader perspective. Scratch has been designed for learners. Professional programmers are learners too. Learning is a core activity of programming. Professional IDEs have affordances to enable productive coding. Learning does not seem to be the main focus. The lens of IDE as a learning environment could add a lot of value.

Beyond routing around many accidental complexities, Scratch provides support for higher levels of learning. It even includes some scaffolding for the learning of Newton’s Laws. Scratch has a “jet-pack-girl” as one of the built-in scripted sprites. Simpler sprite behaviours lead up to this. The 'minor' detail that Scratch makes doing two things at once easy means that a ‘jump’ turning into a parabolic path is very natural. Support for learning is deep in the language and IDE design. 

Professionals too need scaffolding of their learning. Many programmers experience a battle to get their heads around monads in Haskell. It can be argued it’s not the IDEs job to be the tutorial.  Learning can happen outside the IDE, on a tutorial website. But learning monads is about trying them out rather than just reading an exposition. The language and IDE design can promote or hinder that hands-on constructionist learning.  From Monads to Marzullo's Algorithm to Maximum-Entropy Image Reconstruction, to Maintainance of existing code, a large chunk of professional programmer's time is actually spent learning. Programmers must master a lot of intrinsic complexity in addition to the accidental complexity. Scratch shows that IDEs can help with both the accidental and with the intrinsic complexity. Perhaps it is time that IDE designers took a deeper look at learning. Perhaps professional IDEs should have their equivalents of the jet-pack-girl.

 

The Hidden Value of Scratch

Untangling the foundations that make Scratch a success...

by James Crook, 19th October 2015 

Scratch is a visual programming language widely used in coding clubs and schools. I have organised and mentored at many CoderDojo sessions where Scratch was used.  It works well in this role.  There are reasons for this in its design.

I mentored at one particularly memorable session at University College in Dublin. The students, aged from 7 to 14 were new to Scratch. I remember a Japanese girl who soon had butterflies flying around on her screen and changing colour as they did so. She put her hand up because she wanted to make them not all change colour together. Her quietly smiling in delight at getting the computer to do exactly as she wanted is something I won't forget. I remember a student who had the beginnings of a game, and to solve a problem in it he had for himself created a loop within a loop, correctly doing what he intended, in this his first session programming with any language ever. I also remember too my very mixed feelings about a Scratch project, by a ten year old girl, that was a gory story built around a drive-by shooting.

 

Scratch is an enabler for creativity.  It lowers the threshold for writing code at all.  What are the design features that make it so successful?  

These are my thoughts so far:

  1. Classroom tested: As a programmer I see many details in Scratch that would simply not be there without actual classroom experience. If you drag a block into the costumes tab, Scratch switches it to the script tab.  That's where the block belongs. You can drag a block back into the palette to ‘put the brick back in the box’, rather than throw it into a bin. That's what many beginners expect.  The order of items in the palette is not alphabetical. The most useful blocks are first. The 3D look of the blocks and curved corners, the choice of colour palette, the background striping, they look good, they work, and they have clearly all benefited from the classroom testing.
  2. Appropriate Microworld: The Scratch microworld of moving sprites is great for learners making games AND for story telling. As part of supporting that microworld, learners don’t have to go outside Scratch at all.  They can design new sprites in an editor in Scratch. That's part of the Scratch philosophy, 'batteries included'.  The microworld being for learners also informs the choice of blocks. Often used and harder to write operations such as “if on edge bounce” and “if touching” are already written and already packaged up as blocks.
  3. Closeness to text: The design of a visual programming environment, especially if using connectors, can throw away the structuring that has been developed over time for text-based languages. Scratch instead reinforces it. If you fade out the coloured backgrounds of the blocks, and variations on Scratch such as Pencilcode actually can do this, you get a perfectly readable well formatted text program.  Blocks are text in disguise.  The beauty of using blocks to construct text is that they dramatically reduces the opportunity for 'trivial' errors of syntax or spelling.
  4. Remixability: Scratch comes with examples to explore.  Additionally it has small scripts such as ‘jump’ attached to sample sprites. Scratch makes it very natural to remix code at the sprite level, without requiring any abstract knowledge of classes or libraries.
  5. Semantic Colouring: Professional programming environments have syntax colour highlighting. Scratch has an eclectic and useful hybrid of semantic and syntactic colouring along with type-based shaping. For example, boolean constants are green and have pointy ends.
  6. Systematic Shift from Keyboard to Mouse: You drag and drop blocks.  You need the keyboard surprisingly rarely, and it could be made even less with an approach like Tangle. The actual values of some blocks are auto-filled, e.g. with the current position of a sprite, keeping hands off keyboard.
  7. Discoverability: The palette in Scratch, the box of blocks, is a huge asset for exploratory learning. The blocks are named so that they do what they say rather than having abstract names like ‘map’ or ‘typedef’. You can drag blocks onto the script area, click to try them out and see immediate visual results. 

 

Are these thoughts getting to the core of the design features that makes Scratch a success?  I'd welcome other perspectives, elaboration and other ways of looking.


Richard Millwood asks whether a jigsaw approach that scales to professional use may be possible.  Experienced developers are constantly learning too.  The numbered points above, point 3 in particular, make me think that that possibility is very worthwhile prototyping and iterating on. Mark Guzdial in his blog asks about the qualities that make a language learnable, whether specifically for learners or not, how the process of language design can learn - with some fascinating responses from Scratch developer, John Maloney.  There is a lot of hard won knowledge in code like Scratch.  I think professional programmers, and I include myself here, may have a great deal more to learn from code refined for educational use than they at first think.

Diagramming computational thinking concepts

There are many ways to define a terms, but I like diagrams to try and add layers of meaning to the relationships - this is a draft attempt to get at the concepts in computational thinking

by Richard Millwood, 17th October 2015

diagram of Computational Thinking conceptsThis diagram has some of the nature of a Venn diagram, where the overlapping shapes are intentionally devised to indicate where the concepts belong, so 'object-oriented' belongs in the intersect between computational thinking and computer science, whereas 'binary' exists outside of computer science, since it is encountered also in mathematics.

The central circle represents a famous quotation and the title of a book from Niklaus Wirth, which I have found helpful in defining a central idea in computer science, but for computational thinking, I propose the broader notion of problem solving + design = solutions.

What do you think works and what doesn't with this diagram?

Document Actions