Author: Mariam Aljunaibi

Concept

Soo I ended up not doing any of my initial ideas (oops) because I came up with a more exciting one today while talking to my sister. Basically, this project will be an interactive time machine (of some sort) that lets the user travel to different years using physical controls, and choose to either play real music or news from that selected time period/year. My project is inspired by the computer game Club Penguin, specifically the game feature where the player completes missions as a spy for the PSA (Penguin Secret Agency) and uses gadgets to solve tasks. Similarly, my concept is that the player/user is assigned a mission to test out a new prototype time machine. (I’m also making the main screen kind of look like the start screen of the minigame Aqua Grabber in Club Penguin.)

Arduino and P5 Communication

These are the components I’m going to use in my project:

• 2 buttons, where one button selects the music, and the other selects the news broadcast.
• A potentiometer, chooses the user’s preferred year/time period that shows up on the screen.
• One more button, kind of acts like a start button, which will play the sounds of music of news after either one is selected by the user.
• 5 Green LEDs, each LED lights up just like the ones on the screen will.

Just to be clear, the potentiometer is the time period/year selector, and the buttons select either music or news to be played.

The main interface of this project will look like the start screen of one of the minigames in Club Penguin called Aqua Grabber, which looks like this:

Arduino to P5 Communication

Every time the potentiometer’s value changes by 100, the sketch on P5 will change the green lights (as shown in the picture) to the next one. So the first light is initially lit up since the potentiometer’s value is 0, and once it reaches 100, it changes to the next one (goes from left to right).

P5 to Arduino Communication

The specific green LED that’s lit up on the sketch on P5 will also trigger the corresponding green LED on the breadboard to light up as well.

How it Works

1. User turns the potentiometer and chooses a time period/year
2. P5 lights up the corresponding green light on the sketch
3. Arduino lights the matching green LED on the breadboard
4. User presses either the “music” or “news” button
5. User presses the “start” button
6. P5 plays music/news from the selected year/time period

Project Progress So Far

I worked on the Arduino part of it first. I attached 5 green LEDs and a potentiometer. As I explained before, the LEDs light up when the potentiometer’s value is within that specific LED’s range.

Here’s the code I created on Arduino IDE: FullCode

Here’s a video of it:

For my final project, I’m currently deciding between two game concepts. I’m still brainstorming and working on the overall ideas, so since I haven’t fully decided what to go with yet, I’m documenting both possible directions.

Concept 1 — Rhythm Game

This concept is based on rhythm games like Dance Dance Revolution, but turned into a tabletop physical controller. Instead of tapping keys on a keyboard, players interact with physical buttons connected to an Arduino that trigger actions in p5.js.

Interaction (How it Works)

On the p5.js screen, colored notes fall from the top to the bottom. The player has 4–6 physical push buttons arranged in a row, each one corresponding to a lane on the screen. When a falling note reaches the bottom marker, the player must press the matching physical button at the right moment.

The game gives immediate feedback, such as:

• Perfect hits respond with a sound and/or visual flash
• A miss is indicated with a red flash
• The score updates in real time

Arduino Components

• 4–6 push buttons
• 1 potentiometer

The potentiometer will control the difficulty level by adjusting the speed of the falling notes (higher difficulty = faster notes).

I like this idea because I think people will naturally want to try it, and it’s generally easy to understand without needing much explanation.

 

Concept 2 — Wizard Duel (Mashing Game)

This concept is a 2-player competitive game inspired by Harry Potter wand duels and by games like “Wizard” on 1-2-Switch. Each player has a physical button, and the faster they mash their button, the more they push their spell beam toward the opponent.

Interaction (How it Works)

The p5.js screen shows two wizards on opposite sides. Player 1 has one button, Player 2 has another. When the game starts (using a separate start/reset button):

• Both players mash their button as fast as possible
• The faster player pushes the spell beam toward the opposite side
• If the beam reaches Player 2’s side, Player 1 wins
• If it reaches Player 1’s side, Player 2 wins

Arduino Components

• 1 button to start/reset
• 2 buttons (one for each player to mash)

I might also add LEDs for each player that flash with every mash (not 100% sure yet, I’ll see what works best). I’m also open to adding more components if it makes the game more interesting.

I like this idea because I love competitive games, especially mashing games. I used to play them all the time on game consoles with my sisters.

 

Conclusion

I still need to decide which concept I’ll fully commit to (and who knows, I might even change my entire idea by next week). Over the next few days, I’ll prototype small parts of each idea to see which one feels more engaging and fun for me to complete.

After reading Design Meets Disability, I noticed how it sheds light on an ongoing issue with how society views disabilities. The author explains how when design and disability meet, the outcome is always the most intricate and interesting. It’s an opportunity for designers to test out their skills in both creativity and functionality.

I loved the section where he criticizes designers for making many assistive technology (AT) devices, like hearing aids and prosthetics, hidden. I also believe that disabilities should not be shamed, but embraced. By prioritizing the concealment of these devices, we are discouraging disabled individuals rather than empowering them, making them feel like outsiders instead of supporting them. By making AT more visible and beautifully designed, I believe designers can help change how people perceive disabilities.

The idea to bring engineers and designers together (‘solving’ and ‘exploring’) to create AT devices is brilliant because the result will be assistive technologies that are both useful and inspiring. I also think designers will be very useful in coming up with a comfortable device for users, since they’ll be wearing or using them all day (sometimes all night).

I absolutely agree with the enforcement of universal design, meaning designing products that are usable by as many people as possible, which of course also includes people with disabilities. The author mentions that rather than making a device for a very specific disability only, we could make devices with designs that are simple enough to be broadly adapted but smart enough to serve people with different needs. Overall, I believe this approach to design makes devices more accessible and more human.

Exercise 1: Arduino to P5 Communication

For this exercise, we used a potentiometer as the analog sensor. The potentiometer controls the ellipse’s position on the horizontal axis in the P5 sketch. When you turn it one way, the ellipse moves to the right, turning it the other way causes it to move left.

We added a little text at the top of the sketch that displays the sensor value. As the value increases, the ellipse moves to the right, and vice versa.

Link to code: Exercise1_FullCode

Schematic

 

Circuit Design

Demo Video

Exercise 2: P5 to Arduino Communication

Here, we used the keyboard arrow keys to change the LED brightness. Pressing the right arrow increases the brightness, and the left arrow decreases it.

Link to code: Exercise2_FullCode

Schematic

Demo Video

Exercise 3: Bi-directional Communication

For the Arduino to P5 communication, the potentiometer acts like the “wind” in the gravity/wind example. As you turn it, the ball gets pushed left or right depending on the mapped value.

For the P5 to Arduino communication, every time the ball hits the bottom and bounces, it triggers the LED to briefly turn on and then off, so the LED flashes in sync with each bounce.

Link to code: Exercise3_FullCode

Schematic

Demo Video

Bret Victor’s rant on the future of technology had a very interesting take on technological design for the future, which made me realize the things we often ignore. He mentions how a glass screen completely misses the purpose of what our hands can do, which is to feel and manipulate, and how future interaction designs seem to neglect that entirely by reducing interaction to swiping fingers across a flat screen.

Honestly, I can’t help but agree with him on this, but I also find it difficult to come up with a clear solution to this problem. Designing future technology in the “Pictures Under Glass” way is probably the easiest way to do so, which is likely why it became the default design. If we did take the abilities of our hands into account, depending on the purpose of the device you’re using, the design would differ drastically from one to another, making it extremely complex. Although I do agree with Victor’s frustration, I also think his critique shows how difficult innovation can be once a certain design dominates the industry.

In his follow-up, Victor admits that he didn’t offer a solution because the purpose of his rant was to encourage research rather than provide answers. I actually respect his honesty, it made his rant look more like an invocation rather than a complaint. I’m on board with his criticism to limiting designs and to instead imagine new possibilities of greater ones. Even though we don’t yet know what a “dynamic tactile medium” will look like, I think Victor’s ideas push us as readers to think deeply about how our bodies and technology should work together.

Concept

For this assignment, I worked together with Ling to create an instrument using the ultrasonic sensor. He came up with the idea to use the distance sensor, and the way we executed it reminded me of a theremin because there’s no physical contact needed to play the instrument. We also used a red button to turn the instrument on and off, as well as a green button that controls the tempo of the piezo buzzer (based on how many times you click on it in 5 seconds).

Schematic Diagram

 

Code

const int trigPin = 9;  
const int echoPin = 10; 
const int buzzerPin = 8; 
const int buttonPin = 4;  // system ON/OFF button
const int tempoButtonPin = 2;  // tempo setting button

//sensor variables
float duration, distance; 
bool systemOn = false; // system on or off state

// tempo variables
bool tempoSettingActive = false; 
int  tempoPressCount    = 0;   
unsigned long tempoStartTime = 0;
unsigned long tempoInterval  = 500; 

// for edge detection on tempo button (to count presses cleanly)
int lastTempoButtonState = HIGH;

// for edge detection on system button (cleaner)
int lastSystemButtonState = HIGH;


// for controlling when next beep happens
unsigned long lastBeatTime = 0;



void setup() {  
 pinMode(trigPin, OUTPUT);  
 pinMode(echoPin, INPUT);  
 pinMode(buzzerPin, OUTPUT);
 pinMode(buttonPin, INPUT_PULLUP); // system ON/OFF button 
 pinMode(tempoButtonPin, INPUT_PULLUP);  // tempo button 
 Serial.begin(9600);  
}  

void loop() {
  // system on/off state
  int systemButtonState = digitalRead(buttonPin);

  // detects a press: HIGH -> LOW 
  if (systemButtonState == LOW && lastSystemButtonState == HIGH) {
    systemOn = !systemOn;  // Toggle system state

    Serial.print("System is now ");
    Serial.println(systemOn ? "ON" : "OFF");

    delay(200); // basic debounce
  }
  lastSystemButtonState = systemButtonState;
  
  // if system is OFF: make sure buzzer is silent and skip rest
  if (!systemOn) {
    noTone(buzzerPin);
    delay(50);
    return;
  }

  // tempo button code
  int tempoButtonState = digitalRead(tempoButtonPin);

  // detects a press 
  if (tempoButtonState == LOW && lastTempoButtonState == HIGH) {
    if (!tempoSettingActive) {
      
      //first press (starts 5 second capture window)
      tempoSettingActive = true;
      tempoStartTime = millis();
      tempoPressCount = 1;  // Count this first press
      Serial.println("Tempo setting started: press multiple times within 5 seconds.");
    } else {
      // additional presses inside active window (5 secs)
      tempoPressCount++;
    }

    delay(40); // debounce for tempo button
  }
  lastTempoButtonState = tempoButtonState;

  // if we are in tempo mode, check whether 5 seconds passed
  if (tempoSettingActive && (millis() - tempoStartTime >= 5000)) {
    tempoSettingActive = false;

    if (tempoPressCount > 0) {
      // tempo interval = 1000 ms / (number of presses in 5 secs)
      tempoInterval = 1000UL / tempoPressCount;

      // avoids unrealistically fast intervals
      if (tempoInterval < 50) {
        tempoInterval = 50;
      }

      Serial.print("Tempo set: ");
      Serial.print(tempoPressCount);
      Serial.print(" presses in 5s -> interval ");
      Serial.print(tempoInterval);
      Serial.println(" ms between beeps.");
    } else {
      Serial.println("No tempo detected.");
    }
  }
 
  // ultrasonic sensor distance measurement
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);

  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  duration = pulseIn(echoPin, HIGH);
  distance = (duration * 0.0343) / 2.0;  // in cm

  Serial.print("Distance: ");
  Serial.println(distance);

  
  //buzzer pitch and tempo
  // checks if distance is valid and in a usable range
  if (distance > 0 && distance < 200) {
    float d = distance;

    // limit distances for stable mapping
    if (d < 5)  d = 5;
    if (d > 50) d = 50;

    // maps distance to frequency (closer = higher pitch)
    int frequency = map((int)d, 5, 50, 2000, 200);

    // uses tempoInterval to define how often we "tick" the sound (creates short beeps at each interval using current frequency)
    unsigned long now = millis();

    if (now - lastBeatTime >= tempoInterval) {
      lastBeatTime = now;

      // plays a short beep (half of the interval duration)
      unsigned long beepDuration = tempoInterval / 2;
if (beepDuration < 20) {
beepDuration = 20;  // minimum hearable blip
 }

tone(buzzerPin, frequency, beepDuration);
}

 } else {
    // if bad/no reading, silence the buzzer between ticks
    noTone(buzzerPin);
  }
  delay(50); //delay to reduce noise

}

Favorite Code

//buzzer pitch and tempo
// checks if distance is valid and in a usable range
if (distance > 0 && distance < 200) {
  float d = distance;

  // limit distances for stable mapping
  if (d < 5)  d = 5;
  if (d > 50) d = 50;

  // maps distance to frequency (closer = higher pitch)
  int frequency = map((int)d, 5, 50, 2000, 200);

This is a pretty simple part of the code, but I loved how the beeping sounds turned out. It’s so satisfying to see how my hand movements directly control the sound, and it made me realize how significant even a small part of the code could be.

The code was completed with assistance from ChatGPT.

Video Demo

Reflection and Future Improvements

Mapping the distance to control the sound was pretty simple. The challenging part was controlling the tempo, we had to figure out the values to divide in order for it to have a clear change in the sound of the piezo buzzer after clicking the green button. Overall, this was a really cool project and I hope to continue to improve and expand my knowledge in physical computing!

Concept

For this week’s assignment, my overall concept is pretty similar to the one I did last week because it also has something to do with sleep. This time, I created a light system: for the first one, I used a button to turn on a single LED manually, and for the second one, the yellow LED turns on when the lights are turned off, just like a night light! I got inspiration for this idea from my little sister when we were kids, because she always used to sleep with a night light on.

Code

int buttonPin = 8;
int greenLED = 7;  // pin for green LED
int lightSensorPin = A2;
int yellowLED = 6;  // pin for yellow LED

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

void loop() {
  int sensorValue = analogRead(lightSensorPin);
  Serial.println(sensorValue);  // prints sensor value from light sensor

  if (digitalRead(buttonPin) == LOW) {  // button pressed
    digitalWrite(greenLED, HIGH);
  } else {
    digitalWrite(greenLED, LOW);
  }

  if (sensorValue < 175) {
    digitalWrite(yellowLED, HIGH);
  } else {
    digitalWrite(yellowLED, LOW);
  }
}

So basically, I used conditional statements for when I wanted each LED to turn on. The green LED was connected to the digital pins, so I used a button to turn it on and off: when the button is pressed, the LED lights up, and when it’s not pressed, the LED turns off. For the yellow LED, it checks the light sensor’s value, and when that value goes below 175, the LED turns on (so when the lights are off, the yellow LED acts as a night light!).

Hand-Drawn Schematic

Schematic diagram and Photo:

Video Demo

Reflection and Future Improvements

Honestly, it was pretty hard to come up with a concept for this project, but when I did, I’m satisfied with how it turned out. Another thing was that I underestimated how much time this would take, it took me way too long to figure everything out and fix the issues on the circuit. In the future, I plan on practicing wiring more often and getting a better understanding of circuit logic.

Physical Computing’s Greatest Hits (and misses)

I agree with Igoe’s idea of recurring “hits and misses,” but I don’t think a project has to be deeply meaningful to count as a hit. Sometimes, a piece can still be successful if it’s creative, interesting, or just fun to interact with. I also think context plays a role in making something feel meaningful, especially through how users receive feedback. For example, the Monsters Inc. scream canisters in Disneyland Paris come to mind. As a kid, I loved screaming into them and watching the energy bar go up to the top, it’s a perfect example of feedback making the interaction more memorable.

I used to get hesitant about working on projects that weren’t completely original, feeling like I needed to come up with something new. But Igoe’s words reminded me that even if an idea’s been done before, I can still make it mine by adding my own personal touch.

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

I found Igoe’s idea of “setting the stage and shutting up” really interesting because it shows just how much power interpretation has in interactive art. When artists or designers immediately tell their audience what something means, it limits how people can experience it. I think there’s this sort of psychological effect that once you’re told what something is, it’s hard to see it in any other way. So I think it’s more effective to let users come to their own conclusions, even if it means they interpret the project differently from what was intended.

While making my own projects, I understand how my project works but users might not. By actually watching and hearing how they interact with it, I can figure out what’s confusing or what needs improvement. Feedback like that helps me refine my designs to make them more intuitive and engaging.

Concept

For this assignment, I struggled to come up with the idea itself. I mean, a switch without using your hands is pretty tricky. I eventually came up with the idea of using an earring and a shoulder pad (of some sort). Basically, when you tilt your head (so the earring touches your shoulder), that’s when the connection happens and the LED turns off. It turns off because the whole idea is laziness. If I’m napping while sitting up, I tilt my head to the side toward my shoulder. So it makes more sense for the LED to turn off when I tilt my head, just like wanting to turn the lights off to go to sleep.

Code

void setup() {
pinMode(2, INPUT_PULLUP); //earring and shoulder foil
pinMode(12, OUTPUT);
}

void loop() {

if (digitalRead(2) == LOW) {
  digitalWrite(12, LOW); // LED turns off when earring connects to shoulder foil
}
else{
  digitalWrite(12, HIGH); // LED is on (not touching)
}
}

 

Here’s the video of the working switch: Video Demo

Here’s the picture of the wiring:

Future Improvements

Overall, the idea was simple, but I came across some problems. One was the LED kept blinking without a certain pattern, and I wasn’t really sure why. Then i scratched everything and redid it, and it worked. I think it might have been a problem with actually putting the wires and components on the circuit, so I will try to be more precise and careful in the future.

Don Norman — “Emotion & Design: Attractive Things Work Better”

Don Norman argues that it’s important to design things to be visually pleasing and attractive because it makes us happier and improves how people use them. I agree with him because there were countless times when my mood or motivation dropped just because the things around me looked unattractive. A prime example for me is the room I work in, I probably wouldn’t be able to finish, let alone even start doing my work if I were in a gloomy room with barely any colors, or furniture that doesn’t complement each other. Overall, I find that I’m in a much more positive state of mind when I’m surrounded by things with an appealing design.

Robert McMillan — “Her Code Got Humans on the Moon”

The article about Margaret Hamilton really made me think about just how important not only the mission is, but the people who helped make it happen. Hamilton was a computer scientist in the 1960s who worked in MIT, where she led the development of the onboard flight software for the Apollo missions. I found it very impressive how she managed to succeed in a male-dominated field while also juggling her personal life, such as caring for her daughter, all while doing groundbreaking technical work at such a young age.

Thanks to Hamilton’s experience and clever approach to handling errors or casualties, she was able to save the astronauts on the Apollo 8 flight and bring them back home. I find it truly inspiring that even before they launched the mission, Hamilton wanted to add error-detection code “just in case.” Even when her higher-ups thought it was unnecessary, she didn’t give up and made sure the system could handle unexpected problems, and her preparation paid off in the end.