Constructing Modern Music

A view from inside a cardboard model castle of the dragon that threatens it with Gary Stager looking on.
From inside a cardboard model castle – the cardboard dragon that threatens it, with Gary Stager looking on.

Music?

More of a noise really, but made by hand crafted instruments made using servo motors and BBC Micro:bits.

All part of the summer institute, making and programming, that was Constructing Modern Knowledge (CMK), held in Manchester, New Hampshire, USA from 9-12 July 2024.

I went to be amongst friends and like-minded educators such as Cynthia Solomon.

Richard Millwood and Cynthia Solomon enjoying the morning ‘sermonette’ by Gary Stager – a rabble-rousing, amusing and thoughtful reminder of the value of what we were all there doing.

CMK is the invention of Gary Stager and Sylvia Martinez, bringing together teachers who want to explore constructionism in the best possible way, by making.

Each morning, Gary would remind us of the origins of his pedagogical paradigm and re-inforce its precepts in an entertaining and informative way, reminding each of us of our evangelical duties!

A slide from Gary’s morning presentation quoting the late Edith Ackermann: “Learning is less about acquiring or transmitting information or existing ideas or values than it is about collectively designing a world that is worth living in.”

Another important aspect of the summer institute was the huge, ballroom-like space for us to work in, with one long wall filled with table after table of equipment, spare parts and tools for participants to exploit in making their projects.

The cavernous space used for CMK, with tables on the left extending the full length of the room filled with equipment and materials.

In the evenings we enjoyed a baseball game, a meal in an Argentinian restaurant, where the food was supplied on swords, and a pajama party!

Josh Burker and Richard Millwood enjoying the baseball game between the New Hampshire Fisher Cats and the Binghamton Rumble Ponies at the Delta Dental Stadium (you can just make out the emblematic molar on a pole over the entrance to the top left!)

We had impressive guest speakers in Stephen Wolfram, Tricia Tunstall and Melissa Walker as well as drop-ins from Eric Rosenbaum, Dan & Molly Watt and many other friends.

BUT we also had European football!

Richard Millwood (Eng-er-land!), Pauline Maas (The Netherlands) and husband watching the Euros semi-final soccer game between England and The Netherlands.

Like me, everyone I spoke to was committed to creating powerful learning experiences by handing to learners ownership & responsibility over their learning through project work. This means creating the conditions for “hard fun”, leading to meaningful & fulfilling outcomes. Gary and Sylvia’s insight was that we need to do that, not just talk about it in order to be better teachers employing the method.

In my case, I really wanted to understand how to use servos too, so on the first day, when we brainstormed project ideas, I proposed a mechanical orchestra, and luckily, two others (Timothy Patterson and Angela Buffington) wanted to join me.

We made individual instruments which each employed Micro:bit & Hummingbird driven servos to make sounds, and then attempted to coordinate them by using the broadcast radio communication between micro:bits.

We did it!

Here is the code for Tim’s instruments, using MakeCode:

Angela’s code ended up in MicroBlocks, as we scrambled to get everything working, it made the debug loop quicker with its direct coding model:

My code was for the four ‘tuned’ glasses, again in MicroBlocks:

And finally the ‘conductor’ code, in MicroBlocks:

We invited guests to obtain a ticket:

A design based on the baseball ticket:

And, ta-da!, the performance:

All in all, best summed up in Gary and Sylvia’s colourful words:
“CMK 2024 was a powerful refutation of the cruelty fuelling the latest explicit instruction craze.

Curtains for Sashiko

I was pleased to remix the Turtlestitch project which I had previously used to fix my shirt and jersey to repair a torn curtain.

Sashiko is a Japanese embroidery technique to decoratively repair and strengthen old clothes. I had written a Turtlestitch program to stitch a spider’s web to hold fabric together.

A torn curtain with embroidery stabilising material and ruler.
I started by measuring some stabilising material to slip inside the curtain.

Torn curtain material with a few hand stitches to hold it together in preparation for repair.
The torn curtain material with stabilising material inserted and held in place with a few hand stitches.

Torn curtain material with a few hand stitches and sellotape to hold it together in preparation for repair.
Sellotape added to help the embroidery machine frame hold the curtain material as I tried to make the embroidery reach the edge.

Torn curtain material with hand stitches and sellotape now clamped into an embroidery frame.
Now clamped into an embroidery frame.

Material in an embroidery machine frame being stitched with three lines of thread.
Begin stitching the spider’s web.

Material in an embroidery machine frame being stitched with nine lines of thread.
Halfway through the radial threads.

Material in an embroidery machine frame being stitched with lines of thread radiating from a point and cross-connecting lines to look like a spider's web.
Almost completed the ‘rungs’.

Material finished being stitched with lines of thread radiating from a point and cross-connecting lines to look like a spider's web.
Finished!

Material finished being stitched with lines of thread radiating from a point and cross-connecting lines to look like a spider's web hanging in a window.
Hanging in the window.

From beginning to end around an hour’s work one morning – having had the code already written and just adapted it to make a 180 degree web rather than a full circle.

Now I can relax, knowing I am unlikely to make that tear worse!

Speaking to my boiler

My boiler clock stopped working.

A somewhat stereotypical seasonal response to the dropping temperatures and clock changing back last night!

I do hope the central heating engineers out there are raking it in right now, but I am sorry to say, not from me.

Like my late father, I am perhaps too careful with my money despite being able to afford a call out. But for me, it is an opportunity and incentive to experiment with home automation.

I looked at the price of smart controls and blanched. Maybe instead I could replace the aged thermostat with a smart plug? I had to do some considered thinking about how that would work, and paused for a couple of days to do a little online research and devise a solution before deciding I could go for it.

The smart speakers I have are Echo Dot 5s, which can measure room temperature. I planned to write Alexa ‘routines’ to respond to changes (up or down) and do the timing too, so that it is not on overnight. A simple kind of programming, but interesting to think about as it means setting up a feedback-loop to operate at certain times only.

All I needed to do is understand how the thermostat was wired, and instead of the temperature alone switching the boiler heating on, I could perhaps replace it with essentially a home made programmable relay to do the work of thermostat and timer?

The inner workings of the thermostat are simple enough, but I had to think out loud all the connections and label them up before I went further (John Davitt would be proud).

Of course I had already turned off the boiler in the consumer unit and at it’s fused spur outlet for double safety.

The trick was to take the ‘switched’ wire, which needed to be live when the new ‘thermostat/timer’ called for heating, and wire it into an ordinary plug which then is inserted into the smart socket, which can switch it on and off.

Here is the final wiring. Note that the plug needs no neutral connection(!), hence the earth sleeving to indicate that the blue wire was used for earth (for safety) in the lamp flex I used:

And after screwing it all together and plugging it in where the thermostat used to be:

I was pleased to be able to recycle an old plug and especially an old switched socket from my store in the garage, so if anything goes wrong with the smart socket, I can take it out of the equation, plug in the plug and still control the heating manually with the switch on the old socket.

Finally I had to write two routines for Alexa to respond to temperature change and, for now, notify me it has done so, to check it is working. These are simple to make in the Alexa app on my iPhone. Ziggy is the name for my bedroom Echo Dot 5, which I decided to use to monitor my small flat’s temperature. In the living room, I have an Eco Flex, currently on sale at less than £5 on Amazon, which is an amazing bargain! Sadly it has no thermometer function, but it does play music on my hifi and let me control the lights and the rest of the house.

Here are the two routines:

  • first, ‘Turn on heating’ to turn on the smart socket when the temperature is below 17C, within a specified time period;
  • second ‘Turn off heating’ to turn off the smart socket when it is above 18C – at any time. By saying ‘Alexa disable turn on heating’ as I leave the house, I can ensure I am not wasting energy when away.

Total outlay, £7.50 for the smart socket.

Sashiko

No, this not a term of endearment for my son Sasha, not another Russian diminutive of the name Alexander – here are those:

  • Alexander– used at work, in official circumstances, or by people he doesn’t know
  • Sasha – used by his friends and family. An alternative diminutive is Shura
  • Sashenka – used as a form of affection by members of his family
  • Sashulya – used very affectionately, probably by his girlfriend
  • Sashka – used very informally by family and friends, but is impolite if used by a stranger

No, this is Sashiko, a four hundred year old Japanese cultural concept, of a craft that revives old clothes or makes them stronger and warmer.

A man with a holey shirt repaired using a Sashiko technique of embroidery designed to look like a spider's web.

I have this old cotton shirt. The fabric is thin and worn and torn slightly near the breast pocket. I wanted to repair it based on the values and ideas of the Japanese craft of Sashiko.

I made a digital embroidery design, rather like a spider’s web, by writing a program using Turtlestitch, hoping it would strengthen the fabric and prevent the tear from spreading. So far so good – you can see the results in the photograph above – the hole was made bigger by the process, but I think more secure – we’ll see!

I also have a knitted cotton jersey, which I had torn lying down in a plane and catching it in the seat frame, doh!

The fabric is much stretchier, and with the experience of the first repair enlarging the hole, I thought I would try to stabilise the fabric on both sides with washable backing.

To further improve the stability, I chose to make some flour and water glue (with again the intent to wash it away afterwards) and stuck the jersey to the backing before mounting it in the embroidery frame:

The flour and water glue placed on the jersey
Now with the washable backing
Ready to go!

I had to wait overnight for the glue to fully dry and then the fun began:

Stitching the web
The end result before removal and washing
After washing away the backing and glue.

The result should stop the jersey from unravelling, but either way I am pleased with the process and the outcome!

I was unsettled by the amount of trigonometry and list processing I had to use in my first spider web solution, so spent some time while waiting for the glue to dry making a simpler program for the jersey spider’s web, that relied on Turtle Geometry only.

This confinement to Turtle Geometry – move and turn commands from the perspective of an imaginary turtle-like robot – means that when trying to fix or improve the program, one has recourse to bodily movement (imagined or real) to figure out what the program is doing. Seymour Papert, one of the inventors of Logo, on which Turtlestitch is based, called this ‘body-syntonic’.

This has been a focus for my inquiry over several years and I have blogged before about it:

Concepts in Computing – a taxonomy under review

This concept map is derived from a list first developed as a spreadsheet in 2016 by Miles Berry, in the context of Project Quantum. That project produced a mass of multiple choice questions for computing, and to make them searchable, they were tagged with a unique topic code (hence the numbers on each). The project’s output was delivered as part of Diagnostic Questions by the company EEDI, which I worked for in 2019.

On reviewing new computer science questions made by teachers, I found many topics that were not covered by the taxonomy. The outcome of my work wouldn’t be so clear in a spreadsheet, so I constructed the concept map above using Cmap, and my additions are shown in red.

I was a little surprised at the omissions, but it isn’t an easy task to get right. I had the great good fortune to be critiquing it through a form of practice – the development of tests by teachers.

But, since then I have often wondered about this categorisation, and in particular, question its completeness and its hierarchy.

Sub-program

I am particularly surprised at the relegation of sub-program (in all its forms) under a heading of ‘modularity’.

Seymour Papert held a different view of the sub-program.

In MicroWorlds, Papert held that:

“The idea of programming is introduced through the metaphor of teaching the Turtle a new word.”

(Papert, 1980, p. 12)

Papert’s idea suggests the sub-program a more dominant concept than selection and iteration, which with sequence, are held to be the three key algorithmic ideas in the English and Irish curricula, which have little mention of the sub-program as an algorithmic idea.

Parallelism

In a similar way, there is no sign of parallelism – the concept that two or more sequences of instructions may be executed at the same time. This is surprising since this is a major feature of beginning programming languages such as Scratch (and all its derivatives) and MakeCode. Parallelism features strongly because of the way it can simplify the programming of complex behaviours, such as those found in games with multiple independent graphics, that children love to make. Parallelism can bring its own problems of coordination too, but these are rarely noticed at this level.

Much is made of the challenges children face when moving from jigsaw languages like Scratch to text languages like Python, but the focus of concern is on the change of environment and the need to be accurate with syntax and grammar, rather than functionality. The loss of functionality that children suffer when they don’t find it easy to program games in Python as they could in Scratch, can so often lead to a return to Scratch programming – for its greater sophistication! This challenge is identified in the work of the Pytch project lead by my Trinity College Dublin colleague Glenn Strong.

Some of the problem is the way in which technology is a moving target. Scratch appeared in 2007, and although parallelism was in many programming languages around before that, it was not considered a beginner’s topic.

So it probably is a good idea to review the concept map regularly, and I intend to do so at conferences in China, Spain and New York – if my proposals are accepted – in the coming months.

Computational Thinking in Primary

@AttyMassNS "At the recent [CESI] Conference, we mentioned our plans to explore decomposition and patterns/generalisations through Damhsa/Irish dancing. Integrates with/comhthathú le Seachtain na Gaeilge" March 2018
@AttyMassNS     “At the recent [CESI] Conference, we mentioned our plans to explore decomposition and patterns/generalisations through Damhsa/Irish dancing. Integrates with/comhthathú le Seachtain na Gaeilge”     March 2018
I was delighted last November to be asked to write this  Research Paper on Computational Thinking for the Irish National Council for Curriculum and Assessment, and now it is out.

I couldn’t do it on my own, so I invited a team of colleagues and friends in the Computational Thinking for Life group at Trinity College Dublin to help:

  • Nina Bresnihan, who had been conducting literature review on this for her PhD;
  • Dermot Walsh who had been looking at professional development in his PhD as well as being an innovative primary practitioner and
  • Joy Hooper, formerly working to advise both New Zealand and the UK on technology enhanced learning and also an experienced primary practitioner.

We were advised by friends and colleagues Stephen Powell and Glenn Strong and also consulted with Jane Waite, Dave Smith and Amanda Jackson – key players in the UK’s efforts to bring computing to the Primary level. I felt pleased to have such an experienced, knowledgeable and willing bunch to call on.

As well as benefiting from their collective wisdom, the result is a chance to exercise ideas I have been developing since completing my PhD in 2013, but material from the PhD also gets an airing. I hope it is helpful.

Mental models to support competence in computer programming

Mental models

These are the mind’s ‘mechanisms’ for explaining and predicting phenomena. I have written more in my PhD, and you can find good expansions of the idea in Michael Simmons’ post or in the Wikipedia article on Mental Model The idea originated with Craik in World War II and elaborated by Johnson-Laird amongst others, all of whose work made me interested in developing computational models(!) of mental models – a subject of interest to me in the late eighties when I was a member of the London Mental Models group.

I do not think this is the same thing as modelling phenomena in mathematics or in computer programs – such simulation models are expressions in external languages, unlike mental models, which are mostly private to our minds: interconnected, fluid, faulty and ultimately unknowable. When we create and communicate external expressions in natural or formal language, this leads to the possibility of proof, execution and formal reasoning in a shared world of knowledge. But these external expressions aren’t mental models: they are in a linguistic form that can be interpreted by others and in formal cases, by machines.

Nevertheless I believe the unknowable internal mental model remains a useful notion when we think about designing effective learning. I apply the notion here to the design thinking needed for effective courses, materials, pedagogy, software, assessment to teach programming.

Mental models in Computer Programming

This is my second draft diagram which represents four five key mental models that a learner must develop (and continue to develop) as they increase competence in programming. It has been much improved after listening (and reacting) to Jane Waite talk about abstraction in programming. I have now made a poster – Mental models to support competence in computer programming – for the London Computing Education Research Symposium on June 11th 2018.

Programming - five areas of mental model
Programming – five areas of mental model

Problem Comprehension

This mental model allows the learner to reason about the problem itself – it may develop as the learner combines problem solving and design to make a solution. Sometimes prior knowledge can help; for example, Papert would argue that children enjoy, are competent and have mental models about the way their body can move in the physical world. If a problem is aligned to such competence, they can more effectively debug their program (body syntonic) and feel engaged with the challenge (ego syntonic).

Programming Language

This mental model is about the parts of the language – the distinctions between different linguistic components and their connection to create programs. Scratch supports this mental model by categorising statements and thus offers recognition rather than recall. It also reinforces appropriate syntactical combinations, so that the focus is on their meaning, in isolation and in combination.

Notional Machine

The notional machine is a mental model concerned with the variables, computer memory (for data and program), ‘program counter’ – a hidden variable that determines which statement is executed next and thus flow of control. It is much more complex with Scratch than in the past, since multiple parallel process are readily designed using sprites. The design of solutions in this way can be quite different from that made with single process thread programming, but makes the mental model challenging. My favourite example of this was the solution I developed using Scratch with three sprites to draw lines to fill in a shape, hoping to use it with TurtleStitch to make embroidery. Then I discovered that TurtleStitch (a Snap derivative) had only one sprite – my solution was useless due to a mismatch of my mental model of notional machine for Turtlestich and Scratch.

Microworld / Domain

The microworld is the concept of a limited ‘space’, designed to suit a particular class of problems and usually with an ‘object to think with’. The turtle geometry microworld is the most famous, but not the first in Logo. Before that came sentence construction using lists of words to manufacture amusing nonsense! Making a mental model of a microworld’s affordances allows the learner to map solutions to problems and to relate to the notional machine and the programming language, within a limited but meaningful domain.

Interactive Development Environment

The mental model here is of a complex user interface to understand and write programs, manage program files, debug programs and produce results. Sometimes it spans several computer applications, such as an editor, file manager and version control, and sometimes it csn be combined in one place, as with Scratch. It is the interactive development environment (IDE) which can help or hinders the user in forming the mental models of programming language, notional machine and microworld through visualisation and interactivity.

Connections between mental models

The greatest challenge to the learning programmer is in the connections and overlaps between each of the mental models. I believe the educational designer (especially the designer of the IDE) must pay attention to each of these and the questions in the diagram are to help the designer think about that.

Knock knock! – an interpretation of ‘body syntonic’

I recently worked with colleagues to offer similar workshops at two conferences – SCoTENS 2017 in Dundalk (with Pamela Cowan from Queens University Belfast and Elizabeth Oldham from Trinity College Dublin), Ireland and ATEE 2017 in Dubrovnik, Croatia (with Nina Bresnihan, Glenn Strong and Elizabeth Oldham, all from Trinity College Dublin).

The workshops introduced our ideas about using a version of paired programming to give confidence to novices in programming. We had developed these ideas, together with colleagues Mags Amond and Lisa Hegarty, also from Trinity College Dublin, through the CTwins project funded by Google’s CS4HS – Computer Science for High School.

The workshop slides for ATEE 2017 also included ‘Art’ in the title, since it was my notion that developing an art project would be personally fulfilling.

You can see how I have been a little pre-occupied with the relationship between art, craft and programming through my recent blogs:

In a happy co-incidence, I today found myself in a useful conversation about the design of the programming tool, Scratch, that we used in the project and the workshop. In the conversation, we rightly focussed on the design of Scratch, which has become so wildly popular that a heavy weight of responsibility lies on the development team to get it right. I tried to explain why Scratch is important in this blog post:

Nevertheless, I feel that as well as considering the tool design, we must also shift attention to the activity and mental models that I believe learners symbiotically develop alongside their use of the Scratch tool. The Logo programming language developed in 1967 and its turtle geometry microworld is one of the most potent developments to recognise such activity and mental modelling – although I believe not the earliest (I believe sentence generation using lists preceded it?).

A microworld is a slippery concept, but Richard Noss and Celia Hoyles neatly sum up its importance in their book ‘Windows on Mathematical Meanings: Learning Cultures and Computers‘:

“In a microworld, the central technical actors are computational objects. The choice of such objects and the ways in which relationships between them are represented within the medium, are critical. Each object is a conceptual building block instantiated on the screen, which students may construct and reconstruct […]. To be effective, they must evoke something worthwhile in the learner, some rationale for wanting to explore with them, play with them, learn with them. they should evoke intuitions, current understandings and personal images – even preferences and pleasures. The primary difficulty facing learners in engaging directly with static formal systems concerns the gap between interaction within such systems and their existing experience: it is simply too great. That is why computational objects are an important intermediary in microworlds, precisely because the interaction with them stands a chance of connecting with existing knowledge and simultaneously points beyond it.”

In the turtle geometry microworld, the computational object is a robot turtle on a stage, equipped with a pen to trace out lines as it moves according to program steps.

Scratch starts with a different microworld sporting a cat rather than a turtle and is a particular kind of computer game with interacting sprites. It leaves in the jigsaw blocks for a turtle geometry microworld but they are somewhat spoiled by the sideways view of a stage rather than the top down view of the space that the turtle inhabits.

In the conference workshops we asked completely novice learners (adults using Scratch and ScratchJr) to program knock-knock jokes, with two sprites and message passing to synchronise the joke-telling activity.

Firstly, together with colleagues, we performed this joke (thanks to Pamela Cowan for such an excellent idea, performance and preparation):

Ghost: Knock knock!
Cat: Who’s there?
Ghost: Boo!
Cat: Boo who?
Ghost: No need to cry!

Secondly, we asked the adults to humanly perform their own jokes working in pairs, so that one adult would be the first actor in the joke and the other the second. I was building on the concept of ‘body syntonic’ which is so powerful in the turtle geometry microworld, but in this case, it is the act of interactive joke telling that forms the mental model of the problem, to be then expressed formally in programming and debugged.

In the Scratch  turtle geometry microworld, the pen jigsaw blocks are the foundations of formally expressing the acts of an imagined turtle with its pen. Children (and adults) can ‘be’ the turtle and act out the actions either bodily or in their heads, exercising their mental model of the turtle, which may then help them debug their formal expressions in code (jigsaw blocks).

In the case of our knock-knock microworld, we presented on the projector screen a subset of jigsaw blocks to start with:

In one instance of the workshop, to my delight, one learner added other blocks, using repetition to tell a more complex joke.

So perhaps the set of immediately available jigsaw blocks should reflect the microworld the learner’s imagination and mental models are anticipated to inhabit? I would go further and propose microworld-appropriate stages (and stage views, as we have in Turtlestitch and Beetleblocks), sprites and costumes. In Turtlestitch I would propose a spider sprite/costume and indeed rename it Spiderart or some-such. Perhaps there should be a choice of microworld, “I’m doing turtle geometry today” which leads one to the set of jigsaw blocks most appropriate to that microworld? I emphatically do not mean that this means restricting access to the wider set of jigsaw blocks, simply that it provides the best recommendations from the menu for the kind of restaurant you want / are ready to eat in.

To extend an already overworked metaphor, after the learner has been eating at diverse restaurants, each founded in the same underlying elements of heat, ingredients and combination, perhaps they would begin to strengthen their knowledge of the invariates which inform the mental models that underly their understanding of notional machine and programming language?

Turtlestitching – programming embroidery

Automated Landscape as an embroidery
Automated Landscape as an embroidery

My first introduction to programming an embroidery machine came at the Scratch 2015 conference in Amsterdam, when Andrea Mayr-Stalder from Vienna presented the Turtlestitch programming environment based on Snap. I didn’t take that much notice, however lovely the designs and the possibilities were.

Then I went to Seymour Papert’s commemoration in Boston in January 2016 and met Susan Ettenheim from New York. Susan had joined forces with Andrea to explore Turtlestitch and was on a learning journey with Susan’s student Jennifer Lin. Jennifer was struggling with a problem – how to fill in space with an embroidery machine using Turtlestitch. The task she was attempting was to fill in a petal shape. Artemis Papert had made a good solution, which tackled the problem using variables and trigonometry. In this program, the petals have become leafs:

Artemis Papert's petal
Artemis Papert’s petal

Susan told me that Jennifer struggled at first to understand such sophisticated mathematics. Never one to ignore a challenge, I designed an alternate solution which stuck to ‘body syntonic’ principles – essentially, exploiting a learner’s prior knowledge of moving their own body to make and debug a computer program. My solution involved three ‘sprites’ – one to run around one side of the petal, one to run round the other and finally another to run between them, filling in the space. One can imagine children actually acting this out for real, collaboratively, as a precursor to programming a solution in code, in the same way that turtle geometry allows them to solve geometric problems by imagining they themselves are moving and turning. [UPDATE March 2023 – here is a video we made in 2019 to illustrate!] It is salutary to note that my solution involves synchronising concurrent processes – a topic I would have considered above my pay grade, let alone appropriate for learners as young as 5! (Later I found out that ScratchJr, designed for younger learners, also included this kind of notional machine!).

After this, I was hooked, and at Scratch 2017 in Bordeaux I met Andrea, Susan and Jennifer together with Michael Aschaeur, who had programmed Turtlestitch, and had the opportunity to talk about my ideas and learn how they planned to go forward. As a result, I resolved to buy an embroidery machine!

I purchased a Brother Innov-is F440E embroidery machine in September 2017 from SOSBrother in Bray, I resolved to create an opportunity to play with colleagues and friends using Turtlestich to explore programming and embroidery, and thus was born the Turtlestitching workshop held today, Thursday 19th October as part of EU Code Week.

The introduction that Susan from SOSBrother gave me in to the machine’s operation was invaluable and I tried to pass on all I could remember to my collaborators.

Mags created designs seeded by our date of birth:

https://twitter.com/twitter/statuses/921091656694235137

Mary Jo followed the brilliant Turtlestitch cards to create some lovely interlocking circles:

Mary Jo's simple but effective design
Mary Jo’s simple but effective design

Jake was like a duck to water, his work here modelled by Mags:

Jake's pattern
Jake’s pattern modelled by Mags

John’s design started black and white, but became really beautiful when using the multi-coloured thread:

John's design
John’s design

Glenn inspected, analysed and modified an existing pattern to fit the Brother’s 18 by 13 cm space:

Glenn's pattern
Glenn’s pattern

And after they all went away, I made my own Automated Landscape (the illustration at the start of this blog) into an embroidery, using the wonderful multi-coloured thread.

The workshop taught us several things:

  • “move 10 steps” produced a 2mm stitch, which was a ‘good’ size stitch;
  • going over patterns twice or even three times could make stronger designs;
  • multicoloured thread could make spectacular embroideries;
  • more time was spent discussing computational issues than embroidery issues;
  • it was hard fun!

I am absolutely delighted to announce that Trinity College Dublin’s Visual Arts and Performance scheme have agreed to fund a course and exhibition based on this, following a successful Wearable Electronics Workshop last year – look out for the advert in the New Year!

Computational Thinking and Art

Automated Landscape - Richard Millwood (1971)
Automated Landscape – Richard Millwood (1971)

I recently made a presentation with Mags Amond at the Art Teachers Association of Ireland‘s 2017 Annual Conference in the National Gallery of Ireland. I spoke a little about technology and learning, technology and art and then gave some examples of our own experiences and thoughts. You can read our presentation ‘LED by the heart’ here.

Included was the picture above, which I painted in school in 1971 following an algorithm given to me by my art teacher. I remember being satisfied with the process and the outcome, and the pleasure never went away. This was what the teacher asked me to do:

  1. Draw a steep zig-zag line to make a mountain range
  2. Draw a less steep zig-zag line to make a range of foothills
  3. Draw a smoother zig-zag line to make rolling countryside
  4. Extend the lines thinly to divide the space into geometric sections
  5. Paint the sections using sky, mountain, hill and field colours

I have since written a computer program in Snap to do this automatically.

Mags demonstrated to the teachers how simple electrical circuits work, and later we encouraged them to ‘pimp their badge’ with LEDs, coin batteries and decorations.

pimping their badges
pimping their badges

Other examples I showed included the use of Snap by young children to program lights on the front of a four floor building at the Scratch Conference in Bordeaux this year, the use of light emitting diodes with micro-controllers to make wearable electronics and programming an embroidery machine to make patterns:

butterfly class embroidery
butterfly class embroidery

Our proposition to the art teachers, was that computational thinking and computing might be something they have the aptitude for, confirmed by Keith Gregg’s MSc dissertation.

We also proposed that STEAM (Science Technology Engineering Art and Mathematics) might better be written ASTEM, putting the art first, and themselves taking a lead in developing computing in their schools.

Jigsaw programming

Blockly program to compute a factorial
A program to compute the factorial of a number using Blockly

I’m sure many of my readers will know what I mean, but just in case, I am talking about the visual programming languages for programming computers which use blocks that plug together like a jigsaw to express algorithms. Examples include StarLogo, App Inventor, Scratch and Blockly.

These are widely used to introduce programming for the following reasons:

  1. such languages tap in to a pre-literate capacity to help learners make sense of things without depending on technical reading and writing literacies;
  2. learners appreciate the tactile and kinaesthetic sensibilities involved in producing a visually pleasing artefact, the program, regardless of what it does;
  3. such languages clarify the logic of the program through the display of visual, diagrammatic shapes that make it easy to determine the relationship and scope of program elements;
  4. it is impossible to make syntax errors such as incorrect spelling, conjunction or punctuation;
  5. they provide a visual menu of programming elements so that opportunities for expression are clear and the learner’s memory is not overtaxed.

All this I can understand and I am very much a fan, but I am unclear why there is considered to be a desirable progression from these languages to the traditional text-based languages?

In some cases features are missing from the visual programming languages. For example Scratch doesn’t do functions and local variables.

It may be thought that a complex program would be visually unwieldy, but I find that true of any reasonably sized textual program.

Then there is the historical/cultural/custom-and-practice concerns of experienced programmers – I can hear them saying “surely there is something important, expressive and pure about traditional programming languages?”.

I maintain an open mind about this and can even imagine jigsaw programming becoming the method of choice for serious programming in the workplace. If I am right, there are some interesting challenges:

  1. What are the criteria for judging the effectiveness / efficiency / legibility of a program made using jigsaw programming?
  2. What are the examples of programming problems that cannot be solved using jigsaw programming?
  3. How do we benefit from the version control and sharing that matter for collaborative development?
  4. How do they effectively encapsulate and hide libraries of service functions and procedures?
  5. Can we add styling control so that we can tailor the visual appearance to suit the person and the task, or simply provide an alternative view?
  6. How can they reveal and make editable the variables and data they manipulate? (Scratch does this well with lists).
  7. How can they animate the program’s diagram to illustrate its execution, single step, interrupt and thus help us debug?

Some of these challenges may already be tackled – I’d be pleased to hear about where to find developments!

Collabor8 4 Change – Conceptual framework for Computing

Following up my presentations in 2007 at Naace in Feltham  ‘The Importance of Computing as a Specialist Subject in Schools‘ and in 2010 at Computing@School in Birmingham ‘Computing at School‘, I am hosting a table at Collabor8 4 Change at BETT 2012 this year .

Titled ‘Conceptual framework for computing‘ it is planned to be a discussion of how we can be clearer about the nature of the computing subject at primary and secondary level and in particular how we can know better the continuity and progression for learners.

My challenge, in the context of computing and ICT  is:

  1. I believe we need to find out what knowledge children can attain at which age
  2. I suggest we could do mass practitioner research to answer that question
  3. What’s wrong with this proposition?

Here are the few slides to kick off the discussion – I shall add an update to this post when we have had it!

UPDATE 13/1/2012 after attending:

The two sessions went well, with interesting feedback. For most participants, there were more important issues at the level of teacher competence, school organisation and the government’s upheaval of ICT and Computing, which deserved more debate time. On the other hand few felt that I was wrong!

I enjoyed Kathryn Day’s session, ‘ ICT vs Computer Programming curriculum ‘ which usefully contrasted the many documents that inform (or confuse) the practitioner when planning.

I also attended Chris Ratcliffe’s session ‘ How much should pupils be, or feel, in charge of their work? ‘ which clarified some of the barriers to further responsibility being transferred to pupils, whilst agreeing it as a good thing.

Finally I joined Steve Philip for his session ‘Curating the past is more important than creating the future’ in which he proposed the term ‘curativity’ – the act of curating the avalanche of creative work made possible in schools with digital tools through selection, deletion, categorisation and preservation/presentation for an audience. Highly relevant to the National Archive of Educational Computing!

Well done to all the presenters & participants and to  the organisers: Penny Patterson, Dave Smith and Terry Freedman and to compère Russel Prue – the round tables format has a lot to recommend it, with more time for exchange in contrast to the more theatrical Teachmeet.

Computing at School


I presented at the third annual Computing at School conference, reporting Nili Naveh’s research in a seminar I proposed to discuss the research into childrens’ conceptions in computing. The central issue is the contrast in the attention paid to children’s conceptual development in maths and science compared to computing. In maths and science, research has established a Piagetian analysis based on data of what percentage of children can achieve which conceptual understanding at a range of ages, and this is the basis for the National Curriculum levels. Clearly this should not be used as a straitjacket – there is a diversity in attainment and children are often underestimated. Teachers have excellent tacit knowledge of this, but I argued it may be helpful to articulate this more clearly and to construct a data-gathering exercise from schools across the country. We had a good discussion, thanks to some really good presentations earlier in the day which gave good fuel for our debate. Here are my slides:  Algorithms + Data Structures = Programs.

The Importance of Computing as a Specialist Subject in Schools

Naace All-Members Autumn Conference 2007

Shared a platform with Gillian Lovegrove on this topic at the Naace All-Members Conference at Cisco in Feltham. I enjoyed the relatively easy task of listing some of the arguments for computing’s contribution to the wealth of human knowledge:

  1. computing > arithmetic – it is also the engine room of the social network / Web 2.0
  2. ubiquity of knowledge management – all disciplines’ approach to knowledge is infected with computing
  3. creativity and problem solving – it provides extraordinary potential for creative and problem solving activity by making the abstract concrete
  4. concept of the human mind – ideas of the mind have interchanged with concepts of the computer throughout history
  5. historical contribution – the interrelationship with war, economy, culture and democracy
  6. tool culture drives evolution (genetic and social) – tools have been symbiotic with humanity’s evolution since the stone age and the computer is the most sophisticated and diverse tool invented

After Gillian’s points about the problems facing the subject of computing, it was most challenging to hear one member of the audience ask the question: “Could it be our fault?”. It will be interesting to see how this discussion develops in the future.