Week 10 Reading Reflection

Reading Bret Victor’s “A Brief Rant on the Future of Interaction Design” made me think differently about how I use technology. The idea that a tool has “two sides”—one that fits the person and one that fits the solution—really stuck with me. It made me realize that most of the digital tools I use today, like phones or tablets, seem to fit the solution well but not necessarily the person. They make things efficient, but they don’t always feel natural or engaging to use. It made me question whether convenience has come at the cost of a deeper, more human form of interaction.

The part about the hands also made me pause. Victor reminds us that our hands aren’t just for manipulation—they’re for feeling. That distinction hit home because I often forget how much information comes through touch. When I’m drawing, typing, or even cooking, my hands constantly sense texture, pressure, and movement. But when I’m on a screen, all that disappears. His point that “touch does the driving and vision helps from the backseat” made me see how backwards our relationship with technology has become. I depend entirely on my eyes, while my hands just tap glass.

I connected most with his frustration about “pictures under glass.” It made me realize how passive I’ve become when using digital devices—how I only swipe, scroll, or pinch, instead of actually making or feeling something. It reminded me how satisfying it is to sketch on paper or build something physical, where every motion feels responsive. Victor’s ideas made me want to look for tools and experiences that let my hands do more than just point. It’s a call to design and use technology that reconnects me to my body, not one that distances me from it.

Week 10 – Musical Instrument

Concept:

This week, Richmond and I  made a small musical instrument inspired by the piano. We used three switches to play notes.  We also added a potentiometer that can change the pitch of the notes while playing. This means the player can make higher or lower sounds with the same switches. Using the switches and potentiometer together makes the instrument more interactive and fun, giving the player control over both the notes and their frequency.

Video Demonstration:

https://drive.google.com/file/d/1tpGMX4FXWm4Y2IJe1WP9MxxI7M97yWc0/view?usp=sharing

Schematic:

Code Highlight:

// Mini Piano: 3 switches, Piezo buzzer, optional pitch adjustment

const int buzzerPin = 8;      // Piezo buzzer
const int switch1 = 2;        // Key 1 (C)
const int switch2 = 3;        // Key 2 (E)
const int switch3 = 4;        // Key 3 (G)
const int potPin = A0;        // Optional: pitch adjust

// Base frequencies for the notes (Hz)
int note1 = 262;  // C4
int note2 = 330;  // E4
int note3 = 392;  // G4

void setup() {
  pinMode(buzzerPin, OUTPUT);
  pinMode(switch1, INPUT);
  pinMode(switch2, INPUT);
  pinMode(switch3, INPUT);
  Serial.begin(9600); // optional for debugging
}

void loop() {
  // Read potentiometer to adjust pitch
  int potValue = analogRead(potPin);        // 0-1023
  float multiplier = map(potValue, 0, 1023, 80, 120) / 100.0;  // 0.8x to 1.2x

  bool anyKeyPressed = false;

  // Check switches and play corresponding notes
  if (digitalRead(switch1) == HIGH) {
    tone(buzzerPin, note1 * multiplier);
    anyKeyPressed = true;
  }

  if (digitalRead(switch2) == HIGH) {
    tone(buzzerPin, note2 * multiplier);
    anyKeyPressed = true;
  }

  if (digitalRead(switch3) == HIGH) {
    tone(buzzerPin, note3 * multiplier);
    anyKeyPressed = true;
  }

  // Stop sound if no switch is pressed
  if (!anyKeyPressed) {
    noTone(buzzerPin);
  }

  delay(10); // short delay for stability
}

Github Link:

https://github.com/JaydenAkpalu/Intro-to-IM/blob/a60e0ae114d3cd07e5e053a4b028d050f3606b30/Week10_Musical_Instrument.ino

Reflections & Future Improvements:

This week’s assignment felt highly interactive, building upon previous projects while introducing multiple input elements and user-controlled parameters. We learned how to combine both digital and analog inputs to create a responsive musical instrument. For future improvements, we would like to implement a more realistic note duration system, where each note fades out naturally after being played, similar to a real piano. Additionally, adding more switches and possibly multiple buzzers could allow for more complex melodies and chords, enhancing the expressive possibilities.

 

Week 9: Analog and Digital Sensor

Concept:

For this project, I decided to use one digital sensor and one analog sensor to control two LEDs. For the digital part, I connected a push button to a digital pin to control one LED — pressing the button turns the light on, and releasing it turns it off. For the analog part, I used a potentiometer connected to an analog input to control the brightness of a second LED through an analog output. As I turned the knob, the LED smoothly adjusted its brightness, demonstrating how analog signals can vary continuously instead of just turning on or off. This setup reflects the difference between digital and analog control and how both can work together in an interactive circuit.

Video Demonstration:

https://drive.google.com/file/d/1_urM0vEA__Piz7zGG_TUHDnuhy5QYUgQ/view?usp=drive_link

Circuit Illustration:

Code Highlight:

// Define pin numbers
int ledPin1 = 11;   // LED controlled by potentiometer (analog LED)
int ledPin2 = 2;    // LED controlled by button (digital LED)
int buttonPin = 7;  // push button input

void setup() {
  // Set pin modes
  pinMode(ledPin1, OUTPUT);     // pin 11 used for PWM (brightness control)
  pinMode(ledPin2, OUTPUT);     // pin 2 for digital on/off LED
  pinMode(buttonPin, INPUT);    // button as input (external resistor required)
  
  Serial.begin(9600);           // start serial monitor for debugging
}

void loop() {
  // Read the potentiometer (analog sensor)
  int sensorValue = analogRead(A1);     // reads values from 0–1023
  Serial.println(sensorValue);          // print the reading to serial monitor

  // Control the brightness of LED on pin 11
  // analogWrite expects a range 0–255, so divide by 4 to scale down
  analogWrite(ledPin1, sensorValue / 4);
  delay(30);                            // small delay to stabilize readings

  // Read the push button (digital sensor)
  int buttonState = digitalRead(buttonPin);   // reads HIGH or LOW

  // Control the digital LED based on button state
  if (buttonState == HIGH) {     // if button is pressed (connected to 5V)
    digitalWrite(ledPin2, HIGH); // turn LED on
  }
  else {                         // if button is not pressed (LOW)
    digitalWrite(ledPin2, LOW);  // turn LED off
  }
}

Github Link:

https://github.com/JaydenAkpalu/Intro-to-IM/blob/f43175106ae171c88a5c7db0410a56dc965127af/Week9_AnalogAndDigitalSensor.ino

Reflections & Future Improvements:

Working on this project helped me really understand the difference between digital and analog sensors and how they can control things like LEDs. I saw that a digital sensor, like a push button, only has two states — on or off — which makes it easy to control an LED directly. On the other hand, an analog sensor, like a potentiometer, can give a range of values, letting me gradually adjust the brightness of an LED. It was really satisfying to see how these two types of input behave so differently in a circuit.

If I were to improve the project, I’d try adding more interactive elements. For example, I could use multiple buttons or potentiometers to control more LEDs, or even combine the potentiometer with a light sensor so the LED responds to changes in the environment automatically. I’d also like to experiment with different LED effects, like fading, blinking patterns, or color changes, to make it more dynamic and fun. Overall, this project gave me a better understanding of how simple inputs can be used creatively to make interactive circuits.

Week 9 Reading Reflection 2

Reading Tom Igoe’s “Making Interactive Art: Set the Stage, Then Shut Up and Listen” made me rethink the way I think about creative work. What stood out to me most was his idea that artists shouldn’t script how people experience their work. I found it interesting when he said that by explaining too much, artists end up telling the audience what to think and how to act. That made a lot of sense: if the whole point of interactive art is to create a conversation, then the artist needs to give space for the audience to respond. I liked how he compared it to being a director: you can guide your actors, but you can’t tell them exactly how to feel. The same goes for an audience—you set the stage, then step back.

I also appreciated how he described interactive art as something that lives through the audience’s actions. The idea that people complete the artwork through their participation feels powerful. It reminds me that design isn’t just about control; it’s about trust—trusting that others will find meaning on their own. This reading encouraged me to think less about explaining and more about creating experiences that speak for themselves.

Week 9 Reading Reflection 1

Reading Tom Igoe’s Physical Computing’s Greatest Hits (and Misses) really opened my eyes to how creative physical computing can be. I liked how he talked about different project themes that keep coming up, like theremin-style instruments, gloves, or meditation helpers, but still manage to feel fresh every time. What stood out to me was his point that even if an idea has been done before, there’s always room for originality. It’s not about being the first person to come up with something, but about how you make it your own. That made me see creativity in a new way; it’s more about exploring, experimenting, and putting a bit of yourself into the project.

I also liked how Igoe focused on the human side of physical computing. He reminds readers that the goal isn’t just to build machines that move or light up, but to design interactions that mean something. It made me realize that technology can be emotional and expressive, not just functional. Overall, the reading made me appreciate how physical computing connects people and ideas, and how much space there is to create something personal, even within familiar themes.

Week 8 – Unusual Switch

Concept:

For this week’s assignment, I made a foot-activated switch that turns on an LED when you step on it. It uses two pieces of aluminum foil that touch when pressed together, completing the circuit and lighting the LED.

The idea was to make a basic, hands-free switch that works using pressure from your foot.

Video demonstration:

https://drive.google.com/file/d/1tqjnfQByBRSJJjC8D7xZhDbTFqgD4DTf/view?usp=drive_link

Code Highlight:

const int ledPin = 13;     // LED pin
const int switchPin = A2;  // Foil switch pin

void setup() {
  pinMode(ledPin, OUTPUT);
  pinMode(switchPin, INPUT);
}

void loop() {
  int switchState = digitalRead(switchPin);

  if (switchState == HIGH) {
    digitalWrite(ledPin, HIGH);   // Turn LED on
  } else {
    digitalWrite(ledPin, LOW);    // Turn LED off
  }
}

Github link:

https://github.com/JaydenAkpalu/Intro-to-IM/blob/4dfa5eeecae690e073a9bfd35f4140274d87f5f1/Week8_UnusualSwitchAssignment.ino

Reflections & Future Improvements:

Building the foot-activated switch helped me understand how a basic circuit can turn a simple physical action into an electronic signal. I learned how to use digital inputs on the Arduino and how completing a circuit with something as basic as foil can act as a switch.

If I were to improve it, I’d try to make the foil connection stronger and more reliable, since it doesn’t always press evenly. I’d also like to make the setup look cleaner and maybe add another component, like a buzzer or a second LED, to make it more interactive.

Week 8 Reading Reflection – Her Code Got Humans on the Moon

After reading “Her Code Got Humans on the Moon—And Invented Software Itself” by Robert McMillan, what made the biggest impression on me was how much Margaret Hamilton thought about human error. I couldn’t get over how NASA brushed off her warning that an astronaut might make a simple mistake and run the wrong program. As humans, we’re bound to make mistakes, especially under pressure, and it’s always better to be safe than sorry. They told her it couldn’t happen because astronauts were “trained to be perfect.” Of course, during the Apollo 8 mission, the exact thing she predicted actually happened. Instead of blaming anyone, Hamilton treated it as proof that software should be built to handle mistakes. I found that amazing – she didn’t just write code; she designed systems that expected humans to make mistakes.

Her story made me think about how I use and create technology. I’ve gotten frustrated when an app crashes or rejects input that seems fine, but I rarely stop to consider all the thought and safeguards behind it. Hamilton’s approach – designing for human error – is the basis for how we handle mistakes in programming now, such as with try/except statements in Python or input validation. It made me realize that good software isn’t just about making things work; it’s about making sure they still work when people slip up.

Her persistence and foresight were inspiring. She didn’t just follow rules; she questioned assumptions, planned for the unexpected, and thought about people using her code. That’s the kind of thinking I want to carry into my own work with technology: designing not just for perfection, but for real humans.

Week 8 Reading Reflection – Norman, “Emotion & Design: Attractive things work better”

When reading Norman’s “Emotion & Design: Attractive Things Work Better,” it got me thinking differently about how emotions affect the way we interact with design. Before this, I mostly thought good design just meant something that works well and is easy and intuitive to use. But Norman made me realise that how we feel when using something really matters too. I found his idea of positive affect interesting – when we’re in a good mood, we become more creative and open to solving problems. I’ve noticed this myself when I’m working on projects; if I’m relaxed and enjoying the process, I tend to come up with better ideas and find solutions more easily.

What also stood out to me was Norman’s explanation of negative affect – how stress or anxiety can actually help us focus. I totally agree with that because whenever I’m taking an exam or working under pressure, that little bit of nervous energy pushes me to concentrate harder and think faster.

Overall, this reading changed how I see both design and emotion. Emotions don’t just influence how we feel about something – they shape how we use it. Some designs are made to make us feel good – to relax us, inspire creativity, or make things enjoyable. Others use a bit of tension or urgency, like alarms or deadlines in digital design, to grab our attention and help us focus. It’s interesting to realise that designers often plan for these emotions on purpose. Good design isn’t just about working well; it’s about understanding how people feel.

Midterm Project: “Football Obstacle Game”

Concept:

The idea behind this project was to create an interactive football shooting game that combines skill, strategy, and dynamic difficulty. The player must shoot goals while avoiding defenders and a moving goalkeeper. The game incorporates increasing challenge as the player scores, adding both excitement and replay value.

I wanted the game to be simple enough for beginners to play, yet engaging enough to demonstrate programming concepts like collision detection, movement logic, and audio-visual feedback in p5.js

Design and features of the game:

  • Player Controls: Use the arrow keys to move and mouse click to shoot.

  • Dynamic Defenders: Start with 3 defenders; a new defender is added every time the player scores.

  • Goalkeeper: Moves horizontally across the goal area and tries to block shots.

  • Score Tracking: Displays the player’s score at the top left.

  • Audio Feedback: Crowd cheers when the player scores, and a whistle plays when the player loses.

  • Background Image: I used a football pitch background image to visually represent the field.

  • Collision Detection: The game detects collisions between the player, ball, defenders, and goalkeeper to determine goals or game overs.

Code Highlight:

One of my favorite code snippets is the restart logic. Instead of refreshing the entire page, pressing “R” instantly resets the player, ball, defenders, and score to allow for a smooth restart.

Another code snippet I’m proud of is the collision detection function. This function checks whether the player or the ball collides with any of the defenders using the distance formula. It calculates the distance between two objects and compares it to their combined radii — if they overlap, the game ends.

// Restart after lose
  if (gameState === "lose" && (key === "r" || key === "R")) {
      Ball1.reset(Player1);
      Player1.reset();
      score = 0;

      // Reset defenders
      defenders = [];
      for (let i = 0; i < 3; i++) {
          let defenderX = random(width / 4, (3 * width) / 4);
          let defenderY = random(height / 6 + 50, (5 * height) / 6 - 50); // release below goal
          defenders.push(new Defender(defenderX, defenderY, 3));
      }
function checkDefenderCollision() {
  for (let defender of defenders) {
    // Player collision
    let dPlayer = dist(Player1.x, Player1.y, defender.x, defender.y);
    if (dPlayer < 20 + 15) {
      loseGame();
      return;
    }

    // Ball collision
    if (Ball1.isMoving) {
      let dBall = dist(Ball1.x, Ball1.y, defender.x, defender.y);
      if (dBall < Ball1.radius + 15) {
        loseGame();
        return;
      }
    }
  }
}

Embedded Sketch:

This is a link to the sketch: https://editor.p5js.org/Jayden_Akpalu/sketches/_4tt_i0oG

Reflections & Future Improvements:

Through this project, I learned how to manage game states, implement collision detection, and integrate audio and visuals for a more immersive experience. I also improved my debugging and problem-solving skills — especially when aligning the goalkeeper, handling full-screen scaling, and ensuring the game reset logic worked correctly.

If I had more time, I would like to improve the game in several ways. First, I’d like to replace the simple circles used for the players and defenders with animated sprite characters. This will make the movement and shooting feel more realistic and visually engaging. For example, I could use a sprite sheet of a footballer running or kicking the ball, and animate it frame by frame when the player moves or shoots. Also, I’d like to add multiple levels of difficulty with new environments or faster defenders to make gameplay more dynamic. Finally, I’d love to create a high-score tracker, allowing players to save and compare their best performances.

Midterm Draft 1

Concept:

For my midterm project, I decided to create a football obstacle game where the player dribbles through moving defenders to score against a moving goalkeeper. The game gets progressively harder after each goal: defenders increase in number and speed, and the goalkeeper moves faster. The player clicks to shoot when near the goal.

The aim is to design a game that is fun and interactive, combining timing, precision, and quick thinking. I will also include engaging visuals and sounds to give feedback for player actions, like kicking the ball, scoring, or colliding with defenders. This makes the game feel immersive and responsive.

Design:

The game starts with an on-screen instruction explaining the controls: the arrow keys to move, and the mouse click to shoot. Only when the player presses a key or clicks the button does the game begin. The player, defenders, goalkeeper, and the ball in the game will be represented using circles for simplicity and visual consistency. The player will be a larger colored circle that moves freely across the field in response to user input, with the ball represented as a smaller circle attached to the player while dribbling. Defenders will be smaller circles in distinct colors, moving along random paths to create challenges, while the goalkeeper will be a medium-sized circle that moves horizontally along the goal line to block shots. When the player shoots, the ball will separate from the player and travel independently toward the goal.

Classes to be used:

  • Player Class: Controls movement and shooting. Properties include position, size, and speed. Methods: Methods or functions include display(), move(), and shoot()

  • Defender Class: Moves across the field, increasing in number and speed as the game progresses. Properties include position, size, speed, and direction. Methods or functions include display() and move()

  • Goalkeeper Class: Moves left and right along the goal line. Properties include position, width, height, and speed. Methods or functions include display() and move()

  • Ball Class: Moves toward the goal when shot. Properties include position, size, speed, and moving. Methods or functions include display(), move()

Gameplay Flow:

  1. Start Screen: Displays instructions like “Use arrow keys to dribble, click to shoot, avoid defenders.”

  2. Gameplay:

    • Player moves freely around the field with the ball

    • Defenders move continuously in patterns.

    • Player avoids collisions with defenders.

    • When near the goal, clicking the mouse shoots the ball.

  3. Scoring & Difficulty:

    • Passing the goalkeeper scores +1.

    • After each goal, more defenders appear, defender speed increases, and goalkeeper speed increases slightly.

    • Player position resets for the next attempt.

  4. Restart / New Session:

    • Players can restart without refreshing the page.

    • Score and high score are displayed.

Frightening/Challenging Aspect:

The most challenging aspect of this project will likely be keeping the ball consistently attached to the player while allowing free movement around the field. Although the player and ball are conceptually separate objects, the ball must move in perfect sync with the player in all directions – up, down, left, right, and diagonally, which can be difficult to achieve smoothly. This challenge becomes even greater when combining it with collision detection against multiple defenders and a moving goalkeeper. The ball must remain attached until the player decides to shoot, at which point it detaches and moves independently toward the goal.

But this is also the most important part of the project, and implementing it correctly will help create an engaging and fun experience.

Risk Reduction:

To reduce the risk of issues with keeping the ball attached to the player, I plan to implement a step-by-step testing approach. First, I will start by coding the player and ball as separate objects and linking the ball’s position directly to the player’s coordinates with an offset, ensuring that it moves smoothly in all directions. I will test this initially without any defenders or a goalkeeper to confirm that the ball follows perfectly. Next, I will gradually add collision detection with a single defender, then multiple defenders, and finally the goalkeeper, checking at each stage that the ball remains properly aligned. Additionally, I will use simple shapes, such as circles, for all objects to simplify calculations.