One of the practical issues associated with using the Scratch desktop application (or it’s OU fork, OUBuild) for teaching programming is that runs on the desktop (or perhaps a tablet? It’s an Adobe Air app which I think runs on iOS?). This means that the instructional material is likely to be separated from the application, either as print or as screen based instructional material.
If delivered via the same screen as the application, there can be a screen real estate problem when trying to display both the instructional material and the application.
In OU Build, there can also be issues if you want to have two projects open at the same time, for example to compare a provided solution with your own solution, or to look at an earlier project as you create a new one. The solution is to provide two copies of the application, each running its own project.
Creating instructional materials can also be tricky, requiring the capturing of screenshots from the application and then inserting them in the materials, along with the attendant risk when it comes to updating the materials that screenshots as captured in the course materials may drift from the actuality of the views in the application.
So here are a couple of ways that we might be able to integrate Scratch like activities and guidance into instructional materials.
Calysto/Metakernel Jigsaw Extension for Jupyter Notebooks
The Calysto/Metakernel* Jigsaw extension for Jupyter notebooks wraps the Google Blockly package for use in a Jupyter notebook.
Program code is saved as an XML file, which means you can save and embed multiple copies of the editor within the same Jupyter notebook. This means an example programme can be provided in one embed, and the learner can build up the programme themselves in another, all in the same page.
The code cell input (the bit that contains the %jigsaw line) can be hidden using the notebook Hide Input Cell extension so only the widget is displayed.
The use of the editor is a bit tricky – it’s easy to accidentally zoom in and out, and I’m guessing not very accessible, but it’s great as a scratchpad, and perhaps as an instructional material authoring environment?
For more examples, see the original Jigsaw demo video playlist.
For creating instructional materials, we should be able to embed multiple steps of a programme in separate cells, hiding the code input cell (that is, the %jigsaw line) and then export or print off the notebook view.
LaTeX Scratch Package
The LaTeX Scratch package provides a way of embedding Blockly style blocks in a document through simple LaTeX script.
Using a suitable magic we can easily add scripts to the document (the code itself could be hidden using the notebook Hide Code Cell Input extension.
(Once again, the code cell input (the cell that contains the lines of LaTeX code) can be hidden using the notebook Hide Input Cell extension so only the rendered blocks are displayed.)
We can also create scripts in strings and then render those using line magic.
One thing that might be quite interesting is a parser that can take the XML generated from the Jigsaw extension and generate LaTeX script from it, as well as generating a Jigsaw XML file from the LaTeX script?
Historical Context
The Scratch rebuild – OU Build – used in the OU’s new level 1 introductory computing course is a cross platform, Adobe Air application. I’d originally argued that if the earlier taken decision to use a blocks style environment was irreversible, the browser based BlockPy (review and code) application might be a more interesting choice: the application was browser based, allowed users to toggle between blocks and Python code views, displayed Python errors messages in a simplified form, and used a data analysis, rather than animation, context, which meant we could also start to develop data handling skills.
One argument levelled against adopting BlockPy was that it looked to be a one man band in terms of support, rather than the established Scratch community. I’m not sure how much we benefit from, or are benefit to, the Scratch community though? If OU Build is a fork, we may or may not be able to benefit from any future support updates to the Scratch codebase directly. I don’t think we commit back?
If the inability to render animations had also been a blocker, adding an animation canvas as well as the charting canvas would have been a possibility? (My actual preference was that we should do a bigger project and look to turn BlockPy into a Jupyter client.)
Another approach that is perhaps more interesting from a “killing two birds with one stone” perspective is to teach elementary programming and machine learning principles at the same time. For example, using something like Dale Lane’s excellent Scratch driven Machine Learning for Kids resources.
PS the context coda is not intended to upset, besmirch or provoke anyone involved with OUBuild. It’s self-contempt / self-critical, directed at myself for not managing to engage/advocate my position/vision in a more articulate or compelling way.
PPS new JupyterLab blockly extension with blocks to code and back again support: https://olney.ai/category/2020/01/20/intelliblocks.html Repo: aolney/fable-jupyterlab-blockly-extension
OUseful.Info, the blog... 
I agree about the status of BlockPy; it isn’t maintained and developed like an active project. I like the idea of a BlockPy kernel, and would gladly help support that where I can. We have forked code to output the Java source that could be useful. The ability to add blocks via an import is critical. We have a prototype of that functionality, and thought some about consistency. For example, you want the colors of the newly created blocks to be meaningful. We decided to make the colors consistent among users. So, if you and I both import an arbitrary library (say, matplotlib) then your colors and my colors would be the same. Also, I think parsing Python/Java/etc into blocks would be desired.
@Doug I wasn’t so much thinking of a BlockPy kernel, more as an alternative Jupyter interface that could run against a Jupyter kernel.
Re: extending Jigsaw magic, I think it would also be useful to be able to return objects as the last line of the program that could then be displayed in the cell output. For example, constructing a matplotlib chart using the blocks and then displaying it by runnung the programme and returning the chart object as the last item of the programme (or perhaps create an “outputDisplay” block which accepts and object and returns it for use in the cell output?
IPython has added display() to the top-level environment, so I think it would make sense to have a display block with the print block. Having a return for the canvas would be problematic as there isn’t a “last item.” Perhaps the idea of the notebook could be expanded to include whatever your ideas might be regarding such an alternative interface. I may have mentioned the Greenfoot Stride IDE before. In some ways, it combines text and blocks into a new kind of interface. This conversation and motivation reminds me of it.
@Doug “Having a return for the canvas would be problematic as there isn’t a “last item.” Okay, agreed. Head old contributed sloppy language on my part. I meant the ability to return an item from the cell as if it were the last item returned from a code cell, but then the jigsaw editor is sort of that anyway so maybe need to return a variable named in the notebook scope into a code cell (as per the ability to dump code into the code cell) that contains the map. I can’t really concentrate atm :-(
@doug Greenfoot Stride IDE looks interesting. Reminds me of an editor I saw on NeXT workstations for occam? IIRC, that was a hierarchically thing that dropped you into child blocks?
I’m also now reminded of TiddlyWiki again as something to play with in the early hours of the morning…
I loved the NeXT… I remember piping output of one process into another to get a graph view of the data. Cool!
I’m very amused to stumble across this conversation, since we are looking at exporting the BlockPy code/text interface to Jupyter. I’m the BlockPy one-man-band, although there’s actually a few other people too. We’re still at the beginnings, but we’re talking about taking the interface component and sticking it in as a Jupyter extension (“BlockMirror”?). These investigations you’ve done are very helpful, Jigsaw in particular.
Apols for not responding to this before: what sort of thing were you thing re: Jupyter?