Some interesting issues were raised by the discussions that took place in the course of the C1 and TPM1 meetings. I have limited my comments on these to relatively few lines that might serve as an aide memoire that could be the basis e.g. for topics for further discussion / exercises in making construals / abstracts for joint papers at some stage.

A. Hamish's observation (S9) about the potential for making a construal as a way of expressing personal identity was appreciated by Karl King. It echoed Piet's remark about the existential value of learning by making construals, and Erkki's informal observations about the potential value of EM for enhancing self-confidence and passionate personal engagement. There is a strong connection to be made here with a proposal we've often toyed with for making construals as a way of confirming personal identity. That is to say, you can discriminate between one person and another by considering what kind of construals they can make (as in for instance connecting a collection of names with a branch of the family, or interpreting a set of abstract directions as a route from their home to the nearest post office etc).

B. The reflections on JS-EDEN from Peter and Ashley were thought-provoking.

i. Peter described a vision for a tool based on a graphical user interface with dependencies that can be explicitly entered. This idea was explored to some extent by Allan Wong, who completed his PhD in 2003 (see http://www2.warwick.ac.uk/fac/sci/dcs/research/em/publications/phd/awong/). Allan's Dependency Modelling Tool prototypes, which allowed scripts to be represented graphically and manipulated into an appropriate visual form by the maker and in some variants enabled definitions to be edited via the GUI, can be found in the EM project archive: see http://empublic.dcs.warwick.ac.uk/projects/dmtWong2003// An alternative treatment of a similar theme was the DVDMT implemented by Richard Myers, who implemented Web EDEN. This used automatic layout strategies. (Though there are undoubtedly merits in automated layout strategies, there is also a case to be made for manual organisation of observables, which can reflect understanding that is only accessible to the human interpreter.)

ii. Peter proposed that we survey the contents of the projects archive to identify models that make the least use of functions and procedures that require conventional programming. The linesBeynon1991 model in the archive is an example with no procedures that is nonetheless relatively difficult to comprehend (though the model does involve introducing many special-purpose functions to specify dependency relationships). I take the point that the case for making construals as a simpler approach than/to writing programs is potentially undermined by this need for basic conventional programming skills. I also take the view that the difficulty in specifying procedural code can be reduced when making construals so that it is far from requiring the level of mastery expected of an average conventional programmer. This is the code for conducting heapsort in the construal heapsortBeynon2008, for instance:

first = 4;
last = 7;

next=0;

proc heapmake : next
{
	if (next && first>1 && is_heap) {
		first--; next=0;
	}
}	

proc outsort : next
{
	if (first==1 && last>0 && next==1 && is_heap) {
		last--;
		exc(1,last+1);
		next=0;
	}
}

The interpretation of this code is very direct, and describes a sequence of simple (in context!) meaningful actions that is first rehearsed manually, then automated. The fact that actions are meaningful stems directly from the fact that dependency has been used to model the context for action so precisely. This is in sharp contrast to what is involved in explicitly writing the heapsorting procedure (though to be fair, exercising the construal does not have the same performance characteristics as conventional heapsorting).

Other more radical approaches to developing an MCE include the Abstract Definitive Machine, in which all changes of state are modelled by redefinitions triggered by touching observables. This can eliminate traditional procedures. The ADM is a more advanced topic than 'making construals' in the CS405 module (cf. http://www2.warwick.ac.uk/fac/sci/dcs/research/em/teaching/cs405-1112/theadm.pdf). Ruth King prototyped a version of the ADM for JS-EDEN in her WEB-EM-10 submission. There is also a prototype environment called Cadence, developed by Nick Pope, that seeks to express every dependency as conceptually derived from simple incidence relationships. This was one of the subjects of study in CS405 for some years (cf. Lecture 1 and Lab 1 of CS405 in 2010-11: http://www2.warwick.ac.uk/fac/sci/dcs/research/em/teaching/cs405-1011/).

iii. Ashley gave an eloquent critique of the JS-EDEN interface and its poor useability. His suggestions were particularly relevant to the challenges that I faced when trying to use my MENACE construal and commentary to trace my stream of thought in a public fashion. (Indeed, even more topical were the challenges you faced in interpreting what I was doing.) There is a lot of sense in what Ashley is saying if there is ever to be a prospect of effective use of JS-EDEN for making non-trivial construals on a standard mobile device or average laptop platform. After my painful attempts to walk us through the MENACE construal with the OHP, I realised that this is not at all the kind of application of JS-EDEN that I intend to promote in making construals, nor is it similar to what I practised in making the MENACE construal and commentary (where I had two relatively high resolution screens for display purposes - and exploited the possibility of dragging the browser across both).

I don't regard instances of plugins like Symbol Lists, Canvases, Input Windows and the like as components of an interface in the conventional sense, but as constituents of the construal itself that - when configured in appropriate ways through the disposition of panels in the browser window and the selection of appropriate clusters of observables within the panels - enable me to experience the relationships between different 'representations' that are fundamental to the process of making construals. These are the features of the more recent variants of JS-EDEN (i.e. those that are oriented towards allowing customisation of the JS-EDEN display and layout) support. Amongst EDEN interpreters, these features are unprecedented (cf. tkeden or Web EDEN for instance), and are strong motivation for favouring the terminology of 'instrument' and 'environment' over that of tool.

There are two ways in which I'd like to elaborate on this theme:

Firstly, I'd like to demonstrate the practical benefits of environments with multiple screens that the audience can inspect at close range e.g. by giving a compelling account of making a construal of MENACE. Note that for this purpose, I can take advantage of the fact that the state of two or more instances of the same construal on different workstations can be synchronised by entering the same sequence of redefinitions into each instance, so that multiple perspectives on the same state can be simultaneously displayed. (Recent proposals by Ashley for communicating between instances of JS-EDEN may provide a simpler way to achieve this synchronisation.)

Secondly, I'd like to explore the extent to which contemporary technological developments, like mobile devices, whiteboards, and twitter - as opposed to currently less-fashionable workstations, banks of blackboards, and email - may present barriers to certain kinds of learning. The general idea is that nurturing and communicating the stream-of-consciousness is not well-served by working in environments that limit the scope for simultaneously presenting experiences that are to be connected in the experience of the learner, and that privilege little squawks of procedural output that perturb our contemplation of a small pool of pixels over extended commentaries on slowly evolving panoramas of state. There is potentially a basis here for critiques of mobile and distance learning - by which of course I do not mean entirely negative critiques.

C. Peter made several insightful observations about the techniques that I was practising in the MENACE construal development. One was the comment about the 'trickiness' of the encoding of the O, X and blank status of squares in the grid using -1, 1 and 0 respectively. If I understand correctly, Peter's comment is that this is just the kind of choice of representation that appeals to a mathematician, but baffles those who have to decrypt such representations. A somewhat related comment was the observation that "html is the machine code of the web" - where the inference is that some alternative way of keeping this kind of representation out of the sight of the maker is appropriate.

Both of these comments are concerned with the relationship between two perspectives - that of the human agent, who interprets interaction with the construal in meaningful terms, and that of the computer which interprets the construal as a recipe for automated activity. In traditional programming, managing these two perspectives is indeed an exceptionally tricky problem, and it's common for the representation of state to be reconfigured in order to accommodate - or balance - the needs of both agents as well as possible. The choice of 'good' representations is such an important issue that, in a large programming task, a great deal of effort is expended in the design of appropriate data structures - taking account of the agendas such as intelligibility to the human, convenience for the user, efficiency for the machine, and customisation to suit the specific computational objectives.

One of the most significant qualities of dependencies, as engineered when making construals, is that they can mediate effectively between different agent views. The correspondence between 1, -1, 0 and 'X', 'O' and 'empty' is repeatedly reinforced in the interactive experience of the maker till it becomes an element in the integrity of state that is apprehended unconsciously. Rather than having to fix on specific representations, it is possible to use dependency to make automatic links between different representations so that the transformations between them that are being invoked are implicit and hidden from the maker. Of course, the connections that can be experienced by the maker in this way are highly personal in nature (cf. reading in your own language vs reading in a foreign language), but they are quite different in character from the connections that have to be figured out over-and-over-again through mental gymnastics when interpreting state in a conventional program execution.

The status of html in this context is an interesting issue. Personally, I value 'experiencing' the relationship between raw html code as viewed in a text editor and the realisation of this code on a webpage (for me, another two-screen activity). I use only a very basic repertoire of tags in a way that allows me to shape the raw text so that it reflects quite accurately (and as I see it, quite economically) my intended meanings as these emerge. A very important element is the html comment facility, which allows me to document my thoughts as they arise. I'm not sure that I can imagine a way of creating a webpage (e.g. by a WYSIWYG-style interface) that would give me the power to savour the construction of text to the same degree. On that basis, the idea of 'html as the machine code of the web' seems irrelevant, if not suspect.

By and large, I have found that using dependency to overlay and interleave different styles of representation in making a construal eliminates the need for making choices between representations, and for the from-scratch reconstruction that is involved in re-factoring or the adoption of new data structures. This freedom to weave structures on-the-fly can be abused if it discourages the maker from making thoughtful initial choices of representation, or from observing any discipline in the specification of structures. Similar considerations apply to the maker's conventions for naming observables, which can take advantage of the interactive access to meanings of observables that making construals affords. I am often more mischievous than I should ideally be where designing data structures and observable names are concerned, but this is partly because the crafting and blending of multiple viewpoints whose relationship one to another is in no way preconceived is a crucial ingredient of making construals that needs to be kept in the foreground. Another consideration is the evolving nature of a construal, whereby the meanings of observables are subject to change - typically becoming enriched - as the development proceeds and the scope for switching contexts so as to sustain different viewpoints becomes greater. Despite this, as Karl and Ashley have pointed out, it would be a good idea to encourage the adoption of particular conventions for naming observables with a view to making collaborative development easier.

D. For me, the most perplexing sessions of the C1 meeting were those on Monday afternoon and evening when we came to look more closely at the evaluation components of the Intellectual Outputs (O2 and O3). The discussion was primarily focused on how we might evaluate the benefits of making construals in relation to some specific target topic significant for schools, and for this we sought to identify a target age group and subject from the established school curriculum. The curious thing is that no such evaluation has been described in the proposal: the evaluations associated with O2 and O3 are not explicitly concerned with whether construals are a 'good vehicle for teaching some other subject'. Indeed, both O2 ("is the online course O1 effective in teaching learners how to make construals?") and O3 ("is there evidence to support the six key claims about making construals?") are evaluations concerned simply with 'making construals'. Reflecting on this after C1, I realised that this is because the aim set out in the proposal is to demonstrate that making construals has six qualities that are generically relevant to connecting 'making construals' with learning. I also recalled that - even though the proposal makes school education the most central of the 'many fields of application' - it motivation is fundamentally about a new computing practice for which significant implications for education are being claimed.

There are two perspectives on this.

From a pedagogical perspective, what we have by and large seen in practical work on making construals over many years is evidence of students being able to realise, elaborate and communicate their personal understanding of topics about which they typically have long experience and expert knowledge. Though we have tried to make it plausible that making construals can enable novice students of a particular established curriculum topic (such as linear algebra, which was a central focus for the Emile project conceived by Steve Russ) to clarify and share their provisional understandings (and mis-understandings), I don't believe we have yet succeeded. There is a strongly held perception amongst educational researchers that, where computing in education is concerned, technological innovation is not the point - it is all about the activities and the context for use etc. This is a point of view justified to a large degree by the fact that time-and-again the advent of some novel technology has been promoted as about to revolutionise learning, only to be supplanted in this role by the next novel technology. Properly understood, we should not regard making construals as yet another 'new technology', but as a practice that can be recognised in all kinds of construction with or without modern technologies - and that can be exposed and brought to fuller maturity most effectively through exploiting the unprecedented qualities of computers. This should be more congenial to educational researchers as innovation that is quite as much concerned with how we interact with computers (cf. the maker's understanding of a construal) as the technology itself (cf. the inconceivably rich patterns of agency that a computer-based construal can embody). This can I'm sure be better expressed, as I hope it will be over the course of CONSTRUIT!, but I think there is some indication that we are making progress in bringing the pedagogical and technological perspectives into clearer focus from comments made by Piet by email since C1 to the effect that "it is my impression that the learning events appear in quite different patterns compared to when students 'learn about' a new topic. It seems to me that the topic and learning experience coincide to a large degree."

From a technology perspective, it is important to appreciate just how unsatisfactory much thinking and practice in software development has proved to be. The longstanding problem of adapting to changing requirements is fundamentally linked to the problem of binding construction intimately to learning about the domain. The motivation for studying making construals (as I see it) is that there is no better way to create software with and for novel applications (embryonic as this practice is at present). This is what is most critical in the development of educational software, where the trajectory of every learner requires ever-evolving 'novel applications'. And though there may be little as yet to indicate that we are doing anything to make computing more accessible to the non-specialist, that is certainly our aspiration - and even expectation. Hopefully some of the perceived barriers to making 'making construals' accessible stem from legacy thinking about computing: realising that objective means complementing the ingrained habits of computational thinking with a fresh outlook and orientation.

One important issue to be borne in mind is that the words to describe the learning experiences that we have not yet understood and enabled have already been written a million times. It is 'obvious' (or is this controversial?!) that learning about the objective world is the result of private learning experiences and realisations that have empirical roots. The thesis of constructivism is that the objective world is constructed in this way from personal perceptions. As Latour has pointed out, notwithstanding all the literature about constructivism, we have no adequate notion of 'construction'. And (to take perhaps a controversial Jamesian stance) construction is something we do, not something we can characterise simply through description. Not unrelated to this is the fact that we can develop rich and plausible descriptions of programs, models - and indeed construals (cf. the Google Group discussion on 'defining construals'), but need to be bear in mind that this does not translate directly into insight into programming, modelling and 'making construals'.

E. As a footnote, it was interesting how many valuable discussions were initiated by what might be considered 'misconstruals'. From 'assuming the perspective of a child on playing noughts-and-crosses' (as an educational psychologist might), we ended up thinking a great deal about whether and how young children might engage with making construals. From 'who will carry the work forward', by which I had in mind the students who have made so many core contributions to the agenda for CONSTRUIT!, we moved on to considering where the leadership of the project might migrate to post-CONSTRUIT!. From 'creating an interface', by which I meant the kind of meta-configuration of websites that we are now putting in place, we opened up the discussion about the importance of issues that were not amenable to technological solution. Had we but made construals, just imagine what informative diversions we would have missed.

---