One of the things that the OU has always tended to do well is create clear – and compelling – diagrams and animations to help explain often complex topics. These include interactive diagrams that allow a learner to engage with the diagram and explore it interactively.
At a time when the OU is looking to reduce costs across the board, finding more cost effective ways of supporting the production, maintenance, presentation and updating of our courses, along with the components contained within them, is ever more pressing.
As a have-a-go technology optimist, I’m generally curious as to how technology may help us come up with, as well as produce, such activities.
I’m a firm believer in using play as a tool for self-directed discovery and learning, and practise as a way of identifying or developing, erm, new practise, and I’m also aware that new technology and tools themselves can sometimes require a personal time investment before you start to get productive with them. However, for many, if you don’t get to play often, knowing how to install or start using a new piece of software, let alone how to start playing with once you are in, can be a blocker. And that’s if you’ve got – or make – the time to explore new tools in the first place.
Changing a workflow is also not just down to one person changing their own practise – it can heavily depend on immediate downstream factors, such as what the person you hand over your work to is expecting from you in order for them to do their job.
(Upstream considerations can also make life more or less easy. For example, if you want to analyse a data set that the person before you has handed over as a table in a PDF document, you have to do work to get the data out of the document before you can analyse it.)
And that’s part of the problem: because tech can often help in several ways, but is sometimes most effective when you change the whole process; and if you stick with the old process, and just update one step of the workflow, that can often makes things worse, not better.
Sometimes, a workflow can just be bonkers. When we produced material for the FutureLearn Learn to Code MOOC, we used an authoring tool that could generate markdown content. The FutureLearn authoring environment is (I was told) a markdown environment. I was keen to explore an authoring route that would let us publish from the authoring environment to FutureLearn (in the absence of a FutureLearn API, I’d have been happy to finesse one by scraping form controls and bodging my own automation route.) As it was, we exported content from the markdown producing environment into Word, iterated through it there with the editor (introducing errors into code elements), and then someone cut and pasted the content into the FutureLearn editor, presumably restyling it as they did so. Then we had to fix the errors that were either introduced by the editing process, or made it through the editing process, by checking back against code in the original authoring environment. The pure markdown workflow was stymied because even though we could produce markdown, and FutureLearn could (presumably) accept it, the intermediate workflow was a Word based one. (The lesson from this? Innovation can be halted if you have to use legacy processes in a workflow rather than reengineering all of it.)
The OU-XML authoring route has similar quirks: authors typically author in Word, then someone has to copy, paste and retag the content in an XML authoring tool so it’s marked up correctly.
But that’s all by the by, and more than enough for the subject of another post…
Because the topic of this post is a quick round-up of some tools that support the creation – and deployment – of interactive diagrams and explorable explanations. I first came across this phrase in a 2011 post by Bret Victor – Explorable Explanations, and I’ve posted about them a couple of times (for example, Time to Revisit Tangle?).
One of the most identifiable aspects of many explorable explanations are interactive diagrams where you can explore some dynamic feature of an explanation in an interactive way. For example, exploring the effect of changing parameter values in an equation:
One of the things I’m interested in are frameworks and environments that support “direct authoring” of interactive components that could be presented to students. Ideally, the authoring environment should produce some sort of source code from which the final application can be previewed as well as published. Ideally, there should also be separation between style and “content”, allowing the same asset to be rendered in multiple ways, (this might include print as well as online static or interactive content).
Unfortunately, in many cases, direct authoring is replaced by a requirement to use some sort of “source code”. (That’s partly because building UIs that naive users can use can be really difficult, especially if those users refuse to use the UI because it’s a bit clunky. Even if the code the UI generates, which is the thing you actually want to produce, is actually quite simple and it would be much easier if authors wrote that source code directly.)
The example online editor gives an example of the markup language (markdown, with extensions) and the rendered, interactive document:
(It’d be quite interesting to see how closely this maps onto the markdown export from a Jupyter notebook that incorporates
Moving the sliders in the rendered document changes the variable values and dynamically replots the curve in the chart.
I can see Idyll becoming a component of the forthcoming OpenCreate tool, so it’ll be interesting if anyone else can – partly because it would presumably require downstream buy-in into using the interactive components Idylll bundles with.
Whilst Idyll is a live project, the next one – Apparatus – looks to have stalled. It has good provenance, though, with one of the examples coming from Bret Victor himself.
Here’s an example of the sort of thing it can produce:
The view can also reveal the underlying configuration:
The scene is built up from a set of simple objects, or previously created objects (for example, the “Wheel with mark” This feature is important because it encourages another useful behaviour amongst new users: it encourages you to create simple building blocks that do a particular thing, and then assemble those building blocks to help you do more complex things later on.
The apparatus “manual” fits in one diagram:
The third tool – Loopy – also looks like it may be recently stalled (again, code is available and the UI is via a browser). This tool allows for the creation, through direct manipulation, of a particular sort of “systems diagram” where influence at one node can positively or negatively influence another node:
To create a node, simply draw a circle; to connect nodes, draw a line from one node to another.
You can set the weight, positive or negative:
As well as adding and editing text, and moving or deleting items:
You can also animate the diagram, feeding in positive or negative elements from one item and seeing how those changes feed through to influence the rest of the system:
The defining setup of the diagram can be saved in a URI and then shared.
All three of these applications encourage the use to explore a particular explanation.
Apparatus and LOOPY both provide direct authoring environments that allow the user to create their own scenes through adding objects to a canvas, although Apparatus does require the user to add arithmetic or geometrical constraints to some items when they are first created. (Once a component has been created, it can just be reused in another diagram.)
Apparatus and LOOPY also carry their own editor with them, so a user could change the diagram themselves. In Idyll, you would need access to the underlying enhanced markdown.
If you know of any other browser based, open source frameworks for creating and deploying standalone, iframe/web page embeddable interactive diagrams and explorable explanations, please let me know via the comments.
PS for a range of other explorable explanations, see this awesome list of explorables.