One of the things I think we could be looking at more in open ed in general, and the OU in particular, are authoring environments that allow educators to create their own interactives.
A significant blocker is the skills required to create and deploy such things:
- activity design in general;
- front end / UI coding (HTML / js)
- back end coding (application logic, js, or py, for example)
- runtime management (js can run in a browser, R or py likely to require a backend kernel to execute the code).
One of the things that appeals to me about the Jupyter and RStudio environments / ecosystems is the availability of packages that support end-user development by wrapping high level UI components as templated widgets that can be automatically generated from code. (See for example my own attempts at creating an HTML hexjson widget for rendering a hex map given an R dataframe.)
One of the things I started to come round to when creating various binderhub demos to show off how Jupyter notebooks can be used to generate and embed rich media assets for different topic areas (see slides 25-33 of the presentation from Dev.ac.uk embedded below, for example) was that a good collection of IPython magics could provide the basis for end-user developed online materials featuring embedded interactives.
For example, the py / folium magic I started working on makes it relatively straightforward to create an embedded map within a Jupyter notebook, that can then be saved and rendered as a standalone HTML page featuring an embedded interactive map.
It struck me that the magic should also work in the context of Scriptedforms, eg as per Creating Simple Interactive Forms Using Python + Markdown Using ScriptedForms + Jupyter.
And it does…
The markdown (text) file,
scriptedforms_magic.md, on the left can be fired up as the HTML + interactive form on the right from a single command line command:
You can also do “live development” by editing and saving the markdown and then reloading the browser page.
By developing a sensible set of IPython magics, authors with some limited technical skills should be able to write enough “code”, as per the “code” in the markdown document above, to:
- identify form elements;
- bind those form elements as parameters in an IPython magic call.
After all, we keep saying everyone should be able to code… and that’s a level of coding where you can be immediately productive…