The Australian Curriculum has been going through the "everything is changing" part of the ten-yearly cycle recently. As a teacher of technologies it's been both exciting (and gut-wrenching) to see how the draft curriculum has evolved to the point where it is required for implementation in 2018.
I won't go into the design of the digital technologies curriculum itself (you can see the details at the ACARA site) but did want to look at some of the ways people have been talking about implementing the mandatory section (up to and including year 8).
As anyone who is familiar with the Internet and nerds would know, people love arguing about programming languages and platforms. Since I started teaching Computer Science as a year 11/12 course (then called Information Systems) in 2005 I remember reading arguments over what programming languages and databases to use, how to assess them, and so on. Fast forward a decade or so, and sit down with a couple of teachers, and you can have the same argument about how to teach programming (or more specifically 'algorithmic thinking'), this time to students 5-6 years younger.
As an example, I was recently at a moderation session for a year 11/12 course and got to talking to a couple of other teachers there about how they were appoaching Digital Technologies for younger kids. One of the teachers was talking about website design, and learning HTML/CSS/JS. This bothered me on a couple of levels. Firstly, I've never had a lot of success with doing much that's useful with the fundamentals of web design in the classroom. There are usually a few students that really run with it, but there's often a lot of frustration at HTML elements not working as expected (which I'm sure would be shared by anyone who has worked with the web before) as well as with juggling content, presentation and the mish-mash of adding programming into the mix. Secondly, I wonder what the point is. Content creation has largely moved away from requiring an understanding of the underlying technology, we have a bunch of free or cheap platforms to build on like WordPress, SquareSpace, Wix, Weebly and so on, and other tiers as you get further toward the HTML/CSS stage like the various Markdown converters (which admittedly get closer to needing to care about styling for templates).
If we look at understanding for web usage in business, then unless students are going into web development, then again they'll probably be looking at content management systems with integrated editors rather than needing to know (or have much advantage from knowing about) the nuts and bolts.
With the Maker movement in full swing in schools there has been a lot of enthusiasm behind the various microprocessor platforms like Arduino. I've had a conflicted relationship with Arduino with my students since I find it difficult to bridge the gap between electronics and programming, and since programs are compiled and then run on device, programming is usually done in C++, which I think is a very unfriendly learning language, partly due to syntax and partly due to the typically obscure debugging information that you get from C style languages. Earlier this year I was shown ScratchX, which can allow you to plug the lovely Scratch interface into other stuff, like Arduino and its variants (my favourite one so far is Hummingbird). The trouble is that this goes from on-device execution to running code on an attached computer, meaning you're stuck trailing wires around. At a recent conference I was found out about ArduBlock and Visuino, both of which are visual, block-style programming environments but which compile down to Arduino binaries which can then be run on-device. I think these styles of programming interfaces are going to go into my toolbox for my guinea pig classes to test suitability in the near future.
Speaking of Scratch, at the 2016 ECAWA conference I had the pleasure of going to a session by Brett Clarke and Mark Stephens (I tried to find something that wasn't LinkedIn, honest), which looked at adapting materials which Brett wrote for the computing curriculum back in the early 1990s. The session looked at using turtle graphics style commands built as Scratch extension blocks to build complex shapes from primitives, which then extended to scaling and the introduction of parameters to extensions. It was a really nice, accessible way of looking at problem decomposition and encouraging experimentation in an environment which is very fault-tolerant (that is, no syntax errors, colour categorisation of code blocks, and immediate visual feedback).
They went on to look at extending the same principles to build a series of methods for drawing letters (essentially a vector font), straight, curved and mirrored text, and then looking at how this could be applied to lettering on a sewing machine with a zig-zag pattern.
I've been looking at different vectors for teaching parts of the new curriculum this year with my Year 7 and 8 students (neither group really has the time available to cover the lot yet). I've been having a fair bit of success with Scratch, and I'll probably incorporate some of the ideas which were covered in the session with Brett and Mark. I'd like to add a bit more visual design into the mix, which allows some investigation into vector and raster image manipulation, but I'm not sure how much time I'll have. Scratch has an inbuilt editor which allows for both vector and raster tools, but it isn't particularly powerful and I'd like to use something that is a bit more flexible.
I am pretty excited to look at the visual Arduino interfaces. I think there's so much potential for hardware hacking and a huge number of startups using them for prototyping of real world projects which students can be pointed to for inspiration and motivation. One of my projects is to put together a program where I can devote a significant chunk of time to using Arduino in the classroom to address a nice wide swathe of the Digital Technologies curriculum descriptors.
 - Side story, when I was enrolling in my teaching diploma I was looking for majors which fit in with my Computer Science background. Only one university offered a computing major, so I signed up for it, with "design and technology" being my second preference. There was no description about what this "design and technology" entailed but I figured it had technology in the name, so would be fine.
Only later did I find out that "design and technology" was the catch-all for woodwork, metalwork, and so on; areas that when I started in schools were definitely not technology-focused, although in the era of cheaper 3D printing, CNC routers and so on this is becoming less of the case.