Doctoral thesis of Philip Tchernavskij.
This thesis is focused on the problems of Malleable software: how can we create software which can be incrementally and idiosyncratically modified and redefined by end-users, across traditional app boundaries? I really like one phrasing of this aspiration Philip offered: “the goal is to erase the boundaries between apps and create an end-user accessible “physics of interfaces” that dictate how different interfaces and documents can be assembled.”
(There’s also an appeal to a related term—“tailorable software”—“it should be as easy to change software as it is to use it. I don’t understand the distinction, if any, between the ‘tailorable’ and ‘malleable’ aspirations. I think it’s mostly historic, and that tailorable systems were more monolithic, per page 41)
The key contribution is “entanglers”, a declarative and highly composable specification of UI interaction which aspires to solve some of the brittleness problems of existing solutions.
The first few chapters elaborate at length on Tchernavskij, P., Klokmose, C. N., & Beaudouin-Lafon, M. (2017). What Can Software Learn From Hypermedia? Companion to the First International Conference on the Art, Science and Engineering of Programming, 1–5. For me, the important conceptual distinction from the prior papers (particularly those in the Webstrates orbit) is that Philip’s focused on how communities might adapt and recombine tools; the prior work focused on individuals. He also grounds the effort in Marxist “modes of production”; for me, at least, this wasn’t clarifying.
On the technical side, Philip makes several important observations which I hadn’t seen in prior Webstrates-adjacent papers:
Tangler, the prototype system, defines interactions in terms of entanglers, which match co-occurrences of elements and specify a template which adapts those elements as needed for the implementation of the interaction. As a simple example: you might define a drag-and-drop interaction in some very general way; then when an element of some type is in a particular spot on the canvas, you wire the appropriate attributes up to the drag-and-drop interaction’s interface.
The aspiration is to “decouple interactions from interacting elements.” What’s interesting about Tangler’s approach, relative to prior work in this space, is that the co-occurrence concept is dynamic—interactions may be added and removed at runtime as program conditions change. And those co-occurrences are real entities in the system; they can have their own state, which may be useful for cross-cutting concerns like the interaction of several UI elements.
Tangler is built on a declarative programming language called Infusion (Basman, A., Clark, C. B. D., & Lewis, C. (2015). Harmonious Authorship from Different Representations. PPIG.) One thing that’s nice about this approach is that the soundness of the integrations is statically checkable. Webstrates, by contrast, do all their wiring at runtime. If some UI element can’t immediately be repurposed for some interaction, you have enough declarative information with this system that you might be able to surface some UI to the user to adapt the element appropriately. It’s interesting to ponder a GUI for creating these data structures.
I confess I struggled to follow the specific examples implemented in chapter 5. The thesis doesn’t describe the system formally, so I’m largely left to infer how the implementation actually achieves the described effects. I think I ~70% understand, but many holes remain.
I liked this passage on properties of “open authorship” systems (a more technically-focused aspiration related to malleability):
Basman et al. find three key properties to be conducive to open au- thorship. First, adaptations to a system should be additive rather than destructive, i.e. they should be performed by creating a new module and attaching it to the existing system, rather than rewriting existing code. Additive modification is useful because it lets the adaptations of multiple developers be aggregated, whereas multiple modifications of a text may not be possible to consolidate. Second, systems should be freely and stably addressable, meaning that every part of a program can be referenced from outside the program, e.g. by using a global path expression, and that these references are likely to remain valid. Addressability is key to increasing the expressive power of additive modifications: it is the property that allows new modules to extend properties that are deeply embedded in the source code of an exist- ing system. Third, all elements of a system should be externalizable, meaning that it should be possible to represent and share them as data, e.g. as text documents. This property is necessary to enable use cases such as transporting a behavior from one system to another. In the next chapter, I discuss related work and the design of a programming model for malleable software in terms of these properties.
There’s a nice bibliography here of several other approaches to Malleable software which I haven’t yet read, including discussion of “integrations”, “context-oriented programming”, and various toolkits which have tried to solve this problem, e.g. these black-box augmentations:
Interface Attachments (Olsen et al., 1999) and Façades (Stuerzlinger et al., 2006) modify features of the interface of running applications through the windowing system. Improv (Chen and Li, 2017) creates cross-device interactions in the browser by trans- forming input events on remote devices to simulated input events on existing interface elements. Prefab (Dixon and Fogarty, 2010) uses computer vision to recognize and modify interfaces at the pixel level.
If I find myself wanting to dig further into malleable software, I should read through the bibliography more completely.
Q. Two key problems identified with Webstrates?
A. Poor correspondence between code and interface; strong assumptions about DOM structure make broad re-use brittle
Q. What key decompositional move do “entanglers” make?
A. They separate the mechanisms of interactions from specification of how they’re bound to specific UI elements.
Q. Define an “entangler” (two parts).
A. A “co-occurrence description” matches some set of UI elements; an “entanglement template” binds those elements to implementations.