Substrates-26

An increasing number of researchers see their work as interactive authoring tools or software substrates for interactive computational media. By talking about “authoring tools”, we remove the divide between programmers and users; “software substrates” let us look beyond conventional programming languages and systems; and “interactive computational media” promises a more malleable and adaptable notion of tools for thought we are striving for. This workshop aims to bring together a wide range of perspectives on these matters.

Call for Contributions

An increasing number of researchers see their work as interactive authoring tools or software substrates for interactive computational media. By talking about “authoring tools”, we remove the divide between programmers and users; “software substrates” let us look beyond conventional programming languages and systems; and “interactive computational media” promises a more malleable and adaptable notion of tools for thought we are striving for. This workshop aims to bring together a wide range of perspectives on these matters.

Researchers in education, design, and software systems alike have long explored how computation can become visible and adaptable to its users, from diSessa’s learner-centered Boxer microworlds of the 80s, Hypercard, and Maclean et al’s Buttons. Even mundane systems such as spreadsheets blur the distinction between use and creation.

The notion of a substrate is an umbrella for many different traditions which are bringing local agency over software systems.

Our values are aligned with the Malleable Systems community who consider that software should be as easy to change as it is to use – a well-received essay on malleable software coincided with last year’s workshop. Another alignment is with the local-first community who declare that you own your own data, in spite of the cloud.

Substrates are not limited to interactive systems with a user interface. Kell’s (2009) concept of an integration domain stretches the domain of substrates to link-time transformations of executable binaries and the lowest levels of the operating system (should there be one?). This leads us on to the core role of a substrate in establishing a relationship between the inside and outside of a running system. The notions of addressability and externalisability from Basman et al (2018) explain how to refer to and transmit the contents of a substrate from place to place, and open authorship which compiles substrate contents from an ecology of authors rather than insisting one author’s expression has authority over another. This notion of compilation derives from the data feminism framework of D’Ignazio and Klein (2020) which challenges differentials of power in data ecologies.

The common theme amongst all of these alignments of the substrate movement is that the full capabilities of the system, whether these relate to visibility, adaptation or transmission, should be placed at the disposal of the user rather than hidden behind abstraction or implementation boundaries, which positions substrates as a political project. The framework of Ecofeminism (Shiva & Mies, 1993) provides a clear feminist lens with which to see the importance of promoting local agency and user creativity in an ecology of artefacts:

Dominant economics is unable to take [self-provision] into account because it counts as production only that in which the producer and consumer are different, that means that only commodity production is production, and self-provisioning is non-productive work. This is the viewpoint that counts women’s heavy work-load as non-work.

At odds with the substrate movement are popular idioms such as functional programming and object-oriented programming which rely on creating impermeable boundaries between producers and consumers.

A timely issue is the relationship of the substrates programme with software construction by AI. If the majority of code in future systems is synthesized by AI, some might say there is no purpose to developing fresh programming language notations. Others argue that the time has never been more promising for this, and that better notations and substrate transparency may assist AI and human designers alike. Early results from the lopecode substrate and its AI integration, robocoop, support this. Cao et al (2025) have recently written on the importance of substrates as a locus of human-AI cooperation.

The range of vision statements we received in Substrates-25 spanned from the most abstract in which substrate nature can be read into essentially any runtime, to the most concrete which considered that a successful substrate, once fully elaborated, might prove to have a unique canonical structure. We expect Substrates-26 to continue to explore this tension rather than force a collapse onto a particular vision, since a most important aspect to our research programme is to establish how substrate-oriented systems are expected to coexist with and interpenetrate those developed using conventional programming languages.

Substrates-26 also seeks to broaden participation beyond those who might traditionally identify as academic researchers. It is a perennial problem in our communities that work continues in separated self-citing silos who remain unaware of each other’s work over long timescales. It is our aim to create a forgiving, welcoming venue where workers with greatly divergent backgrounds can encounter and enrich each other.

We welcome participation from workers from academia, industry, independent scholars, and others, from any of the communities named above, and from any others who can see their goals reflected in the substrate agenda.

How to participate: Call for Contributions

The day-long workshop will be structured in 3 phases:

Firstly a phase of introductions where each participant can take up to two minutes to explain their programme, background or system.

Secondly, presentations of materials from accepted submissions. These presentations can be short talks, demos, or videos, and will be represented in the workshop proceedings. Each submission will receive a critical response of reflective, constructive feedback from a member of the programme which will be presented after the submission.

Thirdly, we will accept suggestions for “lightning” talks or works in progress, which will not receive a written critical response.

Accordingly, we ask for 3 kinds of contributions:

i) A short introduction, positioning the submitter’s background or projects against the substrates agenda. We’d like all attendees to provide this.

ii) A submitted artefact, which will be reviewed by the programme committee for inclusion in the workshop. Suggestions for a form of the contribution are a paper of 2-4 pages, a video of up to 10 minutes, or a brief description of a working demo, to be presented at the workshop, but this is not exhaustive - submitters should feel free to produce a contribution of any form which could gracefully be accommodated into the schedule.

iii) A proposal for a lightning talk, demo or more lightweight update on work or thought in progress, which will not receive a written critical response from the committee.

Call for Demos/Lightning Talks

The workshop will solicit proposals for lightning talks, demos or more lightweight updates on work or thought in progress. These will be invited from 23rd February 2026 onwards.