Keynote voting wearables at CESI conference

Richard Millwood and Elizabeth Oldham presenting at CESI conference 2018 with voting wearables
Richard Millwood and Elizabeth Oldham presenting at CESI conference 2018 with voting wearables

I had a mad idea.

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:

Richard Millwood, Sean Manning, Dawn O'Sullivan, Dominick Donnelly, Kathleen Touhy & Liam OCallanain in Cork
Richard Millwood, Sean Manning, Dawn O’Sullivan, Dominick Donnelly, Kathleen Touhy & Liam OCallanain in Cork

In Donegal, Sharon, Pauric and Claire collaborated to make their solution:

Richard Millwood, Sharon Lee & Pauric O'Donnell in Donegal
Richard Millwood, Sharon Lee & Pauric O’Donnell in Donegal

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:

The Barbie design think process - Elizabeth Mullan & Maeve Cormican
The Barbie design think process – Elizabeth Mullan & Maeve Cormican

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.

 

Making Elizabeth's wearable
Making Elizabeth’s wearable

And the result (from a distance it looked OK!):

Elizabeth's wearable
Elizabeth’s wearable

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!

Three voters and a speaker in testing
Three voters and a speaker in testing

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-A-speaker’:

Program for 'microbit-audience'
Program for ‘microbit-audience’
Program for 'microbit-A-speaker'
Program for ‘microbit-A-speaker’
Program for 'microbit-B-speaker'
Program for ‘microbit-B-speaker’

I leave it to the reader to puzzle out how it all worked and will welcome suggestions for improvement!

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, leading to an interest 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 – these are expressions in external languages, unlike mental models, which are mostly private, interconnected, fluid, faulty and ultimately unknowable. Expressing them externally leads to the possibility of proof, execution and formal reasoning in a shared world of knowledge – but these aren’t mental models, they are in a formal linguistic form that can be communicated to others and to machines.

Nevertheless I believe the unknowable internal mental model remains a useful notion when we think about designing learning and I apply the notion in this blog to the competence to make computer programs.

Mental models in Computer Programming

This is my first draft diagram which represents four key mental models that a learner must develop (and continue to develop) as they increase competence in programming.

Programming - four areas of mental model
Programming – four areas of mental model

Problem Comprehension

This mental model allows the learner to reason about the problem itself – it may develop as problem solving and design are combined to find a solution. Sometimes prior knowledge can help – for example Papert would argue that children are competent (and have mental models) about the way their body can move in the physical world, and if the problem is aligned to such competence, they can engage more effectively and debug their program.

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

A strong mental model of notional machine is vital to debugging. This mental model is concerned with the variables, data store, ‘program counter’ (which statement is executed next – flow of control). It is much more complex with Scratch than in the past , since multiple parallel process are easily 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 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 – a mismatch of my mental model of notional machine for Scratch/ Snap.

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. Making a mental model of its affordances allows the learner to map to problems and to relate to the notional machine and the programming language, within a limited but meaningful domain.

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 must pay attention to each of these and the questions in the diagram are to help the designer think about that.