Why isn't there more progress toward building systems from existing parts? One answer is that the assumptions of the parts about their intended environment are implicit and either don't match the actual environment or conflict with those of other parts. The authors explore these problems in the context of their own experience with a compositional approach.<>
Compile to Architecture - The Phoenix Architecture
For a long time we’ve treated frameworks as the target of software development. But if systems are meant to be regenerated and replaced safely, the real compilation target has to be the architecture itself.
Designing and Programming Malleable Software
User needs for software features and interfaces are diverse and changing, motivating the goal of making it as easy as possible for users themselves to change software, or to have it changed on their behalf in response to their developing needs. However, in my opinion, current approaches do not address this issue adequately: software engineering promotes flexible code, but in practice this does not help end-users effect change in their software. End-user and live programming systems help users customize their interfaces by accessing and modifying the underlying source code. I take a different approach, seeking to maximize the kinds of modifications that can take place through regular interactions, e.g. direct manipulation of interface elements. I call this approach malleable software. To understand contemporary needs for and barriers to modifying software, I study how it is produced, maintained, adopted, and appropriated in a network of communities working with biodiversity data. I find that the mode of software production, i.e. the technologies and economic relations that produce software, is biased towards centralized, one-size-fits-all systems. This leads me to propose a long-term, interdisciplinary research program in reforming the tools of software development to create infrastructures for plurality. These tools should help multiple communities collaborate without forcing them to consolidate around identical interfaces or data representations. Malleable software is one such infrastructure, in which interactive systems are dynamic constellations of interfaces, devices, and programs assembled at the site of use. My technological contribution is a reconstruction of the programming mechanisms used to create interactive behavior. I generalize existing control structures for interaction as entanglements, and develop a higher-order control structure, entanglers, which produces entanglements when particular pre-conditions, called co-occurrences, are met. Entanglers cause interactions to be assembled dynamically as system components come and go. I develop these mechanisms in Tangler, a prototype environment for building malleable interactive software. I demonstrate how Tangler supports malleability through a set of benchmark cases illustrating how users can modify systems by themselves or with programmer assistance. This thesis is an early step towards a paradigm for programming and designing malleable software that can keep up with human diversity.
Convivial design heuristics for software systems
The theme of this workshop is the proliferation of ideas about calling into question the cultural roots of our current programming languages, and the search for alternative paradigms with other cultural bases.
As someone interested in providing more agency in our computing environment I am on the lookout for pieces of our current computing environments that can be enriched to provide a more malleable experience. Window management is an area that I keep coming back to given how prevalent the domain is. I will provide a recap of what window management is, how it’s used today, and how modern applications have evolved to deal with current deficiencies. Then I’ll provide a compositional approach for window management to move towards and discuss how I think this could make applications more malleable.
Issues in Component Computing: A Synthetic Review
This paper provides a review of the rhetoric behind the component movement in educational software, and a critical analysis and synthesis of issues underlying the movement. We draw on case studies ...
Differ - Adaptive Software
Build software that adapts to each user — without forks or feature flags. One codebase, infinite variants.
Differ - Adaptive Software
Build software that adapts to each user — without forks or feature flags. One codebase, infinite variants.
Components.build
An open standard for building modern, composable and accessible UI components.
Orchestrating Experiences By Chris Risdon & Patrick Quattlebaum
Create seamless customer experiences in complex environments with Orchestrating Experiences. Learn collaborative design strategies for tackling multi-channel challenges.
Dependency Cultures - Richard Feldman | SSW 2026
Regenerative Software - The Phoenix Architecture
Special Issue Editorial – Accumulation and Evolution of Design Knowledge in Design Science Research: A Journey Through Time and Space
Sir Isaac Newton (1676) famously said, “If I have seen further, it is by standing on the shoulders of giants.” Research is a collaborative, evolutionary endeavor—and it is no different with design science research (DSR), which builds upon existing design knowledge and creates new design knowledge to pass on to future projects. However, despite the vast, growing body of DSR contributions, scant evidence of the accumulation and evolution of design knowledge has been articulated in an organized DSR body of knowledge. Most contributions rather stand on their own feet than on the shoulders of giants, and this continues to limit how far we can see, curtailing the extent of the broader impacts that can be made through DSR. In this editorial, we aim at providing guidance on how to position design knowledge contributions in wider problem and solution spaces. We propose (1) a model conceptualizing design knowledge as a resilient relationship between problem and solution spaces, (2) a model that demonstrates how individual DSR projects consume and produce design knowledge, (3) a map to position a design knowledge contribution in problem and solution spaces, and (4) principles on how to use this map in a DSR project. We show how fellow researchers, readers, editors, and reviewers, as well as the IS community as a whole, can make use of these proposals, and also illustrate future research opportunities.
