## to protect against loss of information whilst constructing the presentation ${{ var workIsDone = false; window.onbeforeunload = confirmBrowseAway; function confirmBrowseAway() { if (!workIsDone) { return "Are you sure? If you leave this page now, your work will NOT be saved."; } }; }}$; include("models/jugs/run.e"); include("jspe.jse"); s1 is Slide("

Introducing the JUGS model

This is a simple introduction to the JUGS model as implemented in JS-EDEN.

The JUGS model is displayed on the LHS of the canvas.

There are two 'jugs' in the display: Jug A on the left and Jug B on the right. These jugs have capacities 5 and 7 respectively. From a functional perspective, you are intended to achieve the target quantity of liquid specified to the right of the jugs by filling, emptying and pouring.

You can exercise the model as a program by pressing the buttons. For instance, there is a sequence of actions to reach the target in which you only ever fill jug A and empty jug B (and vice versa).

"); slideList is [s1]; ## s2 is Slide(""); ## slideList is [s1, s2]; s2 is Slide("

Beyond the functional perspective

We can adopt a quite different perspective on the JUGS model by looking at it in relation to physical instances of containers in the world.

Here the emphasis is on how the abstract operations performed on the jugs are informed by our rich experience of the physical world. Consider for instance the meanings of the words 'fill', 'empty', 'pour', and the notion of 'content' and 'liquid'.

When viewed from a functional perspective, the JUGS model is seen as an essential simplification. The model and the operations are just enough to fulfill its purpose.

From the experiential perspective, the JUGS model is an impoverished representation of a referent - a representation that could be enriched in an open-ended fashion.

The idea behind EM is that the way in which the model is constructed is critical as far as supporting both these interpretations is concerned.

"); s3 is Slide("

Exploring the model

To examine the model construction more closely, we can open the Observables & Agents tab (perhaps Observables & Dependencies would be more appropriate).

The observables on display are quite diverse in nature. Some of them (such as 'canvas' or 'slidelist' relate to meta aspects of the state of the artefact on display). It's useful to be able to isolate the observables of interest. Which these are of course depends on the context for observation.

"); slideList is [s1, s2, s3]; s4 is Slide("

What are plausible contexts?

I could be concerned with the actual process of how to achieve the target.
I could be concerned about the aesthetics of the display ... the present form is quite a mess.
I could be concerned about the speed and authenticity of the pouring ... liquid flows in integer multiples (which is a good thing from the functional perspective, bad from the experiential), but a bit too fast for this to be quite obvious (not such a good thing from the functional perspective, good from the experiential).

How can we focus on the particular observables relevant to a context?

"); slideList is [s1, s2, s3, s4]; s5 is Slide("

Displaying observable values

To display the observables relevant to a particular context, enter a regular expression into the search box at the top of the Observables & Agents panel.

For instance, to focus on the key parameters in the JUGS model from a functional perspective, cut-and-paste the following RE into the search box:

content[A!B]|^cap|target

This will display the target and the capacities and contents of the jugs. You can then see how the process of reaching the target is reflected in the values of these key observables.

If you want to make the updating process easier to see, you will need to change the value of the observable viscosity:

content[A!B]|^cap|target|visc

The buttons on the display provide one way of changing the values of observables. Such changes reflect the functional goal and follow a carefully crafted pattern. The buttons give machine-like control over the state of the model.

In the present environment, there are many other ways in which the values of observables can be changed. The model is constructed in such a way that changes that respect potential meanings are the most accessible. This is what makes this particular JUGS model different from a typical traditional program.

"); slideList is [s1, s2, s3, s4, s5]; s6 is Slide("

Changing observable values

Many different kinds of agency are relevant to the JUGS model.

The model was originally conceived as a way of encouraging schoolchildren to explore simple arithmetic operations that underlie elementary concepts in number theory.

The teacher would want to change the jug capacities and/or the target. They might also want to adapt the interface to clarify the way the updating processes work.

Ways to change the values - and definitions - of observables are:

by double-clicking on the observable name in the O&A panel, and editing and saving its definition as then displayed in a textbox.
by directly entering a new definition via the Eden Interpreter Window.

It is also possible to enable the presenter to change values from within this presentation environment. For instance, placing a piece of JS-EDEN script within <jseden>...</jseden> tags allows the reader to execute the script, or copy it to the Eden Interpreter Window for editing prior to execution. There are some simple illustrations on the next slide.

"); slideList is [s1, s2, s3, s4, s5, s6]; s7 is Slide("

Changing parameters from the presentation environment

Embedding actions for redefining observables into a presentation can highlight the way in which changes to parameters are linked with changes in interpretation. This often goes beyond routine interactions. It then has an experimental 'What if?' / 'Could it be that?' quality. viscosity = 300; capB = 8; target is 2 * max(capA, capB) - capA - capB; ## target is max(capA, capB) - min(capA, capB); ## is what is intended, but only max() is built-in to JS-EDEN

The explicit representation of current state makes it easy to restore state: target = 1;

"); slideList is [s1, s2, s3, s4, s5, s6, s7]; s8 is Slide("

Dependencies within the model

The dependencies between observables in the JUGS model guide its possible interpretations. We expect the 'Fill A' menu option to be unavailable when the content of the jug A is the same as its capacity. Assigning contentA to capA confirms this: contentA = capA;

You can trace the relevant dependencies by examining the following observables:

The current values of these observables are displayed in the O&A panel. Observables that are defined explicitly (using '=') and by dependency (using 'is') are shown in black and blue respectively.

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8]; s9 is Slide("

Experimenting with the JUGS model

The idea of experimentation only makes sense if we go beyond the functional interpretation of the JUGS model. After all, classical training in programming warns us that:

our interface should prevent actions that take us outside the scope of intended behaviours.
if a model is used in a way that is inconsistent with its specified preconditions no significance can be attached to the results ('anything goes').

The JUGS model doesn't have a pre-specified interpretation. It has whatever interpretations we can make plausible.

The next slide frames sample experimental interactions.

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s9]; s10 is Slide("

Supporting experimental interactions

An experimental context needs to be configured in a standard way. Reloading the original script for the JUGS model is a way to reset the context: include(\"models/jugs/run.e\");

It may also be necessary or helpful to introduce extra apparatus for an experiment. For instance, to make it easier to change the colour of the liquid in jug A, we can replace: jugA_water is Rectangle(left+linewidth, base - (scale * contentA),jugwidth-(2*linewidth),scale * contentA, \"blue\");

by the two definitions

watercolour = \"blue\"; jugA_water is Rectangle(left+linewidth, base - (scale * contentA),jugwidth-(2*linewidth),scale * contentA, watercolour);

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s9, s10]; s11 is Slide("

Sample experimental interactions

Keep the reset of the context handy in case experiments go wrong! include(\"models/jugs/run.e\");

Simulate selection of the 'Fill B' option by setting the observable input: input = 2;

Reduce the capacity of Jug B by a unit: capB = capB-1;

Now fill jug B again! input = 2;

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11]; s12 is Slide("

Sample experimental interactions (continued)

Keep the reset of the context handy in case experiments go wrong! include(\"models/jugs/run.e\");

Increase the capacity of Jug B by half a unit: capB = capB + 0.5;

Now fill jug B ... input = 2;

Refer to Slide 8 for an explanation ... currentSlide = 8;

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12]; s13 is Slide("

Fix the overfill 'problem'

Currently have the definition: Bfull is capB == contentB;

A more appropriate definition of 'Jug B is full': Bfull is (max(capB,contentB)==contentB);

(Writing 'Bfull is capB <= contentB;' would be much clearer, but there is a bug in the way in which the presentation handles the '<' between the jseden tags.)

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13]; s14 is Slide("

Postscript ...

And finally (handle with care)... currentSlide is contentB;

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14]; s15 is Slide("

Agency in the JUGS model

The JUGS model brings out the contrasts alluded to by SBR.

Moving beyond the functional perspective gives scope for personal exploratory interaction.

The model supports different kinds of human agency (e.g. pupil, teacher, developer, presenter). More significantly, it supports these kinds of agency concurrently in one and the same environment.

It also supports automated agency. To see this, inspect the definition of the pour procedure via the Procedures panel on the left. (You need to empty the search box in the O&A panel for this to work - a bug in emile.)

You will see that pour acts like an agent that carries out automatically what the modeller might do manually. For instance, when B is being filled the content of Jug B is incremented and the fullness of Jug B is checked repeatedly. You can disclose this by intervening in the filling process by resetting contentB thus:

contentB = 1;

"); s16 is Slide("

Visualising dependencies

It can be helpful to visualise the dependencies between observables. A simple visualisation showing dependencies relating some of the key observables in the JUGS model can be generated using the Dependency Modelling Tool developed by Allan Wong:

"); slideList is [s1, s2, s3, s4, s5, s6, s7, s8, s16, s15, s9, s10, s11, s12, s13, s14]; /* target = 1; capA = 5; capB = 7; contentA = 0; Afull is capA == contentA ; contentB = 1; valid1 is !Afull; but1 is Button("but1",menu[1], 50, base+30, valid1); */