Now that it’s school holidays I finally have time to think. Part 1 of my “Demystifying the dig tech curriculum” post went a little viral – as much as a post on a niche Computer Science Education blog can – and there were a lot of requests for Part 2, so here it is. Once again, all constructive feedback gratefully received!
It’s probably best to read Part 1 first, as I’m starting where I left off. This is the beginning of the next strand: Processes and production skills.
|Collecting, managing and analysing data||Collect, explore and sort data, and use digital systems to present the data creatively (ACTDIP003)||Collect, access and present different types of data using simple software to create information and solve problems (ACTDIP009)||Acquire, store and validate different types of data, and use a range of software to interpret and visualise data to create information (ACTDIP016)|
“F-2 Collect, explore and sort data, and use digital systems to present the data creatively”
This is another simple one, that F-2 teachers are already doing: Collect some data, like the hair colour of everyone in the class, or everyone’s favourite fruit. Then you can either graph it (simple pi charts, bar graphs etc), or draw infographic style pictures to represent it, like this (although you would, of course, include better labelling than this lazy Computer Scientist has! :):
This one explicitly says use digital systems to do it, so you would probably use a spreadsheet package like Excel or Google sheets.
“3-4: Collect, access and present different types of data using simple software to create information and solve problems.”
Another thing you’re already doing: collect some data, graph it using a spreadsheet program or some online tool, and try to answer questions like: What is the most popular fruit in class JB? Or better yet, incorporate it with some environmental sustainability and graph which class collected the most rubbish on Clean Up Australia day. And that’s a good one because you can graph it by weight or by piece count, or by rubbish type: wrappers vs bottles vs cans, for example. And you can then try to graph which class has made the most improvement to the environment – which type of rubbish is worst, and who has collected the most of it? Ok, I might be getting carried away here, but you can see how this goes. These types of activities always work best when they’re tied in with other things the kids are already doing, so that they can see the point.
“5-6: Acquire, store and validate different types of data, and use a range of software to interpret and visualise data to create information”
This is really the same as the examples above, but ramped up a little. The data above was all discrete, simple values that you can aggregate: 5 blondes, 4 brunettes, 1 redhead. Or 6 prefer strawberries, 3 prefer apples, and 1 prefers oranges. For 5-6 you could start collecting continuous data like heights that is a bit more complicated. If you graphed the heights of everyone in the class as a bar chart you would likely wind up with 25 different entries on the graph, so you need to aggregate them somehow, like 100-110cm, 111-120, etc. This is a frequency graph or histogram. You can still use a spreadsheet to graph this, or you can make it an art and communication lesson by getting them to draw pictures in drawing software like Paint on a pc, or drawing or whiteboard apps on tablets, that are creative but accurate – for example using relative size, or number of items to represent the different values.
Creating Digital Solutions by:
|Investigating and defining||Follow, describe and represent a sequence of steps and decisions (algorithms)
needed to solve simple problems (ACTDIP004)
|Define simple problems, and describe and follow a sequence of steps and decisions (algorithms) needed to solve them (ACTDIP010)||Define problems in terms of data and functional requirements drawing on previously solved problems (ACTDIP017)|
“F-2: Follow, describe and represent a sequence of steps and decisions (algorithms)
needed to solve simple problems”
This is our first encounter with the dreaded A word: Algorithms. You’ve actually already met algorithms in the form of recipes, LEGO instructions (which are particularly interesting because they are largely visual, not text based), and any set of instructions you’ve ever followed. Kids will be familiar with these too, so you have a starting point. Next time you do a cooking activity, talk about the steps you follow, the decisions you have to make – like: is the chocolate melted yet? If so move on to the next step, if not, heat it some more. Introduce the word “algorithm” for the recipe, and boom! – This line in the curriculum is nailed.
“3-4: Define simple problems, and describe and follow a sequence of steps and decisions (algorithms) needed to solve them”
Here the kids need to define a problem, like “how can someone find my desk from the door of the room?” and then specify the set of steps that someone would need to solve that problem. Then they can follow each other’s steps and see if they work. This is a fun one because you tell the kids to follow the instructions as dumbly as possible, to find problems with the algorithm. For example, if the instructions say “Walk towards the back of the room until you get to my desk” they will walk into any furniture that happens to be between them and the desk if they are really following the instructions blindly, the way a robot would. Similarly, if the instructions say “walk through the door” and the door is closed, there is a step missing that could result in a very sore nose!
“5-6: Define problems in terms of data and functional requirements drawing on previously solved problems”
To be honest, this one seems a bit strange in this context. To me it makes sense in terms of software design, but for Grade 5/6 kids it seems a bit of a reach. For kids programming in Scratch, Snap, or other visual programming languages, you can only really skim the surface of an instruction like this.
So I take it to mean that you need to lay out the problem clearly before you start to write a program to solve it. Spell out what you are going to do, and what data you are going to do it with – for example if a student is writing a program to draw a spiral, they might ask for user input for the colour and size of the spiral. This is their data. And functional requirements simply mean defining exactly what the program is going to do – in the above example, the functional requirements might be “draw a spiral in a colour specified by the user, with as many layers as the user asks for.”
The other part of this one is to relate the new problem to previous problems. How is this problem similar to something you have solved before? eg drawing a spiral is like drawing a circle, but your line has to move outwards each time rather than finishing where it started.
The next row in the table has to come as something of a relief to lower primary teachers. 🙂 The good news is that it’s actually not hard for 5-6 teachers either.
|Generating and designing||Design a user interface for a digital system (ACTDIP018)
Design, modify and follow simple algorithms involving sequences of steps, branching, and iteration (repetition) (ACTDIP019)
5-6: Design a user interface for a digital system
This step is not nearly as daunting as it sounds. In a Scratch program it simply means laying out how a user will use the program. So if it’s a game where you have to click on, say, balloons, in order to pop them, the user interface will be the start button, maybe a speed selector, and using the mouse to click on the balloons. Any interaction the program makes possible – any way the user can do something to change something in the program – is part of the user interface. So anything the user will be able to do – choose a pen colour, change the speed or size of an object, click on something to make it react – is part of the user interface and can be described before the program is actually written.
These goals are all aimed at teaching planning, as well as tech stuff. It’s really easy, even for experts, to just sit down and start doing stuff before they think about what it is they are trying to do. So here the curriculum is saying “let’s think about what we’re going to do, and even write it down, before we actually try to do it.”
5-6: Design, modify and follow simple algorithms involving sequences of steps, branching, and iteration (repetition)
Here we’re talking about algorithms, or recipes, not code. So this one is about being able to lay out the steps involved in solving a problem, using repeated steps (iteration – for example “keep beating until the egg whites are stiff”, “keep walking until you reach the stairs”, or “while there’s still LEGO on the floor, pick up a piece and put it in the box”), branching (testing to see if something is true, for example “if it’s dark, turn on the light”, or “if the cake is a chocolate cake, add cocoa, otherwise add vanilla essence.”)
|Producing and implementing||Implement simple digital solutions as visual programs with algorithms involving branching (decisions) and user input (ACTDIP011)||Implement digital solutions as simple visual programs involving branching, iteration (repetition), and user input (ACTDIP020)|
3-4: Implement simple digital solutions as visual programs with algorithms involving branching (decisions) and user input
Write a program in a visual programming language such as Scratch, Snap, or Blockly that has decision points (if statements, also referred to in the curriculum as “branching”), and user input. An example might be a program that asks the user if they want to draw a square. If they answer yes then it draws a square, otherwise it says “Bye Bye then!”
5-6: Implement digital solutions as simple visual programs involving branching, iteration (repetition), and user input
This is the same as the 3-4 version except now we’re including iteration (loops, or repetition). So the simple square program above can be rewritten to make the repeated bits simpler and just say “do the line and the turn 4 times” instead of spelling out 4 sets of lines and turns:
Once again this has become a little long and I’m not finished yet! So in the best entertainment traditions I am going to end on a cliffhanger (ok, maybe it’s less of a cliff and more of a small step, but work with me here!) and leave you keen for part 3 (I hope!). The good news is that Part 3 will be much shorter. If you find this useful, please share it widely.
These posts are also going to form the basis of a series of Professional Development workshops run by former students of mine (only for Victoria at this stage, but there’s hope for online workshops in the future), so if you’re interested in those, and/or coding workshops that are directly tied to your existing curriculum, please fill out the poll below (purely to gauge interest levels, no names or contact details will be recorded) and watch this space!