To use any authoring system, you need to get familiar with its concepts and available tooling. Especially if we want to create systems that are malleable and adaptable, users need to find out what they can change - and how they can change it. But how do we enable this? Substrates aim to be malleable for everyone, not just system developers; this likely means users should find answers within the user-facing part of the system, rather than requiring a switch to a lower level of abstraction, such as the virtual machine. Additionally, substrates might explore new interaction methods that differ from most established IDEs, making easy explorability and discoverability even more critical.

However, in our software engineering courses, we noticed that students struggle with exploring new systems that aim to contain their own documentation. Even if a system has a variety of tools and is self-documenting, it can be challenging for a new user to know what to look for (and how not to damage the system acci- dentally during exploration). In this submission, we will report on some approaches we have tried and the struggles we encountered in our courses. This concerns both concepts that are commonly found in programming systems (such as debuggers) and tools that are likely specific to a particular system (such as specialized live- editing tools). We want to use this as a basis for discussion to collect approaches and experiences from other members of the substrate community. Additionally, we would like to facilitate a collabora- tive design session or conversation on what the future of teaching “system exploration” might look like.