Author: Madina Kurmangali

The readings made me rethink what interaction design is and what it could become. Bret Victor’s main idea that computers should help people think, not just react stood out to me the most. It made me realize that many of my own projects focus on simple interactions, like clicking or triggering events, rather than supporting deeper understanding. This distinction between reactive systems and thinking tools feels important, especially for someone studying interactive media.

Another key idea is visibility in design. Victor argues that systems should show how they work instead of hiding their processes. I strongly relate to this from a learning perspective when I can see changes happen in real time, I understand concepts much faster. This connects interaction design with education, suggesting that good design is not just about usability, but also about helping users learn and explore. At the same time, I found myself questioning some of Victor’s ideas, especially about using the full human body in interaction. While designing for human capabilities is powerful, it can also exclude people who are not able-bodied. I agree with my peer’s point that accessibility should be central to design. Technology exists to expand access, not limit it. For example, devices like the Meta Quest offer adjustable and inclusive features, showing that immersive design and accessibility can coexist.

I was also interested in discussions about touch and sensory interaction. Technologies like haptic feedback and VR controllers show how physical sensation can enhance digital experiences. The example of devices that simulate textures or resistance demonstrates how interaction can go beyond screens and become more embodied. However, these ideas still feel experimental, and it is unclear how widely they can be applied in daily life.

Reading “Physical Computing’s Greatest Hits (and Misses)” made me feel exposed in a funny way, because I recognized so many of my own “original” project ideas in his list. I have thought about wearable sensors, glowing LEDs that react to touch, and emotional “helper” objects as if they were fresh directions, and seeing them framed as patterns that show up every semester forces me to admit how predictable I am as a beginner. At the same time, I agree with Igoe that giving up once you discover a similar project is a weak response, because what matters is the specific gesture, the context, and the meaning you build around a pattern, not the bare pattern itself. I think he is a bit biased toward downplaying the emotional impact of “shallow” projects like video mirrors or remote hugs, because for someone encountering them for the first time those can still feel meaningful, even if the interaction structure is simple. Still, his critique of projects that start and end at “wave your hand and watch something blink” matches what I have seen in exhibitions and online: I often remember the visual trick but not what I was supposed to feel or think. The reading pushes me to treat “greatest hits” gestures as starting points instead of endpoints, and to ask earlier in my own process what kind of bodily action I am inviting and why that action fits the idea, not only whether the sensor–actuator chain works.

“Making Interactive Art: Set the Stage, Then Shut Up and Listen” challenged a habit I have of over‑explaining my work to classmates. I go into detail about the concept, the symbolism, and the “correct” way to interact, because I am afraid people will miss what I intended, but Igoe argues that this kind of control kills the interaction and turns the piece into a lecture. I find his rule “do not interpret your own work” a bit extreme, and I do think he is biased toward audience freedom over author intention, yet his comparison to directing an actor makes sense to me. I have seen how different people behave in front of the same sketch or installation, and their “wrong” uses often reveal more interesting possibilities than my original script. This reading changes my view of success: instead of asking whether people understood my planned narrative, I want to pay more attention to the patterns of behavior that appear around my work, and treat those as data that should inform the next version rather than mistakes to correct. It also raises practical questions for me: how much ambiguity is productive before people give up, and when is a short label useful support rather than an unwanted explanation.

Concept

For my midterm, I created Strawberry Yurt Cafè, a cozy cafe game. I was inspired by a vlog by Gazi (https://youtu.be/eBt0nV0Y1Y0?si=4Hjy9PetN7n4hHwU) where she coded a game in one night, and that made me want to create a game for my own project too. I did not make mine in one night, but that idea encouraged me to build atmospheric game. I was also inspired by lo-fi playlists, and I wanted the game to feel soft and calm.

This project ended up being very different from what I originally thought I was going to do when I first posted my midterm ideas. My direction changed a lot during the process, but I think that actually helped me find a project that I enjoyed. Since I have been studying in cafes a lot recently, I liked the idea of making a cafe game ran by someone who loves strawberries.

Process

I started by outlining the main parts of the game that I would need to make:

1. The cafe environment
2. The kitchen area,
3. The drinks,
4. The recipe book, the ingredients
5. The customers

After planning those pieces, I moved into sketching.

I first drew the strawberry-themed cafe, the seller. I decided that the cafe would sell cakes and drinks, but the player would be the barista helping the seller prepare drinks for customers. Since the cafe has a dome-like shape, it reminded me of a yurt from my home country, Kazakhstan, which is a traditional home that my ancestors used to live in, so that is why I decided to call the game Strawberry Yurt Cafè.

 

After that, I chose the main color palette of the project. I focused mostly on pink, brown, and beige tones because I wanted the game to look warm and cozy.

 

 

 

 

 

Then I started drawing the individual assets so the drinks, ingredients, and customers. I also sketched the different stages of making drinks, so the player could visually see the process step by step.

 

 

I sketched the ingredients for the drinks like strawberry jam, matcha, milk, ice cream, strawberries, tea, whipped cream.

 

 

After I designed a variety of animal customers and ended up making nine different versions. I also created the recipe book logo in Adobe, which helped give the interface a more finished look.

How the Project Works

The game begins on an intro screen with instructions. After the player clicks Start Shift, the game moves into the cafe scene, where a customer appears with an order bubble. The player can open the recipe book, choose a drink, and then move into the kitchen scene. In the kitchen, the player has to click the ingredients in the correct order to prepare the drink before the timer runs out. If the correct recipe is followed, the customer reacts happily; if the wrong ingredient is added or time runs out, the customer reacts negatively.

One part I am proud of is how the game combines visuals, interaction, and sound to create a full atmosphere. I used my drawings to build the aesthetic of the game, and I also found sound effects for the ingredients, recipe book interactions, and customer mood changes. The game includes cozy background music when it starts, which helps support the feeling I wanted the player to have. Even though the gameplay is simple, I think it succeeds in giving the user a cute and relaxing experience.

Code Snippets

I structured data for the drinks so each one could have its own recipe and ingredient positions:

const DRINKS = {
  "strawberry latte": {
    steps: ["tea", "strawberry milk", "cold milk"],
    ingredients: [
      { target: "strawberry milk", ingredient: "strawberry milk", x: -155, y: -110 },
      { target: "cold milk", ingredient: "cold milk", x: -4, y: -107 },
      { target: "tea", ingredient: "tea", x: 139, y: -109 },
    ],
  },
};

By I creating a DRINKS object where each drink stores its ingredient order and the positions of the ingredient icons in the kitchen scene. Each drink has a recipe, and the game checks whether the player clicks the ingredients in the same order as the steps array. The ingredients array also tells the game where to place each ingredient on the screen. Because of this, I could add multiple drinks without rewriting the whole game logic every time.

Another code section I found important is the function that handles what happens after the player delivers a drink.

function finishDrink(deliveredCorrectDrink) {
  state.scene = "cafe";
  state.recipeBookOpen = false;
  state.ingredientsVisible = false;

  if (deliveredCorrectDrink) {
    state.goodDrinksMade += 1;
    state.reactCostume = "love";
    playEffect("sound-effect-twinklesparkle-115095", 1);
  } else {
    state.badDrinksMade += 1;
    state.reactCostume = "mad";
    playEffect("551543__philracoindie__8-bit-denyerror-sound", 1);
  }

  clearCurrentDrink();
  scheduleNextCustomer();
}

This function basically controls the result of the player’s action. After the player delivers a drink, the game goes back to the cafe scene. Then it checks if the drink was correct or not. If it was correct, the game adds one point to the good drinks counter, changes the customer reaction to happy, and plays a positive sound. If the drink was wrong, it adds one point to the missed drinks counter, changes the reaction to mad, and plays a different sound.

Reflection and improvements

One of the main problems I ran into was with the visual side of the project. At first, I wanted to create and draw some of the assets directly with code, but the results looked off and did not match the soft, cozy style I imagined. Because of that, I decided to draw the assets myself instead. After that, I also had some issues with image transparency, since some files showed unwanted white backgrounds or did not blend well into the game at first. Fixing those problems took time, but it helped me understand that sometimes hand-drawn assets and image cleanup work better for a project like this than trying to build everything only through code.

There are still many things I would like to improve in the future. I would like to add more drinks, more customer reactions, and more animations in the environment. I also think the game could cooler if I added more interactions in the cafe itself. Still, I am very proud of this project because it gives the exact kind of cozy experience I wanted to give to the user.

 

Thinking after Norman’s ideas, as a student two objects that annoy me is the the AC system in the Baraha common rooms and the tiny sinks. In Baraha, the AC is set around 21°C, and when I press the buttons to increase the temperature, the system promises a gradual change, but you have to wait for a long time and I do not feel that the temperature is increasing (and sometimes it is indeed is not), so the interface gives me an illusion of control instead of real control. The tiny sinks have the same problem in a physical way: For me the sinks we have in the dorms are small. The faucet sits so close to the basin that there is almost no space for my hands, and water splashes everywhere, even though the sink looks normal. Both cases show broken mapping: what I do and what actually happens do not match my expectations, and the design never clearly tells me what is really possible. To improve them, the AC interface should not take so long for temperature change and should show honest information about how the centralized system works, and the sinks should be redesigned with more vertical space for more comfortable hand-washing.​

For interactive media, I apply Norman’s principles by treating mapping, and conceptual models as the core of how I design my p5 sketches. As an interactive media student, I know that users understand a piece through the system image in front of them, not through my code, so I need clear signifiers on the screen that show what can be clicked, spoken, or dragged. I design interactions so the layout of elements matches their effects, and I give immediate feedback when the user does something, instead of delaying them, like the AC does. When I build a sketch, I test whether someone new can guess what to do in the first few seconds and form a simple model of how the piece behaves, because for a user that understanding is key for deeper, more emotional experience rather than leaving them stuck in trial .

A strongly interactive system listens carefully, thinks with some complexity, and responds in a clear way that affects what the user does next. It feels more like a back and forth conversation. I agree with Crawford that calling a shampoo bottle or a basic light switch “interactive” weakens the word, because those things only react in one fixed way. At the same time, his strict rejection of books, films, and performances as non interactive feels narrow to me, because people often respond to media through comments, edits, or shared viewing, which shapes the experience indirectly. Crawford seems biased toward systems that resemble one on one dialogue and software with explicit input and output, and less interested in social or cultural interaction around media. That bias is useful for learning to design, but it also raises concerns about how we value hybrid experiences like interactive films.