Category: S2026 – Aya

When I watched the 6-minute video from the article, I immediately thought of a scene from an Avengers movie. In that scene, Tony Stark, also known as Iron Man, works with his technology. He manipulates a floating, transparent screen that he can see through and control with his hands. When I was younger, I remember imagining myself owning the same technology from the movie. I also wondered how many years I would have to wait for that kind of technology to be released, especially since technology keeps evolving so quickly. I almost forgot the article’s main point: technology becomes more meaningful when we can interact with it ourselves, rather than just swiping or looking at it. 

As Bret Victor explains, our hands are meant to feel and handle things, not just tap on a flat surface. I liked the examples he gave about how there is almost nothing in the natural world that we interact with by just sliding. In real life, we do not just slide our hands on things. We hold them, adjust our grip, and feel their weight, which helps us control them better. That kind of interaction is missing when we only slide on a flat screen.

Thinking about it now, even if something like Iron Man’s interface existed, it might still feel limited if it only relied on gestures in the air without any real sense of touch or resistance. This led me to think that even if something looks advanced, it can still miss the deeper idea of creating something that we can fully see, feel, and physically interact with.

Concept

In this project, a simple interactive mini piano was created using Arduino. The system combines both analog and digital inputs to control LEDs and sound output. The main goal was to explore how analog sensor data can be translated into both visual and auditory feedback in a way that feels responsive and engaging.

The project brings together multiple components working at the same time: 

• Analog input through Force Sensitive Resistors (FSRs)
• Digital input using a switch for overall control
• Analog output through a PWM-controlled LED for brightness variation
• Digital output using a red LED and a buzzer for clear feedback

Each FSR functions like a piano key. When pressure is applied, it changes the resistance, which affects the analog value being read. This value is then used to control both the pitch of the sound from the buzzer and the brightness of the LED, making the interaction feel more dynamic depending on how hard the user presses.

All FSRs are connected using a voltage divider with a 10kΩ resistor, and their values are read through analog pins A0 to A3. The system also includes several indicators:

• The yellow LED shows when the system is turned on
• The green LED represents the analog output, adjusting brightness based on the input
• The red LED lights up when a stronger pressure threshold is reached
• The buzzer produces a sound corresponding to the input
• The switch acts as the main ON/OFF control

How It Works

The system starts by checking the switch. When it is OFF, everything stays inactive, so no LEDs light up, and no sound is played. Once the switch is turned ON, the yellow LED lights up to show that the system is active, and the Arduino begins reading the values from all the FSR sensors. It then compares these readings to figure out which sensor is being pressed the most.

This core logic, added by my group partner, is what allows the system to function like a piano:

// ---------- Read + smooth sensors ----------
for (int i = 0; i < 4; i++) {
  int raw = readAverage(FSR_PINS[i]);   // read sensor
  smoothVals[i] = (smoothVals[i] * 3 + raw) / 4;   // smoothing
}

// ---------- Find strongest press ----------
int strongestIndex = 0;
int strongestValue = smoothVals[0];

for (int i = 1; i < 4; i++) {
  if (smoothVals[i] > strongestValue) {
    strongestValue = smoothVals[i];
    strongestIndex = i;
  }
}

// ---------- Determine pressure level ----------
 int level;

 if (strongestValue <= LEVEL_1_MAX) {
   level = 0;   // light press
 } 
 else if (strongestValue <= LEVEL_2_MAX) {
   level = 1;   // medium press
 } 
 else {
   level = 2;   // hard press
 }

 // ---------- Select note ----------
 int nextNote = NOTES[strongestIndex][level];

 // ---------- Play sound ----------
 if (nextNote != currentNote) {
   tone(BUZZER, nextNote);   // play note
   currentNote = nextNote;   // update
 }

Based on how much pressure is applied, the input is grouped into three levels: light, medium, and hard. At the same time, the outputs respond to these changes. The green LED adjusts its brightness using PWM depending on the pressure, the red LED turns on when a strong press is detected, and the buzzer plays the corresponding note.

Tinkercad Link | Code

Reflection

At first, my partner and I both thought about adding a piano-like element to our Arduino for this week’s project, so we then decided to move forward with that idea. It was really interesting to see how different inputs could change the sound and how that made the interaction feel more alive. Instead of just having one tone, being able to play different pitches made it feel more responsive and a bit more like an actual instrument.

I really liked how the project turned out. Setting up the code both in Arduino and Tinkercad helped us see how the system fits together step by step. It was also fun to be able to actually try it out after. Overall, this project gave us a better sense of how input values can be interpreted and used in different ways. It made us more aware of how even simple changes in input can lead to noticeable differences in how a system responds. Because of this, I would definitely consider integrating sound into my future projects as well.

References

• Arduino Documentation
https://www.arduino.cc/reference/en/
• Analog Input Tutorial
https://www.arduino.cc/en/Tutorial/BuiltInExamples/AnalogInput
• PWM (analogWrite)
https://www.arduino.cc/en/Tutorial/PWM
• Voltage Divider Explanation
https://learn.sparkfun.com/tutorials/voltage-dividers

https://youtu.be/JZ44h-jy0p4?si=LTeRxI9Gy2SYuQWJ

https://youtu.be/QYYigxRwXfc?si=fmBr9DmXWSOYV1rm

https://youtu.be/CvZ-SGJ8fGo?si=kRXJ7upESpJA1Qsh

In reading A Brief Rant on the Future of Interaction Design, I liked the author’s argument that current “visions of the future” are not truly innovative but instead reinforces a limited interaction entered on “pictures under glass”. This challenged my previous assumption that modern touchscreens represent cutting-edge interaction design. I always thought sleek, minimal interfaces with progress, but the reading made me realize that these designs may actually ignore a fundamental aspect of human capability being our sense of touch. The passage describing how hands “feel things and manipulate things” (page 4) resonated with me because it reframed interaction not as something just purely visual, but as something deeply understood. Reflecting from my own experience especially using devices for creative work such as  music or design so I now notice how limited these interactions feel compared to real-world engagement. This raises an important question for me which is Why does mainstream design continue to prioritize visual aesthetics over sensory cues? Even when it contradicts how humans naturally interact with the world.

At the same time, this reading expanded my understanding of what “innovation” in interaction design actually means. The author highlights on human capabilities, rather than just needs or technology, shifted my perspective toward a more human-centered framework. I found the example of hands performing more complex, such as intuitively opening a jar or making a sandwich. This is powerful evidence because it illustrates how sophisticated human interaction already is without digital mediation (page 8). This connects to my own work in interactive media, where I often think about how to make projects more engaging, yet I realize I have mostly relied on screens and visual outputs. The reading makes me question whether I am unconsciously limiting my designs by staying within familiar digital conventions. It also challenges me to think more ambitious way. As the author argues, then designers like myself have a responsibility to explore interfaces that incorporate touch, movement, and the full body.

Response A brief Rant on the Future

Reading Responses: A Brief Rant on the Future of Interaction Design made me rethink that my initial interpretation of the original word rant stood out as I think the author’s deliberate refusal to provide a clear solution, emphasizing instead that identifying the problem is a necessary first step toward meaningful innovation. At first, I found this frustrating because I tend to expect readings especially in terms of design to propose directions. This discomfort actually revealed an assumption I hold which is that good design thinking must always be solution-oriented. As the author challenges this by suggesting that premature solutions can limit imagination and that real breakthroughs actually come from long-term research driven by awareness and curiosity. This made me question my own approach in interactive media projects, where I often rush to “make something” rather than sit with the problem deeply. It raises an important question for me whether am I prioritizing productivity over genuinely understanding the limitations of current interaction algorithms?

Another idea that sparked my interest was the critique of alternative interaction methods such as voice, gesture, and even brain interfaces. The author argues that many of these still fail to match the richness of embodied interaction, particularly the role of the hands in creating and understanding spatial systems (page 2). This resonates with my own experience using voice assistants or gesture-based controls which feels convenient but rarely intuitive for more complex tasks. I found the comparison between adult tools and children’s “toys” (page 3) especially provocative, as it suggests that simplifying interaction to a single finger may actually reduce human capability rather than enhance it  . This connects directly to my current practice in digital design, where I rely heavily on screens and touch inputs. The reading encourages me think more critically about whether my work reinforces this limitation or challenges it. Ultimately, I now see interaction design not just as making interfaces easier, but as expanding what humans can do and this shift in perspective feels both challenging and motivating.

A Brief Rant On The Future Of Interaction Design

I enjoyed this reading because what he described is something I have actually experienced first-hand with my younger brother, who had to start KG (kindergarten) online due to COVID. Multiple of children who started their developmental learning stage online lack certain motor skills  which definitely could have been better had they experienced their early learning stage physically.

Although I am not fully against the idea of technology, I do believe it can alter and impact development, especially for younger people; it inhibits your body and brain’s full capabilities. Which is something we can see happening more commonly nowadays, especially with the rise of AI, where people are becoming less capable of doing certain tasks in one sitting without reliance on AI models or taking interval breaks in between 15 minutes. To some extent this text made me reflect on my own usage of certain technologies and media platforms; they should be a supplement and influence and not a replacement to my own capabilities. The text allowed me to reflect on how I should be using the technologies at hand.

I think I particularly enjoyed the reading more because it was more casual than academic. I think when someone speaks from more experience, it becomes more relatable and understandable.

Responses: A Brief Rant on the Future of Interaction Design

I think the people who gave such responses to the post took it to heart a little too much. I’ve heard too many people nowadays who are given a pen and paper say that they haven’t written something by hand in so long. It would be too repetitive if the author gave solutions because then again, the author cannot control how the users use technologies; that’s up to them to decide.  The author should not have to answer every single detail and spoon-feed the readers how to act, which, come to think of it, is what the previous reading was discussing: giving users hints instead of direct instruction.

I don’t honestly believe the questions posed were even meaningful.

My concept: 

For this week’s assignment, I worked on a small circuit that uses a button and a potentiometer to control two LEDs. The button works as a digital input, so the LED connected to it only turns fully on or fully off. The potentiometer is an analog input, so it gives a range of values, and that lets the second LED fade smoothly instead of switching instantly. Seeing both of them together helped me understand the difference between digital and analog in a very clear way. One is fixed, and the other changes gradually.

Code Snippet I’m Proud Of:

int potValue = analogRead(potPin);
int brightness = potValue / 4;
analogWrite(fadeLed, brightness);

This part made the most sense to me once I understood what PWM actually does just like how i learned on the slides. The potentiometer gives a value from 0 to 1023, but the LED only uses 0 to 255.  When I saw the LED fade smoothly as I turned the knob, it finally clicked for me how analog control works.

Process

I started this assignment by deciding which inputs and outputs I wanted to use. Since the goal was to work with both analog and digital inputs, I chose a pushbutton for the digital part and a potentiometer for the analog part. I wanted each one to control a different LED so I could clearly see the difference between the two types of signals.

I began by setting up the breadboard and making sure it had power. I connected the 5V pin from the Arduino to the positive rail and the GND pin to the negative rail. After that, I wired the button to pin 2 and added the 10k resistor to ground so it could work as a pull‑down. Then I connected the potentiometer to A1 and made sure the middle pin was going to the analog input. Once both inputs were connected, I added the two LEDs with 330 resistors to protect them.

At first, I tried to test everything on the physical Arduino, but the board started acting in a way that it wasn’t working and connecting to the laptop and kept shutting down, the green light would blink for a second and then everything will go off, and I wasn’t able to find the cable option on the ports shown to connect the code with my arduino, so that’s why it wasn’t working. After a lot of troubleshooting, I realized the problem was not my code or my wiring. The board itself was not responding properly. Because of that, I moved the project to Tinkercad so I could finish the assignment without dealing with hardware issues I could not fix. In Tinkercad, the circuit worked the way it was supposed to, and it helped me understand the logic more clearly.

My tinkercad:

https://www.tinkercad.com/things/b5J0eHZInWx/editel?lessonid=EFU6PEHIXGFUR1J&projectid=OGK4Q7VL20FZRV9&collectionid=undefined&title=Editing%20Components&sharecode=UdELcMJJ9AZbknNHQbrLb1glfjri4FwRHka6vCkfr5U

Sketch:

My circuit:

My code:

int buttonPin = 2;     // the button
int ledPin = 13;       // the digital LED
int fadeLed = 11;      // the fading LED
int potPin = A1;       // the potentiometer

int buttonState = 0;   // to store what the button is reading
int potValue = 0;      // to store what the potentiometer is reading
int brightness = 0;    // to store LED brightness

// pinMode( tells the Arduino how each pin will be used)
void setup() {
  pinMode(buttonPin, INPUT); //the button is an INPUT because I’m reading from it
  pinMode(ledPin, OUTPUT); // the LEDs are OUTPUTS because the Arduino controls them
  pinMode(fadeLed, OUTPUT); //this runs once when the Arduino starts
}

void loop() {

  buttonState = digitalRead(buttonPin); // this checks if the button is pressed or not, t will be HIGH when pressed and LOW when not pressed


// if the button is pressed this means the LED on pin 13 turns on
// if the button is not pressed this means LED turns off

This is a simple if/else condition.
  if (buttonState == HIGH) {
    digitalWrite(ledPin, HIGH);
  } else {
    digitalWrite(ledPin, LOW);
  }

  // the pot gives a value between 0 and 1023
// this depends on how much I turn the knob

// I store it in potValue so I can use it for brightness
  potValue = analogRead(potPin);

  //analogWrite() only accepts values from 0 to 255 so dividing by 4 converts the 0–1023 range into 0–255
  brightness = potValue / 4;

//this sends a PWM signal to pin 11,the LED brightness changes smoothly based on the pot
// the higher pot value means brighter LED
  analogWrite(fadeLed, brightness);
}

Reflection / Future

This project helped me understand analog and digital inputs in a more real way. I already knew the definitions, but seeing how each LED reacted made it easier to get it. The digital input was very straightforward because the LED only turned on or off. The analog input felt more interesting because the brightness changed slowly when I turned the potentiometer. Using both at the same time made me feel more comfortable with how the Arduino reads different signals.

I also learned a lot about wiring and how small mistakes can mess up the whole circuit. I kept running into problems on the breadboard, and even when the wiring looked right, things still didn’t work. When the physical board stopped responding completely, I had to switch to Tinkercad. Even though that was frustrating, it helped me focus on the logic instead of fighting with hardware issues. It also showed me how important it is to check every connection carefully.

In the future, I want to try using more sensors and making the interactions more interesting. I also want to keep my wiring cleaner because it makes debugging so much easier. Now that I understand the basics better, I feel more ready to try bigger projects and see how these components can work together in different ways.

The Concept:

Using three LED lights and an Ultrasonic sensor, I made a little traffic light thing that goes from green to yellow to red the closer you get to it.

Here’s the (crudely drawn) schematic sketch:

Unfortunately, I encountered an error trying to upload my sketch to the Arduino that persisted throughout every single troubleshooting method and fix I could find.

This means that, while I can show the physical Arduino wiring, I’ll have to use Tinkercad to demonstrate it in action.

Here’s the Arduino:

Here’s the video demonstrating Tinkercad circuit:

The code:

As for the code itself, I used a public domain tutorial for some help because I had no idea how to get the ping received from the sensor and convert it to centimeters.

Here’s the GitHub link.

int cm = 0;
int triggerPin = 7;    // TRIG pin
int echoPin = 6;
int red = 12;
int yellow = 11;
int green = 10;    // ECHO pin
int ping = 0;
int close = 50;
int far = 100;

void setup()
{
  pinMode(red, INPUT);
  pinMode(yellow, INPUT);
  pinMode(green, INPUT);
  pinMode(triggerPin, OUTPUT);
  pinMode(echoPin, INPUT);
  Serial.begin(9600);
}

void loop()
{
  digitalWrite(triggerPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(triggerPin, LOW);

  // measure duration of pulse from ECHO pin
  ping = pulseIn(echoPin, HIGH);

  // calculate the distance
  cm = 0.017 * ping;
  // measure the ping time in cm
  Serial.print(cm);
  Serial.println("cm ");
  Serial.print(ping);
  Serial.println("ms");
  delay(100); // Wait for 100 millisecond(s)
  
  digitalWrite(green, LOW);
  digitalWrite(yellow, LOW);
  digitalWrite(red, LOW);

  
  if(cm < close){
    digitalWrite(red, HIGH);
  }
  if(cm < far && cm > close){
    digitalWrite(yellow, HIGH);
  }
  if(cm > far){
    digitalWrite(green, HIGH);
  }
  
  delay(100);
}

Tigoe’s “Greatest Hits” taxonomy is useful precisely because it reframes recurring project themes not as signs of creative exhaustion, but as flexible starting points. The most interesting tension in the piece is between projects that offer structured interaction — drum gloves, floor pads, tilty controllers — and those that are essentially aesthetic spectacles you wave at, like video mirrors and mechanical pixels. Tigoe is honest about this distinction without being dismissive, and that balance feels right. The example that stuck with me most is the Digital Wheel Art project, designed for a patient with limited mobility — it reframes a “body-as-cursor” trope into something genuinely purposeful, which suggests that what makes a recurring theme worth revisiting is often the specificity of the context, not novelty for its own sake. The piece raises a question though: if these themes keep recurring, is that because they represent something deeply natural about how humans want to interact with physical systems, or just because they’re the easiest things to build with the available tools?
“Set the Stage, Then Shut Up and Listen” makes a compelling case that interactive art is fundamentally a conversation, and that over-explaining your work is a way of refusing to have that conversation. The director analogy is apt — you can set conditions for an authentic response, but you can’t prescribe the response itself. That said, Tigoe’s argument assumes a fairly confident, well-resourced designer. In practice, people often over-explain their work not out of arrogance but out of anxiety that the interaction won’t be legible at all — a real concern, especially for newer designers. There’s a tension between “shut up and let the audience interpret” and “design clearly enough that people know how to engage.” The “Greatest Hits” piece is actually a useful companion here: it shows that certain gestures — tapping, tilting, waving — are already culturally legible, which makes it easier to step back. The question both readings leave open is how much context is enough, and how you know when you’ve crossed from helpful framing into over-interpretation.