Introduction

Pippin Barr’s “It Is As If You Were Making Love” (LOVE in the following), is a satirical short-form browser game in which the player navigates the act of giving sexual pleasure to a user interface in the style of bygone office software. LOVE originates from a speculative play angle that envisions a future where physical intimacy is rare, and people crave the feeling of giving sexual pleasure. In LOVE, a Windows 95-era interface serves as an invitation to provide pleasure to the software at hand. The player’s sole task is to “stroke” a slider according to the instructions given by the program. As the software goes through several stages of arousal, it requests the user to provide input within certain value ranges and different speeds. If the player follows these instructions successfully, the interface reaches its climax, represented by visuals evoking a winning moment in a 90s version of Microsoft Solitaire, paired with some raunchy communication, a seeming crash, and a reset, until inviting another round of interface innuendo.

Ideating, speculating, questioning

The first evidence of Barr’s design thoughts for LOVE is a high-level concept that presents deliberations about look, feel, and meaning. It features descriptions of the basic game design premise, context, UI, and the essential elements for building a prototype.

Figure 1 shows the opening excerpt from Barr’s concept for LOVE. The title lays it out clearly: UI SEX GAME – three words that denote what this project is intended to be about. The reader can reasonably deduce there to be a focus on user interfaces, i.e., the mode of interaction, sex, i.e., the theme and conceptual framework, and game, i.e., the type of interaction – this may be playful.

“There would be a slider.”¹ Barr’s opening statement focuses this specific interaction element, accompanied by a sketch of it. Next, one can witness the first instance of Barr’s habit of constant questioning. As in the present entry, he quickly challenges new ideas and suggestions with questions. Here, he addresses the basic gameplay loop, “It tells you where to set it?”, and how it may be communicated to the player using affordances that integrate with its conceptual framing: “How do you tell someone to masturbate a slider in UI language?” Seemingly trying to find answers to these questions, Barr turns to the game’s conceptual framework and uses that as a relay towards reference work. Here, Barr recalls another short-form browser game featuring masturbation, Sepe’s Cumshot², wondering how LOVE sets itself apart and leading him to question the focus on male masturbation in both his and the reference work.

This demonstrates a recurring moment in Barr’s design approach: When the existing material appears insufficient in answering the questions raised, he expands the scope of inquiry. This entails an exploratory “yes, and” approach, where one inquiry may lead to another, resulting in a chain of reasoning, eventually producing responses that may close the gap. This is apparent in the remainder of the first entry, where Barr’s thoughts on UI feedback led him to explore alternative interaction modalities, eventually refocusing on the original slider concept and stabilizing the approach by listing specific aspects of game behavior and player interaction, informed by the preceding chain of inquiries.

Despite the section discussed here being only one-sixth of the full entry’s length, it represents the first occurrence of a design loop: Barr’s explorations seem to venture from an initial idea that then spawns deeper inquiries, before returning to the original thought with a more concrete answer, informing subsequent choices.

These loops occur not only within self-contained instances of deliberations but may persist throughout several stages of development. In this opening phase of LOVE’s development, Barr’s explorative approach leads to the project’s expansion in scope through new interaction modalities, technical features, and trying to satisfy the speculative framing. However, this path toward eventual closure of the loop comes with confounding moments, as the following section will highlight.

Navigating surprise

Barr frequently describes moments of misalignment between expectation and outcome. These surprises occur throughout all project aspects and can be of experiential, technical, or conceptual nature.

At times, he anticipates such moments. For instance, once Barr provides the first complete description of the game flow in LOVE, he acknowledges that his initial assessment may overlook something: “Doesn’t actually sound like it needs to be especially complex? Ha ha, famous last words.”³ In another moment of anticipation, Barr contemplates the inclusion of overlapping pop-up dialogs, while immediately realizing how this may cause issues on mobile devices.⁴ This suggests a strong sense of material familiarity in game design and development, further supported by Barr’s extensive body of work.⁵

However, Barr may also avoid fully resolving an anticipated or experienced confounding moment in favor of a generative approach. For example, once Barr settles on Windows-95 era aesthetics for LOVE, he begins “to re-question previous ideas around outputs and indicators.”⁶ This results in another series of questions on UI feedback, not all of which are fully answered in advance. Instead, Barr opts to “implement some of these ideas more simply and see what happens.”⁷ This indicates that regardless of experience, a design practitioner may decide to not resolve all questions in theory but instead need to experience a design proposal in its materialized form in order to make informed decisions.

Barr’s implementation thus presents a form of inquiry – experiencing it helps determine what should happen next. This is in line with what Schön (1992) describes as seeing-moving-seeing, in which a design move changes the situation and makes further qualities available for interpretation.⁸

This is especially relevant because LOVE is a digital game. A focus on individual elements during design and implementation may strongly contrast with the dynamic experience that emerges from the interactions with and between these elements. Barr constantly revisits and evaluates the materialized design outcomes. This may lead to exceeded expectations: “Just sliding the slider on mobile feels surprisingly good.”⁹ It may also reveal potential for improvement in aspects that involve multiple design elements, such as the game’s orgasm mechanic. Barr’s experience of the game’s input modality and guiding communication reveals: “There’s a problem, I think, with the pacing of [the orgasm].”¹⁰

External feedback further supports evaluating intention vs outcome. It can expose meanings that may otherwise elude the designer within their own frame of reference. Barr frequently discusses LOVE with colleagues, students, friends, and family, which establishes external reference points that may help reduce personal bias or blind spots. A substantial redesign of LOVE’s main interactable element occurs after Barr receives feedback from his mother: After experiencing the game, she reports that the “game felt like being in service to a male, rather than [Barr’s] goal of the game feeling like giving pleasure to a more ambiguous entity.” Addressing Barr’s previous concern prompts him to rethink the slider’s vertical orientation and instead switch to a horizontal design.¹¹

These moments of alignment and misalignment seem to be important drivers of Barr’s transition from expanding the project’s scope to narrowing it.

Focusing and grounding

During the first phase of Barr’s work on LOVE, the project’s scope appears to be growing. As Barr opens and responds to an increasing number of design inquiries, he adds new features, which come with their own sets of technical challenges and questions of conceptual alignment. When Barr returns to the project after a one-month pause, he admits to being held back from finishing due to having a lack of clarity about “what it is, what it does, what it’s for” and that his enthusiasm for the project has waned. Nevertheless, he sees merit in the fact that the project’s premise resonates with others.¹²

Barr reiterates LOVE’s design goal of facilitating “humans in feeling like they’re giving pleasure to someone/something.” He acknowledges that “one answer to this is that therefore the pleasure-giving should recreate the complexities and subtleties of real lovemaking, in order to seem more authentic.” However, as he recognizes that maintaining subtlety through difficulty and complexity may conflict with the “erotic thrill of pleasuring,” his focus shifts toward centering the affordances and feedback of the interface itself.

Barr himself seems to imply here that there can be several answers to the same inquiry. This is supported by his exhaustive responses to a given question, especially in the early phase of the project. At the same time, Barr’s meandering inquiries may lack a definite solution, and navigating such multiplicity in the pursuit of one definite answer may lead to a loss of focus, as witnessed above. He does not simply dismiss the roads not taken but instead acknowledges them consciously, providing a rationale for his design decisions that ultimately result in a narrowing of the project’s scope.

Barr’s focus on a specific conceptual aspect gives him “permission to massively simplify the way [he is] thinking about this game.” He further states that “the shift to the Windows 95-esque aesthetic helps with that”¹³, indicating that aesthetic grounding supports further consolidating decisions. Here, aesthetics narrow the solution space, since Barr now consciously limits himself to using a reduced set of available sounds and visual elements. Barr’s choice is no coincidence but marks a return to the familiar, as he took this aesthetic direction in a previous game, It Is As If You Were Doing Work (henceforth WORK): Here, Barr adopted the Windows 95 style to support the intention of making the game feel and “look like work” through its office software-like appearance.¹⁴ In LOVE, however, this visual context serves a “humorous tension between the erotic charge and decidedly non-erotic Windows 95 interface […]”,¹⁵ while exploring another angle of speculative play. LOVE is now becoming a streamlined experience, featuring a simple gameplay loop of following instructions to slide a slider between changing value ranges at different speeds.

This aesthetic commitment marks a turning point in the development of LOVE: After widening the scope in a phase of consistent expansion through the exploration of various design concerns, Barr moves on to consolidation. What follows is a focused implementation phase that lasts almost three weeks, features the most commits, and, beyond minor tweaks and fixes, produces the final build. Now that Barr seems confident in how he addresses the speculative framework, final decisions are being made.

For instance, an earlier inquiry into additional UI interactions and exchanges with his students about the power of sound and speech initially prompted Barr to add voice input to LOVE.¹⁶ However, after having encountered several technical issues around its implementation, he decides to cut the feature, grounds this decision in the conceptual and aesthetic framework, it being “too high-tech and […] too intimate”.¹⁷

These moments signify a return of answers to previously open inquiries. As LOVE nears completion, the newly found answers support a reduction in scope, such as by removing a feature or simplifying a conceptual framing. Barr increasingly decides which questions belong to LOVE, and which do not. This leads to stabilization that embeds the answers within the final materialized response. This can be seen when Barr removes positive feedback and text input dialogs.

Barr previously introduced a text input dialogue as an interruption of the game flow that allows players to express themselves differently.¹⁸ However, testing had led him to realize that this was undesirable: positive feedback interrupted successful play, and text input pulled the game in a different direction.¹⁹ Now, instead of following up with new inquiries to try and integrate this feature, his arrived-upon conceptual understanding informs its removal – sorting out the conflict between design decisions eventually makes way for synergies.

What follows is a tying up of loose technical ends, debugging and tweaking, and eventually publishing the final build.

Closing the loop

LOVE’s gameplay loops back into itself, much like the design process of its creator. As outlined above, design inquiries in Barr’s journals tend to move through cycles. Proposals are generally questioned and iteratively developed. They may remain merely theoretical or become part of a refined materialization.

As the designer processes the various inquiries throughout such loops, they progressively focus in on a design implementation through cycles of ideation, evaluation, and surprise, while negotiating conceptual, referential, and technological constraints. As individual inquiries lead to inquiry loops, they are of an inherently recursive nature.

Barr’s chains of reasoning use the conceptual framework as generator for new ideas and filter for resulting materializations of design proposals and inquiries. The interconnected nature of these design inquiries demonstrates how design choices create ripples that propagate within and across domains. Some outcomes may be anticipated; some arrive as surprises that show misalignment between expectation and outcome. Some outcomes must be experienced to make an informed decision, others require, or benefit from external feedback to help the designer navigate their own biases and blind spots. There are often multiple answers to an inquiry, and an explorative design process may help to make informed decisions that intentionally include certain options, while excluding others. In LOVE, repeated evaluation appears to bring the game’s technical, conceptual, and experiential aspects into sufficient alignment for Barr to consider it complete.

It is as if there is a moment when everything falls into place.

Footnotes

1. Barr, P., LOVE Design Journal, March 24, 2018. ↩

2. Yang, R., 2012. ↩

3. Barr, P., LOVE Design Journal, GitHub, April 9, 2018, 2:15 pm. ↩

4. Barr, P., LOVE Design Journal, GitHub, June 6, 2018, 7:17 am. ↩

5. See https://pippinbarr.com/games/, https://github.com/pippinbarr?tab=repositories. ↩

6. Barr, P., LOVE Design Journal, GitHub, May 6, 2018, 6:39 pm. ↩

7. Ibid. ↩

8. Schön, D., Designing as Reflective Conversation with the Materials of a Design Situation, 1992. ↩

9. Barr, P., LOVE Design Journal, GitHub, May 9, 2018, 9:48 am. ↩

10. Barr, P., LOVE Design Journal, GitHub, June 12, 2018, 6:23 pm. ↩

11. Barr, P., LOVE Design Journal, GitHub, June 15, 7:17 am. ↩

12. Barr, P., LOVE Design Journal, GitHub, June 4, 7:33 am. ↩

13. Ibid. ↩

14. Barr, P., “It is as if you were back to work”, June 10, 2017. ↩

15. Barr, P., LOVE Design Journal, GitHub, June 18, 2018, 7:42 am. ↩

16. Barr, P. LOVE Design Journal, GitHub, April 12, 2018, 11:52 am. ↩

17. Barr, P., LOVE Design Journal, GitHub, June 4, 2018, 7:33 am. ↩

18. Barr, P., LOVE Design Journal, GitHub, June 6, 2018, 7:17 am. ↩

19. Barr, P., LOVE Design Journal, GitHub, June 23, 2018, 9:37 pm. ↩

Knowing and Not Knowing

We take for granted that design concepts are linked to their designers: Pippin Barr had an idea about making games about unremarkable life experiences, and these led to him creating his own micro-genre: “it is as if…” games.

Yet everything we know about how design problem solving happens implies a far more complex dynamic at play between designer and design concept ^{1 2 3}. A design concept may originate from a designer’s imagination, but this does not entail that designers initially understand their concept – or indeed, what it will eventually become. A concept that exists in imagination only lacks material form. Devoid of material form, the concept is unmaterialized. It is difficult to predict material consequences of unmaterialized concepts. When granted material form, the concept becomes something else.

Herein lies the paradox: designers both know and do not know their unmaterialized concepts. Materialization implies a crossover of a threshold between imaginary and real. Materiality introduces material consequences. Designers weigh up material consequences and adopt a most appropriate material form through the course of design activity, which is ever framed by context.

Designing as Navigating

Ontological metaphors designers use to express their design reasoning frequently evoke orientation and navigation, as if they are seeking to get somewhere. If the designer’s navigation problem is a search expedition, then the location of the search is the solution space:

My main feeling, though, is that the project is on a good trajectory that I can handle” ⁴.

“...in terms of the environmental design, I'm glad to know I'm on the right track here” ⁵.

It’s a strange navigation problem, though. The quotes above are from the design journals of two different designers. Designers often don’t know from the outset where they are heading. They may have some idea of where, but their directions are incomplete. Precise coordinates of their destinations are hard-won: 20/20 in hindsight; 20/200 in foresight. Which invites the following question:

how does design activity support the search behaviour of designers?

Locating Target

A simple answer might be to say: they use their extant experience and tacit knowledge to fuel their understanding of concept. We find evidence of Barr doing this in his Phone archives journal:

“This is where the sort of metanarrative of the game comes in I guess. Much as in the previous two... the idea that it's a tool with a purpose. In this case my working theory (which I really like) is that it's a tool both to look like you're on your phone (and so a NORMAL PERSON) but also to NOT be on your phone and thus not subject to the abject terrors and punishments of social media and the news and so on...” ⁶.

When Barr writes “previous two”, although we can’t be sure which games he is referring to (his GitHub repository turns up seven projects in response to the search query “It is as if”), since he specifies “tool with a purpose”, we may reasonably guess he is referring to It is as if you were doing work ⁷ and/or It is as if you were making love⁸. Referring to the archives of these two games enables us to compare their materials and designerly reflections to that of Phone.

These archives highlight the following about It is as if games:

• Barr seems to be drawn to designing play experiences that liken life experiences (i.e. computer-based office work, physical pleasure) to manipulation of GUI elements spanning the last three decades
• These games are single player, minimal in terms of narrative and aesthetics, and sufficiently simple that they can be readily engaged with by players outside of typical gamer communities

These traits turn up in Phone too.

But previous work is not the only factor influencing Phone: if this were true, designers would only ever make sequels of their previous work. This would suggest, for instance, that Phone ought to anachronistically feature Windows 95 aesthetics (it does not). Besides, it is clear from early journal entries that Barr’s concept is tethered to thematics on which he does not yet have a set position:

“I don't like the idea of simulating a specific app experience, but I think it's true that there are kind of higher level organizatinos (sic) that are worth preserving right? Like swipe down then double tap, swipe down then double tap (Instagram where you're liking pictures), or swipe right, scroll down, swipe left, etc...” ⁹.

The materials in Barr’s repository for Phone demonstrate two patterns:

• Quantity of design materials or components. There are fewer at the start, and many at the end.
• Co-dependency between concept and materials. It is weaker at the beginning, and stronger at the end.

In fact, this same pattern turns up in (many) other design projects: see, for example, the archives for Matthew Bethancourt’s lest Ten Horizons Cry ¹⁰, Adrian Demleitner’s Ostrakinda ¹¹, Vadim Nickel’s Soundgarden ¹²... etc. If we were to diagram these patterns against one another and against time, they look like this:

These movements look correlated. We will revisit this relationship later.

Dying on Which Hill?

Let’s pick up a Computer Science metaphor to think through what happens during design processes¹³. Hill Climbing algorithms refer to a class of heuristic-based search algorithms that seek the highest point within a solution space, as the highest point within the space represents the best solution. These algorithms attempt to keep bettering their current location by traversing towards nearby locations that have a goodness value better than the value at the current location, where the goodness value is intended to approximate the goodness of the solution. While what is ultimately being sought is the best possible solution, these algorithms proceed by searching for the best goodness value. In which case, how the goodness value is calculated is crucial. Applying the hill climbing lens to design problem solving, Barr’s broad, existing design intuitions based on experience – his tacit knowledge – serve as a form of goodness value to orient him towards paths of future possibility, i.e. I’ve encountered this type of design problem before. From previous experience I know which types of solutions were generative, so I will extrapolate that knowledge to my current problem context.

The efficiency of hill climbing algorithms is connected to how they are not assessing the goodness values of every point in the solution space before making a judgement about where to go next. They are only making judgements based on nearby points. But this strength also sometimes acts as a weakness. Vantage is based on current location, therefore current location determines what one can see. This leads to hill climbing algorithms getting stuck in local maxima - areas within the solution space higher in value than anything else nearby, though not necessarily of equal value to the global maxima (and thus not actually the best solution)¹⁴. What might appear as the best solution may only seem so given the current context.

A corollary of local maxima in the context of design problem solving is design fixation. Described by Jansson and Smith in 1991 as “a blind, and sometimes counterproductive, adherence to a limited set of ideas in the design process” ¹⁵, design fixation results in pursuit of suboptimal design solutions. There may be pragmatic reasons why one (class of) solution must be adopted, for instance, when back compatibility is required or legacy systems are involved. But design fixation does not describe these situations: rather, it is when designers choose not to pursue potentially stronger alternatives. Additionally, Jansson and Smith point out that pursuing a limited set of ideas is not in itself indicative of design fixation: what is deemed limited is defined against the full backdrop of a designer’s experience. A novice designer might appear to be caught by design fixation due to pursuing a small number of ideas, but the limited size of their database of design experience plays a significant role in what they are able to extrapolate. Design fixation, then, is a phenomenon more pertinent to designers with sufficient experience; ones who literally know better. A follow-up study conducted by Condoor and Lavoie in 2007 emphasized that design fixation affects designers of all levels (seasoned and novice alike), and pointed out that all designers struggled to “move away from the prototype”¹⁶.

Doubling Downm

The psychologist Robert Zajonc named the human tendency to view that which they are familiar with in a more positive light as the mere-exposure effect ¹⁷. Framed in the context of design, the mere-exposure effect suggests that known (i.e. lower risk) solutions are rated positively, while unknown (i.e. higher risk) solutions are rated negatively. Sunk-cost fallacy turns up here too: if time is money, and effort is time, then spent effort = fat stacks that won’t come backs ¹⁸. When design fixation strikes during hill climbing, goodness value is hijacked by familiarity and cost, instead of what it is intended to be based on: approximations of solutional goodness¹⁹. Worse, it implies a local maxima. Worse still, that one is stuck in it.

How, then, do designers extract themselves from the local maximal quicksand that is design fixation?

In short, they must notice that it is happening. Barr’s style of reflective journalling involves wayfinding through questions, the practice of designers asking themselves questions during design time as a navigational aid ²⁰:

“I'm concerned by the tension between relief/social camouflage and the gamified version where it seems like it would be very stressful. Why would you play this as a game specifically? There's some way in which that ends up feeling too close to the real experience? Am I just concerned that without some gamified element people won't see the point in interacting longer term? But if it's an application, then it's not really intended to be played in that way - it's a tool not a game?” ²¹

These questions directly identify conflicts that co-exist within his current concept. This suggests that at the time of writing, he was still entertaining competing logics justifying different responses to those questions, i.e. those logics had not yet been organised into a hierarchy of precedence. Barr is taking pause at this intersection: he sees multiple paths ahead, but cannot yet tell which is more promising. But it’s not just that he is at a crossroads: if his navigation instructions had been more appropriate for the solution space, he would not have encountered that crossroads. Barr is thus concerned by the inconsistency within his current grasp of concept. His hesitations with the concept are further evidenced by a later journal entry recalling an attempt to implement a double tap mechanic:

“As I started trying to "easily" "breezily" implement double taps it felt like the moment that everything would break apart (mostly my mind) in terms of the structures at play.”²²

Barr’s mechanism for extracting himself from fixation is to establish careful rules of engagement for how to venture into unchartered territory. As is emblematic of his style of design problem solving, Barr leans on his technical infrastructures to illuminate a path forward.

But this means he must first take a few steps backwards.

Extracting by Refactoring

Directly after writing the above, he writes:

“It spiralled me out into thinking (fantasizing??) about OOP and inheritance and a beautiful clean cool implementation of All This.” ²²

At this stage, the benefits of shifting over the code base to an OOP implementation come across more as an aesthetic fantasy, or indeed a delaying tactic²³ for making decisions about the conflicts mentioned above. Over the next five days, he refactors his ad-hoc codebase in keeping with an object-oriented programming (OOP) structure. Having rematerialized his concept as an OOP implementation, the tone of his journal entries take a turn:

“it feels much more like there's an alignment between implementation and the spirit of the project… in switching programming paradigms I'm finding a better way of thinking about/expressing a part of what this whole thing is about, which is the desire we maybe have (sometimes?) to be more like computers doing computer things in computer ways”²⁴

Having adopted an OOP implementation directly impacts on Barr’s way of perceiving the solution space – both what it constitutes, but also where good solutions are afforded. It becomes an additional lens through which he is assessing goodness values. The benefit of the OOP implementation for Barr is not just what it allows him to understand, it is also how it allows him to act. It becomes the language he uses to materialize and express and extend his concept, evidenced when he says, “the desire we maybe have (sometimes?) to be more like computers doing computer things in computer ways”. This is the first time Barr has presented this sentiment — and this only happens after he has spent time concertedly and consistently expressing the concept in a form that can be compiled by a computer. The Sapir-Whorf linguistic hypothesis posits that the language we use shapes what we want to say, and reciprocally, what we want to think²⁵. Barr’s OOP implementation plays that role here: he must work within the syntactic and semantic constraints of OOP. Future design decisions become framed by OOP. For instance, his implementation of Acts prompts him to make decisions about pragmatic details, such as timing:

“How often do you switch activities? - I suppose just often enough for it not to be excruciating? Some of that is about the support the Acts do/don't offer to things” ²⁶

Accelerated Clicking

A designer’s ability to be appropriately expressive in their materials of choice can be correlated to their density of confidently-made design moves that are internally consistent with one another: we have previously characterised such moves as conceptual clicks ²⁰. In military jargon, click also serves as a unit of measurement. Incorporating this other meaning of click, Barr’s high density of clicks entails accelerated traversal of the solution space, enabling him to cover more ground quickly and gain momentum:

“It was really pleasing to implement a Dating activity with a minimum of confusion and difficulty thanks to the framework I'd set up for the Browsing activity. I was able to just add a set of classes that represented the approapriate (*sic*) swipes and then it kind of just worked without too much difficulty” ²⁷.

In interaction design endeavours, until designers experience their concepts in their intended implementation environment, uncertainty remains about whether those concepts are viable. The OOP implementation enables Barr in knowing that his evolving concept remains aesthetically viable:

“Let me pick up my phone now and do some "dating"... It felt... pretty great at a base level? I continue to feel like the core project here makes sense.” ²⁸

Barr’s adoption of OOP thus acts as a turning point in his design trajectory. It enables him to smoothly yet systematically externalize the interaction experience for which he previously held only a partial, conceptual understanding. Barr’s design concepts herein become expressed as — and thus embodied through — core materials. For Barr to continue building his code base efficiently, all future extensions of concept must be materializable via his code base:

“Interaction Sequencing - Right now interactions have probabilities of showing up but they're not actually sequenced in a way that would build a sense of a well-known interaction (e.g. scrolling Instragram (sic) is like: look look doubletap scroll down look scroll down look look look scroll down scroll down look doubletap -- or something); having a kind of "grammar" of interactions sounds pretty cool but also really tiring, but also maybe what I should be doing... at worst could just be selecting from an array of atomic interactions that deal with "one media unit" or something? Regular expressions?” ²⁶

This, in turn, flavours how future design decision making happens, with greater weighting and priority given to design extensions suggested by, supported by, and/or integratable with existing infrastructural materials. Barr’s understanding of the concept post OOP implementation is granted substrative materiality by his OOP materials, whereby substrate is intended to evoke underlying surface, or foundation. The material of Barr’s substrate — his OOP implementation — plays a strong role in shaping the behavior of consequent layers of material that rest on it. A designer’s choice of substrate shifts the locus of best possible materialization of concept to solutions afforded by that substrate. Returning to the hill climbing metaphor, the coordinates from which Barr is searching for a best possible materialization of concept now cluster around a space that supports not only possible OOP solutions, but generative ones.

Worth exploring is whether any materials Barr used during the process might have equally served as his material substrate. In his second journal entry, Barr speculates on what type of feedback feel to pursue, in relation to an aspect of the initial game concept — a “zen” feeling:

“My inclination as of right now is to lean into the kind of "Zen" conceit involved here and to make the sounds simple chimes or other zenny sounds (gongs?). Some way of continuing the emotional tone of calm, sort of trying to catch onto the seeming calm of this kind of phone use, but making it actually calm, but making it still engaging? So prototyping some sound formats makes sense, starting with Zenning” ²⁹

Although Barr declares an intention to prototype sounds, this does not happen. Once he begins refactoring, his attention shifts elsewhere. As we see later, the entire zen aspect of the game concept is ultimately dropped. Why, then, does the OOP implementation exert substrative materiality while, for instance, sound design does not? A designer’s gravitation towards a particular material substrate will be heavily influenced by their design values: see ³⁰ for a robust overview of motivations driving designers. From Barr’s other GitHub repositories, we find ample evidence that he commonly relies on technical implementations as a way to generate his design concepts, i.e. they are his “go to materials” (presumably because he is highly fluent in them). Designers’ substrates are also filtered by their experience and tacit knowledge.

Pulling into Orbit

Newton’s second law of motion states that bodies exert forces on each other:

f = m x a

A body with larger mass than another body exerts more pull on it, pulling that body towards it. Something similar happens with the pace of how Barr’s concept suddenly coalesces, all while the code base continues to grow. At the start of a design process involving few externalized materials, a designer’s initial understanding of their design concept is uncertain – not least of all because it resides largely in their head. Designers who are very experienced with certain materials might have enough conceptual foresight to predict the consequences of future design moves involving those materials without needing to rely on material experiments ³¹. But if an initial design concept (or material environment) is sufficiently novel, accurate conceptual foresight is less likely. A novel concept entails lack of conceptual clarity or substance, akin to a body with low mass. A body with lower mass will exert lower pull. Follow-up internally consistent design moves are harder for the designer to make (and thus absorb into the initial concept), because the initial concept does not yet exert enough pull.

As the design process continues, the center of a concept’s mass transitions to its material substrate: the design materials that seemed most promising. With a viable substrate in place, the concept grows in terms of mass and clarity.

Rolling Katamari Gathers Mass

The conversational phrase real and material consequences expresses an unequivocal (if ominous) message: actual things will happen as a result. It likewise resonates with what takes place after a design concept has been given substrative materiality: the designer can more confidently predict consequences, on the basis of design moves involving established materials. The substrate exerts pull on other simpatico ideas from the solution space, amassing them into a bundle.

This stage in the design process is evocative of Katamari Damacy. The katamari or ball is the substrate bundle, an assemblage of internally consistent concepts and materials. The designer rolls the katamari around in the solution space based on tacit knowledge or experimentation. If they encounter promising conceptual additions, those are amassed onto the katamari. There comes a point when the katamari has gathered sufficient mass to have a clearly defined identity, boundaries, and material form. At this stage, the katamari will readily attract internally consistent design concepts/materials. From the designer’s perspective, they can confidently and rapidly make design moves — indeed, the moves almost make themselves. The following is a quote from Barr’s journal a few days after has shifted to the OOP implementation:

“I implemented those mockups pretty literally over the last few days and the game has kind of jumped from feeling a bit off to pretty much feeling like what I wanted? It suddenly feels close to done -- though naturally that doesn't mean it *is* close to done. Crucially I think it seems to work” ³²

Forming While Functioning

Remember the graph from earlier, QUANTITY OF MATERIALS VS. CO-DEPENDENCE BETWEEN CONCEPT AND MATERIALS? Notice the general trend: when the quantity of materials is low, the co-dependence between concept and materials is also low. Conversely, when co-dependency between concept and materials is high, the quantity of materials is high.

Over the duration of the design process, there is a clear shift in how Barr articulates his concept: his design concept articulations become increasingly tethered to the materials of his chosen substrate, until his concept and his substrate are inseparable. Once this point is reached, it is hard for Barr to introduce disparate additions to the concept: they cannot easily be integrated into the existing machinery. The katamari will not pick them up. Thus, Barr jettisons the meditative aspect — the zen mode:

“My growing feeling is that the zen mode just doesn't really work right now. It's too distinct from the main project, it's not about pretending you're on your phone and I think that if I'm going to pursue it as an idea (using phone interactions as a form of meditation) I need to give it its own space to breathe and be its own thing… so... bye zen!” ³³

Louis Sullivan’s famous maxim, form follows function ³⁴ may be relevant in situations when function has been settled. But when function is not clear — as is often the case in experimental design endeavours — form and function, in fact, look to one another for cues. Barr leaned on his conceptualization form – his OOP material substrate – to help him understand the function of his concept. Likewise, he leaned on his evolving understanding of the function of his concept to drive the specifics that his OOP implementation ultimately resulted in (his form). Neither of them made room for zen mode.

Had Barr insisted on maintaining zen mode and centralised it from early on, the resulting game would have been different. This is the lesson learned: if a design aspect is non-negotiable, designers need to prioritize it and embody it in the material substrate early on. Otherwise, they will run the risk of losing it later for reasons of lack of internal consistency: it does not align with the spirit of the design — the designgeist.

Feelsmaxxing not Looksmaxxing

Let’s address our friendly, neighbourhood elephant: Barr never actually found the global maxima. This would be a logical impossibility: design solution spaces remain changeable throughout a design process, thus designers can never find the global maxima. Design thinking is a wicked problem³⁵. Barr jettisoned an entire component of his early concept and still felt as if he had hit his intuitive target:

“The game has kind of jumped from feeling a bit off to pretty much feeling like what I wanted?“ ³²

Barr found a good enough solution — resonating with the filtering qualities of abductive thinking ³⁶, as well as how scholars of research epistemology have characterised the relationship between design and truth: “truth is what works at the time” ³⁷. Barr relied on intuition to drive his sense of how successful design solutions behave. This feeling was not based on time, because the timescale of this project (7 weeks) was shorter than many of the timescales involved in other projects housed in his GitHub repositories. Being “done” is a designerly intuition, premised on a designer’s comparison between their intrinsic vision of conceptual designgeist and the iteration of the concept’s body that is ultimately deemed to be its final form.

---

Footnotes

1. Nigel Cross. 2006. Designerly ways of knowing. Springer, London. ↩

2. Johan Redstrom. 2017. Making Design Theory. MIT Press. ↩

3. Donald A. Schön. 1983. The reflective practitioner: How professionals think in action. Ashgate, Farnham ↩

4. Pippin Barr. 2025. Nexts. GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#nexts-2025-01-23 ↩

5. Vadim Nickel. 2024. soundgarden process journal. GitHub. Retrieved November 27, 2025 from https://github.com/Videon/soundgarden/blob/f9e122578115c1904a03614a229b2f5e899086f6/docs/2024-12-04.md ↩

6. Pippin Barr. 2025. Who are you trying to fool? GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#who-are-you-trying-to-fool ↩

7. Pippin Barr. 2016. It is as if you were doing work. Retrieved November 27, 2025 from https://github.com/pippinbarr/itisasifyouweredoingwork ↩

8. Pippin Barr. 2018. it is as if you were making love. Retrieved February 6, 2025 from https://github.com/pippinbarr/itisasifyouweremakinglove ↩

9. Pippin Barr. 2025. Sequencing. GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/tree/main/process ↩

10. M. Bethancourt. 2025. mouseandthebillionaire/_lestTenHorizonsCry. Retrieved May 14, 2026 from https://github.com/mouseandthebillionaire/_lestTenHorizonsCry/blob/main/docs/Process/Precedents.md ↩

11. Adrian Demleitner. ostrakinda. Codeberg.org. Retrieved June 11, 2026 from https://codeberg.org/thgie/ostrakinda ↩

12. Vadim Nickel. 2025. Videon/soundgarden. Retrieved June 11, 2026 from https://github.com/Videon/soundgarden ↩

13. What follows is a reasonable question that may have crossed your mind: why should human problem solving be anything like a computational algorithm? There is more in common between how people and computers problem solve than you might think ³⁸. AI has long been a cousin of design studies, as evidenced by Herbert Simon’s The Science of the Artificial , and specifically, his 1969 definition of design that is still routinely used: “devising courses of action aimed at changing existing situations into preferred ones” ³⁹. ↩

14. Take, for example, Mount Royal (233m). It may be the highest point in Montreal, but it’s laughably far from being the highest point in Canada (5,959m). ↩

15. David G. Jansson and Steven M. Smith. 1991. Design fixation. Des. Stud. 12, 1 (January 1991), 3–11. https://doi.org/10.1016/0142-694X(91)90003-F ↩

16. Sridhar Condoor and Donna LaVoie. 2007. DESIGN FIXATION: A COGNITIVE MODEL. In ICED’07, 2007 ↩

17. Robert B. Zajonc. 1968. Attitudinal effects of mere exposure. J. Pers. Soc. Psychol. 9, 2, Pt.2 (1968), 1–27. https://doi.org/10.1037/h0025848 ↩

18. Richard Thaler. 1980. Toward a positive theory of consumer choice. J. Econ. Behav. Organ. 1, 1 (March 1980), 39–60. https://doi.org/10.1016/0167-2681(80)90051-7 ↩

19. Incidentally, this all serves as further argument for Lim et al.’s economic principle of prototyping: “that the best prototype is the one that—in the simplest and most efficient way—makes the possibilities and limitations of a design idea visible and measurable” ⁴⁰ ↩

20. Rilla Khaled and Pippin Barr. 2023. Generative Logics and Conceptual Clicks: A Case Study of the Method for Design Materialization. Des. Issues 39, 1 (January 2023), 55–69. https://doi.org/10.1162/desi_a_00706 ↩ ↩²

21. Pippin Barr. 2025. it-is-as-if-you-were-on-your-phone/process/journal.md at main · pippinbarr/it-is-as-if-you-were-on-your-phone. GitHub. Retrieved June 4, 2026 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md ↩

22. Pippin Barr. 2025. OOP Browsing · pippinbarr/it-is-as-if-you-were-on-your-phone@4d55b31. GitHub. Retrieved June 4, 2026 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/commit/4d55b31fbd94b2523cf78070797c022b2e00ae90 ↩ ↩²

23. Code base refactoring is a common and productive-looking form of procrastination favored by software developers everywhere. When asked, they will deny it. ↩

24. Pippin Barr. 2025. I wanna be an FSM. GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#i-wanna-be-an-fsm ↩

25. Basel Al-Sheikh Hussein. 2012. The Sapir-Whorf Hypothesis Today. Theory Pract. Lang. Stud. 2, 3 (March 2012), 642–646. https://doi.org/10.4304/tpls.2.3.642-646 ↩

26. Pippin Barr. 2025. What would it take for this game to be done? GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#what-would-it-take-for-this-game-to-be-done-2025-02-14 ↩ ↩²

27. Pippin Barr. 2025. Dating. GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#dating ↩

28. Pippin Barr. 2025. Testing. GitHub. Retrieved November 27, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#testing ↩

29. Pippin Barr. 2025. Early sketching. Retrieved July 13, 2025 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#early-sketching-2025-01-08 ↩

30. Annakaisa Kultima and Alyea Sandovar. 2016. Game design values. In Proceedings of the 20th International Academic Mindtrek Conference (AcademicMindtrek ’16), October 17, 2016. Association for Computing Machinery, New York, NY, USA, 350–357. https://doi.org/10.1145/2994310.2994362 ↩

31. John Sharp, Colleen Macklin, Steven Davis, Yu Jen Chen, Tuba Ozkan, and Carla Molins Pitarch. 2019. Iterate: Ten Lessons in Design and Failure. The MIT Press. https://doi.org/10.7551/mitpress/10826.001.0001 ↩

32. Pippin Barr. 2025. Progress; Zen. GitHub. Retrieved June 15, 2026 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#progress-zen-2025-02-20 ↩ ↩²

33. Pippin Barr. 2025. High praise; explainers; bye zen. GitHub. Retrieved June 15, 2026 from https://github.com/pippinbarr/it-is-as-if-you-were-on-your-phone/blob/main/process/journal.md#high-praise-explainers-bye-zen-2025-02-26 ↩

34. Louis H. Sullivan. 1896. The tall office building artistically considered. Retrieved June 13, 2026 from http://archive.org/details/tallofficebuildi00sull ↩

35. Richard Buchanan. 1992. Wicked Problems in Design Thinking. Des. Issues 8, 2 (1992), 5–21. https://doi.org/10.2307/1511637 ↩

36. Jon Kolko. 2010. Abductive Thinking and Sensemaking: The Drivers of Design Synthesis. Des. Issues 26, 1 (January 2010), 15–28. https://doi.org/10.1162/desi.2010.26.1.15 ↩

37. John W. Creswell and J. David Creswell. 2018. Research design: qualitative, quantitative, and mixed methods approaches (Fifth edition ed.). SAGE, Los Angeles London New Delhi Singapore Washington DC Melbourne ↩

38. Brian Christian and Tom Griffiths. 2016. Algorithms to live by: the computer science of human decisions (First international edition ed.). Henry Holt and Company, New York. ↩

39. Herbert A. Simon. 1996. The Sciences of the Artificial, third edition. MIT Press ↩

40. Youn-Kyung Lim, Erik Stolterman, and Josh Tenenberg. 2008. The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Trans Comput-Hum Interact 15, 2 (July 2008), 7:1-7:27. https://doi.org/10.1145/1375761.1375762 ↩

From Demleitner et. al, 2026

Intentions, Process, and Coin Flips

The initial spark for Ostrakinda was the first author’s wish to explore coin flipping as a game mechanic. Coin flipping is a simple way of deciding an either/or bet through randomization. It is a simple mechanic that has been applied to games and play in a plethora of cultures and eras. One of the earliest examples is a children’s game in ancient Greece, to which the video game owes its name¹. Being a simple act of play, while also culturally loaded, made coin flipping or coin flips a good starting point for a challenging exploration of this mechanic, and enabling reflection on the design process.

Ostrakinda_ came into existence over roughly four months, spanning initial ideation to refinement of a satisfactory prototype, which is shown in Figure 1. The game’s final archive ² contains a collection of inspirational references of coin flips in other games and cultures, reading notes on research articles and game developer lectures, an export of the designer’s personal Discord journal channel³, documentation on Ostrakinda’s mechanics ⁴, a reflexive journal ⁵, mappings and visualizations, screenshots and recordings of playtests, and finally eleven discernable prototypes ⁶ that materialized parts of the final game.

Creating an MDM archive or repository, that encompasses development material and documentation, concludes the first phase. The second focuses on analysing the archive through GT, a way of thinking and conceptualizing data through qualitative coding and emergent theorizing. Our approach to GT follows an iterative, coding-based grounded theory approach, most closely aligned with constructivist grounded theory ⁷, because codes and the codebook are progressively refined across multiple rounds of analysis.

Grounded Theory, and Material Readings

The initial stage of GT, known as open coding, requires analysis of research materials by way of labelling or coding according to patterns the researcher deems those materials to evidence⁸. Once open coding has concluded, codes are revisited in their capacity as theory framing vocabulary. They are then reprocessed through axial coding, where the researcher collates and collapses codes into larger categories, with a view towards preliminary theorization. Once labelling and axial coding are complete, the process can be started anew with an updated set of codes and a deeper understanding of the materials. This process is iterated until theory saturation has been reached, which is when there are diminished insights obtained from analytical passes.

The GT analysis of Ostrakinda involved two such passes of open and axial coding, and a third pass that focused on analysis of Ostrakinda’s materials. The first pass concentrated on open coding the textual artifacts in the MDM archive, namely, the reflective journals and commit message contents. As qualitative data coding results in the generation of significant secondary data, qualitative data analysis (QDA) software is often used by researchers to facilitate the coding process as well as organise code structures. Popular options for such software are MAXQDA, or NVivo⁹. For the analysis of Ostrakinda, the open-source QDA alternative QualCoder was chosen, shown in Figure 2.

During this pass, the researcher focused on distinguishing between material movements (modifications to materials) and immaterial movements (modifications to how the designer thought about or experienced the design process). Movement as a category was further experimented with through metaphorical extrapolation of different types of movements: walking in circles for moments in which the designer was stuck, pacing back and forth or meandering for different ways of exploring, or sprinting for clearly directed actions that get things done. This resulted in a re-conceptualization of the design process as intentional visiting, rather than an active doing.

The analysis of Ostrakinda needed to accommodate two additional needs, the first concerning Ostrakinda’s chronology. An MDM archive can encompass several types of documents linked to specific moments in time, like journals or the aforementioned messages attached to the snapshot. Coding a section of the research material in QualCoder does not automatically append an appropriate timestamp: this had to be achieved manually by adding dates to the codes, shown in Figure 3, which then enabled chronological sorting. As this step depended on a complete pass of coding the research material, it was done between the first and second coding passes.

The second aspect of researching the material development took place after the GT analysis. The aim was to trace what was developed, when, and to what extent in order to understand the impact those developments had on the design process. Concretely, this involved examining each prototype with respect to three dimensions: the period in which it was developed, the programming language or video game engine employed, and the specific manner in which the central mechanic of the coin flip was realized in each case. To do this, the analysis drew on three analytical lenses: the codebook, the reconstructed timeline, and a first attempt at theorization. The insights generated through this secondary material analysis were then fed back into the assembled timeline and brought into dialogue with the interim findings from the GT analysis, producing a set of emerging findings ¹⁰.

This last step of the analysis was informed by critical code studies ¹¹, which treats code not merely as a functional tool but as a sociocultural artifact worthy of study in its own right. Underlying this methodological choice is a theoretical premise drawn from the work of Peter Naur and David M. Berry, both of whom foreground the relationship between programming and cognition. Naur’s notion of programming as theory building ¹² suggests that code externalizes the mental models its author holds about a problem domain. From this perspective, studying and re-reading code amounts to reconstructing a way of thinking. Berry’s work on the cultural and critical dimensions of software ¹³ similarly argues that the choices made in writing code (including which abstractions are employed, which structures are favoured, and which solutions are reached for) are not purely technical but reflect and shape the programmer’s cognitive and conceptual engagement with the problem at hand. For a study concerned with a design process unfolding through iterative prototyping, this perspective made attending to the material and syntactic character of the code an analytically meaningful complement to the grounded theory approach: the prototypes were not just by-products of the process, but meaningful traces of thinking in and through the medium of programming.

Handling several dimensions of analysis (qualitative data analysis, process chronology, material movements) proved challenging, and the researcher had to augment the capacities of QualCoder with spreadsheets and hand-drawn timelines, as shown in Figure 4. Despite being specifically designed to support qualitative data analysis, numerous QDA platforms fall short in terms of facilitating work with materials that are born-digital ¹⁴.

Designer as Guest, towards Materials as Hosts

Our emergent theory concerning the development process of Ostrakinda is summarized as designer as guest. Although the notion of guest never explicitly appears in vivo in the archive materials, it is an apt characterization of the uncertainty and carefulness the designer experienced in relation to the practice of game design. We find ample evidence in the documentation on the struggles of creating an appealing video game as well as reflections on anxiety. Visiting was thus a fitting description of how this designer experienced their practice, because they did not feel at home.

While grappling with the theme of visiting, the researcher deemed visitor to be an inaccurate description of their engagement with the design materials at hand. Their engagement was not passive, as in visiting an art exhibition, but active, like a visiting guest appreciating and reciprocating in the experiences enabled by their host. The following quote by Donna Haraway on Vinciane Despret’s polite interest closely captures the mindset the designer inhabited while developing Ostrakinda:

In every sense, Despret’s cultivation of politeness is a curious practice. She trains her whole being, not just her imagination, in Arendt’s words, “to go visiting.” Visiting is not an easy practice; it demands the ability to find others actively interesting, even or especially others most people already claim to know all too completely, to ask questions that one’s interlocutors truly find interesting, to cultivate the wild virtue of curiosity, to retune one’s ability to sense and respond — and to do all this politely! ¹⁵

Sharing these findings from the analysis with the MDM research team led to the emergence of a secondary insight. Much of the reflective documentation of Ostrakinda was coded as retroactive sense making, of which the following excerpt, taken from the designer’s documentation, is an example:

Implementing the doubts¹⁶ today was really interesting. I didn’t really know where to attach it to. I wanted something that appeared a bit more spontaneously and not directly linked to an interaction. As in thoughts that might appear while just being. We can’t choose when these appear. And I wanted to have that in the game as well. So the doubts should not be attached to every single time I flip a coin, not even randomly if I flip a coin. But they should nonetheless appear when I’m on the desktop¹⁷ so they get a bit contextualised.

Retroactive sense making refers to the designer’s post hoc sense making of the consequences of material changes they had made. Interestingly, there was close to no actual documentation on the technical implementations they were reflecting on. Most often, new features or milestones were announced in single sentences, and only later expanded on and processed via retroactive sense making.

Bookending the researcher’s emergent theory of designer as guest, the MDM team proposed the addition of design materials as hosts. If design is a situated and embodied practice, then it can likewise take place as an encounter. This finding suggests that insights regarding design and development, i.e. a designer’s tacit knowledge, exist as a by-product of a designer interacting with their materials. This position is supported by design research theory ¹⁸, new feminist materialism ¹⁹, thing theory ²⁰, as well as writing on affordances and enactivism ²¹.

---

Footnotes

1. Ostrakinda has children flip a shell, painted white on one side, black on the other. While the shell is mid-air, the child flipping it will need to call the outcome. Depending on the resulting side of the shell and the bet, the child’s group is either hunter or hunted in a game of tag. ²² ↩

2. thgie. 2025. Ostrakinda. Codeberg.org. https://codeberg.org/thgie/ostrakinda ↩

3. In an experimental phase, each MDM research project member cultivated their own Discord channel journal to entangle documentation, micro blogging, and communication with other team members. ↩

4. thgie. 2025. Ostrakinda/Notes/Coin Betting Mechanic.Md at Process. Codeberg.org. https://codeberg.org//thgie/ostrakinda/src/branch/process/notes/ Coin%20Betting%20Mechanic.md ↩

5. thgie. 2025. Ostrakinda/Journal.Md at Process. Codeberg.org. https://codeberg. org//thgie/ostrakinda/src/branch/process/journal.md ↩

6. thgie. 2025. Ostrakinda/Prototypes at Analysis. Codeberg.org. https://codeberg.org/thgie/ostrakinda/src/branch/analysis/prototypes ↩

7. Savithiri Ratnapalan. 2019. Qualitative Approaches. 65, 9 (2019), 667–668. pubmed:31515317 https://pmc.ncbi.nlm.nih.gov/articles/PMC6741812/ ↩

8. Not all qualitative coding approaches include such a stage: thematic analysis, for instance, makes use of labels or codes that may be predefined in code books. ↩

9. See https://www.maxqda.com and https://lumivero.com/products/nvivo , accessed 27 March, 2026 ↩

10. The documentation of the analysis process, as well as the data that was produced through grounded theory can be accessed at https://codeberg.org/thgie/ostrakinda/src/branch/analysis, accessed 27 March, 2026 ↩

11. Mark C. Marino. 2020. Critical Code Studies. The MIT Press ↩

12. Peter Naur. 1985. Programming as Theory Building. 15, 5 (1985), 253–261. doi:10.1016/0165- 6074(85)90032- 8 ↩

13. David M. Berry. 2015. The Philosophy of Software: Code and Mediation in the Digital Age. Palgrave Macmillan. ↩

14. Enric Granzotto Llagostera, Rilla Khaled, and Kalervo Sinervo. 2025. Tracing Research Through Design with Ponte: Bridging Game Development Repositories and Qualitative Research Tools. In Proceedings of the 20th International Conference on the Foundations of Digital Games (New York, NY, USA, 2025-05-09) (FDG ’25). Association for Computing Machinery, 1–10. doi:10.1145/3723498.3723821 ↩

15. Donna Jeanne Haraway. 2016. Staying with the Trouble: Making Kin in the Chthulucene. Duke University Press. ↩

16. Doubts in this case is referring to a mechanic within the video game. ↩

17. Desktop is a place the player can go to within Ostrakinda. ↩

18. Andy Dearden. 2006. Designing as a Conversation with Digital Materials. 27, 3 (2006), 399–421. doi:10.1016/j.destud.2005.11.004 ↩

19. Laura Forlano. 2017. Posthumanism and Design. 3, 1 (2017), 16–29. doi:10.1016/j. sheji.2017.08.001 ↩

20. Bill Brown. 2001. Thing Theory. 28, 1 (2001), 1–22. jstor:1344258 https://www. jstor.org/stable/1344258 ↩

21. Marta Jorba and Pablo López-Silva. 2024. Mind in Action: Expanding the Concept of Affordance. 37, 7 (2024), 1579–1589. doi:10.1080/09515089.2024.2365554 ↩

22. William Smith. 2013. A Dictionary of Greek and Roman Antiquities (1 ed.). Cambridge University Press. doi:10.1017/CBO9781139794602 ↩

From Khaled & Bethancourt, 2026

In Declaration by Design, Richard Buchanan argued that the form and function of a designed object collectively serve to communicate rhetorical assertions concerning preferred modes of use, preferred ways of being in the world, as well as preferred design values¹. At the same time, experiencing and analyzing only the designed object (i.e. ignoring additional context concerning how it came to be) can only go so far in explaining the reasoning that went into it, including how it may have been significantly informed by earlier design efforts. Design reasoning happens not just during design projects but between distinct design projects. Extending Buchanan’s framing of how designed objects declare rhetorics, we argue that non obvious, higher orders of design reasoning are at work when designers engage in design activity. The higher order begins to be hinted at through design rhetorics expressed by design artifacts, as well as values and techniques adopted by makers in individual projects. That these rhetorics, values, and techniques then turn up across distinct projects reinforces the potential presence of a higher order, operating maybe even below the conscious radar of designers themselves.

To illustrate our emergent theory, we rely on material evidence from the MDM archives of two projects undertaken by one of us concerning alt.ctrl experience design. To simplify the written voice, we refer to the designer in the third person as “the designer”, acknowledging that he is one of the authors of this paper. We invite readers to open up the archives of these projects and examine some of their materials as our case study progresses. LTHC’s archive can be accessed here ² and IE’s archive can be accessed here ³.

Lest Ten Horizons Cry

Lest Ten Horizons Cry (LTHC) ⁴ is an alternative-control game that arose from the designer’s research and was featured at A MAZE Berlin 2024. The initial impetus for this project was to explore the research question, “what would a game controlled with a synthesizer look like?” ⁵ The game’s website describes it in this way:

Initially, users are presented with a custom-built boutique synthesizer. By turning the dials, the various sonic parameters can be adjusted, creating an everevolving sonic landscape. The large synthesizer screen displays simple, cryptic, but generally traditional visuals mapped to each of these physical dials.

But underneath this all is something hidden.

Below the surface is a doorway to an unknown and secret history. Who has built this strange device, and what are they trying to tell us? At first the visualized parameters make sense, but over time the images on the screen distort, fragment, and morph into something else entirely, giving glimpses of images, text, and sounds that tell an entirely different story ⁴

Based on the play experience of the final iteration of LTHC, an outside observer would likely predict the following as design rhetorics expressed by LTHC:

• Traditional synthesizer hardware components can be used to control different forms of “playing”.
• Game controllers need not be “user friendly” in the standard sense of facilitating clearcut understandings of input-output relationships.
• Related to the above, the attentional engagement demanded by nonstandard game UIs is rewarding once it has been demystified.

From these design rhetorics in combination with the public facing media available about LTHC, we can predict the following as core experience design intentions the designer was pursuing:

• To recontextualise traditional synthesizer hardware design for controlling playful environments.
• To embrace ambiguity in game input-output pairings by forgoing standard game controllers, i.e. directional pads, buttons, and joysticks.
• To foster attentional attunement as a means of discovering hidden experiences in gameplay.

Instauratio Exiguus

I definitely want to do another project that builds on this. Not this. I think this is done, but something that nexts this idea. That keep poking at the question of granular audio control, reflective experiences, and abstract "puzzly" bits⁶.

The above statement comes from the final MDM reflective journal entry for Lest Ten Horizons Cry. In early 2025, after the designer had worked on other projects, the LUDODROME showcase of experimental and indie games in Montreal ⁷ provided a context to revisit the terrain of LTHC. The initial version of the README file for Insauratio Exiguus (IE) states that it will be “a small alt.ctrl project building off of Lest Ten Horizons Cry to create a version that is more: Minimal, Puzzly, Abstract, Linear” ⁸.

The public facing documentation for the final version of IE describes it as:

a minimal, contemplative, alt.ctrl game where players use a hand-made, synth-like controller to find the correct locations for on-screen pixels. Subtle visual and sonic cues help to guide the player. As these pixels are moved to their correct locations, they create unique constellations. The creation of these constellations resolves obfuscated abstract content on the screen, revealing texts from Søren Kierkegaard’s essay Repetition. Once the image is fully uncovered, the player is given the opportunity to read the text before the whole image shrinks back down to the single white dot, offering them the opportunity to undergo the activity again. Through this repetitive act of finding, listening, observing, and reflecting, the player is invited into a more contemplative form of play, a play that is guided by them, where there is no discrete ending or win-state ⁹.

The physical form factors of IE put it in conversation with LTHC, as both appear to use highly similar external casings and input devices. The design rhetorics of IE are related to those of LTHC, though on a reduced scope, prompting a more tightly focused design experience:

• Traditional synthesizer hardware components can be used to control different forms of “playing”.
• Paying attention to relationships between visual and sound cues reveals the functioning of underlying logics.
• Degree of clarity in visual or sound output correlates to degree of correctness of action.

The design goals for IE based on its play experience and public facing media seem to concern the following:

• To support interactions that evoke ritual and invite contemplation.
• To steer players towards attending to their own processes of sense-making through changes in simple abstract imagery and ambient audio.
• To deploy sonic and visual clarity as feedback mechanisms informing players about “more correct” and “less correct” paths of action.

The MDM archives for these projects enable us to explore the relationship between them more deeply than what is possible via examination and engagement with their final artifacts alone. The archives show that IE was borne out of reflections and learnings triggered by LTHC. While IE is not obviously LTHC 2, it explores and occupies sufficient common ground with LTHC that it would be difficult to argue that they are not related. In which case, how should we characterize these projects in relation to one another?

We argue that they are sibling iterations to one another, both of which build on a higher order design conceptual substrate. In a design context, iteration usually refers to a cycle of conceptualization and making directly building on materials and insights obtained from an earlier cycle of the same project, where consecutive cycles are motivated by shared underlying design concerns ¹⁰. We add further nuance to how iterative relationships can be characterized in the context of design by proposing that they can be understood as parent-child relationships (i.e. directly building on each other and sharing the same set of design concerns) or as sibling relationships (i.e. not directly building on each other but sharing common material, common processes and practices, and common design ideologies). By identifying resemblances between sibling iterations in the form of common design values, reuse of design techniques, and a continuous approach to design reasoning spanning shared memory – made possible because of the designer’s MDM archives – we gesture towards the presence of an underlying, higher order design substrate.

Sibling Iteration Resemblances

Common Design Values

Hidden (information / mode)

The archives of LTHC ² and IE ³ reveal that they share common design values, including the discovery of hidden information.

For LTHC, while its archive articulates an early design intention of the presence of multiple “discoverable states, instead of one ‘right’ state,” ¹¹ over time the designer settles on a more specific design intention of uncovering hidden content:

Over the weekend a new (old) idea presented itself: the concept of a secret world hidden within an otherwise confusing-yet-seemingly-traditional-interface. If we lean more heavily on the first part of the interaction as ‘traditional’ synthesis manipulation, then the switch to the second part can be more rewarding ¹².

The intended design experience of uncovering hidden information became a core design goal for LTHC, with the second distinct play “mode” (as described above) intentionally completely obscured from the player at the outset of gameplay. The designer’s interest in bimodal gameplay culminated in a 2024 XOXO festival talk about LTHC titled Secrets, and drew connections to the secret areas and Easter eggs of classic games from the 1980s and 1990s, as well as more modern examples, such as Frog Fractions ¹³.

The IE project, although initially conceived as a more traditional puzzle game, also centres on hidden information. Indeed, the core game mechanic of reliance on sensory clues to “locate hidden locations and lock them in” ¹⁴ is standard for hidden-object puzzle games. But extending traditional hidden object game mechanics, like LTHC, IE relies on a bimodal form of gameplay. Its core mechanic requires auditory cues to be paired with visual cues to reveal node locations. Once all node locations have been uncovered, hidden information in the form of texts are revealed.

Minimalism

The archives of both projects reveal the designer’s pursuit of minimalism as a design value, perhaps stemming from a broader consideration of conditions that invite reflective or contemplative experiences in games – subject matter of the designer’s research.

The LTHC design journal declares a design goal of “elegant simplicity - in the physical object, visual representation, and music” ¹¹. This core value proves to be useful for navigating design decisions early on in the ideation process, when the designer is at a crossroads with regards to the visual identity of the project:

My second major idea hurdle here is what will the visuals look like. I really want this to be a robust simulation-type thing [...], but while ideating it becomes clear that there is just too much complexity to deal with here. Also, it somewhat goes against the design value of simplicity, which is important ¹¹.

The IE project, meanwhile, is declared from the outset as “an experiment to make a simpler version of Lest Ten Horizons Cry” ¹⁴. As stated earlier, the final reflection in the LTHC journal articulates the designer’s desire to revisit LTHC’s themes in a future project that keeps “poking at the question of granular audio control, reflective experiences, and abstract ‘puzzly’ bits” ⁶. By examining the documentation of IE, we can see that it takes LTHC’s minimalist ideals as a point of departure and continues to streamline and simplify them. This is evidenced in IE’s overall interface (fig. 6), its gameplay loop, as well as its software and hardware elements (which we further detail below).

Ambiguity

Both projects make use of ambiguous input-output pairings that are not immediately discernible to the player. Worth noting is that the initial stated project goals of LTHC do not identify ambiguity as a design experience. The first line of the process documentation states solely,

The initial idea here is alt-control audio-based gamelike interaction. Specifically, what would a game controlled with a synthesizer look like? ⁵

Ambiguity as a means of structuring puzzle design for LTHC instead emerges later during the conceptualization stage. As a second journal entry authored one week later states:

I like the ambiguity here, especially with the idea of letting the system decide where these "desirable states" should be. (. . . ) Feels like an interesting place to be, as far as causing the player to reflect. The textual output itself could enforce this ¹¹.

The aforementioned proposal of how to invite player reflection (i.e. with textual output) is prescient of IE’s experience. The final interaction of IE leans on this textual element both for meaning and for rewarding the otherwise ambiguous node discovery challenge demanded of the player:

I like the idea of the node-discovery also uncovering some sort of visual element (leaning more into the puzzly parts of this), and after thinking about what this could be, I settled on written text. [..] Once all the nodes are found, the constellation will fade out, leaving the text for a given amount of time, before it collapses in on itself, becoming the starting node for the next "puzzle." And these just keep going and going. Repetition. Some users might walk away after working out one of these, but the hope would be that these function almost more like a labyrinth, where traversing the space in a semi-prescribed way leads to a contemplative state ¹⁵.

Adding additional substance to our proposed concept of sibling iterations is a telling line from LTHC’s process journal, placing it within an even longer lineage stretching back to a project called TIKATMOS undertaken by the designer two years earlier ¹⁶:

The solution for TIKATMOS, where the system randomly chose values that the user is trying to locate, is a good place to start. However, there should be some slight increase in complexity and beauty. "A better implementation of the TIKATMOS tuner minigame" still stands ¹¹.

TIKATMOS was a voice-controlled alt.ctrl game (developed in collaboration with the Whaaat!? Lab of the ATLAS Institute at the University of Colorado, Boulder) that won the Live Action Award at the 2022 IndieCade Festival. Worth noting is that it was only in authoring this paper that the designer became properly cognizant of the common design experience threads linking IE, LTHC, and TIKATMOS.

Common Design Techniques

Hardware

An outsider to the design processes of LTHC and IE would be able to glean a relationship between both projects for a simple reason: they literally share each other’s physical materials. Components from LTHC were repurposed to create IE, meaning that LTHC no longer exists in physical form. LTHC’s dials, screen, microprocessor, and external monitor were all recycled in order to physically realize IE. Likewise, the handmade wooden box enclosure for LTHC was deconstructed, cut down, and repurposed to house IE. The designer sacrificed the physical materials of LTHC to bring IE to life, even if he did not use the materials to identical effect in IE.

LTHC’s archive contains numerous journal entries dedicated to explaining, complaining about, and documenting the various issues that arose during the construction of the project, such as the following excerpt:

I always seem to forget how un-friendly all of these electronic components are with each other, and how annoying it can be to get everyone playing nicely. [...] Even with the large number of technically similar projects that I’ve made, these issues still arise. There are unexpected failures. The pieces don’t always fit. And it seems like this is more the rule than the exception ⁵.

In contrast, the IE archive is notably absent of experiences like the LTHC entry above. This suggests one of two major possibilities: either the designer chose to stop being bothered by hardware hurdles (less likely), or was no longer bothered by them because they were no longer hurdles (more likely). If the latter, the hardware problems presented by LTHC and IE were similar enough that the knowledge gleaned from LTHC was transferable to IE, and the designer’s attention was freed up to focus on higher-level design goals. We additionally point out that an absence of technical hurdle mentions from the IE archive is only possible to notice because they were centrally present in the earlier LTHC archive occupying similar design territory, i.e. our observation arises by reasoning about materials across multiple archives from the same maker.

The shared physical material lineage between LTHC and IE is of particular note in the context of practices commonly deployed by boutique hardware and alt.ctrl design communities. Games scholar Enric Llagostera notes that research on the projects developed by these communities is significantly complicated by how such projects rely on specific enough hardware and software arrangements that they are experienced in their intended form only within tightly controlled space and time frames ¹⁷. Even games showcased at large game conventions such as alt.ctrl.GDC are only played by a few people. Due to the physical size, spatial storage requirements, and specialized controls of alt.ctrl games, after they have been showcased, they are often deconstructed and mined for parts that are reused in future projects. We point out that MDM archiving significantly extends the material life of alt.ctrl games, through the transmediated material traces that MDM documentation entails. Someone who is unable to attend a games conference featuring alt.ctrl works may still benefit from the design learning and reasoning experienced by alt.ctrl game designers if those designers have committed to documenting their design reasoning using MDM.

Software

Several LTHC archive journal entries detail the issues the designer faced when initially prototyping its software, including how to make the various third-party pieces of the interaction communicate with each other. The designer had to develop a specific process for turning RNBO patches into usable Unity instruments using a third-party tool for LTHC. Beyond this, the designer also had to learn how to navigate the use of multiple cameras, serial routing, I2C addressing, and other issues specific to his workflow. With much of the designer’s attention and energy consumed by mastery of technical challenges, there were simply fewer cycles remaining for addressing LTHC’s expressive qualities and experience. This is voiced by the designer in the LTHC reflective journal as frustration at how much cognitive real estate has been occupied by software integration problem solving:

I don’t even want to get into all the ups and downs (and smashing my head on the table) it took to get this set up, but I will because it’s all part of the job ¹⁸.

Just as repurposing the hardware of LTHC pushes IE forward, the ready reuse of software plays into the eventual success of the IE project. Comparing the two project repositories, we see that many of the software solutions from LTHC reappear in IE. First, the Arduino code that the controller uses to send information to the Unity build is unchanged (fig. 9). As mentioned above, the same microcontroller is used for both projects, and the code written to handle the dial movement is untouched. Similarly, the Controller script, written for Unity to parse the incoming serial data from the controller, is reused with minimal changes ¹⁹. Additionally, although the two projects have very different on-screen visual styles, they both utilize the third-party Limitless Glitch Effects plugin for handling glitch effects ²⁰. Likewise, RNBO ²¹, a special version of the software Max, has been used to create instruments for both projects. In fact, the IE synthesizer is a direct iteration on the LTHC synthesizer: other than a series of simplifications, it is primarily the same instrument (cf.¹⁹²²).

The reflective journal for IE suggests that software concerns played a far less central role in comparison to LTHC. Mirroring our earlier observation of absence of mention of hardware hurdles, in the IE journal software concerns are also absent of mention. The archive for IE also verifies that the software for dial interaction, communication between the controller and Unity, and the implementation of RNBO instruments for Unity is ready and available for application in the new context from early on in the lifespan of IE ²². The designer was therefore able to easily use the newly created medium (controller + external screen + specialized software synth + Unity) to explore his original design goal of finding secret locations with a minimal interface. Not only did this speed up development time, it afforded an environment in which the designer could return to the core experience design values of the project: why explorations as opposed to how ones. Why explorations cannot be addressed without addressing how explorations when bespoke technical infrastructure is in play – like the relationship between comprehension and reading. Time spent earlier with LTHC navigating technical infrastructure was recouped in IE, enabling the designer to turn his attention to honing the designed experience into the desired experience.

The Spectral Parent (of sibling iterations)

Both of these projects share too much in common to be unrelated. They have significantly overlapping design values. They make use of the same bundlings of technical infrastructure. The transferability of knowledge between LTHC and IE further gestures to their similarity as design problems.

Yet they are also distinctively different from one another. The earlier project archive focuses a lot on technical difficulties, the later project archive does not. The earlier project was an attempt to do more, the later project was an attempt to do less. The earlier project did not land its experience design goals entirely successfully, the later project did.

The fact that the designer made a project so similar to an earlier one suggests there was some kind of drive to revisit something. But the later project is not an iteration to the earlier one. We assert that both projects were iterations to the same thing: a spectral parent design concept. Both projects looped off of a single implied – and unmaterialized – parent concept. This would explain why throughout their making trajectories both projects occupied sufficiently similar design solution spaces: iterations are co-located with their predecessors. The lack of mention of hardware and software concerns for IE also suggests that engagement with technical questions was not of primordial importance to the designer: those questions remained interesting only insofar as they facilitated exploration of a certain form of tangible experience design. The designer being satisfied by the end of the IE project that his design goals had been met also speaks to a curiosity being sated; a question having been properly answered.

From the archives of LTHC and IE, we see that the designer privileged an approach of “paring back” both concept scope and materials in IE as a way to hone in on the desired design experience, akin to the process of editing film or engaging in the process of sculpture. The successful combination of materials and mechanics – as landed on during the IE design process – was present in the LTHC iteration, if obscured by additional elements of designed experience. The designer was even aware, at some level, that this was the case: perceiving the distance between the spectral parent design concept and LTHC’s experience, he pursued a design problem solving strategy of “less is more (like the parent design concept)” to lessen the gap between the spectral parent design concept and sibling IE’s experience.

---

Footnotes

1. Richard Buchanan. 1985. Declaration by Design: Rhetoric, Argument, and Demonstration in Design Practice. Design Issues 2, 1 (1985), 4. doi:10.2307/1511524 ↩

2. Matthew Bethancourt. 2023. mouseandthebillionaire/_lestTenHorizonsCry ↩ ↩²

3. Matthew Bethancourt. 2025. GitHub - mouseandthebillionaire/losFinisCDE. ↩ ↩²

4. Mouse & the Billionaire. 2024. Mouse & the Billionaire: Lest Ten Horizons Cry. https://mouseandthebillionaire.com/lthc/ ↩ ↩²

5. Matthew Bethancourt. 2023. Context Statement | 09.01.23. ↩ ↩² ↩³

6. Matthew Bethancourt. 2024. A MAZE. Berlin | 05.13.24 ↩ ↩²

7. LUDODROME. 2025. LUDODROME 2025. https://www.instagram.com/ludodrome/ ↩

8. Matthew Bethancourt. 2025. losFinisCDE/README.md. ↩

9. Mouse & the Billionaire. 2025. Instauratio Exiguus. https://www.mouseandthebillionaire.com/ie/ ↩

10. John Sharp, Colleen Macklin, Steven Davis, Yu Jen Chen, Tuba Ozkan, and Carla Molins Pitarch. 2019. Iterate: Ten Lessons in Design and Failure. The MIT Press. doi:10.7551/mitpress/10826.001.0001 ↩

11. Matthew Bethancourt. 2023. ideation | 09.08.23. ↩ ↩² ↩³ ↩⁴ ↩⁵

12. Matthew Bethancourt. 2024. New Adventures in UI | 01.10.24. ↩

13. Inc. Twinbeard. 2020. Frog Fractions. https://store.steampowered.com/app/ 1194840/Frog_Fractions_Game_of_the_Decade_Edition/ ↩

14. Matthew Bethancourt. 2025. 03.01.2025. ↩ ↩²

15. Matthew Bethancourt. 2025. 04.26.2025 / Busy Week! ↩

16. Mouse & the Billionaire. 2022. TIKATMOS. https://mouseandthebillionaire.com/tikatmos/ ↩

17. Enric Granzotto Llagostera. 2024. On Critical Controllers: Exploring Reflective Game Design Through Altctrl Devices, Games, and Practices. https://core.ac.uk/outputs/636728443/?source=2 ↩

18. Matthew Bethancourt. 2023. RNBO Setup | 10.05.23. ↩

19. Matthew Bethancourt. 2024. _lestTenHorizonsCry/Assets/Scripts/Controller.cs. ↩ ↩²

20. Limitless Development. 2021. Limitless Glitch Effects Asset Pack. https://limitless-development.itch.io/limitless-glitch ↩

21. Cycling 74. n.d.. RNBO. https://cycling74.com/products/rnbo ↩

22. Matthew Bethancourt. 2025. feat: so much work. ↩ ↩²

From Khaled and Barr, 2023

We share key GDT findings from Love’s archive to demonstrate the possibilities of MDM and to articulate design knowledge specific to Love and Barr’s design practice.

Wayfinding Through Questions

Design must start somewhere but settling on an overarching design question is nontrivial. Schön refers to this stage as problem framing (i.e., identifying the problem space), noting that this starting point necessarily has lasting effects on how the problem can be solved. [40] When Barr began work on Love, his design journal entries showed evidence of locating a starting point, of planting a flag that says, “start here.” As Figure 3 shows, the nature of the design questions and visions proposed are expansive, high level, and open: Barr was still relatively unfamiliar with the design terrain being traversed.

As work on the project progressed, the questions Barr asked himself were increasingly specific. In a commit message accompanying a game build one week later, Barr commented [41]:

I do need to make sure I have a way of making the interaction actually feel like something. It still feels a little frictionless and a little undirected. It would make sense for the interface to have desires that can be communicated, rather than be a black box? In which case literal instructions? “Slide me between 3 and 5”?

Because MDM requires every build to be paired with a commit message, the relationship between design prototypes and the design hypotheses they embody is demystified. From this commit, we know that Barr has a prototype that implements an interaction, but the prototype does not yet convey the right feeling. Research on how designers use prototypes acknowledges that prototypes are experiments, materializations of design hypotheses that essentially always ask (alongside other potential questions) “is this going in the ‘right’ direction?” [42] The answer from Barr’s writing seems to be “not quite, not yet.” Indeed, one week later, Barr is still grappling with how to design his interface such that interacting with user interface (UI) elements feels like giving sexual pleasure[43][44]:

What can the player do with the slider and how can that be detected and transformed into information that I can interpret?

Could you ask them to just brush the mouse over the slider without sliding? Over the handle? Or is that sufficiently foreign that it doesn’t make sense (and also doesn’t work with mobile).

Deeper into the project, earlier questions start to be resolved, while new questions become ever more specific. The following is an excerpt from a commit message[45]:

Now have stroke ranges and numbers set up with arrays so that it’s easier to tune to specific stroke formats and numbers, it works well I think and makes more sense in terms of being able to control the experience the player’s having—there are particular kinds of strokes that are sexier, I think, than others (e.g., 0 to 10 is hotter than 1 to 7, say). I mean, this is getting pretty weird, but I think it’s true.

By now Barr has successfully answered his earlier question of how to design his interface such that interacting with UI elements feels like giving sexual pleasure, and is instead focusing on the more fine-grained issue: which kinds of UI interactions feel sexier? Abstract depictions of design often depict it as a funnel lying horizontally: at the start of design, questions, concerns, and solutions are explored broadly, erratically, and divergently, whereas toward the end of design, a tighter, directed, and convergent approach is used.[46] MDM equips us with the means to precisely engage with how wayfinding happens through design spaces and elucidates how design questions, concerns, and solutions become increasingly specified across a project’s lifetime.

Bidirectional Framing

When Barr initially began work on Love, he posed questions about UI sliders and masturbation, as can be seen in Figure 2. It becomes clear that these stand in for two broader concept systems: UI interactions and sexual pleasure respectively, for example, “Caress my dates,” “Tickle my weekends,” and “Touch my Mondays.” [47]

From the first to the last day of work on the project, Barr endeavored to understand each concept in terms of the other. That is, he looked for how sexual pleasure can be framed as UI interactions: “the game can certainly make it fairly easy/straightforward/ non-oblique as to how to give pleasure (set me to 2, set me to 4 set me to 2 set me to 4...).”[48] Likewise, he looks for how UI interactions can be framed as sexual pleasure: “what becomes more important, maybe, is the reaction of the interface . . . proving that you are, indeed, successfully pleasuring it (through dialogs, sounds, perhaps other visual effects).”[49] A straightforward interpretation of Barr’s process here might be to consider UI interactions as a metaphor for sexual pleasure. Indeed, more generally oriented and academic game design writing both identify finding playable metaphors as a common design approach for games that seek to express familiar qualities of our lived experiences.[50] We propose that a different dynamic is at work in Barr’s process: bidirectional framing. Whereas metaphors concern unpacking how a metaphor’s subject is like its vehicle, bidirectional framing concerns unpacking two distinct phenomena in terms of each other, progressively closing in on understandings of each phenomenon that mutually reinforce each other. In Playing with Feelings, Aubrey Anable provides an account of touch-focused play experiences that mirror the design dynamic of bidirectionality: “We are accessing through touch how the game’s algorithms work, and we are learning to manipulate the algorithms according to our desire for a certain outcome . . . . At the screen, we touch the game and the game touches us.”[51]

Anable posits that a procedural, rule-based view of games will only explain part of their affective experience. Returning to the designerly standpoint, Barr proceeds with design reasoning by using a bidirectional lens. The UI interfaces he codes and develops over the course of the project are significantly influenced by affordances for expressing sexual pleasure, while the type of sexual pleasure focused on is that which resonates with the affordances of UI interfaces. Barr uses bidirectional framing throughout the design process at ever finer granularities to rescope and refocus his design questions [52]:

Game over is now an “arousal overflow” which I find pleasing. It’s an ending dialog based around a screenshot I found of a Windows-based buffer overrun error. It works nicely as a deadpan ending, with the app itself still orgasming all over the place in the background. When you dismiss the message, the whole thing shuts down. I actually only did it this way in order to be able to turn the sounds off! But it works well.

Barr’s use of traditional UI elements as a way to perceive and receive sexual pleasure resonates with Pozo’s positioning of haptic visuality—productive troubling of the distance between haptic experience and meaning—an approach that Pozo notes is frequently used in queer games that explore love.[53]

One of the final changes Barr makes to Love concerns reorienting the slider from vertical to horizontal [54]:

I’m in conversation with Jim and Mary (my parents) about the gendered nature of the vertical slider. Had the important experience of Mary pointing out that sliding the vertical slider has different connotations for her as a woman . . . if I want it to feel like “pleasuring a computer because pleasuring other people (or things?) is a pleasure” then it needs particular kinds of inflections. If it feels like a chore, or a gross patriarchal or gender normative thing, then it’s going to lose that sense.

Bidirectional framing is especially evident here: by now Barr was explicitly working not to represent normative, male-oriented sex. Indeed, we find in his design journal many hundreds of words diving deep into questions of eroticism, qualities of interaction, and moving beyond anatomy.[55] Instead, he is camped out in the resonant middle ground between UI interfaces and sexual pleasure, between queering interfaces and queering sex.

Generative Logics and Conceptual Clicks

Partway through the design process, Barr admits to feeling stuck: “Whenever I return to this project I feel deeply uninspired by it . . . something it [sic] wrong with it. What is wrong with it?”[56] Barr identifies roots of the problem as well as a potential solution [57)]:

I wonder if it’s actually just too clean looking? Is this a situation where I need to reference another style again? Should I be returning to the idea of the Win95 styling of It is as if you were doing work? It makes them a nice pairing for one thing, feels more dehumanising but with a lighter touch than total minimalism. There’s no reason for this thing to look “stylish” . . . perhaps that’s the issue . . . it needs to say “user interface” not actually be a slick user interface.

In a journal entry from the next day, Barr is increasingly convinced that the potential solution is promising for reasons beyond aesthetics [58]:

I’m trying to give myself permission to massively simplify the way I’m thinking about this game. I think the shift to the Windows 95-esque aesthetic helps with that (it doesn’t look particularly capable of complexity or subtlety). I think I need to radically simplify how pleasure works . . .

Two days later, Barr verifies that shifting to Windows 95 styling has changed his perception of the design problem [59]:

I changed over the style file and also redid the styling of the pips to look more Windows-y. At that point it also somehow seemed to make more sense to have the slider click to different settings rather than slide smoothly among them, so I also reinstated that (default) behaviour. So it’s quite a different slider at this point, feels different, looks different.

While he initially characterizes the shift to a Windows 95 styling as aesthetic, Windows 95—along with its associated design tropes, interactions, and functionality—becomes a generative logic for the project. Identifying this specific generative logic eases the task of determining and justifying future design moves in ways that reinforce internal consistency with other design moves: “This kind of interface feels like it would be much more direct and obvious about registering how the sex is going—it would just tell you.”[60] This generative logic is demonstrably effective through the sheer density of successful design moves it gives rise to, which we refer to as conceptual clicks. A recognizable feature of a conceptual click is that the designer understands when they are experiencing them; resulting design moves flow (relatively) freely and internally consistently, and they satisfy the designer’s internal compass for whether they are headed in an appropriate direction. The following passage illustrates Barr having a conceptual click concerning slider feedback after adopting Windows 95 as a generative logic [61]:

I’d been assuming the slider would express its pleasure via more anthropomorphic things like vibration, pulsation, etc. But with the windows95 version it’s much less clear that makes sense... I’m suddenly more inclined toward other forms: a progress bar that could show current intensity of pleasure? Or “progress to organism”? (Completion. The happy ending.) Other read-outs? Sounds might need to again draw from the windows system sound set? How can they then be made sexy? Repetition, out of control at the end. Still like the idea of breathing in there somehow... Okay well it seems kind of like this is going to make my job easier?

Further evidence of conceptual clicks linked to the generative logic accompany the build that introduces a Windows 95 progress bar [62]:

Added a progress bar officially and again styled it as per win95 (they have a white background, garishly). The progress bar is kind of a nice symbol of the simplification of this game, moving away from ambiguity and the sexiness of not knowing to certainty and the sexiness of knowing. Makes my life easier and it’s good to have that symbolised right there in the UI in case I forget!

On adoption, an effective generative logic will engender a density of conceptual clicks, as in this case. By contrast, we conjecture that an ineffective generative logic will invite far fewer conceptual clicks, either because it lacks generative potential or because it is a poor fit to the design problem.

Incidentally, Barr’s generative logic bears a family resemblance to one used by Naomi Clark in her card game about sex and consent, Consentacle [63] In her interview in Bonnie Ruberg’s collection The Queer Games Avant-Garde, Clark recounts: “When I was playtesting Consentacle, I saw these moments of friction where people were like, ‘Wait, why am I thinking about tokens when what I want to be doing is having sex? That’s so weird.’ I thought, ‘Yes, perfect! There’s something here that’s wrong in just the right way.’”[64]

Humor as a Critical Lens

As expressed in one of Barr’s quotes, he has used Windows 95 as a generative logic before: in the predecessor sibling game to this one, It Is As If You Were Doing Work (Work).[65] For Barr, Windows 95 is inexorably linked to a particular feeling: it is slightly clumsy, its elements too big and aged in a way that does not flatter computational technology; it is funny. Like Love, Work can be characterized as critical/speculative design. For Barr, humor is an essential part of the critical designer’s repertoire. He reflects on Work in the context of the current game: “In that game, too, I started with a slick and futuristic UI only to realise that it was holding me back from the comic element that (I think) good critical design needs.”[66] As Auger points out about speculative design, humor is an especially rich perspective to draw on as it is often premised on surprise, which can only be generated when we have an expectation that events will unfold differently. [67] Critical and speculative design must evoke a slight familiarity to have rhetorical power. Windows 95 as a generative logic succeeds in engaging Barr in a critical design mode, as it gives him permission to embrace humor and look for what is funny, familiar, and unsettling about the design research questions. On listening to sound packs from earlier editions of Windows for inspiring the game’s sound design, Barr says: “I really do like the fact of them being these awkward corporate sounds to be incorporated into this sex game... The logoff sound is pretty funny for when the window closes post orgasm.”[68] Because Barr has used Windows 95 as a generative logic before, it constitutes tacit knowledge for him, that is, knowledge developed via previous practice. Schön argues that one difficulty of capturing how professionals work is their reliance on tacit knowledge to solve current problems, because tacit knowledge itself is hard to annotate.[69] The MDM gives us an infrastructure for annotating tacit knowledge and examining its reach, as we can see in comparing our GDT analysis of Work [70] with the current case study.

References

[40] Donald A. Schön, “Problems, Frames and Perspectives on Designing,” Design Studies 5, no. 3 (July 1984): 132–36, https://doi.org/10.1016/0142-694X(84)90002-4.

[41] Pippin Barr, commit message, commit db90b59e, GitHub, April 2, 2018, https://github.com/pippinbarr/itisasifyouweremakinglove/commit/db90b59e

[42] Youn-Kyung Lim, Erik Stolterman, and Josh Tenenberg, “The Anatomy of Prototypes: Prototypes as Filters, Prototypes as Manifestations of Design Ideas,” ACM Transactions on Computer-Human Interaction 15, no. 2 (July 2008): 1–27, https://doi.org/10.1145/1375761.1375762.

[43] Pippin Barr, Design Journal, GitHub, April 9, 2018, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#2018-04-09-1415-mondayon-cart415-discussion-input-parametersfailure-sepes-cumshot-game-flow

[44] Barr, Design Journal, April 9, 2018.

[45] Pippin Barr, commit message, commit 66f1cc74, GitHub, June 8, 2018, https://github.com/pippinbarr/itisasifyouweremakinglove/commit/66f1cc74.

[46] Bill Buxton, Sketching User Experiences: Getting the Design Right and the Right Design (Amsterdam: Morgan Kaufmann, 2011) https://doi.org/10.1016/B978-0-12-374037-3.X5043-3

[47] Pippin Barr, Design Journal, GitHub, March 24, 2018, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#2018-03-30--in-whichsome-more-design-notes-from-the-ipad

[48] Pippin Barr, Design Journal, GitHub, June 4, 2018, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#monday-4-june-2018-733am

[49] Barr, Design Journal, June 4, 2018.

[50] Sebastian Möring, “Simulated Metaphors of Love: How The Marriage Applies Metaphors to Simulate a Love Relationship,” in Game Love: Essays on Play and Affection, edited by Jessica Enevold and Esther MacCallumStewart, (Jefferson, NC: McFarland, 2015), 196–215

[51] Aubrey Anable, Playing with Feelings: Video Games and Affect, 67 (Minneapolis, MN: University of Minnesota Press, 2018).

[52] Pippin Barr, commit message, commit 0484e25, GitHub, June 22, 2018, https://github.com/pippinbarr/itisasifyouweremakinglove/commit/0484e25bcd28d9a922c926724189e27588f764f8

[53] Teddy Pozo, “Queer Games After Empathy: Feminism and Haptic Game Design Aesthetics from Consent to Cuteness to the Radically Soft,” Game Studies 18, no. 3 (December 2018), http://gamestudies.org/1803/ articles/pozo.

[54] Pippin Barr, commit message, commit fbc8aa4, GitHub, June 14, 2018, https://github.com/pippinbarr/itisasifyouweremakinglove/commit/fbc8aa486a9c6a1be605ee0bf0cf683a9b6f727a.

[55] Pippin Barr, Design Journal, GitHub, June 15, 2017, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#friday-15-june-2018-717am.

[56] Pippin Barr, Design Journal, GitHub, June 3, 2018, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#2018-05-03-1452-thursday--honestly-im-going-to-get-back-to-this.

[57] Barr, Design Journal, May 3, 2018

[58] 58 Barr, Design Journal, June 4, 2018.

[59] Pippin Barr, Design Journal, GitHub, June 6, 2018, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#2018-05-06-1839-sunday--windows-95.

[60] Pippin Barr, Design Journal, GitHub, June 7, 2018, https://pippinbarr.com/itisasifyouweremakinglove/process/journal.html#thursday-7-june-2018-655am

[61] Barr, Design Journal, June 6, 2018.

[62] Pippin Barr, commit message, commit cedebc40, GitHub, June 6, 2018, https://github.com/pippinbarr/itisasifyouweremakinglove/commit/cedebc40.

[63] Naomi Clark, Consentacle (card game), 2018.

[64] Bonnie Ruberg, “Naomi Clark: Disrupting Norms and Critiquing Systems through ‘Good, Nice Sex with a Tentacle Monster,’” in The Queer Games AvantGarde: How LBGTQ Game Makers Are Reimagining the Medium of Video Games (Durham, NC: Duke University Press, 2020), 102–12.

[65] Pippin Barr, It Is As If You Were Doing Work, browser game (2018), https://pippinbarr.com/itisasifyouweredoingwork/

[66] Barr, Design Journal, June 7, 2018

[67] James Auger, “Speculative Design: Crafting the Speculation,” Digital Creativity 24, no. 1 (March 2013): 11–35, https://doi.org/10.1080/14626268.2013. 767276

[68] Barr, Design Journal, June 6, 2018.

[69] Schön, The Reflective Practitioner

[70] Khaled, Lessard, and Barr, (2018) “Documenting Trajectories in Design Space." https://dl.acm.org/doi/10.1145/3235765.3235767

From: Khaled, Lessard, and Barr, 2018

Work was released by Pippin Barr in July 2017. It presents itself as an application designed to give a sense of purpose to the idle humans of a near future in which all work has been delegated to robots ¹. It takes the form of an early Windows-style desktop environment with modern office-like tasks to be performed through the manipulation of conventional GUI elements, such as sliders, radio buttons, and text boxes (see figure 3). The game was noticed by a number of generalist and specialized publications, most picking up on the game’s social commentary: “A job simulator designed to make you feel useful, chasing your existential anguish. Horrible, isn’t it?” ², (translated from French).

A U.I. Game

A key finding in looking at the design process of Work is that the post-work satire (arguably the most salient aspect of the released game) is completely absent from the project’s inception. Barr’s first entry states his new project’s basic idea as: “A game made entirely of small (WarioWare-esque) activities from our daily life of using computers. So, for instance, you might be challenged to drag a folder into the trash, or move a slider to a specific setting” ³. This brief statement is already very rich with game designerly thinking. For one, Barr begins from an observation of a human behaviour (here the trivial yet omnipresent use of standardized graphic user interface elements) and asks the question of how this activity could be thought of as a game. This is one of the most basic yet fruitful game design operations: I see that people move toward destinations – what if they were challenged to get somewhere before others? What if they had to jump over small fences in the process? Game designers are always on the lookout for activities that have not yet been appropriated for the realm of games. The proof that this is key to Barr’s thinking about his project is that before he had settled for a title, he often refers to his project as the “UI game”.

Another typical game design approach is to think in terms of other games or game genres to articulate aspects of the project. Games are rarely entirely novel, and the parts that are derived from pre-existing designs can be summarily communicated by referring to examples (especially since game design is still very much in the process of standardizing terms to refer to typical forms). One of the first things Barr says of his project is that it is “WarioWare-esque”, by which he probably wants to evoke a series of mechanically varied, randomly selected mini-challenges prompting players to quickly understand what the actions they need to perform as in the game WarioWare ⁴. If GUI manipulation was the core activity targeted by Barr, WarioWare was his reference in thinking the framing of that activity as a hectic series of mini tableaux.

In his “basic idea” statement, Barr judges it useful to embody his design intuitions in concrete, low-level examples: drag a folder to trash, move a slider to a specific setting ³. These examples are extremely important as Barr is already visualising his future game in action. He can see the pop-up window with some text and a slider awaiting to be slid. There are countless other ways to imagine what a “UI-game” could be, but this is his mental image. This will both help him operationalize his design process (I need a window, text, and a slider) but is also already causing the abstract idea to sediment in a specific form. As these thinking examples follow him, they will act as a closing force, restricting the design space. It is not a bad thing: designing is in a way the process of progressively reducing that space to one single possibility. One simply needs to be aware of that effect. It is telling that the slider example will in fact make its way to the released game.

Barr’s first diary entry thus already gives a glimpse of typical game design reasoning and operations. Ideas are harvested from observation. Just like the master painter’s eye is trained to spot the interesting lighting conditions or the facial expression of a model that will lead to a complete painting, the game designer notices activities or situations that can be modelled meaningfully in a ludic structure. Hybridization is another common game design operation, relieving both designers and players of the burden of re-thinking (and re-learning) a completely new game structure by working from familiar patterns: what if we took X but replaced Y with Z? This requires game literacy: a large repertoire of ludic structures and components to draw from, juggle with, and reorganize. Finally, a game designer needs the capacity to imagine a game not yet made in action, so as to anchor abstract ideas in material form.

The Problem of Language

In his March 27th diary entry, as Barr is picking up speed in the development of this game, he brings up what he calls “the question of language” ³. Now that he has an actual GUI window to work with (see figure 4), he simply acknowledges that these usually contain text, which begs the very material question of: what text? Barr seems to want to avoid this question (probably to keep the focus on the “UI game” and not so much on whatever content might create the context of these operations) by imagining non-text alternatives such as “emoji or ‘censored’ unicode block elements”. This leads him to thinking in terms of an alien language that could be rendered as strings of varying non-letter characters such as in figure 5.

The following entries show how the seemingly decorative question of how to dress up the core mechanics of the game begins to steer the project in new directions. Barr is concerned that the alien language might beg to be deciphered, that players will bite on this Figure 4: Early screenshot of It is as if you were doing work with placeholder text ⁵ mystery, perhaps overlooking the GUI play. He juggles with ideas to discourage such an interpretation: “perhaps animating the characters?” He considers dropping it in favour of generic labels such as “Radio 1” and “Radio 2” and “Button” but regrets that it would end up “missing out on the cool language thing”. We see that in the process of solving the design problems raised by his initial question, Barr has stumbled upon a formal idea that is now exerting its own pull. The default visual settings of the JQuery library Barr is using is yet another factor of influence. The Unicode blocky characters look even more alien in white on dark grey than they would in more desktop-like styles.

We can easily imagine a very different Work game building up from here that would still be hinging on the mechanics of familiar GUI elements, but as a foundation to support a decrypting/discovery gameplay: What do these buttons mean? What is this an interface to? How can I work it to do something? On March 31st, Barr backtracks completely from the alien language idea and opts for a more traditional early Windows aesthetic ⁶. His reasoning is that it was “detracting from being able to think of it in a humorous way” and “pulling away from the original idea of a person pretending to work” ³. His new answer to the “content” problem is to resort to “business-y wording and phrases generated through Tracery” (eventually, the list of prewritten phrases visible in figure 6).

This episode in the game’s development highlights how much influence seemingly disparate elements of design can have on one another. The notion that a game’s abstract mechanics and their visual or narrative elements can be considered entirely separately does not hold. In the design process, every input – whether systemic, technical, visual – exerts a force on the resulting artefact; and these effects are cumulative as they inform decisions further down the line. Next, we will see just such a dynamic take place with the game’s narrative premise.

Finding a narrative

In his first post, Barr was already pondering the narrative potential of this project: “One twist would be to incorporate narrative into the texts and imagery in the game, so that over time it becomes apparent it’s also a story” ³. Barr’s interest lay in the fact that “...you could tie the UI actions as metaphors for content in the story and vice versa”. This thread of thinking ends up not being followed-up in later development, perhaps because of the early realization that: “...it would obviously massively complicate how the game would be able to work in terms of randomising things”.

Eight months later, as the core elements of the game are now functional, Barr consider the bigger picture: the “meta-interface/narrative/aesthetic of this game”. Interestingly, a player character story suddenly appears fully formed:

‘the player’ is a person who lives in the near future of fully automated work and a living wage. They have no obligations day to day, but they remember the concept of working and the idea that having a job and doing work (on a computer) gave them value in society. They want to continue to have that feeling, but there’s nothing for them to actually do, so this game “It is as if you were doing work” exists to allow them to have that feeling - the semblance of doing work without the actual productivity. ³

There is no discussion as to how this setting came about, with the exception of a need to establish a framing context for the player’s activities in the game: playing at working. Part of the elegance of this solution is its economy: it requires no additional design work. Everything remains as it was, except there is now a need to convey the piece’s fictive backdrop. Eventually, this will be reduced to a diegetically grounded “About” document left on the desktop to be read by the player, shown in figure 7.

This late adoption of a background story could be interpreted as an argument favouring the superficial contribution of narrative to games. However, press coverage demonstrates the contribution of the story to Work’s interpretation: “I’ve been playing It Is As If You Were Doing Work on the same computer I use to do work during work hours, and I don’t quite know what’s real anymore. Time to hit this button marked ‘publish’ and see if I get any promotion points.” ⁷. Its influence on the design process should not be underestimated either.

Once Barr had committed to this story, it became a core structuring factor in following design decisions. For example, a lingering concern seemed to be the balancing of difficulty. A week earlier, he had written, “how hard is this meant to be??” ³. Level of difficulty is always a hard question for a designer to answer, as it is arbitrary and hinges on a clear understanding of the quality of experience being sought. Early versions of Work rely on a succession of prompts, as opposed to a single desktop environment, enforcing an intense pace on players. Dialog boxes asking the player to click a single button can be dealt with quickly, but others that require typing a specific sentence or setting a spinner to a given number require sufficient time and effort that completion is interrupted by new dialogs appearing. As they pile up, the play experience soon becomes overwhelming and stressful. This hectic rhythm remains in keeping with Barr’s initial WarioWare reference, materialising an aesthetic of intense productivity. The fast-paced versions of the game could in fact be interpreted as a very literal take on Janet Murray’s provocation that we can read Tetris as “the enactment of the overtasked lives of Americans” ⁸.

There are multiple factors that Barr finds difficult to settle: Should it be more of a continuous grind, or punctual, more intense challenges? How should actions be rewarded? Should players be punished for errors or simply be stalled until they succeed? How hectic should the pace be? At what interval should pop-up tasks appear?

What is a good length for each task? Ultimately these design questions are answered by making them consistent with the chosen narrative: this should feel like office work, so a level of effort is necessary, but the fictional application is ultimately designed to soothe, and so should not be too stressful. Barr chooses to not punish players, with errors simply leading to an opportunity to try again, but still requests a certain intensity from them, exploiting the ubiquitous familiarity of multi-tasking in contemporary computer-assisted work.

---

Footnotes

1. Pippin Barr. 2017. Press Kit for ‘It Is As If You Were Doing Work’. (2017). itisasifyouweredoingwork Press on GitHub ↩

2. Sebastien Wesolowski. 2017. “It is as if you were doing work”, un simulateur de travail pour un monde postemploi. (2017). vice.com/fr ↩

3. Pippin Barr. 2016-2017. ‘It is As If You Were Doing Work’ Process Diary. (2016-2017). README.md on GitHub ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

4. Nintendo. 2003. WarioWare. WarioWare, Inc.: Mega Microgames!. (2003). ↩

5. Pippin Barr. 2017. ‘It is as if you were doing work’ screenshot of UI with placeholder text. (2017).Link of Asset in Repo ↩

6. Pippin Barr. 2017. ‘It is As If You Were Doing Work’ commit c0a887d890ffd2a0b2b2dbc34aa1a214f9d3b3e4. (2017). https://github.com/pippinbarr/itisasifyouweredoingwork/c0a887d8 ↩

7. James Vincent. 2017. Relive the Windows 95 glory days with this work simulation game. (July 2017). theverge.com ↩

8. Janet Horowitz Murray. 1997. Hamlet on the Holodeck: The Future of Narrative in Cyberspace. The Free Press, New York, NY, USA. ↩