Here is some general feedback on the modelling studies and papers you submitted for WEB-EM-9.The overall standard was good, and I was impressed with the level of engagement with the ideas and tools. I appreciate that it was difficult for you to devote time to this assignment in the context of other deadlines, and it was a pity that several students who submitted abstracts were unable to complete the assignment. If you would like to have more detailed personal feedback, please contact me by email to arrange a meeting.

This year's submissions to WEB-EM-9 were quite exceptional. For the first time since EM coursework was first introduced, not a single submission used the long-established EDEN interpreter. This was particularly surprising given that the alternative that everyone adopted - the JS-EDEN interpreter - is still relatively immature.

The Modelling Studies

My first impression on reviewing the submissions (eleven in total) was that your JS-EDEN models by-and-large did not compare in sophistication with good-old tkeden ("trad EDEN") models. To some extent, this can be attributed to the fact that JS-EDEN is itself work-in-progress, and there are still issues that can make it frustrating to use, and slow down the development. But there is also a positive side to the experimental activity with which many of you have had to engage. Having looked in detail at all your modelling studies, I can see many subtle ways in which the potential for using JS-EDEN to support EM has been illustrated and explored:

• integrating human and computer agency [e.g. Marshall]
• implementing environments where the scope for interaction depends on internal observables [e.g. Corbett, Yarnall, Shah]
• more effective web-based visualisation [e.g. Walton, Riley]
• exploiting JScript agency, as when interfacing with the keyboard via JScript "hacks" [e.g. Janssens]
• using JScript to bridge to the agent-oriented culture [e.g. Donnelly]
• reconceptualising JScript development in EM terms [e.g. Palimonka]
• deeper issues re design and implementation of EM tools [e.g. Sexton, Long]

These explorations will be helpful in future research and development for what are probably most appropriately called "instruments for EM". As part of my general feedback, I elaborate below on the way in which your work has helped me to clarify and reinforce thinking about EM that has been influenced by the advent of new tools that include Cadence as well JS-EDEN.

Where the use of JS-EDEN was concerned, my only disappointment was that some features that were ripe for exploitation were ignored. These included:

1. the html Model Readme: This was a place where useful and rich documentation of your models might have been included. As it was, documentation was not in general a strong point of your submissions! Where there was good documentation, it was not integrated into the model itself.
2. the showObservables() procedure: this feature was a useful way to focus attention on particularly significant sets of observables in your model, of the sort you might yourself have identified whilst model-building.
3. The Definition Factory: this only exists as a rough prototype so far, but it has been used quite effectively by Hui Zhu and is more straightforward to use than it might at first appear. As it happens, this tool is currently probably more relevant to developing trad EDEN models, where there may be extensive near-repetition of definitions.

The Papers

The standard of paper writing this year was generally quite high. Occasional points of weakness were:

• thinking of EM in rather too prescriptive terms, rather than as a conceptual framework that is broad enough to permit and encourage many alternative ways to approach a task. (Of course, it is important to emphasise the things that are distinctive about EM, so long as this is not in the spirit of 'this is how it must be'.)
• writing a conventional report on the model, following the format that would be appropriate for documenting a typical "closed-world" software development. In the first place, it's important to highlight the higher-level theme(s) behind your paper, rather than fill up space with low-level details. Secondly, I'm looking for evidence that you appreciate the potential for open-ended exploratory development that EM enables, and this is not well-represented in a report that has a sense of "this is how I arrived at the finished product and fulfilled the goals I initially set myself". The contrast here is somewhat related to the Jamesian concept of 'understanding forwards', rather than 'understanding backwards'.
• not using the specified format for the paper, not respecting the page limit. Once your ideas reach a certain level of maturity, it is appropriate to put your text into the standard template, as this helps you to shape your exposition, focus your ideas about how you can best use the space available, and achieve a good balance between topics.
• abuse of expressions. For instance, the term 'empirical model' is not a good alternative to 'EM model' (cumbersome, but semantically preferable, since what is commonly understood by 'empirical modelling' is not the same thing as 'Empirical Modelling'). Another often abused construction is 'as such', which should only be used when you have just characterised an object and are elaborating on what is significant about an object with these characteristics. "She is an English teacher. As such, she dislikes seeing the phrase 'as such' abused." (Cf. http://grammar.ccc.commnet.edu/grammar/grammarlogs4/grammarlogs536.htm)

Because using JS-EDEN promotes a richer view of EM than traditional modelling with definitive scripts, the communication challenge was sometimes great. I was impressed by the way in which almost all the submissions tackled the problems of organising what sometimes turned out to be a very rich agenda: background context, theme, model design and development, illustration, relevant technical considerations, evaluation, comparison with alternative approaches, reflection on outcomes etc. One way of keeping conceptual control of such an agenda is to choose suitable key words and concepts that you can link to each topic. (You can see the evolution of writing about EM as well-represented through the emergence of key concepts of this nature: model, observable, dependency, agency, metaphor, construal, context, referent, modeller/maker, definitive script, network of definitions.) When you use such key words, or if you venture new key words of your own that relate to your specific theme, the challenge is to use them in a consistent way throughout. To this end, it's a good idea to review the way in which you use each key word in the text on each occurrence.

Reflections on WEB-EM-9

A key issue to be considered in evaluating your submissions was how far your models could be construed in EM terms. Sometimes this construal related to re-engineering EM models in a traditional style (possibly - but not necessarily - explicitly, as when "translating" an existing model into JS-EDEN). In other contexts, it was a matter of conceptualisation: interpreting the development of a JS-EDEN model with reference to the ODA concepts.

The quality of trad EDEN models has often been assessed by the extent to which networks of dependencies have been used to represent state. This idea has been reinforced in the applications of the Cadence interpreter to EM, where there is really no choice but to conceptualise all state in these terms. As I see it, the motivation for using Cadence is centrally bound up with exploiting computers for making EM construals. The limitations of trad EDEN in respect of serious computer-based modelling of the kind that would be needed to address the challenges of practical software development more effectively were starkly exposed by Nick Pope in his doctoral thesis. These stem from its exclusive emphasis on 'modelling with definitive scripts', and motivate Cadence-like modelling. If you want to run EM models on concurrent architectures to support distributed modelling with performance guarantees, then you have to do something more radical than use definitive scripts, and the pure 'structural approach' to networks of dependency in Cadence looks to be the promising alternative. Likewise, you can't really regard the kind of modelling with definitive scripts that is practised in trad EDEN as delivering software fundamentally well-matched to the characteristics of the computer as an agent.

To put JS-EDEN as an EM tool into perspective, you need to think of EM more broadly as applying to modelling activities and construction that are not necessarily exclusively computer-based. In discussing the notion of construal, I have argued that it makes sense to think in EM terms even about the context in which Gooding first introduced the term construal, viz. interpreting the 19th century experimental practices of Faraday (cf. EM paper #114). If we accept that EM principles can be invoked even when construction does not involve computers, we are then able to view MWDS with trad EDEN as a hybrid activity, where some of the observables, dependency and agency are derived from different sources. To simplify what should be a much more nuanced argument, we can justify the construction of trad EDEN models - where (e.g.) functions are specified procedurally, inputs are derived from external devices such as wiimote, and triggered actions are used to mimic agency - in these terms. What ultimately matters is the quality of the experience that is generated, and the scope to manipulate the observables, dependencies and agency that mediates this experience in ways that faithfully reflect possible interactions with the referent.

Because of the rich culture that has already been established around JScript and web environments, JS-EDEN is ripe for exploitation for EM in this hybrid fashion. As your modelling studies illustrated, it is relatively easy to incorporate pure JScript agents (as represented in sliders, comboboxes, buttons and keyboard input etc) and functions (such as abound in JScript applications) into JS-EDEN models. At this stage in the development of JS-EDEN, it isn't appropriate to be too prescriptive about how these features should be exploited, and - for better and worse - many of your models necessarily have an experimental quality. In due course, it will be necessary to identify a more disciplined way of practising EM with JS-EDEN. There are 'features' of JS-EDEN, such as the purely accidental possibility of using the JScript "." syntax to manipulate the components of structures, that either have to be much better explained and consistently supported or deprecated. Features such as JScript comboboxes either need to be re-engineered in JS-EDEN or properly integrated so that their state is accurately reflected in all respects. At present, EM models in JS-EDEN resemble the pure EDEN translations of trad EDEN models in which additional domain-specific definitive notations feature. Whilst there are arguments against the proliferation of special-purpose definitive notations, it is important to recognise the role that these currently play in conceptual simplification (even if this is at the cost of technical complication!). For instance, many trad EDEN models have lots of Donald and Scout definitions. Each definition of a geometric component typically gets translated into an EDEN definition together with an action (triggered procedure) that updates the display. Provided that definitive notations are being appropriately used (so that lines and points serve as a good metaphor for observables in the referent, for instance), what gets to be generated in this translation is a body of observables, dependency and agency that is more amenable to meaningful manipulation. Bernard Sexton's investigation into using SVG in place of or in conjunction with the HTML5 canvas is particularly interesting in this connection.