Reading Physical Computing’s Greatest Hits and Misses alongside Making Interactive Art: Set the Stage, Then Shut Up and Listen really made me rethink how we interact with technology in creative spaces. Both texts explore the tension between human intention and technological behavior, but they approach it from slightly different angles. The first one dives into successes and failures in physical computing projects, highlighting that even the best ideas can flop if the execution ignores user experience or the unpredictability of the real world. The second reading, on the other hand, emphasizes listening to the audience and letting interactions evolve naturally, rather than forcing a rigid narrative onto the art or installation.

The most interesting part for me was the recurring theme of “letting go.” In physical computing, there’s often a desire to control every aspect of a system, to make it work perfectly according to the designer’s vision. But as the readings show, interaction is messy. Sensors misfire, people behave unexpectedly, and sometimes the “mistakes” end up being the most engaging parts of the project. I appreciated the reminder that in interactive art, and in technology projects more broadly, failure isn’t always a failure, it’s data, feedback, and sometimes even the spark for something better.

One question that came to mind while reading was: How do we balance designing for reliability with designing for surprise and emergent behavior? Both readings suggest that embracing unpredictability can make projects more engaging, but too much unpredictability can frustrate users. My takeaway is that the key might be thoughtful scaffolding, providing enough structure so that the system is understandable and responsive, while leaving space for improvisation and interaction to shape the experience.

Overall, I found these readings both inspiring and a little humbling. They reminded me that creativity in physical computing isn’t just about technical skill, it’s about curiosity, flexibility, and, honestly, patience with both technology and people.

Concept

When driving at night, high-beam headlights often blind oncoming drivers. I wanted to explore a simple and affordable system that encourages responsible use of headlights, something that detects oncoming glare and helps the driver automatically or manually switch to low-beam mode. This prototype uses a photoresistor to sense incoming light and a button to simulate the driver’s manual response. Two LEDs represent the vehicle’s headlight (green) and alert indicator (red).

Mechanism

Ambient calibration: when the Arduino starts, it reads the surrounding light for about 1.5 seconds and sets that as a baseline for normal nighttime brightness. This is important in the real world because ambient light differs in places, times.
Glare detection: if the light level rises significantly above that baseline, similar to when another vehicle’s high beams hit, the red LED begins to blink as a warning.
Manual response: when the button is pressed, the green “headlight” LED dims to a predefined low-beam brightness, showing that the driver has dipped the lights.
Return to normal: releasing the button restores full brightness once the road ahead is clear.

Everything happens automatically in a simple loop, using only one analog sensor (photoresistor) and one digital input (button).

Link to video demonstration

Schematic Diagram

Code highlight

The most interesting part for me was sensing ambient light accurately.
I learned how to smooth noisy analog readings using an exponential moving average (

ema = ALPHA * raw + (1 - ALPHA) * ema;

 

) and how to calibrate a baseline from Arduino documentation and community projects.
This taught me how real-world sensors fluctuate constantly and why filtering is crucial before making decisions based on their data.

Use Cases:

• A bike or e-scooter headlight that adjusts automatically when another vehicle approaches.
• A low-cost training aid for driving schools, showing how to react responsibly to high beams.
• A foundation for smart vehicle lighting projects that aim to reduce glare and improve road safety.

Further Enhancement

1. Replace the LEDs with an actual headlight driver or relay for real-world testing.
2. Use a camera or focused photodiode to distinguish streetlights from oncoming cars.
3. Add automatic dimming without manual input, fully autonomous dipping.
4. Integrate with IoT dashboards to log light data and analyze driving environments.
5. Use a microcontroller with more PWM channels to control multiple lamps independently.

Conclusion

This project started as a simple assignment, but it quickly became a meaningful experiment in safety-oriented design.
By combining analog sensing, human interaction, and basic control logic, I built a small system that mimics how real vehicles manage headlight behavior. It reminded me that even modest hardware, guided by thoughtful logic, can address real-world problems.

Assignment Overview:

The goal of this task was to create a simple interactive circuit using one digital sensor (a pushbutton) and one analog sensor (an LDR) to control two LEDs on the Arduino Uno. The digital LED turns on and off when the button is pressed, while the analog LED smoothly changes brightness depending on the amount of light detected by the sensor. This task helped me understand how digital and analog inputs behave differently and how they can work together in one circuit.

My Circuit:

Planning the Schematic:

I started by sketching a schematic on my iPad on procreate to visualize how each component would connect. The schematic represents the button on pin D2, the LDR with a 330 kΩ resistor forming a voltage divider to A0, and two LEDs connected to D8 and D9, each with their own 330 Ω resistor to ground. Planning it out first helped me avoid confusion later when placing components on the breadboard and made the whole process smoother. Of course when actually going to build the board a few elements moved around but the schematic mainly shows my thought process and “map” while planning this assignment.

Building the Circuit

Next, I built the circuit on the breadboard, carefully following the schematic. I color-coded my jumper wires to stay organized: red for power, black for ground, green for digital signals, and yellow for analog. One small challenge was understanding that the breadboard’s left and right halves are not connected across the middle gap. Once I fixed that mistake, the circuit started to behave exactly as expected.

(Its kinda hard to see but when I cover the sensor the blue LED shifts in brightness, and the button turns the yellow LED on)

Coding Elements:

This Arduino code connects both a digital and an analog input to control two LEDs in different ways. The process starts with defining pin connections: the pushbutton on pin 2, the LDR sensor on analog pin A0, and two LEDs on pins 8 and 9. In the setup function, the button uses input pullup so it naturally stays HIGH until pressed (no external resistor needed). The digital LED on pin 8 simply turns on when the button is pressed and off when it’s released. The LDR, wired as part of a voltage divider, continuously sends changing light readings to A0. In the loop, these readings (ranging 0–1023) are mapped to 0–255 with the map function so they can control the brightness of the second LED through analogWrite on pin 9. The small delay at the end makes the light level changes smooth and stable. Overall, the code demonstrates how digital and analog signals can be read simultaneously to control different outputs in real time.

// Pin setup 
const int buttonPin = 2;   // Button connected to D2 
const int ledDigital = 8;  // Digital LED (on/off)
const int ledAnalog = 9;   // Analog LED (brightness control)
const int ldrPin = A0;     // LDR sensor connected to A0

void setup() {
  pinMode(buttonPin, INPUT_PULLUP); 
  pinMode(ledDigital, OUTPUT);
  pinMode(ledAnalog, OUTPUT);
}

void loop() {
  // Digital LED controlled by button 
  bool pressed = (digitalRead(buttonPin) == LOW); // LOW = pressed
  digitalWrite(ledDigital, pressed ? HIGH : LOW);

  // Analog LED controlled by LDR light level 
  int lightValue = analogRead(ldrPin);        // Reads LDR 
  int brightness = map(lightValue, 0, 1023, 0, 255); 
  analogWrite(ledAnalog, brightness);         // Set LED brightness

  delay(10); 
}

Troubleshooting and Adjustments 🙁

The most challenging part was honestly just starting this task. It was very overwhelming since I never used arduino before and had no experience in coding C++. It took me a few hours to look through videos and articles just to get a better understanding of how the board works, and I even gave myself a few warm up tasks, like a simple blink test which I will show later in this documentation. In this particular assignment, one of my main challenges was getting the circuit itself right. The first few times I tried to setup the button the led wouldn’t turn on and I felt like I had so many wires and it was hard to focus on what the problem was. To combat this, I took the time to properly think about my schematic as a map, then followed that instead of blindly building my board first then drawing my schematic after. This really helped me when I got frustrated, and I also took many breaks in between so I could come back to the task with fresh eyes.

Random Blink Test Experiment:

Before starting the full circuit, I experimented with a simple blink test using just one LED. I uploaded the basic Blink example to the Arduino IDE to see the LED turn on and off every second. This small test helped me understand how the digital pins, resistors, and ground connections actually worked together in a real circuit. Since it was my first time using Arduino, doing this warm-up made me more confident in reading pin numbers, placing components correctly, and recognizing how code controls physical outputs on the board.

Reflection 🙂

Overall, I really want to emphasize that i’m very proud of myself for this assignment. This showed me how coding and wiring work hand in hand, the schematic guided the hardware setup, and the code brought it to life. This was a rewarding first experience combining both analog and digital sensors in one interactive circuit.

Concept

I got the idea for this assignment after watching a campus cat swiftly pounce upon a tiny lizard on the wall in front of the arts center. It got me thinking about reflexes and reaction times and how I can create a mini-game out of this using Arduino. The game basically works like this:
There are two LEDs, one red and one green, one button, and one potentiometer. When the green LED turns on, the player must press the button as fast as they can. If they press it in time, the green LED flashes thrice, indicating a win, otherwise the red LED flashes, indicating the loss. If the green LED flashes, they can see their reaction time in milliseconds on the screen as well. The potentiometer controls the difficulty of the game in two ways. Firstly, it controls the random waiting period (i.e. how long the Arduino waits before turning on the green LED). A decrease in the delay between instances would need the player to be on higher alert. Secondly, it controls the reaction time threshold (i.e. how fast the player must press the button to win). At the easiest setting, the player has 400ms to react, and at the hardest, only 100ms.

Image & Video Documentation

The code

// potentiometer (A0), button (2), red LED (9), green LED (8)

const int potPin = A0;
const int buttonPin = 2;
const int greenLED = 8;
const int redLED = 9;

void setup() {
  pinMode(greenLED, OUTPUT);
  pinMode(redLED, OUTPUT);
  // use a resistor in the microcontroller instead of on the breadboard
  // causes inverted logic: not pressed - HIGH, pressed - LOW
  pinMode(buttonPin, INPUT_PULLUP); // Internal pull-up resistor
  Serial.begin(9600);
  randomSeed(analogRead(A5)); // Add some randomness
}

void loop() {
  Serial.println("Get ready");
  digitalWrite(redLED, LOW);
  digitalWrite(greenLED, LOW);
  delay(2000); // brief pause before start

  // Read difficulty from potentiometer
  int potValue = analogRead(potPin);
  int waitTime = map(potValue, 0, 1023, 1000, 3000); // 1s to 3s random wait range
  // potValue = 0 then threshold = 400 ms; 
  // potValue = 1023 then threshold = 100 ms (hard)
  int threshold = map(potValue, 0, 1023, 400, 100);  

  // Random gap time before LED turns on
  int randomDelay = random(1000, waitTime);
  delay(randomDelay);

  // Start the test
  digitalWrite(greenLED, HIGH);
  unsigned long startTime = millis();

  // Wait for button to be pressed or timeout
  bool pressed = false;
  unsigned long reactionTime = 0;

  while (millis() - startTime < 2000) {       // 2 seconds max to press button
    if (digitalRead(buttonPin) == LOW) {
      pressed = true;   // player successfully pressed the button
      reactionTime = millis() - startTime;    // calculate the player's reaction time
      break;
    }
  }

  digitalWrite(greenLED, LOW);    // turn off green LED

  if (pressed && reactionTime < threshold) {
    // Player wins
    // Display reaction time
    Serial.print("Your reaction time: ");
    Serial.println(reactionTime);

    // Flash green LED thrice to indicate win
    for (int i = 0; i < 3; i++) {
      digitalWrite(greenLED, HIGH);
      delay(150);
      digitalWrite(greenLED, LOW);
      delay(150);
    }

  } else {
    // Player loses
    Serial.println("Too slow!");
    // Flash red LED thrice to indicate loss
    for (int i = 0; i < 3; i++) {
      digitalWrite(redLED, HIGH);
      delay(200);
      digitalWrite(redLED, LOW);
      delay(200);
    }
  }

  delay(1000); // small 1s pause between game rounds
}

Reflection & Future Improvements

I had a lot of fun making this project. I think the physical setup was not too complicated, and still gave an effective output through the implemented code. In future versions, I think it would be nice to have a buzzer that gives different sounds on win/loss conditions, and maybe also implement a score counter that keeps track of how many times the player won throughout multiple rounds. I believe it would also be effective to add another LED (probably yellow) that blinks during the “get ready” phase of each round.

Tom Igoe’s “Making Interactive Art: Set the Stage, Then Shut Up and Listen” advocates for a shift in the role of the artist in interactive work: the artist must stop controlling the experience and instead facilitate a conversation with the audience. Igoe’s key argument is that interactivity only truly begins when the artist relinquishes interpretation and allows the audience to complete the piece. This concept challenges the creator’s ego and promotes a more humble, open-ended form of art. While I appreciate the insight, I find Igoe’s emphasis on “shut up and listen” a bit idealistic. In practice, many audiences need some level of guidance to fully engage with an interactive installation. Too much ambiguity can easily lead to frustration. Nonetheless, his metaphor of the artist as ‘a director—staging a conversation rather than dictating a lecture’ resonates strongly. At its core, this advice serves as a reminder that interaction requires mutual respect: artists must listen as much as they create.

In “Physical Computing’s Greatest Hits (and Misses),” Igoe reflects on recurring projects in interactive art, such as theremins, drum gloves, and video mirrors, and contemplates why they keep resurfacing in new forms. He doesn’t dismiss these repetitive ideas; rather, he sees their evolution as evidence of growing refinement and deeper understanding. Igoe suggests that repetition is a form of progress, not stagnation. In physical computing, each reimagining of a “classic” project offers new possibilities, whether it’s smarter sensors, more intuitive designs, or deeper contextual relevance. Igoe also rejects the notion that novelty for its own sake is the ultimate goal, calling attention to the often-overlooked value in revisiting older concepts. This stance challenges the modern fixation on innovation for innovation’s sake, emphasizing that novelty must be paired with genuine engagement and a willingness to learn from the past, not just chase aesthetics or trends.

Synthetically, both essays stress the importance of humility in interactive art. Whether talking about listening to the audience or refining established ideas, Igoe places the artist’s role not in the creation of definitive, controlled experiences but in the facilitation of dialogue and discovery. The act of interacting with art, according to Igoe, is an ongoing process that requires responsiveness and openness. The artist’s task is to create the conditions that encourage curiosity, rather than rigidly scripting the conversation. In the end, good interactive art is about paying attention to what the interaction itself reveals and adjusting accordingly, facilitating a space where discovery is as important as design.

Physical Computing’s Greatest Hits (and misses)

The article highlights that originality doesn’t always mean creating something entirely new from scratch. Many people shy away from existing physical computing ideas because they think someone else has already done them, but that’s not the point. What matters is how we, as artists and engineers, can bring our own perspective, creativity, and purpose to these ideas. The author emphasises that real creativity lies in reimagining how people interact with technology in expressive and human centred ways.

Physical Computing’s Greatest Hits (and misses)

I think my main takeaway from this reading would be that we could have interactions but what’s more important is for those interactions to be meaningful.I liked how he pointed out that waving your hand over a sensor “has little meaning by itself.” As creative coders, I think that’s such an important reminder. It’s easy to get caught up in cool tech and forget the why behind our interactions. If the action doesn’t hold some significance, it ends up feeling more like a CS demo than an expressive piece (no shade, I’m a CS major myself).

The part about video mirrors also really resonated. I totally agree. They’re super visually engaging (who doesn’t love staring at themselves?), but there’s not much to do. It reminded me of our early class discussions about high vs low interaction. Just because something responds doesn’t mean it creates depth. And also I think mirrors are often more reactive than interactive.

I loved the section about interactive pets, especially since I’m not really into real animals. The idea of a cuddly robot pet that behaves like a dog but doesn’t shed or poop? Count me in.

Making Interactive Art: Set the Stage, Then Shut Up and Listen

I found this reading really refreshing because it reframes the role of the artist in interactive work in a way that feels freeing. The title, Set the Stage, Then Shut Up and Listen, is blunt, but it hits hard. It’s such a shift from the traditional idea of art being about your expression, your vision, and instead saying, “Hey, I’ve built the framework,  now let them do something with it.” That resonated with me and also reminded me of the advice Professor Mang gave us when presenting our mditerm projects, letting our audience interact with our projects, without any additional instructions or explanations. While it can get frustrating if the audience doesn’t interact the way we expected, I think that’s where we actually find room for improvements in our work. Also, if they don’t interact in the way we expected them to, maybe it’s because we didn’t design with them in mind.

I agree with the idea that interactive work is the beginning of a conversation rather than the whole message. It means not trying to force people into a specific reaction, but creating space for them to explore and find their own meaning. That kind of openness can be scary, but it’s also really exciting.

I also really liked the part about using space and affordances thoughtfully. Like, if something has a handle, we naturally want to grab it. That kind of design isn’t just about aesthetics, it’s about instinct and behavior. As someone making interactive things, I think the key takeaway for me is the shift in mindset, moving away from a rigid, outcome-driven approach where I expect the audience to engage in a specific way, and instead embracing curiosity about how they actually interact. It’s less about forcing a response and more about observing what they do, learning from it, and letting that shape the work.

You know those days when you’re going about your day, composed, unfazed, maybe a little affected by how things are going,  a compliment here lifts your mood a bit, an awkward text there dims it slightly. Nothing dramatic. That’s me, most of the time. Collected. Measured. But then someone says something, or does something, and boom, something inside flips. And I get  triggered (Only a good squash session can fix that).

That’s the idea behind this project, the emotional snap, that flips from calm to intensity. The potentiometer controls a blue LED, which I chose because blue is often associated with calmness (or at least that’s the association I have). The idea is: when things are calm, you’re still feeling things, but softly. You turn the dial, and the blue LED glows brighter or dimmer depending on how strongly you’re feeling. It’s gradual, and ever-changing, just like most of our emotional states.

But then there’s the toggle switch. 

When flipped UP, it triggers a red LED, one that doesn’t fade in or out. It’s either ON or OFF. That red LED represents those intense moments of anger, panic etc. The contrast here is what makes the circuit special. On one hand, you have the blue LED, whose brightness gently flows with the potentiometer, like your emotional depth shifting over time. On the other, the red LED is binary, triggered by the switch, like someone pushing a very specific emotional button.

So this project is a metaphor for the way we, as humans, respond to the world around us.

The code for it:

int potPin = A0;      
int switchPin = 2;     
int redLED = 9;      
int blueLED = 10;    

void setup() {
  pinMode(redLED, OUTPUT);
  pinMode(blueLED, OUTPUT);
  pinMode(switchPin, INPUT);   
  Serial.begin(9600);
}

void loop() {
  int potValue = analogRead(potPin);
  int brightness = map(potValue, 0, 1023, 0, 255);
  int switchPosition = digitalRead(switchPin);
  if (switchPosition == HIGH) {
    //Red LED ON 
    digitalWrite(redLED, HIGH);
    analogWrite(blueLED, 0);
  } else {
    // Blue LED with analog control
    digitalWrite(redLED, LOW);
    analogWrite(blueLED, brightness);
  }
}

The schematic design:

Video Demo:

IMG_0611

 

 

For Tigoe’s “Physical Computing” piece, one of the quotes that stood out to me was the idea that pretty much everything physical computing-related has already been done before, and if it hasn’t, many aspects of your idea are inevitably going to be unoriginal, and that is okay. The main message I got from this piece was that there are endless ways of remixing things using the same concepts you see– your specific combination of physical computing-ideas is going to make your idea.

Out of the motifs he listed, I thought the tilty stands/tables were the most amusing to me. The first reason why is because it reminded me of the game Super Monkey Ball, a game I loved as a kid; the second reason is because I’ve been wanting to integrate my old skateboard into our final project since the first class, and a skateboard is basically a “tilty table” you stand on. I hope to learn more physical computing skills to eventually create an interactive experience using my skateboard.

For Tigoe’s second piece, “Set the Stage, Then Shut Up and Listen”, the title immediately reminded me of the mindset I had to approach my midterm presentation with– if my game is good, I have no need to explain anything myself. Sure enough, that was roughly the mentality Tigoe was preaching here.

I’ve heard staying quiet and watching the experience can be very frustrating for many people, but my personal belief is that the frustration is an indicator of poor user experience design. My experience with watching has always been so much fun as I get to confirm my hypothesis with how the user interacts with the game.

For example, I wanted to create a situation where players would communicate “let me handle the red ball and you get the blue ball” in my midterm game’s co-op mode. The game would only start with one ball but a second one would spawn after the ball’s second bounce, which would hopefully prompt the players to coordinate whose responsibility the new ball was. When it came to the first ever playtest in-class, I was overjoyed when Yongje and Khatira said “let me handle the red ball and you get the blue ball” pretty much word-for-word.

However, I also recognize that not every system is foolproof as there are prerequisites I had not considered for understanding the game. Many people struggled to figure out what fingers to use to press WASD or the arrow keys so they would use one finger from each hand to press WASD separately and get really confused why the controls were so clunky. Obviously, WASD is a very gamer-coded instinct so anyone who inherently doesn’t play games would not understand to put their middle finger on “W” and ring and index fingers beside on the “A” and “D” keys respectively. That begs the question of whether explaining finger placement was necessary or whether there was an unforeseen restriction on who could enjoy my project.

 

Physical Computing’s Greatest Hits (and misses)

Sometimes I feel like the authors of our readings can read my mind. Usually, my first thought when thinking of a project idea is that I don’t want to do something that’s already done, but the author starts by saying not to think that way. I guess he is right, and that no work is ever truly ‘original’, but always takes inspiration from somewhere or something.

One of the applications of physical computing that really struck me was the Dance Dance Revolution. I realized that I never really thought much about the mechanics of it, but it’s crazy to think that just having a few switches on the floor managed to create this dynamic that took over the world. I also don’t think that I’ve ever encountered the theremin instrument, but it seems very interesting that even though it’s a physical object affected by your actions, you can’t actually think about the actions, but must actually think about the music.

The author’s section on Dolls and Pets also got me thinking about how that concept has evolved compared to the year 2008. The image in the reading shows normal dolls physically connected to a device, but nowadays we have toys with the screens built in, so that the doll/pet seems even more life-like. An example of this is the Eilik Interactive Robot Pet, which went viral on social media a while ago (I actually really want one, but they’re so expensive).

Making Interactive Art: Set the Stage, Then Shut Up and Listen

I agree with everything the author says throughout this reading, however, I do think that it’s easier said than done. He mentions, “Some will be emotionally moved, some will not get it, others won’t care.” This dynamic is why I believe that artists tend to offer interpretation notes about their artwork to their audience. I think it’s quite painful to see people not understand or not care about an interactive work you poured hours of your time into. Therefore, to save themselves from this struggle, artists tend to offer the script beforehand. On a similar note, this is also the approach I took with the first half of this class. Every time I showed someone my work, I would be quick to explain the concept behind it before they even began to explore, making sure that they didn’t do anything “wrong”. But after reading the insightful comparison done by the author between planning interactive artworks and a director working with actors, I think I’ve really understood that an interactive artwork is only completed by the audience’s curiosity. I’m excited to apply this new approach to my own interactive artworks, where the audience is nudged to discover the statement of the artwork by themselves.