Borowski, M., Kristensen, J. B., Bagge, R., & Klokmose, C. N. (2021). Codestrates v2: A Development Platform for Webstrates.

This paper extends Codestrates (Borowski, M., Rädle, R., & Klokmose, C. N. (2018). Codestrate Packages: An Alternative to “One-Size-Fits-All” Software. Extended Abstracts of the 2018 CHI Conference on Human Factors in Computing Systems, 1–6) to build a more robust foundation for developing Webstrates. The central move is separation of concerns: the codestrate’s data (“fragments”) are now stored as non-rendered DOM nodes, which are synced to rendered DOM nodes by the authoring environment, which may express a computational notebook, or something more like a traditional IDE, or whatever.

This is certainly a more flexible architecture, but I can’t help feeling it’s somehow moving away from the transparency and malleability of the original Webstrates. HTML interface elements must be escaped in their source fragments (e.g. <p>Hello world</p>). Cauldron, the demonstration IDE, isn’t implemented using code fragments, sacrificing malleability.

Interestingly, the latter seems to have been motivated in part by hiring professional developers to help implement these platform changes. I bet I could learn something useful about this practice, e.g. given the experiences described in Tools for thought collaboration seems to prefer either part-time contractor help, or deep full-time partners, with a big chasm between.

I notice that this is published as a technical report rather than an archival paper. Makes me wonder if this is a demonstration of Systems work is disincentivized in academic HCI. Was it not publishable, just because it’s mostly implementation detail? Clearly it was a lot of work, and clearly it’s essential to subsequent research. And as an interested “systems person”, this info is certainly novel to me!

I don’t understand this move:

By rendering HTML in a transient element opposed to changing it directly, it is possible to collabora- tively edit the fragment code. This in turn, however, also means that changes to the rendered DOM elements are not synchronized back to the fragments, as this could cause conflicts (see Figure 3).

Wasn’t it possible to collaboraitvely edit the HTML before, too? Since it was represented as a DOM tree, which should behave well under Operational transformations syncing?

I also don’t understand the implementation of the model in the todo list MVC example. It reads/writes the data as a JSON string in the contents of a DOM node. But how do the Operational transformations work in this case?

Q. In Codestrates v2, “paragraphs” (e.g. “code paragraph”) become…
A. fragments (e.g. “code fragment”)

Q. How is markup (e.g. for an interface) represented in Codestrates v2?
A. As e.g. <code-fragment data="text/html" auto>, synchronized to rendered DOM nodes by an ID.