Skip to main content Skip to navigation

Department of Computer Science

Original draft for WIPCSE 2015

Making construals as child's play

'Making construals' is the central theme of the EU Erasmus+ CONSTRUIT! project. The principles and environments being developed in CONSTRUIT! were originally conceived in association with a broader view of computing, complementary to a 'computational thinking' perspective, that addresses the role that modern computing technology plays in generating rich experiences and instruments. A central challenge for CONSTRUIT! is to adapt resources that have been prepared for an audience of university computer science students so as to disseminate the idea of making construals to the school context.

As part of our dissemination programme, we organised activities for young people visiting the annual SciFest event at Joensuu in Finland in April 2015. We had expected to find that the construals we had prepared for this event would be best-suited for secondary school children. To our surprise, our most enthusiastic participants were younger children, typically 8-11 years old.

The following short demonstration/presentation details how observing the reactions of these unexpectedly young visitors has helped us to clarify our thinking about the role of construals in computing, and indeed may be evidence that 'making construals is child's play'. It also helps to explain why making construals can help to address topics that are problematic for the traditional 'computational thinking' approach, such as isssues of design and debugging in software engineering and the application of computing in disciplines other than science.

The construal depicted on the canvas on the left is one of three that were deployed at SciFest. It is concerned with what we observe when we set about colouring the grid of hexagons in such a way that no two adjacent hexagons have the same colour. Our observation at SciFest suggested that young children interacted with the Hex Colouring construal in quite different ways from older children. A younger child would typically simply jump in and begin colouring the hex grid 'thoughtlessly'.

So for instance, they might colour as follows: hexcols = [["yellow", "green"], ["blue", "red", "blue", "green"], ["yellow", "green", "red"], ["green", "red", "yellow", "green"], ["blue", "red"]];

in the following sequence:

31 - green / 32 - red / 43 - blue / 22 - green / 21 - yellow / 33 - yellow / 44 - red / 34 - green / 23 - red / 13 - green / 12 - blue
/ 11 - red / 01 - green / 00 - yellow / 10 - blue

For the most part, the older children were more careful and deliberate in their approach to colouring. If they encountered a situation similar to that displayed, they would refer to the 'error message' at the top of the display, realise that they had used green too many times. and make some small reconfiguration to solve the puzzle. For instance:

Sequence followed

00 - white /  01 - yellow / 10 - white / 21 - blue / 10 - yellow / 00 - blue

The resulting colouring is: hexcols = [["blue", "yellow"], ["yellow", "red", "blue", "green"], ["blue", "green", "red"], ["green", "red", "yellow", "green"], ["blue", "red"]];

... or alternatively:

Simply recolour cell 34 in blue
hexcols = [["yellow", "green"], ["blue", "red", "blue", "green"], ["yellow", "green", "red"], ["green", "red", "yellow", "blue"], ["blue", "red"]];

For older children, the resulting 'Well done!' was then interpreted as a sign-off signal - the set task has been accomplished. Younger children were more comfortable simply experimenting with the colouring, and arriving at the 'Well done!' message in a serendipitous way.

One of the features of the construal is that the values of arbitrary observables can be directly reassigned at any stage. If the young child is made aware of the possibility of assigning a new value to the maximum number of times they can use a colour: showObservables("max");

they may prefer to adapt the rules rather than solve the puzzle as stated: maxgreen = 5;

.. and are then motivated by the 'Well done!' message to explore the puzzle further. To an older child, this is seen as 'cheating' and does not hold the same fascination.

It is often observed that children tend to lose their appetite for experiment and become more conservative as they grow older. This may be linked to the essential need to train children to appreciate the consequences of their actions and the potential dangers of not 'observing the rules'. In such training, children are often encouraaged to follow systematic processes in a constrained, structured and purposeful way. This entails:

  • Understanding a situation as fully as possible before you take action.
  • Clarifying the goal of your action as precisely as you can in advance.
  • Monitoring your interactions with careful attention to whether it brings you nearer to your chosen goal.
Ths kind of approach to constructing things is associated with 'good programming practice'. It represents a mode of investigation and problem-solving that is characteristic of 'computational thinking'.

The younger child's interaction with the Hex Colouring construal is quite different in character:

  • They jump into interaction without much reflection and prior understanding.
  • They are not clearly focused on meeting a specific goal but are open to being delighted by whatever their interactions disclose.
  • They are prepared to adapt their expectations and goals to the situation as they find and imagine it to be.
Interaction of this nature is entirely in the spirit of 'making construals'.

This is reflected in the way in which the agency associated with mouse actions has been specified in the construal. A typical user-interface to a conventional program for solving the colouring puzzle as originally posed would constrain the solver so that it would be impossible to select a colour more than the specified maximum number of times. The more permissive interface that allows the solver to violate the rules not only invites creative interaction - it can also be a practically useful feature that allows the solver to iterate towards a solution. As the possibility of directly reassigning the value of the observable maxred illustrates, there is scope for developing far more permissive interfaces. Scope for open-ended interaction is well-matched to the young child's experience of the world, where actions and meanings are not yet constrained by convention and etiquette.

A somewhat similar contrast between attitudes to interaction with the construal is also encountered where adults are concerned. A naive observer may be quite happy to trust the interpretation of an observable purely on the basis of empirical evidence that is derived from experimentation. By contrast, it is very natural for someone trained as a scientist - and especially as a computer scientist! - to look critically at relationships they observe in a construal and want to know precisely how these relationships are represented in computational terms.

Consider the observables named "adjPosList..." for example. showObservables("adjPosList");

When we survey the definitions of these observables it is immediately plausible that the lists on the RHS of these definitions refer to the neighbouring ("adjacent") cells. For instance, the five pairs in the adjPosList00 (viz. [0,1], [1,1] and [1,0]) correspond to the three cells that are adjacent to the cell labelled 00.

You can interact with the construal so as to convince yourself that the colour options available when you hover over a cell are determined by the colours that have been assigned to those cells that are identified as adjacent in its associated adjPosList... observable. For instance, you can assign colours to the cells 01, 11 and 10 and observe how your choice of colours affects the options for cell 00.

Because of the essential character of a construal, deeper kinds of analysis and experiment are possible. In a conventional program, though there might be a variable similar to adjPosList00 whose value was correlated with the options for colouring cell 00 in the way that is observed in the construal, it would make no sense in general to assert that the value of a variable adjPosList00 determines the options that are available when colouring cell 00. There is in general no context within which to change the value of a variable within a program to test such a hypothesis about 'causality'. In the construal, in contrast, the way in which the adjPosList00 observable affects the options available for cell 00 can be further explored by inspecting the values of other related observables: showObservables("adj|currColAdj|curr|set|can");

Pasting the expression 'canBeRedCurr|currColAdj' into a Dependency Map view will show the chain of dependencies that connect the availability of red as a choice of colour for the currently selected cell with the adjPosList... observables.

The nature of this dependency can be further tested by modifying the definitions of the adjPosList... observables. We know how we would expect changing the entries in the adjacency list adjPosList00 to affect the possible colour options for cell 00, for instance.

By way of further illustration, if we were to glue the bottom edge of grid cell 00 to the top edge of cell 44 to make a non-planar grid structure, we should expect the cells 00 and 44 to be coloured differently. We can confirm that if we press 'Reset', make the redefinition adjPoslist00 = [[0, 1], [1, 1], [1, 0], [4,4]];

and assign a colour to cell 44, it is not then possible to assign the same colour to cell 00.

A good computer scientist will demand much more rigorous evidence and explanation of the significance of the adjPosList... observables than this simple test supplies. They would be right to be cautious: with the above definition in place, it is quite possible for cells 00 and 44 to have the same colour. To verify this, press 'Reset' and first assign a colour to cell 00, then assign the same colour to cell 44.

This confusing scenario is resolved when we recognise that 'being adjacent' is a symmetric relation between cells, so that a second redefinition is required to ensure that cells 00 and 44 cannot be assigned the same colour (supplying this redefinition is an exercise to the reader).

When we understand the way in which the adjPosList... observables work, and have inspected their definitions and experimented with the construal enough, we can be reasonably confident that we understand the relationship between the adjPosListMN observable and the options for colouring cell MN. For the naive observer who plays with the construal, this relationship is perceived as a dependency - a connection that is directly experienced whenever they interact with the construal.

If - like the pedantic computer scientist - you are dissatisfied with such pragmatic empirical evidence, you will want to be convinced by tracing the computational steps that specify this relation in detail. It is indeed possible to expose the steps by which this relation was crafted in making the construal - this is the theme of a companion presentation which explains in more detail how the construal was made☆. Studying that exposition is valuable as a way of gaining confidence in the integrity of the construal, and may also suggest ways in which it could be improved. But this kind of activity (which might be likened to checking the computational mechanisms that are operating in the background when we use a spreadsheet) may detract from the playful creative 'what if?' interaction that is characteristic of a young child's engagement with the construal. For this sort of interaction, we don't require full understanding, can tolerate elements of ignorance and confusion, and give priority to our imagination rather than our reason.

☆ If required, this can be loaded at the end of this presentation as follows: poster is [poster_1, poster_2, poster_3, poster_4a, poster_4b, poster_5a, poster_5b, poster_5c, poster_6, poster_7]; blankslide is Slide(""); slideList is poster // [blankslide] // A_initphase // B_introconstrual // C_introMC // D_morereMC // E_demo3col;

One of the challenges in teaching computing is to convey the scope, richness and subtlety of the concerns that arise in real software development. When we teach computing, it is natural to focus initially on algorthmic solutions to abstract problems. In practice, computing-in-the-wild is concerned with ill-specified problems in environments framed by real-world engineering constraints and social conventions over which the software developer has little control. Making construals is an activity that is complementary to abstract computational thinking. Rather than offering closed solutions to problems, it invites makers to explore issues and possibilities, provoking questions about the potential application domain and context in which software is to be developed.

The issues raised in the preceding discussion illustrate how making construals can give some flavour of software design and debugging concerns and practices. For instance:

  • How permissive do we wish to make our interface to the colouring puzzle?
  • What are the consequences of overlooking the need for two redefinitions to specify the symmetric adjacency relation? ... and could we reconfigure the construal to make this unnecessary?
  • How would you go about adapting the Hex Colouring construal to model colouring the faces of a Buckminster Fuller ball?

As has been illustrated to some extent in the above discussion, making construals is associated with the thinking and experiment that precedes a clear understanding. In this role, it can be helpful in handling the problematic and confusing scenarios that arise in learning and in 'making sense of things'. This is particularly relevant in the arts and humanities, or indeed in social and experimental science, where questions may admit no immediate objective answers.

A famous quotation by the English poet John Keats speaks of a quality that he associates with an artist's outlook:

"I mean Negative Capability, that is, when a man [or woman!] is capable of being in uncertainties, mysteries, doubts, without any irritable reaching after fact and reason".

Wikipedia amplifies this idea as follows: "John Keats used the term negative capability to describe the artist's receptiveness to the world and its natural marvel, and to reject those who tried to formulate theories or categorical knowledge. In this concept, Keats posited the world and the human to be of infinite depth."

Making construals invites us to conceive interactions with computing technologies in this spirit, and not solely in 'scientific' computational terms. In this respect, it can be seen as an approach to computing that bridges the 'two cultures' of art and science.