Month: March 2021
I’ve been enjoying the idea of “research products” as opposed to “research prototypes”. Prototypes are understood as a partially working thing as a step towards an answer to a design problem. Research products on the other hand are understood as they are, rather than what they might become. Here’s how Odom et al describe it in their 2016 CHI paper “From Research Prototype to Research Product”. Unfortunately this is a closed access ACM paper, but you can find a pdf online, for now at least. Here’s the four features of research products that they highlight:
- Inquiry driven: a research product aims to drive a research inquiry through the making and experience of a design artifact. Research products are designed to ask particular research questions about potential alternative futures. In this way, they embody theoretical stances on a design issue or set of issues.
- Finish: a research product is designed such that the nature of the engagement that people have with it is predicated on what it is as opposed to what it might become. It emphasizes the actuality of the design artifact. This quality of finish is bound to the artifact’s resolution and clarity in terms of its design and subsequent perception in use.
- Fit: the aim of a research product is to be lived-with and experienced in an everyday fashion over time. Under these conditions, the nuanced dimensions of human experience can emerge. In our cases, we leveraged fit to investigate research questions related to human-technology relations, everyday practices, and temporality. Fit requires the artifact to balance the delicate threshold between being neither too familiar nor too strange.
- Independent: a research product operates effectively when it is freely deployable in the field for an extended duration. This means that from technical, material, and design perspectives an artifact can be lived with for a long duration in everyday conditions without the intervention of a researcher.
I’m finding this helpful thinking about my live loom. It’s not intended as a commercially viable product, but it’s also not intended as a step towards one. It’s intended to be a device for exploring computation, without automation and all its forced simplicity. It works very well, every time I use it I’m blown away by the generative complexities of handweaving, and it helps me see computer programming language design afresh, with a beginner’s mind. So it’s inquiry driven, and finished in that it’s ready to embody an area of inquiry and host exploration of that. In terms of fit – well its lasercut body and trailing arduino aligns it with 21st century maker culture, and solenoids align it with 20th century electromechanics, but its fundamental design is that of an ancient warp weighted loom, so it has some fit there although it has a lot to learn from the past in terms of ergonomics.
In terms of ‘independence’ it’s not quite there yet, but is designed with open hardware principles, using easy to source parts and permissive CC licensed designs. The next step is supporting others in replicating the hardware which will happen in the next few months. This is where it gets exciting for me – how will the live loom function as an ‘epistemic tool’ – will the research ideas carry with the loom, or will the replicators ‘misunderstand’ the loom and take it in a new direction? Of course the latter case would be failure in one respect, but I get the impression that designers see such failure as positive, where objects support divergent use..
In any case by thinking about the live loom as a research product, it helps me explain what it’s for. When I show it to people, they often treat it as a work-in-progress towards a fully automated loom, like one driven by the famous Jacquard mechanism. That’s the opposite of what I’m trying to do, as that mechanism is what separates humans from the mathematical basis of weaving as computational interference. As a research product, the live loom foregrounds computational augmentation rather than automation.
Research papers as research products
This leads me to think about research papers as research products too – many will have the experience of publishing a research paper, getting excited when someone has cited it, only to find that they’ve totally misunderstood what you were trying to say, even taking the opposite meaning. What if we treated papers as research products, that we deploy in the world, and then observe what they do? I just read Christopher Alexander’s foreword to Richard Gabriel’s book “Patterns of software”. Alexander is an architect (of buildings), and Gabriel is a computer scientist who has studied Alexander’s work for decades in order to try to develop a similar pattern-based approach in software. What’s interesting is that Alexander seems profoundly disappointed in the book that he’s writing a foreword for, although he’s chooses his words generously he basically asks Gabriel to write a different book, and to learn from his more recent work where he solves all the problems in his older work that Gabriel references. It is amazing that Gabriel would host such a text at the front of his book! Really Richard Gabriel is an amazing computer scientist and thinker, and I think Alexander is being a bit naive in assuming that such a comparatively young field of computer science could solve its core problems by going through his four-volume text on designing physical buildings – these are really very different domains indeed. What is more interesting is that Gabriel gives voice to the person he cites. This goes way beyond peer review to giving his text its own life in the process of being published. I’m looking forward to the rest of the book!
I really enjoyed mentoring Lizzie’s project last year as part of the ‘summer of haskell’, which is in turn part of the Google Summer of Code. Every year Google pay students to spend a couple of months over the summer contributing to a free/open source project, and Lizzie spent the time exploring automatic generation of Tidal code. It was a fun time, and sparked off a nice collaboration with Shawn and Jeremy around their awesome Cibo project (which we should really pick up again soon)..
It’s sometimes a bit lonely working on Tidal, as Haskell has the perception of being difficult to learn, especially if you’re used to another language.. But it’s also super interesting and rewarding, a great language to think deeply about representations. Over the last year or so there have been more contributors pop up though with great PRs coming in, so I think a community is slowly forming around the innards, helped by cleaner code, a more complete test suite etc.
Anyway the Summer of Haskell folks are getting ready to accept submissions, and I’ve contributed a Tidal idea to the list – to make Tidal easier to install. The reason this hasn’t been done before is because making a binary distribution of a Haskell interpreter is no mean feat.. But I think it’s possible, would have some interesting aspects and would attract the profound gratitude of a lot of people (Tidal isn’t the easiest to install). I’d be very happy to hear about other Tidal-related projects I could helpfully mentor too.
More info on the summer of haskell here.
I’m excited to be working with some ace people planning a new project “AI as collective performance”, namely Mika Satomi (artist and designer), Berit Greinke (Universität der Künste Berlin and Einstein Center Digital Future) , Juan Felipe Amaya Gonzalez (performance artist) and Deva Schubert (freelance choreographer). We’re part of a cohort of ten projects, exploring the intersection on AI and culture, jointly funded by Stiftung Niedersachsen and VolkswagenStiftung.
Here’s the blurb so far:
The project “AI as collective performance” deals with the explainability of algorithms and artificial intelligence. The goal is to develop a collaborative performance in which the processes behind AI become visible through choreography, interactive costumes, and live coding. Each person represents a node of the network that grows, changes, breaks patterns and creates new ones again. In this project, the human body acts as a processor. Here, a choreographer is also a programmer. By translating AI into physical movements, the complex technology becomes tangible and perceivable.