This article was really interesting when talking about about physical implements and how they affect user. This goes back to the recurring theme of designing interactive system where the user should be the center of the design and user feedback. The idea of pictures under glass in my opinion creates a pseudo-realistic feeling where everything is meant to imitate the actual objects not not give the user the actual feeling and new design principles are becoming more and more virtual which makes I question how much humans will be involved with tools or implements in the coming period and we may actually lose touch with what we deem as reality now. The reading itself was very self-explanatory so I do not have much to say but it was just a simple reminder to keep in touch with physical things when designing interactive systems.

A Brief Rant on the Future of Interactive Design + Follow-up

The first article is essentially arguing that the dominant vision of future technology, which is everything being a flat glassy touchscreen you slide your finger across, is not actually visionary at all. It is just a timid extension of what already exists, and what already exists ignores almost everything that makes human hands remarkable. His point is that our hands do two things extraordinarily well, they feel things and they manipulate things, and touchscreens strip both of those capabilities away in exchange for a visual interface that he calls Pictures Under Glass. I reflected on his example of making a sandwich. He asks you to pay attention to how many tiny adjustments your fingers make without you even thinking about it, switching grips, sensing weight, feeling texture, and then he asks whether we are really going to accept a future interface that is less expressive than that. That question reminded of the time I tried learning drums through one of those tablet apps, and the difference between that and sitting in front of a real kit is almost laughable. On a real drum the stick bounces back after you hit it, and that rebound produces important information. Your wrist reads it and adjusts the next stroke automatically, and I could feel even as a beginner that my hands were supposed to be learning something from that response. On the app there is nothing. You tap a flat surface, it makes a sound, and that is the entire relationship. I was learning the pattern but I was not learning to actually play, and from what I can understand, that distinction is what the author is getting at.

About his response to pushback, I actually found it more interesting than the original rant. In the part when someone asked about voice interfaces and he said he has a hard time imagining a painter telling his canvas what to do. That, again, reminded  of the drums. There is no way to describe with a voice or replicate on a screen the feeling of a snare cracking back against your stick, or the way a cymbal responds differently depending on where and how hard you hit it. That knowledge is supposed to live in your hands built up over time, and I genuinely felt the absence of it every time I went back to the app and realized my fingers were learning nothing they could transfer to a real instrument. It felt like I was practicing the appearance of playing drums without any of the physical intelligence that actually makes someone a drummer.

Github Link

https://github.com/da3755-ui/intro-to-im/blob/c068b1ccbdb5f327243be9640104c9f9cde83fe1/IntroToIM_MusicalInstrumentAssignment.ino 

Demo on Deema’s page

Concept

For this week’s assignment, we had to create a musical instrument that incorporates both digital and analog input. The concept we came up with was inspired by the floor piano tiles that play notes when you step on them. So, we built a similar concept where we created tiles that produce musical notes when stepped/pressed on AND we incorporated a potentiometer that changes the pitch of the note depending on how you twist and turn it. 

We created three tiles in total. We built it so that no specific tile is linked to a specific note. Just that when you press any tile, a note plays; and if you step again on any other tile, the next note in the sequence plays.

Schematic 

The Process

First, for the piano tiles, we decided to follow the same logic we used in the invisible switch assignment: foils attached to wires that generate power when they make contact, once that was complete, we moved on to incorporating the analog component. We placed the potentiometer and connected it to an analog pin, a 5V pin, and a GND pin. 

For the code:

In order for the arduino to not translate every single LOW reading from a single step into multiple notes, we included a lastTileState component, where the buzzer will only translate the LOW reading to a note if the previous state of the tile was HIGH. This would prevent the tiles from playing multiple notes in one single press.

We had to figure out a way to change the pitch of the notes without completely changing what the note was. Since there is a trend among the notes where if you want to move from a note from higher pitch to a lower or vice versa, the note’s pitch value/frequency would need to either be divided by 2 or multiplied by 2. 

For example: standard Do sound = C4; a lower pitch would be C3. The difference between the pitch of the two is that C4 is double C3

For that we mapped the potentiometer’s input values (0, 1023) to (50, 200) and divided by 100, this allows us to shift between notes and their pitches smoothly using the potentiometer. 

We multiplied this factor to the original note that would have been played and set the tone to include the multiplied value as the frequency in the tone statement.

Originally I had the pitch and factor as just mapping the potentiometer values to the values of all the notes (31, 4978) so the note that is played would correspond to the values of the potentiometer. But then I realized this would change the notes altogether instead of just changing the pitches of the specific notes I chose, that’s when I used chatgpt and it suggested creating a factor component which is where I got the idea from.

I also initially tried keeping the analog and potentiometer section separate from the digital section of the code, adding a separate tone statement for the pitch and another one for the regular notes, but it caused an error, so I had to resort to figuring out a way to incorporate the pitch and analog section in the same section as the digital input.

I also tried incorporating a step counter within the if statement, but it practically added nothing and was not communicating anything to the code so I just removed it entirely.

Code Snippet

I’m personally proud of this if statement snippet because it helped me solve the problem of when to detect if the tiles were JUST pressed instead of if it’s pressed in general, which helped me avoid many problems. It also helped me to get rid of many variables I tried to include to keep track of the steps and presses.

if (
  (tileOneState==LOW && lastTileOneState==HIGH) ||
  (tileTwoState==LOW && lastTileTwoState==HIGH) ||
  (tileThreeState==LOW && lastTileThreeState==HIGH)
)

 

 

Response 1: Attractive Things Work Better by Don Norman

What stood out to me the most was Norman’s “heretical” claim that attractive things actually work better. I always thought of usability and beauty as two totally separate things like a tool is either pretty or it’s functional. But the way he explains how positive affect (basically just feeling good) makes us more creative and tolerant of minor glitches really clicked for me. It’s funny how he used to be a “usability bigot” who didn’t even see the point of color screens but now he’s out here admitting he owns teapots just because they’re sculptural art. It made me realize that when I’m happy using a well-designed app or object, I really do find it easier to navigate, even if it has a few flaws.

Response 2: Her Code Got Humans On The Moon by Robert McMillan

The most interesting thing about Margaret Hamilton’s story is how she was essentially one of the guys in a field that didn’t even have a name yet. It’s wild that when the Apollo mission started, software wasn’t even in the budget or the schedule. I loved the detail about her bringing her daughter Lauren to the lab and how a mistake the four year old made while playing actually helped save the Apollo 8 astronauts later on. It shows how Hamilton’s intuition for human error was way ahead of its time, especially since NASA’s higher-ups insisted astronauts were trained to be perfect and wouldn’t make mistakes. She didn’t just write code, she basically invented the rigor of software engineering because she knew that in space, there is zero room for any flops.

“Salteñada”

Concept

For this project I wanted to create something that actually represents me. I thought about my culture and also something I really enjoy which is cooking. So I asked myself what are my favorite Bolivian dishes and which one feels the most iconic. For me that is the salteña. It is a type of empanada but very unique because it is juicy and has a mix of different ingredients inside.

From that idea I decided to turn it into a game where people can learn how to make salteñas. I was also inspired by a game I used to play when I was younger called Papa’s Pizzeria, where you receive orders and have to complete them correctly. I liked that structure a lot so I adapted it into my own concept but based on Bolivian food.

The main goal of the game is to complete four salteñas correctly by following the recipes shown in the tickets. Each time you play the orders are random so the experience changes every time.

Implementation

I started by thinking about the aesthetic of the game. I wanted it to match the same style I have been using in my other works which is clean, flat, and stylized with shadows made using shapes instead of realistic textures. That is why I built everything using p5.js shapes instead of drawing or importing detailed images.

I created different classes like Ingredient, Dough, and Order so I could organize the logic better. This helped me control how things move, how they are displayed, and how the player interacts with them.

One of the hardest parts at the beginning was figuring out how to drag the ingredients and the dough. I wanted it to feel smooth but also controlled. Designing the ingredients was also challenging because I wanted them to be recognizable but still look like part of a stylized game.

Then I worked on the main mechanics of the game. I created a system where orders are randomly generated so every game is different. I also built a system that stores the ingredients inside each dough and then checks if they match the recipe. This is a simplified version of how salteñas are actually made but it still represents the main ingredients.

For the visual part I used an image of an aguayo as the background and applied a pointillism effect to make it look more organic and consistent with the rest of the aesthetic. I also added a custom font that matches the vibe of the game and background music to make the experience more immersive.

I did not rely too much on external sources. Most of what I used was the p5.js library for things like collision detection and interaction, class notes, and inspiration from Papa’s Pizzeria and Bolivian cooking. I also spent a lot of time experimenting to make everything look visually consistent.

Another important source was actually my younger brother. I made him play the game when it was almost finished to see how a real user would interact with it. This helped me realize several issues like missing instructions or unclear elements. Because of that I ended up spending more time improving the tutorial than the game itself, since I wanted the player to clearly understand what to do and feel rewarded when they succeed.

I also used AI tools like ChatGPT and Claude mainly for debugging (a big part of this project was honestly debugging haha) and understanding certain technical problems and knowing what function, variable or tool would be useful for what I wanted to do.

Code that I am proud of

The part of the code I am most proud of is the recipe validation system. I had to create a way to store all the ingredients that the player places inside each dough and then count them correctly. After that I needed to compare those counts with the order requirements.

This was challenging because it connects multiple parts of the game. The interaction of dragging ingredients, storing them inside the dough, closing the salteña, and finally checking if everything is correct. Making all of that work together correctly took me a lot of time to understand and debug.

function checkRecipe(dough, order){
  let counts = {};

  for(let ing of dough.ingredients){
    counts[ing] = (counts[ing] || 0) + 1;
  }

I am also proud of the full game logic that decides if the player wins or loses. It checks if all salteñas are closed, if they have the correct ingredients, and also handles the timer and the Done button.

for(let d of doughBalls){
  if(!d.closed){
    loseReason = "Some salteñas are not closed";
    endGame(false);
    return;
  }

Finally, one that seemed so simple but it took soooo much time out from me was this multi – clicking to close the salteña

if(now - d.lastClickTime < 400){
  d.clickCount++;
}

Reflection

I really enjoyed making this project and I think I challenged myself a lot. There are still things I would improve. For example there was a moment where I did not like the dragging interaction and I wanted to change it to a pick and release system. However that was very difficult to implement and I was already deep into the project and felt like I was going down a rabbit hole while debugging that, so I decided to keep the drag system to avoid breaking everything.

It bothered me because when I played the game myself I noticed that dragging a lot can get tiring, especially because you are trying to finish quickly. So I think a different interaction system would make it more user friendly.

I also would have liked to add sound effects and more steps to the cooking process. Right now when you close the salteña it is assumed that it already has the juice and is baked. Ideally I would add another stage where the player adds the juice and then bakes the salteña to make the experience more complete.

Another challenge I faced was organization. Because of time changes and breaks in between working on the project, my coding process was not as consistent as before. Sometimes I would go a long time without looking at the code and then come back and work for many hours. That made the code feel a bit disorganized and sometimes I would get lost.

I also struggled at the beginning with making the design responsive to different screen sizes. I could not rely on fixed dimensions like before, so I had to adapt everything to the window size. That was difficult at first but I eventually got used to it.

Overall I am very proud of this project. Even though there are things I would improve, I feel like it represents me, my culture, and my interests. It is also a game that I would actually enjoy playing and I think my friends and family would too.

Overall Concept

links:

https://editor.p5js.org/mss9452/sketches/OTs6tFggnA

https://editor.p5js.org/mss9452/full/OTs6tFggnA

For my project, I redesigned the classic Snake game, with more focus on the atmosphere and visual experience rather than just the gameplay. For the design I added geometric patterns for the background with music playing as well. The game also changes themes by pressing the t button to either light or dark. Instead of the usual blocky snake I made it with a glowing circular shape to represent light movement through an environment.

I wanted the experience to feel somewhere between calm and intense. The background slowly shifts between geometric patterns, creating subtle motion without distracting from the game itself. At the same time, the gameplay remains simple and familiar, allowing the user to focus on both playing and experiencing the visuals. Overall, my goal was to take a very well-known game and transform it into something more immersive while still keeping it intuitive.

How the Project Works / What I’m Proud Of

The game is built using p5.js and uses object-oriented programming to organize the main elements. I created separate classes for the Snake and the Fruit, which made the code easier to manage and extend. The snake moves across a grid system, updating its position each frame, while collision detection checks for walls, self-collision, and fruit collection. When the snake eats the fruit, it grows, the score increases, and a sound effect plays to give feedback to the player.

One part I am particularly proud of is the visual design. I replaced the traditional square snake with glowing circular segments that create a layered light effect. This connects back to my concept of light moving through darkness. I also added two background images that slowly fade into each other, which gives the game a more dynamic and atmospheric feel without interfering with gameplay. The dark/light mode toggle was another feature I liked, since it allows the user to switch between two different moods.

Another aspect I think works well is the overall structure of the program. I used a game state system (start, playing, and game over), which made it easier to control what is displayed at different times. I also added background music and sound effects, which made the game feel more complete and interactive rather than just a basic version of Snake.

Code Snippets

Fruit interaction + sound

if (snake.getHead().equals(fruit.position)) {
  score += 1;
  snake.grow();
  fruit.relocate();

  eatSound.play();
}

Snake movement

move() {
  this.segments.pop();

  let head = this.segments[0].copy();
  this.segments.unshift(head);
}

Areas for Improvement / Challenges

One of the biggest challenges I had to deal with was the interaction between the different parts of the program, especially when incorporating new features such as the use of sound, images, and different game states. There was also the time when some of the functions were not recognized, as well as the issue with the game over screen not displaying as desired. This was easily solved by organizing the code in such a way that the state system is utilized.

Another challenge I encountered was dealing with the images and the sound files with the p5.js library. There was some difficulty with the formats as well as ensuring that the sounds do not overlap. This made me think more critically about the use of the sounds.

If I had more time, I would definitely consider incorporating some new features such as the difficulty level as well as the level. This would definitely make the gameplay experience more interesting. In addition to this, I would consider further improving the looks as well as incorporating some interactive elements. While the atmosphere is good, there is still room for improvement with regard to the gameplay experience.