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.
Having learnt all about the amazing Microbit at CESI•CS meetings and in particular their capacity to inter-communicate using Bluetooth Low Energy (BLE) after being shown by the indefatigable Keith Quille, I wondered “how many Microbits could be broadcasting at once?” and “could I put together a voting system where the audience have Microbits and the speaker has a wearable with Microbit that listens for their votes and displays the outcome?”
I had been asked by the Computers in Education Society of Ireland (CESI) to present a keynote speech with my good friend and colleague Elizabeth Oldham at the CESI conference on 10th March 2018 at Dublin City University. I told Elizabeth about my idea and suggested we dramatise disagreement from time to time in the speech and then ask the audience to settle our dispute. She agreed!
Keith Quille also thought I wasn’t mad, but I’m not confident he is the best judge 🙂
So, Keith started me off with a first go at a program for each Microbit. Then I tried at our CESI•CS meetings to get participants to try and solve the problem – they all came up trumps within only an hour or so, some with no experience at all – amazing!
In Cork, a group with primary and secondary teachers quickly made a solution:
In Donegal, Sharon, Pauric and Claire collaborated to make their solution:
In Athlone, Elizabeth and Maeve made a plan, using a Design Thinking process by treating me as their client and empathising, before writing down their ideas and then programming:
In each case, we discussed design processes, collaboration and the project work proposals in the Leaving Certificate for Computer Science. There were good discussions about foundations, progression and continuity, since all the CESI•CS meetings included primary and post-primary teachers.
So, having established feasibility, I set about making something Elizabeth would be prepared to wear, so cut up an old shirt and got stitching and glueing according to this fabric flower design.
And the result (from a distance it looked OK!):
Behind her flower (and with no adornment on my wearable) was a Kitronix Zip Halo fixed to a Microbit, and with a safety pin provided by Adrienne Webb (thanks!) Elizabeth pinned it to her cardigan, and I mine to my shirt.
The final task was to complete the programming. With Keith’s inspiration and the many design conversations and prototypes made by CESI•CS participants, I finally completed the code with two hours to spare – I only had time to test with three audience voting Microbits, so there was no certainty it would work. Once in the room and with minutes to spare, we set about downloading the audience program to a pile of Microbits generously lent to me by Stephen Howell of Microsoft. It couldn’t be done without the generous help of Stephen Howell, Keith Quille, Tony Riley and John Hegarty. We think we had over fifty voting in the room!
There were three programs – a program for the audience ‘microbit-audience’, a program for my wearable to control the voting process & display votes for ‘A’ positions ‘microbit-A-speaker’, and a program for Elizabeth’s wearable to display votes for ‘B’ positions ‘microbit-B-speaker’:
I leave it to the reader to puzzle out how it all worked and will welcome suggestions for improvement!
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.
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).
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.
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.
It is often argued that we need clarity about the nature of Computational Thinking and how it relates to the more established mathematics and problems solving worlds. This diagram is an attempt to set out some of the key elements of computational thinking content and their interrelationships, particularly with respect to computer science.
Using my notion of competence, the content analysis in the diagram focusses on those aspects of knowledge: facts,concepts and mental models, but does not describe knowledge strategies, craft skills and dispositions of character that might be needed for a full description of Computational Thinking.
It is my contention that much of the content of Computational Thinking is to be found outside the subject of Computer Science, in other subject disciplines and in the everyday world. Computing offers the chance to make such ideas programmable and thus transform sometimes abstract ideas into more concrete, executable form – making their learning all the more amenable to the loop of expression and evaluation described in my view of Expressive Constructivism as set out in my PhD.
lies in the centre of the diagram to remind us of the importance of data structures in a time when algorithms are the fashion. It is my thought that computational thinking is better defined as: combining problem solving and design to create useful solutions, informed by the possibilities that Computing offers.