Tag Archives: computing

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. 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:

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.