Skip to main content Skip to navigation

The CONSTRUIT! project: introducing construals to school education


Orientation

There are many different ways in which information and communication technologies are applied in education. To deepen our understanding of such applications, and potentially build better applications, we need to look critically at the way in which the science of computing is related to learning.

The established focus for computing science is on activities that can be viewed as computational in character. Such activities have clearly defined goals that can be addressed by systematic program-like recipes. Computational thinking [13] is clearly relevant to subjects such as mathematics and business where calculations and decisions are based on standard algorithms and processes. The scope for applying computational thinking is without doubt yet to be fully realised, and is still the focus of active research. For instance, computational techniques are being developed with a view to automating scientific experiments, resolving questions of attribution in the humanities, and analysing learning processes.

The extent to which computing science needs a broader perspective than computational thinking supplies is controversial. The recent reform of the computing-related curriculum in UK schools aims to promote traditional computer science topics at all age levels. This should dispel the idea that computing is no more interesting and intellectually challenging than the use of standard utilities for creating word documents, spreadsheets and databases that was for many years the staple offering under the subject heading 'ICT'. But whether 'hard' core computer science provides a suitable foundation for computing as it is being applied in the social sciences, arts and humanities, engineering and laboratory science in general is unclear. In their provisional 'Manifesto for Web Science' [7], Halford, Pope and Carr make the case for a framework for thinking about computing that takes more account of the role of human judgement and of social context. Established authorities on software development such as Peter Naur [10] and Michael Jackson [9] have stressed the need to recognise the limitations of formal mathematical approaches to computing where engineering aspects are concerned. This is in keeping with Ferguson's observations concerning academic courses in engineering [4]:

The real "problem" of engineering education is the implicit acceptance of the notion that high-status analytical courses are superior to those that encourage the student to develop an intuitive "feel" for the incalculable complexity of engineering practice in the real world.

The CONSTRUIT! project promotes 'making construals' as a new digital skill that can potentially help to address such concerns.

Discussing the philosophical backdrop that is best suited to making construals is far beyond the scope of this paper. Nonetheless, it may be helpful to be aware that some commonplace assumptions are potentially being challenged. For instance, in the spirit of Halford et al's controversial manifesto, making construals engages with our experience in ways that are so primitive that they can take precedence over: the duality between mental and the physical realms, the status of mathematical abstractions as absolute foundational concepts, the subjective-objective classification of observation and the identity and object-like status that we attribute to elements of our experience. That is to say, making construals is an activity that may entail exploring how distinctions of this kind, which we often take for granted, are being constructed though our interaction [1,2].

Construals

The accepted theoretical foundation for computing is based on an abstract notion of 'a computer program' that has its roots in Turing's seminal study of a mind following rules [12]. By contrast, as discussed in [3], the concept of 'a construal' is oriented towards less constrained states of mind that are associated with creative and innovative practices. We are not the first researchers to use the term 'construal' in this sense. It was introduced by the philosopher of science David Gooding to describe the way that the celebrated experimental scientist Michael Faraday recorded his emerging understanding of electromagnetism from first principles through to the development of the electric motor [5,6]. We propose 'making construals' as a way to support the mind which is not - or not yet - following rules. This has broad implications, at present far from fully explored, for activities like the development of software and domain learning where systematic understanding is yet to be established.

A construal is informally 'how we think of something'. Making a construal is associated with questions we often ask in everyday life: What do you make of that? What 'construction' do you put upon that? How does that work?. It is tempting to make our definition more formal by attributing identities to a construal and the 'something' to which it refers. We might wish to refer to the construal C as representing 'how we think of X'. This is not always appropriate, since 'how we think of something' is typically dynamic in nature, and our construal, the something to which it refers and the relationship between the two may themselves be 'under construction'. (Consider, for instance, the status of the intermediate phenomena that Faraday recorded before he arrived at a mature conception of electromagnetism.) Indeed, making construals is most interesting and significant where refinement to an absolute objective relationship is most challenging - and perhaps even impossible. This is in keeping with the idea that learning about something is not in general a finite process.

Some informal examples of making construals

Writing a computer program is the formal equivalent of informal everyday activities that are associated with the idea of 'a mind following rules'. The counterpart of a computer program is a 'digital' construal that we construct by exploiting computing technology. By studying informal everyday activities that can be regarded - and may have already been described in other contexts - as making construals, we can likewise derive general principles for making digital construals.


A. Making construals of words and phrases

The idea of 'making a construal' is most commonly linked with language learning. Consider for instance the English phrase: "It's really hot". This can have many interpretations:

  • It may be a reference to the weather, in which case it might well mean something rather different to a Greek and a British person. It may be a factual statement - as uttered by a weather forecaster, or ironic - as spoken in jest.
  • It may refer to a hot object - as uttered by a waiter bringing a dish to the table, or by a mother to her child - who might say this whilst pretending to put her hand on the oven door, whether or not it is actually hot.

The phrase has other less commonplace connotations. It can be used by a conference delegate who is alluding to a topical session on the schedule. It can be used by luggage handlers at an airport to indicate that an item has to be dealt with urgently [14]. The phrase may have significance that is beyond the scope of any literal dictionary meaning - consider for instance what a doctor might infer from hearing a patient make this comment.


B. Making a construal of a familiar real-world situation

A construal of a spoken phrase is typically a mental image of what is the most appropriate interpretation. More generally, we can apply the term 'construal' to the diagrams we draw or gestures we make to give physical expression and form to what we have imagined, and which, in effect, serve as "extensions of our mind".

electriccircuit
Figure 1: A circuit diagram as an informal construal

Figure 1 is an example of such a construal. It depicts a simple circuit diagram such as an electrician might draw to explain how switches and lights are configured. To appreciate the nature of the construal fully, we must consider the kind of dialogue that accompanies the electrician's explanation. We can imagine the electrician pointing at the circuit diagram, indicating how the on-off status of switches and lights are correlated. The typical context for such an explanation would be an actual installation within a building, where there is a correspondence between the entities in the circuit diagram and physical switches, lights and connecting wires. In this case, the dialogue about the diagram would be carried out alongside operating the physical switches and observing their effect on lights. Though a circuit diagram is not in itself an interactive artefact, the electrician is in effect simulating interactions with the circuit diagram virtually. In making digital construals, we can give explicit support for this interactive 'what if?' activity, as will be illustrated below.


C. Making construals in devising and tracing a walk

A circuit diagram is a standard generic way in which to represent a situation. Standard construals of this kind are the result of a sophisticated process of design and communication through which their interpretation eventually becomes formalised. The live ongoing processes that lead towards such formalised interpretations provide more characteristic and interesting instances of making construals. By way of illustration, construal plays a vital role in giving an account of a guided walk - both for the author of the walk and the walker who must then trace it. Here for example is a fictional fragment from a guided walk, as described in the style of Tait [11]:

'Walk up the rough track, passing a small stone cottage, below shady pine trees. After a second cottage, the track becomes steeper as it veers to the right. Soon the village of Amnesia comes into view, some distance above. When you see the distinctive bell-tower directly ahead, leave the main track and take another, less-used, down to the left.'

At first sight, this account resembles a computer program, in that it describes a sequence of actions that contribute towards the goal of completing the walk. In fact, there are many significant differences:

  • On closer inspection, the agency that is being programmed is quite unlike a machine. The instructions to the walker have little of the abstraction and precision that are required of programming commands. A high level of comprehension of concepts and of language is assumed ("what is a bell-tower?", "when is it distinctive?", "How do we recognise a less-used track? "how do we know this is the village of Amnesia?")). The answers to such questions are in fact of their very nature ambiguous and uncertain. The text invites the walker to draw on implicit contextual knowledge to which they may or may not have access. The skill of the author of the guide book is in picking out those features that are most likely to be drawn out by exploring the context, whether by recalling previous experience to mind, consulting a map, or making short exploratory excursions.
  • The account is framed not solely in terms of abstract procedural steps (cf. primitive Logo commands), but with reference to recognisable states in which characteristic relationships pertain ("After a second cottage ...", "When you see the distinctive bell-tower directly ahead ..."). This sets up a process that is quite characteristic of making construals: correlating what is conjured up in the imagination through reading the text and what is experienced through attending to the current situation. This essentially personal process of interpretation is particularly fascinating when several people are involved, and there is a strong incentive for all parties to reach a consensus.
  • Though the walker will certainly be concerned to ensure that they eventually reach their prescribed destination, this is not their primary goal. It may well be, for instance, that 'the main track' leads more directly to the same point as 'the lesser-used track', but to take this option would not be appropriate.

Though the three informal examples of making construals are quite different in character, they have a core feature in common. Each can be described in terms of 'a person making sense of a situation'. Turning our attention to how this sense-making scenario can in principle be supported by using the computer helps us to clarify the essential nature of making construals.

Making digital construals

Figure 2 below depicts the key ingredients in making a digital construal. We shall elaborate these with reference to the informal examples A, B and C above.

construingconstrual

Figure 2: Making a digital construal

The way in which Figure 2 is to be interpreted is perhaps most simply illustrated in connection with the circuit diagram discussed as example B. (The reason for the word 'perhaps' will become clear later.) The maker of the construal is the person who is trying to make sense of the situation - the electrician. The role of the construal in this case is being played by the circuit diagram and its referent is the electrical installation to which it refers. As described above, the electrician makes a connection between imagined changes of status in components of the circuit diagram and what is observed in the installation. The correspondence between the circuit diagram and the installation is so straightforward that this connection could be thought of as abstract and law-like in nature, but this is not what we have in mind. The purpose of the eye icon in Figure 2 is to depict making a connection between the status of the components in the circuit diagram and their physical counterparts in its referent as a matter of direct immediate experience.

It is easier to interpret Figure 2 appropriately if we think of the construal not as a static circuit diagram with a virtual behaviour but as an interactive artefact. A suitable artefact is the digital construal depicted in Figure 3 (you can access this construal in the browser by clicking on the url http://jseden.dcs.warwick.ac.uk/scifest/ and selecting 'Electrical Circuit' from the Project List). The status of the switches can be changed by clicking on them, and the status of the lights changes accordingly.


electriccircuit
Figure 3: A digital construal of an electrical circuit (Hudnott, 2015)

[A later version of this construal, implemented by Nicolas Pope in April 2017, is now available at http://jseden.dcs.warwick.ac.uk/construit/?load=162]

It is not only the interactivity of the digital construal that matters here: the way in which this is achieved is also significant. If we only wish to reproduce the law-like pattern of behaviour that is the norm, it is not difficult to prescribe this using other graphical applications, such as Geometer's Sketchpad [8]. The way in which we make a digital construal aspires to take account of the whole range of experimental interactions that can be ventured within the domain, not simply the relationships that are encountered in some constrained and preconceived 'normal' interaction with the referent (as a typical computer program does). With this objective in mind, the digital construal is developed as a network of observables linked by dependencies that express the way in which their values are interdependent whatever the overall status of the system.

By way of illustration, as may be confirmed by typing the expression '.*bulb' into the search box of an Observable List in the JS-EDEN environment, there are observables to represent the status of each light bulb in the construal. The current status of 'bulb2' has the definition:

bulb2On is masterSwitchClosed && switch2Closed;

which reflects the fact that whether it is lit depends on whether the 'master switch' and 'switch2' are both switched on. By replacing this definition by

bulb2On = false;

we set up a scenario in which 'bulb2' can be interpreted as having burnt out.

The way in which a digital construal is fashioned from primitive observables and dependencies plays an essential role in the interpretation of the key ingredients (the construal, its referent, the maker's understanding and the context for their interaction) depicted in Figure 2. The understanding that is attributed to the maker is empirical in character - it is the knowledge of patterns of interaction and interpretation with which the maker has become familiar over time. This kind of understanding is important to the engineer in practice - as when trying to diagnose a fault in the installation. There is a sense in which the engineer can never be absolutely sure that the installation is fault-free - failure may occur at any time, and in principle a new fault may arise even whilst the engineer is in the process of fixing another. In this respect, a digital construal is better aligned to the 'incalculable complexity of engineering practice' to which Ferguson alludes than idealised analytical models. The context for the maker's interaction with the construal and the referent reflects the current role and agency of the maker and other relevant assumptions about the overall environment. It might be that the maker is interacting with the construal simply in order to adjust the visualisation of the circuit diagram, or that a learner is acting in the role of the maker. There may be no power to the circuit, or the voltage may be such that it is only safe to have both lights lit in parallel.

In principle, the key ingredients in Figure 2 all have a fluid dynamic character. This makes it possible to cope with much richer scenarios for design and experiment than can be supported by traditional computational representations. The benefits are not so obvious in the informal example B, since a circuit diagram is itself an abstract artefact with a well-defined meaning. By contrast, examples A and C highlight the challenges we face in trying to make sense of situations, and give some insight into why making construals through studying agency as reconfiguration of networks of observables and dependencies as depicted in Figure 2 is a promising way to address these.

Example A highlights the crucial importance of context ('are we talking about the weather, or the food?'), the latent context-dependent dependencies ('how the doctor interprets what the patient inadvertently reveals'), the need to be able to synchronise action with utterance (saying 'it's really hot' at the same time as 'pretending to touch a hot surface'), the subjectivity of interpretations ('when is a topic hot?'), the benefits of being able to integrate new kinds of observations into a pre-existing construal ('e.g. introducing a thermometer'), the need to support negotiation and collaboration (cf. the pooling of experience and comparison of construals that is associated with the discussion of 'hot' luggage on the Flyertalk forum), the essential role for ambiguity of interpretation where humour is involved (cf. the response 'Have you been outside recently?' on the forum), the personal characteristics of the agents involved (cf. the response 'Are you remotely attractive?' on the forum).

Example C illustrates that making construals, though of its essence focused on state (cf. the way in which Figure 2 is to be interpreted as referring to a specific moment in the experience of the maker), is also relevant to purposeful behaviours. The understanding by way of "knowledge of patterns of interaction and interpretation with which the maker has become familiar over time" is analogous to the knowledge of our neighbourhood that we develop by settling in one place. In exploring our neighbourhood so that we can be 'at home' in it, the intensity and quality of the experience takes priority over the efficient attainment of a goal. As the potential impact of GPS technology on traditional walking practices illustrates, blending human and automated agency in ways that enhance our quality of life is a topical challenge for our time. Making construals offers a plausible conceptual framework in which to address this challenge.

The principles and environments for making construals are still immature relative to the resources for supporting more traditional techniques for software development. We are not yet in a position to evaluate the prospects for using digital construals to support the informal sense-making described in A and C, for instance. Addressing these concerns is part of the agenda for the CONSTRUIT! project.

References


  1. Monks, T., Pope, N., Myers, R., Harfield, A., Beynon. M., Zhu, H. (2013) Web support for e-learning: a constructivist computing approach. Proceedings of the International Conference on E-Technologies and Business on the Web (EBW2013), University of the Thai Chamber of Commerce (UTCC), Thailand, May 7-9, 2013, ISBN: 978-1-4673-4969-7, 181-188
  2. Beynon, M. Modelling with experience: construal and construction for software. (2012) Chapter 9 in Ways of Thinking, Ways of Seeing (ed. Chris Bissell and Chris Dillon), Automation, Collaboration, & E-Services Series 1, Springer-Verlag, January 2012, ISBN 978-3-642-25208-2, 197-228
  3. Beynon, M. (2013). Turing's approach to modelling states of mind. In (eds. S Barry Cooper and Jan van Leeuwen) Alan Turing - His Work and Impact, Elsevier, May 2013, ISBN: 978-0-12-386980-7, 85-91
  4. Ferguson, E.S. (1994). Engineering and the Mind's Eye, The MIT Press. (page 168)
  5. Gooding, D. (1990). Experiment and the Making of Meaning: Human Agency in Scientific Observation and Experiment. Dordrecht: Kluwer.
  6. Gooding, D. (2007). Some Historical Encouragement for TTC: Alchemy, the Calculus and Electromagnetism. At url: http://www2.warwick.ac.uk/fac/sci/dcs/research/em/thinkcomp07/gooding2.pdf (Accessed 10/5/2011)
  7. Halford, S., Pope, C., Carr, L. (2010). A Manifesto for Web Science. In Proceedings of the WebSci10: Extending the Frontiers of Society On-Line, http://journal.webscience.org/297/.
  8. Jackiw, R.N., Finzer. W.F. (1993). The Geometer's Sketchpad: Programming by Geometry. http://acypher.com/wwid/Chapters/13Sketchpad.html
  9. Jackson, M.A. (2006). What can we expect from program verification? IEEE Computer, 39(10), 53–59.
  10. Naur, P. (1995). Knowing and the Mystique of Logic and Rules. Dordrecht: Kluwer Academic Publishers.
  11. Tait, Bob and Lynn (2003). More Walks Around Paleochora, Geographics, Chania, Crete
  12. Turing, A.M. (1936). On Computable Numbers, with an Application to the Entscheidungsproblem, Proc. Lond. Math. Soc. (2), 42, 230-265
  13. Wing, J. M. (2006). Computational thinking." Comm. of the ACM 49.3: 33-35.
  14. The Flyertalk forum, at http://www.flyertalk.com/forum/delta-air-lines-skymiles/1240660-somewhat-unusual-question-tagged-luggage-said-hot.html