Category: F2025 – Mang

Interactive art should be designed as a conversation (or workshop seminar) instead of a speech. The clearest takeaway from the two pieces is that affordances and arrangements matter more than artist statements. If the system communicates its possibilities through handles, hints, and constraints, the audience can complete the work through action. When artists over-script, they collapse the range of possible meanings and behaviors into one narrow path.

Physical computing’s “greatest hits” list is useful because it exposes where interaction often stalls. Video mirrors and mechanical pixels are beautiful, but they rarely push beyond “move, see response.” Gloves, floor pads, and utilty controllers introduce a structured gesture vocabulary that people already know, which shortens the learning curve. Across categories: where gesture has meaning, interaction retains depth; where mappings are shallow, novelty fades quickly.

These pieces prompt two design questions. First, what minimal cues will help a participant discover the interaction without text? Second, what state changes will keep the system from settling into a single loop? In practice, that means compositional choices, such as discrete modes, cumulative effects, and recoverable errors.

For attention sensing, presence is not engagement. Designers should think of for signals that correlate with intent, then treat them probabilistically. Use the audience’s behavior as feedback to adjust affordances, not narratives. If the work does not evolve under interaction, you likely built a display, not a performance.

Today’s class went over some of the questions I had in mind in creating the circuit and I was able to complete the assignment.

I made a circuit that took in two inputs, green switch and potentiometer. The output is displayed with two led lights: green and red.

int greenPin = 10;    
int redPin   = 9;     
int buttonPin = 8;    
int potPin    = A0;

void setup() {
  pinMode(greenPin, OUTPUT);    //two outputs led
  pinMode(redPin, OUTPUT);
  pinMode(buttonPin, INPUT);   //Input for button 

  digitalWrite(greenPin, HIGH);   //testing if leds work
  delay(1000);
  digitalWrite(greenPin, LOW);
  digitalWrite(redPin, HIGH);   
  delay(1000);
  digitalWrite(redPin, LOW);
}

void loop() {

  int potValue = analogRead(potPin);               //reading potentialometer value
  int brightness = map(potValue, 0, 1023, 0, 255); //scaling the potentimeter from 0 to 255
  int buttonState = digitalRead(buttonPin);        //when pressed it is set as high

  if (buttonState == HIGH) {      //if button is pressed, turn both lights off
    analogWrite(greenPin, 0); 
    analogWrite(redPin, 0);
  } else {                          //if not pressed, light's brightness is controlled by pot.
    analogWrite(greenPin, brightness);
    analogWrite(redPin, brightness);
  }
}

Basically, by default, the two led light’s brightness is controlled by the potentiometer. When I turn the potentiometer to max voltage, the led lights light up with maximum brightness. Otherwise, if I turn the potentiometer to 0, it means that the voltage becomes 0, hence showing no light.

Another input is the green switch and I made it so that when the button stage is high, meaning that when its pressed, the output becomes , turning the lights off.

This is the sample video:

This is the hand-drawn schematic, that we practiced in class today. Re-drawing it definitely helped.

Schematic Week 9 Handrawn

 

Physical Computing’s Greatest hits and misses

When I read Physical Computing’s Greatest Hits (and Misses) by Tom Igoe, I found it fascinating how creativity often repeats itself, not out of laziness, but because some ideas are simply too human to let go of. Whether it’s waving your hand to make music like a theremin, or building dancing floor pads inspired by Dance Dance Revolution, these projects remind me that interaction is a language our bodies already know.

Igoe’s writing made me realize that physical computing isn’t just about wiring sensors or programming microcontrollers. It’s about finding meaning in movement and connection. His examples like gloves that make drum sounds or video mirrors that reflect your gestures  all blur the line between play and design. I like how he admits that some of these projects are “pretty but shallow.” It’s honest. It’s easy to get lost in flashing LEDs and forget to ask: what experience am I creating for the user?

The part that stayed with me most was his reminder that originality doesn’t mean doing something no one’s ever done before  it means doing something familiar in a new way. That’s comforting. As someone who’s just learning, I often feel like my ideas are too simple or already “done.” But after reading this, I see that even a basic project, a light sensor or a glove, can become unique if I bring my own perspective, story, or purpose to it.

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

When I was reading Tom Igoe’s Making Interactive Art: Set the Stage, Then Shut Up and Listen, I was struck by how simple yet challenging his message was. He tells artists and creators to stop explaining their own work  to resist the urge to direct, interpret, or control what others should feel. It’s funny how that sounds easy, but for anyone who’s ever made something personal, it’s actually the hardest thing to do. We want to be understood. We want people to “get it.”

Igoe reminds us that interactive art isn’t about showing, it’s about inviting. The artist’s job is not to tell a story, but to create a space where others can find their own. When he says, “Once you’ve built it, shut up,” it hit me like a creative reality check. In most traditional art forms painting, photography, sculpture  the work speaks through form and color. But with interactive art, the audience literally completes the piece through their movement, curiosity, and touch. That’s terrifying and beautiful at the same time.

I also loved how Igoe compares designing interaction to directing actors. You can’t tell an actor how to feel; you just set the stage, give them a prop, and trust that they’ll find emotion in the act itself. That idea applies perfectly to physical computing and interactive design. The best projects don’t just respond to people  they encourage discovery. They leave space for mistakes, surprises, and personal interpretation.

Reading this made me think differently about my own work. I realized that in some of my projects, I’ve tried to control the experience too tightly giving too many instructions or forcing a specific reaction. But now, I see that a good interactive project is a conversation, not a lecture. It listens as much as it speaks.

Concept:

In my home town, we don’t usually have automatic traffic lights for pedestrian (zebra) crossings. When I came to the UAE, I found it really interesting that many crossings have a touch-sensitive button on the pole, when a pedestrian presses it, the system detects the request and changes the traffic light to red for vehicles, allowing people to cross safely.

I wanted to mimic that concept using simple electronic components. In my prototype, a light sensor (LDR) acts as the pedestrian touch detector. When I place my finger over the sensor,  “green” light turns on (in my case, a blue LED, since my green ones were damaged), signaling that a pedestrian wants to cross. When the sensor is not covered, meaning the LDR value stays above a certain threshold (around 400), it represents that no one is waiting to cross, so the “red” light for pedestrians remains on.

Additionally, I included a digital switch that simulates a traffic officer controlling the lights manually. Whey they clicked the red button, red light turns on and force they vehicle to stop.

Video:

 

Code:

const int LDR= A2;
const int LDR_LED=10;
const int red_LDR=8;
void setup() {
  // put your setup code here, to run once:

  Serial.begin(9600);
}

void loop() {
  // put your main code here, to run repeatedly:
  int value= analogRead(LDR);
  Serial.println(value);
   
  if(value<=500){
    digitalWrite(LDR_LED,HIGH);
    Serial.println("yes");
   
    digitalWrite(red_LDR,LOW);
   
  }
  else{
    digitalWrite(LDR_LED,LOW);
    digitalWrite(red_LDR,HIGH);
  }
  
}

 

Schematics:

For this assignment, I decided to use the potentiometer and the button. I wanted the potentiometer to control how bright the RGB light is and use the switch button for 2 purposes, to change the general colour of the RGB but to also start and stop the blinking of the red alarm LED I used.

I had the code use 4 different colours but have this also a factor on how many blinks occur with the LED light.

I had the switch button be used as a way to have the red LED on or off.

To be honest, I used the Claude Sonnet 4..5 model to give me ideas on how I can make the whole system more interesting / creative. That is how the idea of having the number of pings be dependent on the colour came from.

this is the code I used

// PIN location
const int POT_PIN = A0;           // Potentiometer
const int BUTTON_PIN = 2;         // Push button 
const int RGB_RED_PIN = 9;        
const int RGB_GREEN_PIN = 10;     
const int RGB_BLUE_PIN = 11;      
const int MODE_LED_PIN = 13;      // Ree LED 

int potValue = 0;                 
int brightness = 0;               
bool buttonState = false;         
bool lastButtonState = false;     
int colorMode = 0;               
unsigned long previousMillis = 0; //  non-blocking blink timing
const long blinkInterval = 150;   // blink interval for mode indicator
bool modeLedState = false;        

const char* modeNames[] = {"White", "Red", "Green", "Blue"};

void setup() {
  Serial.begin(9600);
  
  // set pins
  pinMode(POT_PIN, INPUT);
  pinMode(BUTTON_PIN, INPUT);
  pinMode(RGB_RED_PIN, OUTPUT);
  pinMode(RGB_GREEN_PIN, OUTPUT);
  pinMode(RGB_BLUE_PIN, OUTPUT);
  pinMode(MODE_LED_PIN, OUTPUT);
  
  // initialise LEDs as off
  analogWrite(RGB_RED_PIN, 0);
  analogWrite(RGB_GREEN_PIN, 0);
  analogWrite(RGB_BLUE_PIN, 0);
  digitalWrite(MODE_LED_PIN, LOW);
}

void loop() {
  // potentiometer read
  potValue = analogRead(POT_PIN);
  
  // map the values of the potentiometer to a brightness value
  brightness = map(potValue, 0, 1023, 0, 255);
  
  // button read
  buttonState = digitalRead(BUTTON_PIN);
  
  // when button is pressed, change the colour
  if (buttonState == HIGH && lastButtonState == LOW) {
    colorMode = (colorMode + 1) % 4;  //cycle through 0-3
    Serial.println(modeNames[colorMode]);
    delay(50);  
  }
  
  lastButtonState = buttonState;
  
  // change RGB LED based on selected colour
  switch(colorMode) {
    case 0:  //  white
      analogWrite(RGB_RED_PIN, brightness);
      analogWrite(RGB_GREEN_PIN, brightness * 0.8); 
      analogWrite(RGB_BLUE_PIN, brightness * 0.6);  
      break;
      
    case 1:  // red 
      analogWrite(RGB_RED_PIN, brightness);
      analogWrite(RGB_GREEN_PIN, 0);
      analogWrite(RGB_BLUE_PIN, 0);
      break;
      
    case 2:  // green 
      analogWrite(RGB_RED_PIN, 0);
      analogWrite(RGB_GREEN_PIN, brightness);
      analogWrite(RGB_BLUE_PIN, 0);
      break;
      
    case 3:  // blue 
      analogWrite(RGB_RED_PIN, 0);
      analogWrite(RGB_GREEN_PIN, 0);
      analogWrite(RGB_BLUE_PIN, brightness);
      break;
  }
  
  // Mode 0 = no blinks (off)
  // Mode 1 = 1 blink
  // Mode 2 = 2 blinks 
  // Mode 3 = 3 blinks
  handleModeIndicator();
  delay(10);  // Small delay for stability
}

//function to handle the 
void handleModeIndicator() {
  unsigned long currentMillis = millis();
  static int blinkCount = 0;
  static unsigned long patternStartTime = 0;
  static bool isBlinking = false;
  
  // when white, keep LED off
  if (colorMode == 0) {
    digitalWrite(MODE_LED_PIN, LOW);
    blinkCount = 0;
    isBlinking = false;
    return;
  }
  
  // new blink pattern every 2 seconds
  if (!isBlinking && (currentMillis - patternStartTime >= 2000)) {
    isBlinking = true;
    blinkCount = 0;
    patternStartTime = currentMillis;
  }
  
  // perform blinks equal to color mode number
  if (isBlinking) {
    unsigned long timeInPattern = currentMillis - patternStartTime;
    int currentBlink = timeInPattern / (blinkInterval * 2);  // *2 for on+off
    
    if (currentBlink < colorMode) {
      // still within the blink count for this mode
      unsigned long timeInBlink = timeInPattern % (blinkInterval * 2);
      
      if (timeInBlink < blinkInterval) {
        digitalWrite(MODE_LED_PIN, HIGH);  // LED on
      } else {
        digitalWrite(MODE_LED_PIN, LOW);   // LED off
      }
    } else {
      digitalWrite(MODE_LED_PIN, LOW);
      isBlinking = false;
    }
  }
}

 

IMG_2228

 

I initially really struggled to come up with a concept for this week’s project. While I understood how to use analog and digital switches, I wasn’t sure how I would use them in conjunction to create something engaging and interesting. I slept on it and woke up with the idea to build off the theme of security from week 8 and make a lock mechanism using analog inputs like the potentiometer.

One of my biggest concerns was that I wasn’t sure how to draw a proper schematic so I looked online and used Tinkercad Circuits for a while but it wasn’t exactly the simple schematic drawing I wanted so I decided to save the site for future use instead.

This was the schematic I came up with. I knew I was going to mess up and have to move stuff around so I did it digitally using simple shapes and lines on canvas. I barely knew what I was doing and to be honest it made a LOT more sense to just start putting wires and pieces together on the breadboard but this schematic was how I thought it would look.

And this is how it looked physically with all the relevant pieces attached to the breadboard.

I knew the wiring would get pretty crazy as I started to connect everything so this is how I color-coded them:

• • Red: Power Source (+)
  • Black: Ground (-)
  • Green: Inputs Connections to Arduino Uno (Switch, Pot Meter, etc)
  • Yellow: Output Connections to Arduino Uno (LEDs)

On the code-side, I made sure to declare each pin I was going to use at the very top so I could quickly change it if I needed to swap stuff around.

int greenButton = 7; //button to open lock
int blackSwitch = 2; //part of the lock (the black on/off switch)
int potMeter = A4; //part of the lock (the roating blue one)

int greenLED = 12; //lock is open
int redLED = 11; //indicates lock is still locked

//LOCK COMBINATIONS
int blackSwitchANSWER = LOW;
int potMeterANSWER = 1000; //above X value to be correct

This is what the final product looked like:

I didn’t run into many bugs when coding but I did initially accidentally set the red light to always be on unless I was holding down the green button. I had to search online how I could fix this and I eventually found I could set the pinmode for the button to “INPUT_PULLUP” which was useful for inputs that otherwise would have no stable value when not pressed.

pinMode(greenButton, INPUT_PULLUP); //INPUT_PULLUP is good for buttons that automatically spring back uppinMode(blackSwitch, INPUT_PULLUP);
pinMode(potMeter, INPUT);

pinMode(greenLED, OUTPUT);
pinMode(redLED, OUTPUT);

I did have a physical difficulty where I was testing different kinds of inputs with the switch and the potentiometer and forgot what the correct combination actually was– and with no way to know if the green light was even going to turn on when it WAS correct. Thankfully a minute of trial and error and making sure the code side of things was correct got me to return to the original combination, but that could’ve been pretty annoying if the lock was any more complicated.

When it came to the LED light responses. I originally had the appropriate light turn on for 2 seconds and then turn off. I felt like this didn’t feel quite right so I made a creative decision to flash the appropriate light as feedback instead; I did this by creating a for loop that would flash the light 5 times with a small delay. This felt a LOT more responsive than the brief moment that the light would turn on previously. Below is the full if-statement that checked whether the confirm button, the green one, was pressed.

if (greenButtonState == LOW) {  
  if (LockIsUNLOCKED == true) { 
    digitalWrite(redLED, LOW); //turn OFF red light
    for(int i = 0; i < 5; i++) {    // flash 5 times
      digitalWrite(greenLED, HIGH);
      delay(150);
      digitalWrite(greenLED, LOW);
      delay(150);
    }

  } else {
    digitalWrite(greenLED, LOW); //turn OFF green light
    for(int i = 0; i < 5; i++) {    // flash 5 times
      digitalWrite(redLED, HIGH);
      delay(150);
      digitalWrite(redLED, LOW);
      delay(150);
    }
  }
}

I am very proud of how it turned out in the end with both the technical difficulties that I solved and how it feels to interact with it. Below is a demonstration of the lock working; you need to toggle the black switch to the right side and twist the potentiometer counterclockwise to the end.

Link to ino File (Google Drive)

Concept

This piece transforms a simple circuit into a puzzle. The connection between the switches is not obvious. The user needs some time to figure out what makes the LEDs light up.

The red LED changes brightness as you turn the potentiometer. Also, pressing only one of the push buttons does nothing you have to discover the specific “sweet spot” gesture. Only when all conditions align do the LEDs respond.

Video & Image Documentation

IMG_9510

Schematic Drawing

Future Improvements

A single puzzle could evolve into something far more complex by layering additional challenges:

• • Timing urgency: Buttons must be pressed within 2 seconds of entering the sweet spot, or the blue LED only stays lit for 3 seconds before requiring you to solve it again. This adds urgency and makes the victory feel earned rather than permanent.
  • Pattern memory: The blue LED blinks a simple pattern (like short-long-short) at startup. Users must recreate this rhythm with the buttons while in the sweet spot to unlock, transforming a spatial puzzle into a temporal one.

The metaphor of interactive art as a directorial process reveals creative control and trust. When Igoe compares designing interactive work to directing actors, it exposes a fundamental tension in the fear of without constant explanation, our vision will be misunderstood or ignored. But this fear might actually be the enemy of good interactive work. Traditional artists can hide behind the permanence of their statement, for example, a painting doesn’t change whether viewers “get it” or not. However, Interactive artists must confront the uncomfortable reality that their work is incomplete without the audience’s participation. The most interesting implication here is that over-explanation isn’t just bad pedagogy. It’s a form of creative cowardice, a way of avoiding the vulnerability inherent in truly collaborative expression.

What strikes me about the “greatest hits” catalog is how it inadvertently maps the evolution of human-computer intimacy. The progression from theremin-like instruments (where gesture has “little meaning by itself”) to gloves (which borrow existing gestural vocabulary) to meditation helpers (which attempt to read involuntary bodily responses) represents increasingly ambitious attempts to collapse the distance between intention and interface. Yet Igoe’s skepticism about certain forms, particularly “remote hugs” and meditation helpers, suggests that some human experiences might be fundamentally resistant to technological mediation. The machine can measure breath rate and skin response, but it cannot know meditation; it can transmit signals between paired objects, but it cannot convey warmth. This raises an uncomfortable question for interactive designers: are we sometimes trying to technologically recreate experiences that derive their meaning precisely from their technological absence?

The recurring critique of projects that confuse “presence with attention” opens up a broader philosophical question about what interaction actually proves. A sensor detecting someone standing in front of a painting tells us almost nothing about engagement, yet many interactive projects treat physical proximity as evidence of meaningful exchange. This seems related to a contemporary cultural anxiety about whether we’re truly connecting with anything. We’ve become so focused on measurable interaction (clicks, views, sensor triggers) that we’ve lost sight of the immeasurable dimension where actual meaning resides. Perhaps the most radical interactive artwork would be one that deliberately resists confirming whether interaction happened at all, forcing both creator and participant to sit with uncertainty rather than seeking the reassurance of sensor data. The blink of an LED becomes a form of emotional comfort: see, something happened, you’re not alone.

Concept

For this project, I decided to make a small interactive game called “Light & Shadow”. The concept is simple but fun: the yellow LED changes brightness depending on how much light the photoresistor (LDR) senses, and the blue LED only lights up when it’s dark and the button is pressed, basically “catching the shadow.” I liked that idea because it combines analog and digital inputs in a way that feels like a mini game.

The Process

The production process was mostly about setting up the circuit on the breadboard and figuring out how to connect everything correctly. Choosing the right resistors was harder than I expected,  sometimes the LEDs didn’t light up properly, and I had to try a few combinations before it worked. I also spent a lot of time drawing the schematic to make sense of the connections. I must have redrawn it several times to make it at least slightly understandable. Even now, I’m not 100% sure my plan is perfect, but it works!

Figure: the process of sketching the plan

The Finalized Sketch

The coding part was fun because it was simple enough to understand but still taught me a lot. I read the analog value from the photoresistor and mapped it to the brightness of the red LED, then used a simple if-statement to check the button and darkness to control the green LED. Seeing the LEDs react in real time to light and button presses made all the work feel rewarding.

int lightSensor = A0;
int buttonPin = 2;
int redLED = 9;
int greenLED = 8;

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

void loop() {
  int lightValue = analogRead(lightSensor);    // 0–1023
  int brightness = map(lightValue, 0, 1023, 255, 0); // dark = bright
  analogWrite(redLED, brightness);

  int buttonState = digitalRead(buttonPin);

  if (buttonState == HIGH && lightValue < 400) {
    digitalWrite(greenLED, HIGH);
  } else {
    digitalWrite(greenLED, LOW);
  }

  delay(100);
}

Reflection

Overall, this project was a great learning experience. I got hands-on practice with analog and digital inputs, using resistors correctly, and writing basic Arduino code. I also learned patience, both in wiring and drawing schematics. Even though some parts were frustrating or confusing, it felt really satisfying to see the LEDs respond the way I wanted. Next time, I’d probably try adding a buzzer or even a little LCD display to make it even more interactive.

The video demonstration

IMG_8850

I started this project with a few ideas. One of the ideas was to make a secret switch hidden on a bookshelf. One of the books would have a piece of copper tape underneath that would touch the copper tape beneath it on the shelf. However…I realized that I didn’t have enough books to make it look convincing so I started looking around my room for something that inherently had motion to make my life easier. So I thought– what if I used my door?

Sometimes I don’t fully close my door properly and don’t know if it’s fully closed. That inspired me to make the door a switch to act like a DIY security system. I have no experience with physical computing so I had some trouble visualizing how it would look in my head, and it didn’t help that I’ve been out sick for so long. This image below was my initial concept for it.

The idea is to set up a simple LED light on the breadboard that would light up when the door was fully closed. I think I understood that pretty comfortably, but I didn’t know how the rest would work.

One of the challenges was having a mobile power source, as I was definitely not going to use my laptop for power when the Arduino kit is all the way up on the wall. I remembered that I found a battery pack in the kit so I dug that out and went down to the IM lab to ask for help and got some spare AA batteries.

The breadboard and Arduino setup was pretty straightforward but the one thing I had to think about was which wires to leave as an open connection later. From my perspective, it made sense to have the ground be split up and later connected using the copper tape so that’s what I did, while following the color conventions of PWR and GND.

I walked over to my door and applied some copper tape and set up my Arduino & battery pack on the wall using some mounting tape. However, as I worked on setting up the rest of the copper tape, I realized that this was going to very clunky– the door’s frame is not seamless with the door itself which means I need something solid to connect it; however, the copper tape was a bit too flimsy to be that connection. This is what I had so far at the time:

 

I was pretty perplexed by this. After some critical thinking, I realized that I could set up the arduino on the door itself. And not only that– I could even take advantage of this metal piece that helps the door slide into the lock near the door handle. This was my updated plan for my switch:

When it came to positioning the wires, I thought the copper tape would suffice to keep the wires in place but it just wouldn’t stick very well; I also needed to be able to micro-adjust and tune the location of my wires to make sure the system worked smoothly. I decided to use mounting tape again to make fine tuning the position of the wires much easier on me

I think the final result turned out to be really nice, and I’m proud of myself for adapting to the difficulties encountered during the process of mounting the project on the wall. It’s a shame I have to take it down to make future projects but I had fun making it.

 

Here’s a video of the final result in action; the green LED lights up to indicate a full lock when closed properly. I would not recommend installing this as your sole security system.