Week 2: User input and conditions

This week we introduced students to the concept of "user input". This allows us to write programs with which they and other people can actually interact, and is a vital early stepping stone in our curriculum.

After a quick refresh of our existing programming tools (ellipse, rect, fill), we started into the three main topics of week two.

  1. User input: This is a big subject so we started off with mouse button clicks. Once students had this part figured out we moved on to distinguishing between left and right button clicks, and using each one to do different things.
  2. If conditions: 'if' statements core to all programming logic. They allow the programmer to test if a 'condition' is true or false, and act in different ways depending on which it is. 
  3. We also introduced the "pointer base", a simple programming tool (programmed in-house by the Academy of Code team) that helps show the position of the mouse on the app window, allowing easier identification and placement of shapes on-screen. Most students find this useful, but especially those who might be struggling slightly with the co-ordinate system, or those younger students who simply hadn't come across it before attending the Academy of Code.
Eammon and the Tuesday class coding up Pumpkins

Eammon and the Tuesday class coding up Pumpkins

Other things we learnt:

Another basic function, background - similar to the fill command (and similarly allows students apply their knowledge of RGB colours from week 1!), this function lets us set the colour of the background of the window.

We also took the opportunity to get seasonal (if perhaps several weeks early), and students practiced their use of functions and co-ordinates by drawing pumpkins and ghosts!

Week 1: Shapes and Colours

One of the great things about Processing is how you can write just two lines of code and immediately have a shape appear on your screen. If you've never studied programming this might not seem like a big deal, but trust us when we tell you that this is a radical departure from how coding is taught to computer science students in Universities and Colleges. 

When I was in University (which is not really all that long ago, and I'm told not much has changed) we had to slog through literally dozens of lectures, tutorials and labs where all we did was input and output text. Only then did anyone even acknowledge the fact that actually, yes, it is possible to write programs which do more than this.

The merits of this approach are a whole post unto themselves, but suffice to say text adventures stopped being exciting in the early 90s, and we like to use a slightly bigger and more colourful hook with which to grab their attention. To start with they are given code to type in that looks something like this:

Week One, Step One: The journey begins!

Week One, Step One: The journey begins!

Then they hit the play button (that's the little triangle near the top left - no prizes for guessing what the square does). All going well, another window pops up that looks like this:

A circle! How exciting!

A circle! How exciting!

And that's a computer program!

There is quite a bit to talk about, even in those two lines, but when the students have gotten their heads around that much we add another element: colour. 

Colour is interesting because most students won't ever have needed to describe a colour in numbers (why would they, after all?). Moreover, what colour mixing they have done will have mostly been in art class in school, where they will have mixed paint. Computer colours obviously aren't composed of paint though, and in fact they mix in almost the opposite way.

Paint mixes subtractively, which means that if you keep adding different colours you'll end up with black. (My memory of art lessons is that inevitably any colours mixed indiscriminately ended up more of a gloopy brown, but probably I just gave up too easily).

Computers use light to make up colour, which mixes additively. Keep adding more colour and you get to (or near) white. The image below neatly sums up the difference:

How light mixes (on the left) versus how paint or ink mixes (on the right).  © Athabasca University / Wikimedia Commons /   CC-BY-SA-3.0

How light mixes (on the left) versus how paint or ink mixes (on the right). © Athabasca University / Wikimedia Commons / CC-BY-SA-3.0

We describe each of the component parts - Red, Green and Blue - with a number between 0 and 255. (The images above only show the 0 and 255 values, of course, but all shades in between are possible too. A total of around 16.7 million, if you were wondering, albeit a lot of them quite hard to tell apart). By using the fill command we can make subsequent shapes change colour. A very simple example, typical of what the students wrote in class this week, might look like this:

Note the lovingly precise comments - students are encouraged to comment their code from day one!

Note the lovingly precise comments - students are encouraged to comment their code from day one!

And it would output the beautifully simple:

This face doesn't look all that happy - possibly because describing curves is one of those things that's inexplicably hard. We don't start drawing curves for quite some time!

This face doesn't look all that happy - possibly because describing curves is one of those things that's inexplicably hard. We don't start drawing curves for quite some time!

All this means that by the of the lesson students are making coloured shapes and positioning them on screen using co-ordinates (younger students might be using co-ordinates for the first time). They've grasped the idea of parameters, and of functions. They understand the basic idea that computers execute instructions in the order given. They've also, almost certainly, had the experience of drawing a second circle in the exact same position as the first, wondering why they're only seeing one, and then laughing when they realise what's happened. Little do they realise that they've just successfully completed their first exercise in debugging!*

On top of this they've learned about how computers actually understand colours, and (somewhat unbeknownst to themselves) they've started internalising 255 as an important number (it's the biggest number you can store in a single byte, since you asked, and one which crops up almost constantly in computer programming).

All that, and 11 of our 12 classes still to go. Welcome to The Academy of Code!


*A lecturer of mine once made the observation that if "debugging" is the process of removing bugs from code then the process of writing the code should surely be known as "bugging". Not that it's ever likely to catch on, but I guess you could make the argument that the students were introduced to both debugging and bugging this week, which is really quite a lot to take in all at once. Thus far they seem better at the latter than the former, although the same could no doubt be said of plenty of professional developers.