These supplementary notes on JsEden serve several different roles. They are intended:

• to give you more context for the activities and exercises in the JsEden lab, and to guide any further practical work you may do with JsEden e.g. in your coursework;
• to give you more insight into the design and technical issues relating to the development of JsEden;
• to stimulate you to think about the characteristics of tools to support EM - which will be an examined (but optional) topic in the Summer 2012 examination.

0. The JsEden open source development project: JsEden was originally conceived and implemented by Tim Monks. Nick Pope is currently taking a leading role in making JsEden more accessible, and there is interest, encouragement and input from many previous developers - including Edward (Eden) and Simon Yung (tkeden), Antony Harfield (GEL/EMPE) and Richard Myers (Web EDEN) whose work on EM tools has also been influential. Ambitious goals for the JsEden project include: re-engineering the existing EM projects archive so that it is a resource that can be used to teach EM online (cf. the "apprenticeship" style of teaching that has been used here at Warwick), and - principally building on the Abstract Definitive Machine and Distributed EDEN concepts and the insights from Nick Pope's work on Cadence - to develop a new EM tool that realises the full potential of all these prototypes. (For more details of this project, see https://github.com/EMGroup/js-eden.)

1. Web-enabling EM tools: The first web-enabled version of EDEN - Web EDEN - was developed by Richard Myers in his final year project in 2007-8. Web EDEN has certain potential disadvantages: the EDEN models run at the clients are sent to the server for interpretation. so that load-balancing between a network of EDEN engines must be implemented - Web EDEN also relies on Adobe Flash for visualisation. These disadvantages motivate the alternative approach to web-enabling EDEN initiated by Tim Monks in his MSc dissertation: A Definitive System in the Browser in 2010-11. JsEden is a prototype that is based on a Javascript implementation of (as of now a simplified variant of) EDEN. A major advantage of JsEden over Web EDEN is that EDEN models run at clients and make much smaller computational demands on the server.

2. Cross-platform issues: The principles of EM seem well-oriented to addressing issues of portability in some respects. Concepts like observables, dependency and agency are not framed in machine-specific terms, and relate to experience that comes from many different sources within the modelling context. Richard Cartwright's work on Portable Content Format in cross-platform digital broadcasting demonstrated how the use of dependency can enable portability. Cadence also has qualities that allow diverse applications to be inter-linked using rich forms of dependency - including those that are process-like in character. Though web-enabling eliminates machine-dependence to a large degree, it raises compatibility issues at the browser level. JsEden uses features that may not be available in all browsers, but works fine - for instance - with recent versions of Firefox and Chrome.

3. Qualities of JavaScript for EM tool implementation: Traditional implementation of EDEN has relied on invoking procedural actions triggered by changes to observables. In tkeden, these procedural actions drive a tk/tcl interface which has to be explicitly programmed so that (for instance) when the coordinates of a point on the display are redefined, the point is removed from its current position on the display and redrawn in its new position. The effect of this remove/redraw activity is to maintain a dependency between the internal values of points and their visual counterparts on the display. Because JavaScript is primarily intended as a vehicle for managing the browser, and bringing its state up-to-date when the values of observables change, this aspect of dependency maintenance is much more simply implemented in JsEden.

4. Orientation of EM tools: It is important in reviewing EM tools to bear in mind that the primary motivation for EM was academic - rethinking computing - and (though model-building has an essential role in this rethinking) the practical usefulness of the tools was an incidental issue. There are two sides to this: a good conceptualisation should lead to a better practice, whilst existing good and effective practice should be something that we can account for in a satisfactory reconceptualisation. For instance, there are obvious qualities in object-oriented software development practices that are beyond the scope of EDEN, and it is clear that Cadence is much better oriented towards linking EM principles with good features of these practices. Now that the conceptual framework for EM is more mature, and we have gained more experience and a deeper understanding of EM tools like EDEN, Cadence and the ADM, it is appropriate to start making more concrete links with the practical software scene, and to distill how and where EM principles could be / are being applied. JsEden is an excellent place to focus this activity, since the software developments surrounding JavaScript have a lot in common with EM by way of character (e.g. diversity of application, human-centred and experiential emphasis, scope of metaphorical representations deployed) and techniques (e.g. the role of dependency relations, the open-ended nature of the development, the agile, participatory and distributed model of software development). (For more context on these issues, see the CS405 lectures on Imagine-Logo, and on Dependency in Action by Antony Harfield, and Eric Chan's thesis.)

5. Implementing agency at the interface: In championing EM as a new conceptual framework for computing, it has been natural to want to take a purist view of how notions like observables, agency and dependency should be deployed. The first definitive notation for window layout, Scout, was designed with a view to showing that every aspect of interface presentation and management could be framed in terms of primitive observables, dependencies and agency. The initial idea was that the relatively complex interaction and agency that surrounds interface constructs such as textboxes, drop down menus and radio-buttons could be reduced to its primitive terms and expressed with respect to the 'pure' model of display state that Scout affords. When VB-like features like textboxes with attendant built-in procedural actions were later introduced, the effect was conceptually highly confusing - to such an extent that the use of these features in Scout is deprecated. From a practical point of view, it is of course painful to have to build such interface mechanisms from first principles in EM every time, and this has been one reason why tkeden seems clumsy and outdated (cf. the fate of formal specification as a universal paradigm for software development). Harfield's Angel notation is an important extension of tkeden in this respect - it generalises what can be done in Scout in a way that does not conflate the agency in interface widgets with the agency that is most semantically interesting in building an EM construal. From a conceptual viewpoint, we then don't have to mix together the model of the "essential" macro-state of the referent and the inconsequential micro-states of the interface widgets. From a practical viewpoint, we can recruit agents that do the routine low-level interface interaction without incorporating models of their inner micro-states into our construal. In JsEden, it would be ridiculous not to exploit the agency of built-in widgets and instead attempt to realise their functionality from first principles.

6. Accommodating blind agency without violating EM principles: An underlying premise in the conceptual framework for EM is that potentially nothing of present experience can be discounted in sense-making ("everything you experience might be meaningful"). In practical living, we are always separating groups of observables according to their perceived relevance to topics of interest. The object-oriented software developer is unimpressed when you point out that in their imitation of an EM model of a vehicle there is no provision for immediately reconfiguring the steering wheel mechanism so that it adjusts the wing mirror. And I'm unlikely to ask you in the CS405 exam whether, when we discussed the distinction between a construal and a program, Steve's slide was showing in fullscreen mode, or it was raining, or we were both wearing socks of the same colour. But even when we do declare boundaries between different aspects of our experience, we can still treat the relevant observables from an EM perspective (e.g. as open-ended, and potentially richly interconnected in ways that are not preconceived). One way of using the JavaScript component of JsEden is to implement agency that - in this spirit - we can choose to discount as irrelevant to making meaning. For instance:

• we can accommodate agents as commentators quite easily without subverting EM - a commentator just says something about state "without changing it" (cf. the use of an Alert Box).
• we can admit agents (such as feature in window management systems and in the Angel notation) that dispose interface elements automatically. Though such agents undermine the notion of specifying very explicitly where interface components are disposed - in the manner of Scout - it may make perfect sense to presume that their intervention doesn't materially affect the meaning with which we are concerned. JavaScript is very naturally deployed for window management of this nature (e.g. the location of an Alert Box, and its relation to other visual elements of the display, need not be specified).
• we can use agents to help us to begin the exploration of a construal in specific places in the space of sense are also acceptable. Such agents simply help us to set things up so that the states of the computer and the referent are matched to the contextual state (cf. the use of a Prompt Box to initialise the EM OXO model according to which variant of OXO is to be played).

7. Designing the JsEden interface: Traditional applications, with clearly specified functional behaviours, benefit from neat and intelligible interfaces designed for users. There is currently great excitement about the potential for mobile devices where interfaces must be very compact. The systematic way in which software development is typically approached has promoted the development of Integrated Development Environments (IDEs). Where interfaces to EM tools are concerned, the priorities are rather different. Because the traditional idea of a user is too narrow, interfaces must be flexible and evolvable so that they can developed alongside the sense-making activity, should not be circumscribed in scope, layout and scale, but potentially cover very large canvasses, being distributed and pervasively interconnected by dependency. These characteristics are quite well-suited to web technology. There are both design and technical issues to be addressed. For instance, it is unclear how best too handle the display management (cf. the way in which html output is temporarily an alternative to graphical output in the current JsEden prototype).

8. The role of Cadence: Cadence will play an important role in the design and implementation of JsEden and help to address design and technical challenges of the kind mentioned above. As an EM tool, Cadence has much greater potential than EDEN where the management of complex state is concerned, and is very well-suited to capturing and integrating observables at the operating systems level. The design issues for the JsEDen interface discussed above reflect the need to support model-building both for construals and for programs - and indeed for construals that evolve into programs. The messy open-ended nature of the environments surrounding EDEN models is in fact quite well-matched to the free, ill-developed and unstructured nature of preliminary construals, but the kind of conceptual support that Cadence affords becomes critical in managing structures and processes as these emerge. In other respects, EDEN is more restricted than Cadence however. Whilst Cadence favours adding visualisation through attaching C++ agents to interface to the environment for purposes of visualisation and manipulation (cf. the WGD library), EDEN relies predominantly on introducing definitive notations (though adding C-functions by way of extensions to EDEN is possible - see the EDEN Handbook). In developing JsEden, it is clearly natural both to find ways of supporting existing and new definitive notations (e.g. so that models in the EM archive can be readily translated, and the possibility of adding new definitive notations that the AOP affords is retained) and to exploit the more open-ended approach of integrating JavaScript functions in the spirit in which Cadence exploits C++ extensions.

9. Varieties of agency in EDEN: The role of EDEN as an "Evaluator for Definitive Notations" is well-recognised; EDEN acts as a general-purpose dependency maintainer for the internal data structures underlying a definitive notation and generates external state by triggered actions. What has been quite as significant in making EDEN such a useful modelling tool is the rich way in which it supports varieties of agency. You can describe state change by redefinition, by procedural actions that are explicitly invoked or triggered, by using edenclocks, by using execute() and todo() commands, by loading files of definitions with or without using autocalc etc. Such rich varieties are needed because of the subtlety of the agency that arises when a construal evolves into a program. As Cadence illustrates, this still doesn't go far enough in making a bridge from construals to programs, for which more expressive ways of managing structure and process-like change (cf. willbe definitions) are also necessary. In developing JsEden, we shall aspire to develop and integrate such richer forms of agency - the introduction of the after() construct (illustrated in jugs.e) indicates one direction for exploration. We also intend to address this objective by using "JsCadence" to underpin JsEden. (There are interesting parallels with the - implicit - use of dependency and explicit agency in the Scratch programming language from MIT.)

10. Inconsistencies between tkeden and JsEden: In general, the prototype for JsEden as developed by Tim Monks for his MSc dissertation mimics tkeden exceptionally well - primarily because there is such a close match between the procedural constructs in EDEN and those in JavaScript, so that actions to generate JavaScript can be relatively easily attached to the standard EDEN parser. There are a number of minor differences between the two interpreters however - some of which are documented in the dissertation report. Some issues that were encountered in translating the existing JUGS and OXO models are:

• there are no direct counterparts for constructs such as eager(), autocalc and edenclocks;
• JavaScript uses '+' for string concatenation, where EDEN uses '//' - because of the very simple and direct nature of the EDEN to JavaScript translation, this can potentially mean that a '+' in EDEN can be translated as string concatenation - rather than flagged as an error! - if introduced in the wrong context (e.g. try replacing the '//' in the definition of the statuslabel observable in JUGS by a '+', and see what happens);
• JavaScript doesn't directly support integer division, so that 3/2 is 1 in EDEN and 1.5 in JavaScript (cf. the two versions of the vis() function in the text version of the JUGS display);
• in the current JsEden prototype, functions must first be defined before they are used in definitions.

Another issue that affects JavaScript execution is the potential for timeouts when updating display - the browser does not expect to keep the viewer waiting for long whilst a page is updated, and will prompt the modeller if a script requires "too long" to execute fully. In some cases (as when loading the 3d OXO model for instance), it is possible simply to request that the execution of the script should continue. In the case of larger EDEN models, it seems likely that such behaviour will be problematic in the absence of the autocalc feature.