Contextualising 'making construals'

This report from the CONSTRUIT! project was originally conceived in the project proposal as a review and reflection on the feedback that had been gained from the evaluation activities associated with the Intellectual Outputs O2 (concerning the effectiveness of the online resources for making construals being developed in the project) and O3 (concerning six key claims about qualities of making construals that were to be investigated). In practice, the significance of the evaluation activity was rather different from what was originally expected. Whereas we had expected that the online resources being developed would evolve through a process of incremental refinement that afforded a consistent process of ongoing evaluation, feedback in fact served a rather different purpose, stimulating much more radical changes to online resources than we had anticipated. As a result, this report is more concerned with what has been learnt about the limitations of the resources that we had been originally expecting to deploy and the challenges that have had to be overcome in creating online resources for making construals that are fit for purpose. These challenges encompass high-level concerns about the nature of making construals in relation to other computing and educational practices as well as practical logistic issues concerned with using, modifying and creating construals.

There is a recognised need for a broader account of computing than computational thinking (CT) alone provides [Matti Tedre, CONSTRUIT 2017]. This is in keeping with Seymour Papert's notion that programming has an educational value that goes beyond imparting skill in specifying algorithmic recipes: more important from a pedagogical perspective is the way in which it may oblige us to think deeply about the nature of the agency that lies behind such recipes. This is very different from accepting the computer as a device with unambiguous agency and formal rules of interpretation, as we typically do in abstract classroom programming exercises; it acknowledges that in many software development scenarios much of the complexity derives from the contingent way in which the actions of the computer are interpreted and mediated, so that a major component of the software development challenge is configuring the agency within the environent so that it can be deemed machine-like [cf. EM paper #087]. Papert is interested in this activity as it applies to gaining understanding of how human activities operate, and reflecting on how we are able to carry out tasks is an important higher-level ingredient in learning. To consider programming in this light is to look beyond functional goals and to explore epistemological issues that are closed in a pure CT perspective. Papert characterised this shift in perspective in terms of 'programs as objects-to-think-with'; as Charles Crook points out, in the broader educational context, there is a need for learning to have an intersubjective character and to this end 'objects-to-converse-with' have a key role to play. This is one way in which to characterise the concept of a 'construal' [CONSTRUIT! publications: Edurobotics 2016].

Making construals seems very well-suited to the purpose of developing software to meet the practical and pedagogical needs identified above. Such software development necessarily has a very different character from 'rational formal' approaches: it requires a more empirical approach in which the developer makes direct connections-in-experience between the application domain and the elements. Modern software development in some application areas (especially those in which the user experience is the primary concern and nothing is safety-critical) is 'stumbling towards' practices that closely resemble making construals [Richard Cartwright, CONSTRUIT 2017]. Plausible reasons why this should be so may be found in the writings of the software pioneer Peter Naur, which stress the essential roles for 'intuition' and 'lived experience' in development (cf. EM papers #105, #121). The merit of an alternative perspective on software of this nature is suggested by many of the applications addressed at CONSTRUIT 2017: for instance, in decision-support for policy making [Karl King, CONSTRUIT 2017], humanities computing [Willard McCarty, CONSTRUIT 2017] and science studies [Frank James, CONSTRUIT 2017]. It is also well-suited to the blending of physical and computer-based artefacts that is required in introducing digital technology into making, thinking and learning.

From an educational perspective, the potential for conversation amongst people with different interests and levels of technical expertise that is afforded by construals was quickly evident in the CONSTRUIT! Learning, Teaching and Training (LTT) activities. The readiness with which young children at Scifest 2015 adapted to the idea of modifying observables without reference to a clear user-specification (as when opportunistically changing the constraints in the hex colouring task) was striking. Older children engaged well with a construal of a 'lightbox' (an artefact in which the path followed by a ray of light passing through an array of hidden mirrors could be experimentally studied) that was juxtaposed with a physical counterpart. Less conducive to uninhibited interaction was a construal of the game of Nim in which the winning strategy was exposed through a staged sequence of exploratory activities. In these examples, the readiness to engage in conversation around a construal seemed to be inversely related to the perceived degree of freedom to explore in an uncircumscribed imaginative way.

In general, the broad scope that construals afford for conversation was far from fully exploited however. The hex colouring construal in principle supported conversations (though not amongst young children!) about many issues: graph colouring as a recreational puzzle, as a topic of mathematical interest, and as an algorithmic task; the trigonometrical relationships underlying the construction of a regular hexagon; the alternative data representations that might feature in a program to support hex colouring; the dependencies being expressed in making the construal itself. Though each of these conversations was scaffolded by an interactive presentation, few (if any) wished to explore the construal in sufficient depth to appreciate this (and perhaps few people would be qualified to understand all these perspectives).

Of the many pupils who visited the CONSTRUIT! stand at Scifest 2015, one stood out. By playing with the Nim construal, Eemil Tarnenen (then a 16 year old) learned the winning strategy and came back the following day to register his delight. Though we did not meet up again until Scifest 2017, he emailed us several months later to say that he had made use of the Construit environment to support his school work and subsequently became the first person independent of the project team to develop a teaching resource using the book presentation introduced in January 2017. Eemil contributed a poster on this work to CONSTRUIT 2017 and attended the conference.

The unusual liveliness of the interactions and the quality of engagement in the first encounters with construals of school teachers in Athens at C14 was remarked by those experienced in introducing teachers to technology. We had expected making construals to be most attractive to secondary school teachers with computing expertise, but this was not what we typically observed. Teachers who did not have advanced programming skills, or who were working with younger children in a way not too tightly constrained by the curriculum, appreciated the openness of the interaction and interpretation that was possible, and wanted to know more about the potential to make close connections between observables in the domain and their counterparts in the construal without needing specialist computing knowledge. Those who had more technical knowledge had also typically made use of special-purpose tools such as Geogebra, Geometers' Sketchpad and Interactive Physics that made it easy to establish a direct correspondence between observables of interest in the domain and their computer counterparts. These tools and associated resources are refined to target the observables that matter in the application as far as illustrating the established theory of the domain is concerned. For teachers with a strict curriculum to follow, the additional openness and potential for creative exploration of a construal had little relevance: making a construal was perceived as too time-consuming, not sufficiently well-focused on the topic to be studied and not so well-refined for this specific purpose.

Teachers who saw potential in the CONSTRUIT! approach and wished to understand how they might exploit construals in the classroom felt the need to go beyond interacting with prepared construals to find out how to modify and create them. In the initial stages of the project, making construals was a hybrid paradigm for modelling with observables, dependency and agency that presumed elementary programming knowledge (using simple functions and procedures as the building blocks with which to construct scripts of observables and dependencies and associated agent actions). This presented a challenge to non computer specialists, as became clear at the C2 meeting in September 2015, where we tried to capitalise on the interest generated a C14 and demonstrate how a construal might be built from scratch.

At this point in the project, the reliance on basic technical computing skills that were considered routine by computing specialists emerged as a serious obstacle to dissemination. Though tasks such as managing files, using a text editor, writing syntactically correct definitions, using elementary html-style code to document script development, and framing definitions and actions as functions and procedures using simple procedural code were individually relatively straightforward, the aggregate effect of contending with all these technical features was obscuring the underlying simplicity of the concept of making construals. To this point, the principal remedy for this problem had been to try to build in more powerful library functions that enabled would-be makers to avoid writing their own. The downside of this was that this in effect introduced much more procedural code (Javascript) and detracted from the core principles of modelling with observables, dependency and agency. These problems were thrown into higher profile by the more positive response that was obtained at the C2 meeting through a parallel workshop developed for pupils by Antony Harfield and Nicolas Pope (cf. [Construit #39]), where a simplified interface was deployed.

The C2 meeting was a water-shed for the project. Piet Kommers observed that putting the emphasis on optimising tools for making construals had achieved only modest results, and stressed the need to face up to the difficulty of engaging schoolteachers. It was appropriate to devote more attention to the broader pedagogical perspective, to consider the status of making construals in relation to other pedagogical approaches and to determine where it might best be deployed. Whereas Kommers felt that 'the environment for making construals (MCE)' had by now been optimised, Pope regarded the MCE as most unsatisfactory and saw great potential for improvement. In coming to this view, Pope was influenced by knowledge of how modern software environments that were 'stumbling towards' a similar paradigm, though lacking clear principles for development, were in effect providing implicit support for communication of observables, dependency and agency by exploiting much more effective techniques for editing, searching, storing, retrieving and sharing scripts.

Pope's radical new version of the MCE, the first prototype for the current Construit environment, was first deployed at C6 in December 2015. Amongst many innovations introduced were: an online repository for construals and projects (co-designed and implemented by Jonathan Foss); a new interface that served to integrate script execution with editing functions previously served by an external editor; a hand-crafted parser that had syntax highlighting and gave live feedback on syntax errors; a 'live edit' feature for scalar values; a 'when'-clause ingeniously integrated into the script editing environment that can be used to specify and control agent actions in the form of redefinitions. Conceptually more important than any of these innovations was the introduction of a new 'with'-construct that in effect empowered a mode of development that gave much more powerful and direct support to 'observational thinking (cf. CONSTRUIT! publications: PPIG 2016). The 'with' construct made it possible to derive a new observable from an old one by identifying it as equivalent to observing the original observable in a context where one or more of the observables on which it depends has been changed. This overcame a tedious problem in all previous variants of the MCE, whereby families of similar observables had to be explicitly and inflexibly specified (e.g. by using a macro-generator or through manually replicating and editing), and made it possible to use a single observable as a prototype for a family of observables in a flexible manner. Most significantly, the use of 'with' and 'when' constructs ensured enough expressive power to make the use of 'basic functions and procedures', borrowed from a procedural programming paradigm, redundant.

Notwithstanding the conceptual advances represented in the Construit environment, Kommers's concern about the contextualisation of the environment with respect to pedagogical theory and practice was a most important influence on the subsequent project meetings. The transformation of the MCE could be interpreted not merely as a very substantial improvement on its predecessors but as enabling a conceptual shift in thinking about computing. Broadly speaking, programs that had been conceived in 'computational thinking' terms could now be reconceptualised in 'observational thinking' terms. This technique was applied by Beynon to a simple Scratch program for giving change that had been developed by Phil Bagge for use by computing teachers. The resulting construal of giving change [Construit #107] can be interpreted both as a plausible account of precisely what observations are being made when a competent person gives the correct change and as the basis for a program that automates this process through tracing the meaningful observational states. In some sense, this correspondence between 'what a competent person observes' and 'what a program to automate this process does' precisely realises Papert's vision for 'learning through programming' (cf. CONSTRUIT! publications: Constructionism 2016b). It is nonetheless much in tension with established practices in teaching programming.

In a fascinating Skype discussion with Jane Waite at C6 in December 2015, it became apparent that this approach to developing a 'program' from a construal of giving change is far from conceptually simple. (This is perhaps unsurprising in view of the many possible transformations of the program behaviour that can be derived by configuring the construal.) As a former software developer with experience of primary classroom teaching of mathematics and computing who is currently doing a PhD on computer science education, Waite could appreciate fully the subtlety of observational skills that must be learnt by a child in order to be able to give change, recognise how alien to traditional software development practice embedding this in a construal seems to be, and understand how unreasonable it is to expect a child to implement a program for giving change that is derived from a construal of their own cognitive processes.

The Giving Change construal [Construit #107, #138] illustrates the role that construals can play in software development in microcosm. Examining the construal invites us to ask a series of epistemological questions: "How does a child know that a 20p coin is worth more than a 2p coin?", "... that a silver coin is worth more than a copper coin?", "... that some big coins are worth less than smaller coins?", "... that a coin has a worth?". From a constructivist standpoint, there is no limit on the extent to which we can deconstruct an abstract concept such as the relative worth of two coins in observational terms. Computational thinking has to intercept this process of deconstruction at some point to declare that an entity can be formally represented by an abstract entity. This works well when applied to a computer as an abstract computational device. It is far more problematic when applied to computers as they are deployed in the broader context of software-in-the-wild, where the connection between observables in the domain and abstract entities that purport to represent them can be much more situation-specific, subtle and obscure. The trends in modern software development alluded to above are symptomatic of this essential shift in perspective; fluid representations that can accommodate nuanced and qualified interpretations are required.

An individual's stance towards the deconstruction of observation influences their view of making construals. If we consider observables as objective, potentially fundamental, entities, in the way that a physicist might view space and time, the setting for making construals is similar to that in which programming and engineering are conceived. Within the consortium, there are those who regard making construals as simply another variety of programming, or at any rate are primarily interested only in this aspect of its application. The project has benefited greatly from Pope and Tomcsanyi's interest in this perspective, as it has immeasurably improved the environment for making construals as a computing application. Pope's concern to apply the principles of making construals to the engineering of the Construit environment itself has been the catalyst in this respect, and reflects an aspiration to apply Construit to large scale applications, where the conceptual simplicity of thinking in observational terms can help to clear away obfuscating technical complexity. Some of this simplifying potential is evident in the way in which Construit has been interfaced to Arduino artefacts [Construit #247], to geometric modelling tools such as Hyperfun [Construit #277] and to Virtual Reality viewing devices such as Google Cardboard [Construit #295].

If we adopt the philosophical stance of radical empiricism to which making construals appeals, there is no absolute point beyond which we cannot take the process of deconstructing observables; we can only make a pragmatic judgement about whether deeming an observable to be 'primitive' is appropriate, helpful or counter-productive. There is an inverse relationship between the scale of an application of making construals and the richness of the observational analysis that can be sustained. Where one person may be acutely interested in understanding a specific child's personal perception of money ('their construal') in the most intimate detail, another may be more concerned with the observational norms that are made explicit in the primary school curriculum -- and are appropriate for social interaction in the everyday world: what a ['normal'] child needs to appreciate ("to be able to observe") before they are able to assess the relative value of a pair of coins.

From a constructivist pedagogical perspective, making construals is interesting because of the unbounded deconstruction it supports in principle and the precise control over the degree of deconstruction it allows. With hindsight, the problematic aspects of presenting the giving change construal as program based on observational thinking identified in our Skype discussion at C6 stem from our perception of what constitutes a 'primitive observation'. If we are prepared to assume (as Phil Bagge surely does in developing his Scratch program) that the learner (who is not an archetypal 'young child') can observe whether one coin is worth more than another, without introspecting about why, there is no conceptual difficulty. The virtue of making construals is that it gives us the flexibility to pitch the level of observational detail at what is pragmatically appropriate, but this virtue is not necessarily welcome in the classroom -- at least once we have left the imaginations of childhood behind. In the secondary science curriculum, the primary emphasis may be on what modes of observation are understood to be fundamental, and any attempts to explore alternative modes of observation are seen as subversive (cf. the observation cited by Frank James at CONSTRUIT 2017 to the effect that 'had Faraday had a university education, he would never have devised the electric motor').

In the light of its semantic model, making construals stands in opposition to the computationalist perspective that is closely associated with computer science in many people's minds. Since the claims made for the validity of a construal are so pragmatic in nature, one might regard 'making construals' as a poor relation of the kinds of activities that are represented in 'Exploratory Explanations' (cf. for instance Hamish Todd's Measles epidemic simulation from CONSTRUIT 2017) where the primitive 'scientific' observables are deemed uncontroversial, and all else is derived by applying computational rules. The raison d'etre of making construals is to challenge the claim to assured authenticity and universality of such explanations, in the spirit of William James's refusal to accord a privileged status to the notion of absolute knowledge.

The merits of the pragmatic informal semantic model for construals were in evidence in the developments that occurred between C6 and the first pedogogical interim review (C19) in March 2016. During this period, Steve Russ had a Thai visitor, Hengmath Chonchaiya, a specialist in mathematics education, and took the opportunity to introduce him to the maths education community by arranging talks at the British Society for Research into Learning Mathematics and The Association for Mathematics Teachers, and attending a local conference on 'Mathematical Resilience'. The pedagogical value of the 'simple' construals of shopping were much appreciated in this context by educators who understood the difficulties faced by children in construing adult behaviour. One teacher who was accustomed to teaching mathematics at secondary level and had chosen to take up primary mathematics teaching with some apprehension, remarked that the pedagogical challenge at primary level resonated more closely with mathematics as taught at university than with the traditional secondary mathematics curriculum. It was instructive that Chonchaiya was able to appreciate the potential of making construals and could think of many ways in which they might be applied in teaching mathematics (cf. the OXO symmetries construal [Construit #10]), but could not come to terms with the process of construction. One aspect that was particularly confusing was the way in which a construal, being specified by discretionary patterns of interaction and interpretation, could be presented in many different states, and the project manager gave little support for setting up an initial state for the learner in a coherent way.

A complementary project activity that gained momentum at this time was the integration of construals with physical computing devices such as Arduino and with educational robots. The potential for this integration was demonstrated by Jormanainen and Toivonen at C6, and prompted Pope to develop his own interfaces using the new variant of the MCE. The simplicity of these interfaces when compared with traditional practices for integrating programs with Arduino was most striking, and reinforced the idea that making construals is a better match for the necessarily pragmatic stance of the engineer than abstract computational thinking. It also encouraged us to believe that schoolteachers who struggled with the technical challenges of introducing physical computing into the classroom would favour the adoption of CONSTRUIT! principles. Whilst this is possibly true for the primary schoolteacher, it does not take account of the perspective of a secondary school teacher of computing wishing to motivate students to learn a 'professional' programming language such as C, for whom (e.g.) the need to incorporate C code in the interface to Arduino is the salient point rather than an inconvenient obfuscation.

It is an ironic that advocating a more pragmatic framework to computing should be in conflict with a pragmatic approach to computing education in this way. There will always be an incentive to encourage students to follow mainstream commercial software practice even where this is a practice to be deprecated in an ideal world (and can be expected to change in the future (cf. [Cartwright, CONSTRUIT 2017])). This issue is seen in microcosm in the way in which we encourage students perplexed by the semantics of assignment, where assigning 'b+c' to 'a' does not mean 'defining a to be b+c', to learn to 'think like the machine'. A key objective in making construals is to obviate his need by addressing the behaviour of the machine in a manner that better reflects human understanding. That said, it is inevitable that students of computing need to be familiar with the pervasive practices of procedural programming, though they should not be encouraged to propagate or promote them where they are inappropriate.

The most significant contribution to the pedagogical agenda for CONSTRUIT! was made in a 'pedagogy interim review' ("C19") meeting held at Warwick midway through the project in March 2016. This brought together the pedagogical consultants Piet Kommers and Hamish Macleod, the scientific coordinators Meurig Beynon and Steve Russ and four of the team members principally responsible for the practical development of the MCE and its applications: Nicolas Pope, Elizabeth Hudnott, Jonathan Foss and Tapai Toivonen. Other contributors were Chris Hall, Russell Boyatt and (by Skype) Rene Alimisi and Ilkka Jormanainen. C19 had a strategic purpose identified by Kommers as:

• identifying complementary learning/teaching methods that are needed in order to make CONSTRUIT! more complete and overall more successful (CONSTRUIT!+ or even CONSTRUIT!++)

• making CONSTRUIT!++ more self-contained not just by packaging tutorials as video lectures on the web (MOOCs or OERs), but also by superimposing the current sequence of exercises with an instructional envelope that adapts the transition from scaffolding into autonomy to student characteristics like impulsivity/failure-anxiety, memory/reasoning ratio etc etc.

and the immediate practical goal of preparing the forthcoming LTT activities C15 at Athens and Scifest at Joensuu.

Much of the discussion at C19 focused on exploring the relationship between making construals and discovery-, experiential-, collaborative- and exploratory-learning paradigms that have been studied over the last four decades. This led on to an extended email discussion that was documented by Steve Russ (see http://go.warwick.ac.uk/em/construit/year2/interimreview/aboutconstrualssummary/). Central to this discussion was the status of the notion of 'making connections in experience' to which making construals appeals. The interpretation of 'experience' in this context, which derives from James and Dewey, is controversial in that (unlike many other uses of the term) it refers to experience 'as lived', 'immediate' or (to borrow an informal colloquial phrase that has no scholarly pedigree) 'in the moment'. The controversy as to whether experience can ever be other than the result of reflection, however 'instantaneous' that may be, featured at C19 in a memorable sequence of exchanges that in some ways resembled a 21st century re-run of the debate between William James and F H Bradley, as recorded in James's Essays in Radical Empiricism (cf. https://www2.warwick.ac.uk/fac/sci/dcs/research/em/wj_re_em/wjquotes/). Pope's perspective on this issue, as someone who had just invested much thought in implementing the interface between the MCE and physical devices, where issues of timing played such a critical part in the construction of 'observables', was particularly thought-provoking. Such issues are a vivid reminder of the philosophical questions raised by appealing to 'making connections in experience', obliging us to consider the status of 'time' in James's radical empiricism, and potentially calling an interpretation of James that refers to "experience in the moment" into question.

The status of 'immediate experience' may be a philosophical concern, but its practical implications for how 'making construals' is understood and received are fundamental. The trigger for the philosophical discussion at C19 was the reference made to Wiliam James in Kolb's seminal work on 'experiential learning'. It is quite possible to map the Kolb cycle onto a form of words that can be readily applied to 'making construals' but refers to experience only in a prosaic sense. Adopting a similar perspective can seem to dissolve the distinction between 'making construals' and other activities such as 'constructionist learning' (and 'agile software development'). Of course, it may be that some practices in experiential and constructionist learning and agile software development are based on precisely the same principles as 'making construals'. The prominence given to modelling with dependency in many contemporary applications suggests this. Distinguishing between the different kinds of practice in these fields is nonetheless crucial to a better understanding, and the nature of the appeal to experience is critical in this respect. The shift in perspective that the project has commended is implicit in Kommers's summary of what has been achieved in CONSTRUIT!:

"CONSTRUIT!'s goal to implement the specific constructivist moment of sharpening learners' understanding through experiencing an algorithmic emulation [interaction with a construal] has been materialised further throughout the project stages. In terms of contributing to the actual state of learning theories, CONSTRUIT! can be viewed as a significant step forward in clarifying and illustrating what actually constructivistic learning implies and what it may entail in coming years. ... from the participants' empathy with CONSTRUIT!'s methods and JS-Eden's growing implementation it became clear that essentially there is a match with didactic notions like discovery-, experiential-, collaborative- and exploratory learning paradigms from the prior four decades. However the observations in CONSTRUIT! also helped to detect obscure spots in those attempts and delivered a more clearly articulated agenda for future research."

Further elaboration of this agenda is beyond the scope of this draft, and would be an appropriate subject of another paper.

A secondary theme that emerged from C19 was the idea that making construals should not in fact to be regarded as aligned to any specific pedagogical strategy, but as an enabling technology that can have an important influence especially as far as digital support for learning in a constructivist tradition is concerned. Broadly, making a construal is a means of expressing an understanding that is quite general; it can be applied to knowledge that we construe as objective and might choose to represent by logic but its power and interest mainly derives from being able to capture much more primitive aspects of knowing, for which (in keeping with James's notion of radical empiricism) 'being able to make specific connections in experience' is the archetype. The benefit of making construals for learning is that the interplay between what is accepted as 'knowledge' and what we personally experience as knowing is fundamental. To question the status of a Jamesian notion of experience is to deny the legitimacy (and potentially the authenticity, if not the very existence) of meanings that cannot be articulated formally. In the process, the concept of learning is necessarily diminished. In fact, making construals can play other roles that are not perhaps so readily characterised as 'learning' since they serve to problematise rather than to consolidate knowledge. In other contexts, the term 'provocative modelling' has been used to describe the way in which making construals discloses rather than closes the gaps in our understanding (EM paper #120).

At C19, learning in mathematics was the topical subject we discussed with reference to the educational value of making construals. Steve Russ was interested in how making construals could help to illuminate abstract mathematical concepts such as 'ratio' and 'proportion' that have a long historical pedigree. He related this to concrete illustrative examples that might be used to convey these abstract notions to schoolchildren. Meurig Beynon and Jonathan Foss implemented a construal that illustrated properties of ratio that were recognised to be difficult for the learner to understand in a concrete everyday life example; though this drew on one of Russ's illustrative examples, it stemmed from misconstruing his motivation. The status of mathematical abstractions in a Jamesian perspective was a relevant issue. Beynon demonstrated three examples of educational applications which exploited a construal of number representations in conceptually different ways: each contextualising mathematical relationships using a different strategy (cf. https://www2.warwick.ac.uk/fac/sci/dcs/research/em/construit/year2/interimreview/). This prompted Kommers to characterise making construals as "the obstetrics department for educational design".

The potential role for making construals in computer science education, and in the "Computing At School (CAS)" context in particular, was a natural focus of interest throughout the project. Attracting the interest of this community turned out to be most difficult. Making construals is most naturally aligned to an epistemological account of computing, one that asks searching questions about the nature of the agency that carries out the computation. As far as making construals is concerned, the archetypal model for meanings is found in the spreadsheet, where everything hinges on the correspondence between numbers in the grid and significant observables in the context to which the spreadsheet refers, as experienced by the user. For many computer scientists, it is inconceivable that the semantics of spreadsheets can be qualititatively different from that of an abstract algorithm. To consider computational agency as constructed by establishing a particular kind of relationship between a person and the computer is an unwelcome idea. There is much more interest in the extent to which all disciplines can benefit from machine-like and rule-based thinking than in how far such thinking about computing is a confining construction that may empower the science of computing in some respects, but in other respects constrains it. Conference submissions to that community were the only ones to be rejected, and elicited perplexed reactions from reviewers. In the same way that the expert in pedagogy asks: "but isn't this just experiential learning?" so the expert computer scientist asks: "but isn't this just reactive functional programming?", setting aside the idea that the nature of the personal experience being invoked is critical in distinguishing one kind of learning or programming from another.

Perhaps paradoxically in view of the motivation behind CONSTRUIT!, it proved hard to attract an audience in the CAS forum because of the intense interest in how to teach academic computer science and programming most effectively. But neither did it seem appropriate to confuse dedicated teachers working against the odds to retrain as computing teachers from other disciplines. One positive outcome of the project was a better understanding of how making construals might contribute to computing education without being subversive (whether intentionally or unintentionally!). Making construals is in fact well-suited to constructing the kinds of artefacts and experiences that have been favoured in 'unplugged' computing education. The point of such artefacts is after all to take advantage of physical metaphors as a way of construing abstract mechanisms. An analysis that is observationally based is a most natural way in which to conceive such artefacts, and there are advantages in using the Construit environment to implement these on the computer. Curiously, neither the teacher nor the learner should be encouraged to ask the question 'how is this 'unplugged' artefact [the construal] implemented on the computer?' but there are advantages to the maker, as is apparent from the 'giving change' construal for instance.

Some further clarification may be useful at this point. In the course of the project, the question 'why make a construal rather than write a program?' has often been asked. It is indeed a question that is posed by Pope whenever some trivial functional objective has been achieved by making a construal and (as has been frequently remarked upon as a distinctive quality of construals) a minor modification to the construal realises another equally trivial functional objective. For the skillful programmer, writing a program to achieve a trivial functional objective is much easier than making a construal. This argument is a good reason why we should not make construals merely in order to achieve the effect of writing a program. But it is also a good provocation to reflect on why making a construal is not writing a program.

A construal is a physical artefact with which we can make connections in our experience state-by-state. A behaviour is some sequence of states for which the associated connections in experience follow a familiar pattern. If this pattern of transitions can be reliably retraced and automated it may be that the construal 'achieves a functional objective'. Conceptually, the transitions between states in 'the behaviour' are not different in kind from any other change of state we might initiate. They are distinguished only by the construction we put upon them, so that there is no counterpart of the distinction in kind between editing [changing the state of] the program and changes in the state of the 'executing' program.

An 'unplugged' explanation of why this is significant may be helpful. A familiar activity in CAS circles is the classic sandwich making exercise, where a student instructs a teacher impersonating a robot to perform a sequence of actions intended to make a sandwich. The teacher's task is to be as perverse as possible in misinterpreting the student's requests and so encourage them to be as precise and explicit in their instructions as possible. The moral of this exercise is that the student has to think very carefully about the programming instructions for a computer.

Reflection on the sandwich making exercise provokes some challenging questions. It is apparent that if a sandwich is ever to be made, this will be because the teacher exercises discretion over possible misinterpretation. 'Cut a piece of bread' may be taken to mean 'cut a piece of bread that has already been cut off the loaf' but perhaps 'place the loaf on the table', 'pick up the knife, 'place the knife on the loaf about a centimetre from the end of the loaf', 'orient the knife at right angles to the top of the loaf and parallel to the end with the blade downwards' etc might be regarded as a more plausible less ambiguous prescription.

The distinction between one set of instructions and another has much to do with making a construal. The teacher has in mind a set of observables that they are prepared to recognise as shared and a repertoire of actions that can be performed on them. The student has to recognise the difference between actions that 'belong to the program behaviour' ('cutting a slice of bread off the loaf') and other physically undifferentiated actions that do not ('cutting a piece of bread that has already been cut off the loaf'). If the teacher is in fact programmable, there is a construal to account for this. This is a good motivation for developing a construal to give digital support for such an unplugged exercise, but perhaps this is only essential if our intention is to highlight the fact that in general robust protocols for communicating with computing devices rely on crafting reliable primitive observables and operations.

The reasons for which, at this stage, it is inappropriate amd potentially counterproductive to take our overtures to CAS beyond 'exploiting making construals to support teaching computing in a traditional way' are most delicate. If we take the breadth of its epistemological agenda into account, and acknowledge the implications this has for computing and pedagogy, it is not that making construals is more complicated than other practices; on the contrary, in principle it is potentially simpler conceptually and technically because of its observational rather than behavioural orientation. By way of illustration, we may compare Phil Bagge's Scratch Coins program with the Giving Change construal (cf. the Giving Change construal [Construit #107]): much of the code in the program has to do with explicitly maintaining dependencies between observables and so detracts from what is semantically significant. The fact that making construals is so closely related to emerging software development practices (and that e.g. ODA mechanisms similar to those exploited in Construit are explicit in Apparatus environment developed by Toby Schachman: cf. http//aprt.us) is further circumstantial evidence that a simplification is involved. The key problem is that the principles and techniques behind making construals are out-of-place in the traditional 'computational thinking' setting and it is in general unhelpful to expose the computing teacher (whether novice or expert) to their influence. Indeed, the priorities in making construals are such an inversion of computational thinking that Kommers proposed to call it 'thinkutational computing'.

One of the most fascinating developments over the course of CONSTRUIT! has been the transformation of script management within the MCE. At the outset, the process of developing and executing scripts was logistically complicated by the fact that the definitions associated with making a construal were distributed between the JS-Eden interpreter and the external file system. One way of modelling an agent action was to include a file of definitions stored in an external file, for instance.

In the original prototype for MCE, as of C1 (cf. jseden.dcs.warwick.ac.uk/construit.c1), the maker viewed the MCE simply as an interpreter into which definitions were passed for execution. In the maker's mental model, there were many different ways of classifying definitions. At any given time, there was a script of definitions that had been interpreted: that is to say, had been fed into the input window and accepted. Since an input script containing one definition of an observable x might be followed by an input script containing another definition of x, the current definition and value of x depended on what scripts had been interpreted, and in what order. Part of the maker's mental model was then the set of extant definitions: this comprised the latest definitions of all observables that had been input. In addition to this, the maker might be interested in the history of the input: the entire sequence of definitions that had been input. Support for these various components of the maker's model was provided by means of views that could be constructed e.g. by typing a search expression into an Observable List.

In practice, when making a construal, the conceptually interesting activity was associated with editing scripts in external files, and inputting definitions to be interpreted by a cut-and-paste technique. The contents of a file might have very different significance. One might have a block of definitions intended to restore the values of a set of observables to their original values. Another might comprise many alternative definitions for the same observables, and serve as a record of alternative options with which the maker wished to experiment. The files associated with a construal would typically be organised in a directory, and there would be some kind of 'run' file that specified what files were to be included in what order so as to set up the construal, or restore its previous state. Ensuring that these files were maintained up-to-date and that the way in which they were input was properly recorded was an important file management task. Sharing a construal with someone else meant preserving appropriate versions of the files within a directory together with an appropriate run file.

This complex process of managing scripts was only possible because of the way in which interaction with the construal was guided in a live manner by making-connections-in-experience. In many cases, the construction of a complex construal had to be scaffolded by a commentary that gave insight into the meanings behind the maker's definitions. This commentary required an auxiliary script that was interpreted alongside the unannotated definitions.

In understanding a complex or unfamiliar script, there were many significant logistic problems:

• identifying the meanings of observables from their names
• organising windows on the display
• managing the evolving versions of construals as they were being constructed
• preserving a point of reference in the construal state
• many applications required extensive replication of similar observables.

Nicolas Pope's design for the Construit environment, as implemented with the support of Jonathan Foss and Elizabeth Hudnott, has been a major achievement of the project. Construit has eliminated the dependence on an external file system and text editor, integrating the script into a single source that is assembled automatically from subscripts specified by the maker, ensuring that construals are retrieved in a consistent state, and enabling projects to be recorded online in such a way that previous versions can be readily inspected and retrieved. It has introduced a construct that allows scripts to be specified much more concisely and in a far more homogeneous way, and means to annotate observables for search and reference. Commentaries on scripts can be expressed using a mark-up notation in a book format in a screen resolution independent manner. This has transformed the way in which mature construals can be presented and communicated. Most importantly, these qualities have been introduced without compromising the environment as a playground within which the expert maker can experiment freely wth scripts in a loosely organised fashion. The potential for construals to act as objects-to-converse-with has also been respected through adding support for public comments and for peer-to-peer communication between construals.

In a report that intended to review and reflect the feedback from CONSTRUIT!, it is appropriate to highlight the radical implications that feedback has had on the design of the MCE in this way. As far as providing the resources for an online course on making construals is concerned (cf. Intellectual Outputs O1 and O2), the new modes of presentation have made open independent access to 'virtual workshops' much more realistic (cf. the construal of online resources for making construals [Construit 340]). They have also transformed the scope for the conversations about topics scaffolded by construals that are essential for dialogue between learners, teachers and expert makers. Such conversations can be one-to-one and occasional initially but could in principle evolve into co-design activities based on live interaction with peer-to-peer communication. To enable such a practice, there is an urgent need for a body of expert makers (who might in the first instance be higher education students with good computing and communication skills similar to those who sustained work on making construals prior to the project) who can play the role of consultants. The Construit archive currently has many projects that can serve as prototypes for OERs for a wide range of learning applications, but only with the input from practising educators, teachers and learners can a more coherent archive of practical exemplars suitable for classroom use be developed (cf. Angeliki Theodosi's pioneering work with regular polygon construals [Construit #267]).

Where the six key claims for making construals are concerned (cf. go.warwick.ac.uk/em/construit/sixclaims and Intellectual Output O3), the development of the MCE over the course of CONSTRUIT! has without doubt dramatically enhanced their credibility. The claims themselves originated from intimations about unusual qualities that were documented in the work of students prior to CONSTRUIT!, but they reflected personal experience that was acquired only through using practical computing survival skills that allowed them to navigate the jungle of logistic problems cited above (not to mention other idiosyncrasies of the original tkeden desktop environment). Construit has eliminated much of the accidental complexity in previous environments for making construals and demonstrated far more compelling proof-of-concept for each of the six claims: enhancing accessibility and comprehensibility; scope for collaboration and instrumentation; the potential for new modes of collaborative development of OERs; and the connections between making construals and contemporary computing applications. Jonathan Foss's construal of the Artiphon [Construit #37] stands out as an exceptional illustration of what is possible in principle by way of authentic practically useful personal learning supported by making construals.

Making construals can be seen as the practical face of a larger project, the Empirical Modelling project (go.warwick.ac.uk/em). CONSTRUIT! has deliberately striven to maintain its focus on promoting a practice and avoid intimidating potential learners by explicitly exposing them to the deeper questions about its status in relation to established thinking about computing and education. As Kommers's proposals for CONSTRUIT!++ indicate, it is exceptionally hard to give making construals greater credibility without acknowledging the social, political and philosophical context that surrounds it. Though the number of affirmative references to Empirical Modelling at CONSTRUIT 2017 is a source of encouragement, there is still strong evidence of resistance to its grander pretensions to a broader view of computing and learning. Few people, even amongst scholars in other disciplines, favour placing the thinking of William James alongside the legacy of Alan Turing (cf. EM paper #115).

Though CONSTRUIT! has had modest practical success in dissemination to schools as its declared primary target group, the overall response from higher education students, schoolchildren and schoolteachers at the annual events in the UK, Greece and Finland has been most encouraging, and its future prospects should not be underestimated. In the face of such formidable barriers to its acceptance as a holistic mode of thinking and practice, a pragmatic approach to promoting making construals has much to commend it. In this, the Construit environment has a central part to play.

In due course, several factors may assist the cause. The affinity between making construals and the culture of making, thinking and learning is an important incentive for the adoption of Construit. New technologies that are becoming affordable and prevalent, such as 3D printers, Virtual Reality devices, educational robots, electronic construction kits and large high-resolution displays, can benefit from the simpler interfaces conceived in terms of observables, dependency and agency that Construit affords. Future changes to software practice may also create the political imperative to re-orient computing education in schools in congenial ways.

References

• For references to CONSTRUIT 2017 see
  go.warwick.ac.uk/em/construit/conference/programme/
• For EM papers, consult
  go.warwick.ac.uk/em/publications/papers
• For more details of the LTT activities C1, C2, ..., C20 conducted in the project, consult the links from Year 1, 2 and 3 at
  go.warwick.ac.uk/em/construit/
• To access construal #X developed in the Construit environment, go to the url:
  jseden.dcs.warwick.ac.uk/construit.erasmusplus?load=X
• For details of other online resources from CONSTRUIT!, consult the online resources construal [Construit #340] at:
  http://jseden.dcs.warwick.ac.uk/construit.erasmusplus/?load=340
  which includes full details of the publications from the project.

---

Appendix

This report has drawn on feedback from:

• the workshops with Athens school teachers organised by Edumotiva at C14, C2, C15 and C16
• the workshop activities carried out at Scifest 2015, 2016 and 2017
  [Hex Colouring/Light Box/NIM, Shopping, Mars and Arduinolas, Internal Combustion Engine]
• the C5, C6 and C7 activities with HE students

and other learning activities that include:

• Jonathan Foss, the Artiphon construal
• Eemil Tarnanen, sin and cos "oscilloscope" construals
• Errol Thompson, 7 stone NIM construal
• Angeliki Theodosi, regular polygon construals for the primary school
• Hamish Macleod and WMB, lesson plans for the OXO laboratory
• Jeremy Chan, Mechanics simulations, 3rd year ug project
• Matt Roman, Construals for Linear Algebra, 3rd year ug project

Conference workshop events

• ICL 2016
• UK National CAS conference 2016
• <i>TAG 2015, 2016
• KST 2016, Chiangmai, Thailand
• CONSTRUIT 2017

Miscellaneous other workshop events including

• Newman University
• Cheltenham Festival
• CAS Local Hub events
• an informal experimental workshop with music teachers
• Nottingham Trent University students
• May Day Open House
• King Edward VI Grammar School, Stratford
• Peer-to-peer Hangman session