Welcome to CONSTRUIT!! Steve and I are delighted to have the privilege of bringing together such a consortium of experts in educational technology from across Europe. Being able to discuss with such an audience the work that we have done in collaboration with several generations of students in computer science over the last twenty five years or so is a dream come true. We know that we have a lot to learn from the expertise and experience of our partners, and believe that there is great potential in our collaboration for further developing and disseminating an approach that can bring something genuinely new to education and computing. We also know, from long experience, that - even though there are rich connections to be made between your research and the theme of 'making construals' - it will take some time for these connections to be more fully understood. In that respect, the project is itself an exercise in construal. And whilst we, and you, are very eager to hear what everyone has to say about their potential contribution to this project, it is important to bear in mind that the primary function of this C1 meeting is "Familiarisation with making construals".

Cautionary remarks ...

1. If, as a result of C1, no-one from the project team goes away with enough understanding EITHER to practice making construals themselves OR sufficiently convinced of the merits of making construals that they will encourage others to adopt this approach, then the entire CONSTRUIT! project is vulnerable.

2. During C1, questions about what we DO when we are making construals are encouraged. Questions about what we THINK we are doing when we are making construals will distract us from achieving the desirable outcomes stated in 1. Such questions will be welcome at the TPM and more welcome in the later stages of C1.

For those of you who will insist on thinking :) about what we are doing, here are some intimidating and provocative observations to keep you occupied ...

C1 aims to introduce to principles for making construals. Making construals is intimately tied up with expressing and developing our understanding of the agency that we think is at work in a situation.

a. From a functional 'user' perspective, it is possible to apply the principles we shall introduce to build anything that can be made by conventional programming methods. Likewise, insofar as a construal can be interpreted from a functional 'user' perspective, it is possible to replicate this behaviour precisely (and typically much more efficiently) by adopting conventional programming methods. The significance of a construal rests entirely upon how it has been constructed and how it is and will be conceived.

b. (A corollary to a.) What is distinctive about a construal is not expressed by 'its functional specification' - indeed, it doesn't have one. A construal is intended for the maker, and admits interaction that cannot be characterised as 'use'. A maker's interactions with their construal is more general than 'use'; by then restricting interactions, a construal can typically be 'used' in myriad ways. It is characteristic of the maker's interactions with a construal that their interpretation is as yet unknown - an interaction need not have a preconceived interpretation, and is not even guaranteed to be interpretable.

c. The significance of a construal is essentially personal; it depends entirely upon how it relates to the experience of the person who interacts with it. Everyone who interacts with a construal in an authentic way (i.e. in a way that respects its character as a construal) becomes a maker. There is no proposition about the status of the elements of a construal or the relationships between them that cannot be contradicted at the discretion of the maker ("if something is true, it is only true NOW, and only because the maker takes a conscious decision not to make it false").

Making connections with existing software and practices ... some reflections:

• You are not advised to regard 'making construals' as practised in CONSTRUIT! as a technique for which there is a precedent in existing software. This is not to deny that there is software and an associated practice which in some respects resembles 'making construals' in terms of "how it has been constructed and how it is and will be conceived". The distinction between the environment for making construals we are developing and other software comes down to how we aspire to empower 'the maker'.
• A characteristic of much state-of-the-art software is the use of dependency in some way. Examples include: GeoGebra, Interactive Physics, Scratch, Chris Gardner's forthcoming EVE environment - and of the course the EU Erasmus+ proposal forms. In broad terms, our perspective is that dependency is semantically exceptionally powerful, but when it is exploited in a context where software is being conceived in conventional terms, it can be a highly disruptive influence. In making construals, identifying, specifying and manipulating dependencies takes precedence over all other semantic devices.
• By way of specific illustration of how dependencies feature in software: when you set up a spreadsheet, you can introduce speculative or nonsensical definitions into cells. Even an end-user can mess up a spreadsheet if they wish. What you can't do in the characteristic role of someone setting up a spreadsheet is decide not to organise data in a grid or to visualise the data in some completely personal off-the-wall manner or make the data depend on the GPS location of the device its running on.
• The fact that it matters how software is constructed should come as no surprise: it is well-known that it is hard to adapt software to new requirements. In other words, although two pieces of software can have abstractly the SAME functionality, everybody knows that one may be easier to adapt than another. You may well ask, how can we possibly make it easier to adapt a program for a new context when the degree of novelty cannot be known? The answer to that is: how well-prepared we are for novel experience in a domain depends critically on how well we understand the sort of agency that is potentially at work in that domain. We may not understand it well at all, which is why making construals is no silver bullet - though it may well be our best shot.
• Relating software construction to learning about the domain is naturally connected with the problems of adapting to new circumstances and understanding about a domain. To unify constructing and learning is an extreme form of adaptation, where we need to reconfigure our constructs in a way that is intimately linked with our shifting conceptions. The history of Logo suggests that realising Papert's vision for constructionism in this style is not a solved problem. Thinking about software construction with the traditional categories of activity in mind: requirements capture, specification, design, programming, human factors, testing etc is a major barrier to the kind of migration from role to role in construction that is ideally needed to support constructionist learning.
• The computer is commonly used as a way of making what is difficult for the human mind to comprehend accessible. Computational thinking is a way to abstract from the unfathomable perplexities and subtleties of 'real life' and find the simple rules that (if sometimes only on the face of it) give us control and intelligence. In making construals, the emphasis is on how we can also use the computer to expose the extraordinary richness and contingency of human interaction even in what appears to be the most uncomplicated situation. The excitement in making construals is not primarily about what goes on on the computer screen, but in the maker's imagination. (My son Will and I toyed with characterising this quality of making construals as 'provocative modelling', but this term already has an accepted meaning somewhat reminiscent of the distinction beween 'hyperfun.org' and 'hyperfun.com'.)

---