Category: F2025 – Mang

Concept

The idea behind this project is to create a hands-free switch that uses body weight to control a simple electrical circuit. When someone sits down, the pressure causes two layers of aluminum foil, separated by a bouncy piece of foam, to touch, completing the circuit and lighting up an LED. When the person stands up, the foam returns to its original shape, breaking the connection and turning the light off. This project demonstrates how everyday materials like foil and foam can be turned into a functional pressure-sensitive switch, showing how creative design and basic electronics can work together to make an interactive, responsive object.

Image & Video Documentation

Future Improvements

In future versions, the pressure switch could be made more durable and precise by replacing the foil with conductive fabric or copper tape, and using a softer, more uniform spacer material to ensure consistent contact. It could also be used to trigger more complex outputs, such as sounds, animations, or notifications, when someone sits down. Equally important, it could also be made more aesthetically pleasing by adding color and by making it smaller, making it not only functional but also a cute device to have hidden somewhere, such as on a chair.

Concept

This project takes inspiration from the dual-manual organ, an instrument that engages both the hands and feet to create layered musical expression. Similarly, I wanted to explore how interaction not only through hands can become a creative control method. I built a pedal-activated LED system, allowing the user to light up different colors by stepping instead of using their hands. The choice of red, yellow, and green LEDs draws directly from the universal language of traffic lights, symbolizing stop, pause, and go, which could creates a visual rhythm that also parallels musical tempo. The pedal thus becomes both a practical switch and a metaphor for coordination and rhythm through movement.

Image & Video Documentations Video(Download)

Future Improvements

Building this project helped me better understand how simple sensors and physical actions can create meaningful interaction. The foot-controlled design felt intuitive and playful, emphasizing how movement can extend beyond the hands in creative electronics. However, I also noticed that the current version only allows a binary on-off behavior. In the future, I’d like to make it more expressive, for example, by integrating pressure sensors so that the brightness or color changes based on how hard the pedal is pressed, or adding a fade-in/out animation for a smoother, more musical response. Another possible direction is to connect the pedal to sound or musical output, letting each color correspond to a tone similar to the dual-keyboard organ.

If good design induces positive emotion, why do bad designs exist?

For a long time, I thought good designs not “nice-to-haves”, because it would take much mental efforts for me to even open an app I don’t like. Norman’s piece reinforced my belief, and I started noticing how intentional UX design can guide positive feelings. If good design makes users happier (and presumably more loyal), why would anyone create something clunky or unpleasant?

One big reason is cost. Last year, I bought a cheap disposable raincoat for a trip. It was thin, the buttons fell off easily, and it didn’t even cover my shoulders properly. The design was terrible, but it cost $5 compared to a $50 waterproof jacket that would’ve lasted years. For the brand, the goal was to sell a low-cost, single-use product, not to create something that felt good to wear. Good design here would’ve raised production costs, which didn’t align with their business model.

Another reason is misaligned priorities. I’ve used software for courses that’s so confusing—not p5.js, but it would be fair to mention Arduino IDE and most Adobe offerings. The team behind it probably focused solely on function, “Does it track data, can it be integrated with all hardware?” They forgot to ask, “Will this feel easy to use?” Maybe they were rushed to launch, or thought “usability” was less important than checking off feature lists.

There are also cases of designing for the wrong user. I’ve read about stories where the visually impaired struggles with many “well-designed” apps, with all the bright colors that blur together, tiny text, no screen-reader support. The designers may have imagined a “typical” user and didn’t consider how their choices would exclude others. Poor design is a lack of empathy for diverse needs.

Is software engineering compatible with good design?

Software engineering becomes non-negotiable in high-risk, high-pressure contexts, most probably the world Hamilton worked in. When a product’s failure could mean disaster (e.g., a space mission, a medical device, or a banking app), engineering ensures no crashes, no glitches, no errors that cost lives or money. Overall, reliability. I think about Apollo 11. If Hamilton’s code hadn’t detected and fixed the P01 flaw mid-flight, the moon landing must’ve failed. In that case, engineering wasn’t just “important” but existential.

But engineering and good design don’t conflict, but rather complement each other. Engineering builds the “trust” (i.e., will a product work when I need it?), and good design builds the “connection” (i.e., will it be easy, intuitive, and after all nice to use?). Take the Wio banking app as an example. Its engineering ensures my transactions are secure and fast, and its clear, low-jargon design makes it easy to check my balance or transfer money. If the app crashed every time I used it, its pretty interface wouldn’t matter. If it worked perfectly but was impossible to navigate, I’d switch to another bank.

This week’s readings were definitely something refreshing to analyze as I agreed with the authors notion that physical computing is less about the devices themselves and more about the relationships they create between people and machines. In “Physical Computing’s Greatest Hits (and misses),” the authors critique of overly complicated projects made me question how often creators mistake complexity for creativity. I found his idea that “the simpler interaction is the more meaningful one” especially relatable. It reminded me of minimalist interactive artworks like Rafael Lozano-Hemmer’s Pulse Room, where a simple heartbeat sensor becomes a profound collective experience. The authors argument made me reflect on my own tendency to prioritize aesthetic or technical sophistication over intuitive engagement from the audience.

In “Making Interactive Art: Set the Stage, Then Shut Up,” his metaphor of the artist as a stage-setter really reframed how I think about authorship. I used to believe that creators should guide the audience toward a specific emotional reaction, but this readings insistence on letting the user finish the work through participation challenged that assumption. It raises the question: where does authorship end in interactive media? Is the true art in the design, or in the unpredictability of human interaction?

Both readings pushed me to see interactivity as a dialogue rather than a display. They align with theories I’ve encountered in my Interactive Media classes, especially discussions around user agency and co-creation. Ultimately, The authors perspective helped me realize that successful interactive work doesn’t shout, it listens. These readings made me rethink what it actually means to design something interactive. I used to believe that making an interactive project meant using as much technology as possible to impress people. But the ideas these readings assert is that the simpler interaction is often the more meaningful one, which really clicked with me. It made me realize that interaction isn’t about showing off sensors or screens, it’s about designing moments that feel natural. I thought about projects I’ve made where the tech took over the experience, and how maybe, the more invisible it becomes, the more powerful the interaction actually is.

The balance between aesthetics and usefulness has always been a hot topic. My perspective on beauty and productivity is that if something does its job well, that is enough. I used to value productivity more than aesthetics. According to the reading, for a product to be truly beautiful, it “has to fulfill a useful function, work well, and be usable and understandable” (p. 7). I agree with this idea because if a product does not serve its intended purpose, it fails to justify its existence.

However, in reality, this is not always the case. Take Apple, for example. People love Apple products because they are well-designed and undeniably beautiful. Yet, in terms of productivity, they may not always be the most practical option. MacBooks, for instance, perform most of the functions that a laptop should, but they lack a USB port. While users can buy external hubs, many find it inconvenient and would prefer at least one built-in port. Despite this, people continue to buy MacBooks. The success of Apple’s stock market performance suggests that many consumers value aesthetics just as much as, or even more than, productivity.

The next reading, about the code that helped send people to the moon, reminded me of the importance of checking and rechecking every detail. It shows why it is essential to anticipate every possible error, even those that seem unlikely or unnecessary. Launching the P01 program midflight might have seemed like a situation that would never occur, but it did. If Lauren had not accounted for this scenario, the outcome for Jim Lovell and the mission could have been very different.

Attractive things Work Better

I’ve always noticed how looks can open doors. It’s something people like to call pretty privilege. In most industries, they prefer someone who has good looks. You see it everywhere at the airport check-in counter where the smiling, well-dressed staff makes you feel calm, or in a company that hires someone polished to sit at the front desk because, somehow, they represent the brand better.

We are naturally drawn to beauty, whether it’s a charming smile or a sleek phone screen. Companies know this; that’s why a tech gadget with a glowing logo or a car with smooth curves often sells better than a clunky but equally powerful competitor. Don Norman’s idea that “attractive things work better” isn’t just about vanity. it’s about psychology.

A MacBook isn’t the fastest laptop in the world, and yet when we open that smooth aluminum case and feel the satisfying click of the keys, we tend to believe it’s faster, smarter, and somehow more capable. The elegant design creates a sense of trust and delight that shapes how we experience the product. The beauty of it literally makes us think it works better.

Attractive design doesn’t just sell. It softens us. It makes us more patient with flaws, more forgiving of errors, and more willing to explore. That’s the secret power of beauty: it opens the door for better experiences.

Norman explains this beautifully in “Attractive Things Work Better.” He talks about how our emotions influence the way we interact with the world. When something looks good, it makes us feel good and when we feel good, we actually perform better. He even gives a simple example: imagine walking on a wooden plank that’s safely on the ground you’d stroll across without a second thought. But put that same plank high in the air, and suddenly, your fear takes over, your body stiffens, and it becomes ten times harder. The situation didn’t change; your feelings did.

That’s what happens with design too. When we see something beautiful like a teapot with elegant curves or a smartphone that feels right in our hands it puts us in a positive mood. We become more relaxed, more open, and surprisingly, even more creative. Norman calls this the power of positive affect. It’s why we forgive a beautiful product for small flaws but get frustrated quickly with an ugly one, even if it works just as well.

So when I think about “pretty privilege,” it’s not just about faces or appearances it’s about how beauty changes behavior. Attractive people, like attractive designs, create comfort and trust before a single word is spoken or a single button is pressed. And through this text, I feel like it helped me see that aesthetics aren’t shallow; they’re psychological. Beauty works because it changes us somehow.

Her Code Got Humans On The Moon — And Invented Software Itself

When I was in eighth grade, our school hosted a  movie event through a club called Global Female in STEM (Science Technology Engineering and Mathematics). They showed movie called “Hidden Figures” which is  the story of three brilliant African-American women, Katherine Johnson, Dorothy Vaughan, and Mary Jackson, whose work made NASA’s early space missions possible. I remember sitting there, completely mesmerized, realizing for the first time how many women had shaped history from behind the scenes, only to have their names forgotten.

Since that day, I’ve carried a quiet admiration, and maybe a little fire, for women in STEM who were never given the recognition they deserved. Now, as a Computer Science major myself, I’ve felt small moments of that same bias. Sometimes, it’s a look that says “are you sure you can do this?” It’s subtle, but it stings like being told you have to prove your worth twice before anyone believes it once.

That’s why reading about Margaret Hamilton hit differently and fill me up with pride. Here was a woman in the 1960s, leading a team at MIT, writing code that would land humans on the moon  all while raising her daughter.

The image of her bringing her little girl to the lab late at night felt so familiar. My mom, also a working mother in STEM, used to take me to her computer lab  when I used to be alone. Margaret’s story reminded me of my mother of every woman who’s ever juggled passion, work, and motherhood with quiet strength.

What moved me most was how Margaret didn’t just write code; she invented software engineering itself. She gave structure, respect, and permanence to something the world didn’t even consider a real science yet. And when her code saved the Apollo 11 mission, it wasn’t just a victory for NASA. It was proof that brilliance has no gender.

Reading her story filled me with pride. It made me realize that every time a woman like Margaret Hamilton, or my mother, or even I sit behind a computer and type, we’re not just writing code. We’re continuing a legacy.

Concept

When the screen closes, the light turns on.

I wanted to create a Moment of Tranquility generator. Usually, when we close our laptops, we are plunged into darkness (or at least, the dull reality of a messy desk). I wanted to invert that.

When the computer goes to sleep, the physical world should wake up.

Build

To make this work, I essentially turned my MacBook into an expensive switch, and then I hooked this makeshift switch up to an Arduino Uno and a 12-LED NeoPixel ring.

I used two strips of conductive copper tape:

1. Base: One strip taped to the palm rest of the laptop (connected to the Arduino’s 5V power).
2. Lid: One strip taped to the top bezel of the screen (connected to NeoPixel power input).

The logic is the opposite of a fridge light. When the laptop is open (in use), the circuit is broken (Open). When I fold the laptop shut, the two pieces of copper tape make contact, closing the circuit.

The Code

For the lighting effects, I utilized the standard Adafruit NeoPixel library. A full range of colors and patterns would show to represent the return of creativity after a day of monotonous spreadsheets.

Here is the code I used to drive the ring:

#include <Adafruit_NeoPixel.h>
#ifdef __AVR__
  #include <avr/power.h>
#endif

#define PIN 6

// Parameter 1 = number of pixels in strip
// Parameter 2 = Arduino pin number (most are valid)
// Parameter 3 = pixel type flags, add together as needed:
//   NEO_KHZ800  800 KHz bitstream (most NeoPixel products w/WS2812 LEDs)
//   NEO_KHZ400  400 KHz (classic 'v1' (not v2) FLORA pixels, WS2811 drivers)
//   NEO_GRB     Pixels are wired for GRB bitstream (most NeoPixel products)
//   NEO_RGB     Pixels are wired for RGB bitstream (v1 FLORA pixels, not v2)
//   NEO_RGBW    Pixels are wired for RGBW bitstream (NeoPixel RGBW products)
Adafruit_NeoPixel strip = Adafruit_NeoPixel(12, PIN, NEO_GRB + NEO_KHZ800);

// IMPORTANT: To reduce NeoPixel burnout risk, add 1000 uF capacitor across
// pixel power leads, add 300 - 500 Ohm resistor on first pixel's data input
// and minimize distance between Arduino and first pixel.  Avoid connecting
// on a live circuit...if you must, connect GND first.

void setup() {
  // This is for Trinket 5V 16MHz, you can remove these three lines if you are not using a Trinket
  #if defined (__AVR_ATtiny85__)
    if (F_CPU == 16000000) clock_prescale_set(clock_div_1);
  #endif
  // End of trinket special code

  strip.begin();
  strip.setBrightness(50);
  strip.show(); // Initialize all pixels to 'off'
}

void loop() {
  // Some example procedures showing how to display to the pixels:
  colorWipe(strip.Color(255, 0, 0), 50); // Red
  colorWipe(strip.Color(0, 255, 0), 50); // Green
  colorWipe(strip.Color(0, 0, 255), 50); // Blue
//colorWipe(strip.Color(0, 0, 0, 255), 50); // White RGBW
  // Send a theater pixel chase in...
  theaterChase(strip.Color(127, 127, 127), 50); // White
  theaterChase(strip.Color(127, 0, 0), 50); // Red
  theaterChase(strip.Color(0, 0, 127), 50); // Blue

  rainbow(20);
  rainbowCycle(20);
  theaterChaseRainbow(50);
}

// Fill the dots one after the other with a color
void colorWipe(uint32_t c, uint8_t wait) {
  for(uint16_t i=0; i<strip.numPixels(); i++) {
    strip.setPixelColor(i, c);
    strip.show();
    delay(wait);
  }
}

void rainbow(uint8_t wait) {
  uint16_t i, j;

  for(j=0; j<256; j++) {
    for(i=0; i<strip.numPixels(); i++) {
      strip.setPixelColor(i, Wheel((i+j) & 255));
    }
    strip.show();
    delay(wait);
  }
}

// Slightly different, this makes the rainbow equally distributed throughout
void rainbowCycle(uint8_t wait) {
  uint16_t i, j;

  for(j=0; j<256*5; j++) { // 5 cycles of all colors on wheel
    for(i=0; i< strip.numPixels(); i++) {
      strip.setPixelColor(i, Wheel(((i * 256 / strip.numPixels()) + j) & 255));
    }
    strip.show();
    delay(wait);
  }
}

//Theatre-style crawling lights.
void theaterChase(uint32_t c, uint8_t wait) {
  for (int j=0; j<10; j++) {  //do 10 cycles of chasing
    for (int q=0; q < 3; q++) {
      for (uint16_t i=0; i < strip.numPixels(); i=i+3) {
        strip.setPixelColor(i+q, c);    //turn every third pixel on
      }
      strip.show();

      delay(wait);

      for (uint16_t i=0; i < strip.numPixels(); i=i+3) {
        strip.setPixelColor(i+q, 0);        //turn every third pixel off
      }
    }
  }
}

//Theatre-style crawling lights with rainbow effect
void theaterChaseRainbow(uint8_t wait) {
  for (int j=0; j < 256; j++) {     // cycle all 256 colors in the wheel
    for (int q=0; q < 3; q++) {
      for (uint16_t i=0; i < strip.numPixels(); i=i+3) {
        strip.setPixelColor(i+q, Wheel( (i+j) % 255));    //turn every third pixel on
      }
      strip.show();

      delay(wait);

      for (uint16_t i=0; i < strip.numPixels(); i=i+3) {
        strip.setPixelColor(i+q, 0);        //turn every third pixel off
      }
    }
  }
}

// Input a value 0 to 255 to get a color value.
// The colours are a transition r - g - b - back to r.
uint32_t Wheel(byte WheelPos) {
  WheelPos = 255 - WheelPos;
  if(WheelPos < 85) {
    return strip.Color(255 - WheelPos * 3, 0, WheelPos * 3);
  }
  if(WheelPos < 170) {
    WheelPos -= 85;
    return strip.Color(0, WheelPos * 3, 255 - WheelPos * 3);
  }
  WheelPos -= 170;
  return strip.Color(WheelPos * 3, 255 - WheelPos * 3, 0);
}

Reflection

The interaction was surprisingly satisfying, given it’s an extremely simple one… Usually, closing a laptop signifies an ending. But with this setup, the “ending” of work immediately triggers a new “beginning” of ambient light.

The biggest challenge was wire management. You don’t generally want loose wires hanging off your expensive computer! However, as a POC it was a success. It forces a moment of pause, allowing me to sit back and watch the lights rather than doom-scrolling on the next available screen.

Norman’s ideas highlight that aesthetics are not just surface decoration but a way for design to work with the human mind rather than against it. When something looks and feels good to use, our brains relax into a more open, imaginative mode. We stop fighting the interface and start exploring through it. This isn’t about luxury or indulgence. It’s about survival in a world full of cognitive overload. A beautiful interface lowers emotional friction, it turns stress into curiosity. Even something as small as the choice of a teapot, depending on mood, shows how design can become a companion to our emotional state. Good design doesn’t simply function well It cares for the user’s attention, focus, and resilience, allowing “pleasure” to become a quiet form of intelligence.

Margaret’s “software engineering” wasn’t only about logic and precision, but it was about understanding the unpredictable human behind the code. When Hamilton built systems that could recover from error, she was acknowledging fear as real variables in the machine. She designed not for perfection but for forgiveness. The Apollo guidance software’s ability to prioritize critical tasks during overload was, at its core, a kind of empathy written in code. It recognized that even astronauts under pressure could make mistakes, and that the system should protect rather than punish them. Hamilton’s foresight turned technical design into an act of emotional intelligence, embedding trust and calm into the most high-stakes environment imaginable.

Norman and Hamilton sketch a fuller philosophy of design, one that sees beauty and reliability, emotion and logic, not as opposites but as collaborators. Norman’s teapot and Hamilton’s Apollo code both remind us that good design anticipates human vulnerability and builds grace into its response. Whether the context is a kitchen or a lunar landing, the designer’s role is to create conditions where people can think clearly, act confidently, and recover gently from error. The aesthetic and the algorithm share the same goal: to make complexity humane.

Reading Norman’s Emotion & Design and Her Code Got Humans on the Moon made me rethink what we usually praise in tech. Norman’s main idea that “attractive things work better” makes sense at first. If a product is enjoyable to use, we’re more likely to stick with it. But honestly, it feels a bit too neat. Just because something looks good doesn’t mean it works well. I’ve had plenty of apps or gadgets that are gorgeous but a pain to actually use. Norman makes a strong point about emotion shaping usability, but sometimes I feel designers lean on aesthetics as a crutch instead of solving real problems.

On the other hand, Her Code Got Humans on the Moon reminded me that behind every “perfect” design or software is a ton of human effort — in this case, women programmers whose work literally made moon landings possible. It’s wild how long their contributions were invisible. It makes me question why we hype technology itself while ignoring the people who make it run. The “heroic inventor” story Norman sometimes leans on in design discussions seems incomplete — we rarely celebrate the actual humans doing the work.

Putting these together, I think the readings challenge the usual tech narrative. Norman focuses on emotion and aesthetics, which are important, but Her Code highlights that real success comes from skill, persistence, and problem-solving. My takeaway? Great design isn’t just about looking or feeling good — it’s also about respecting and acknowledging the humans who make it work. Otherwise, we’re praising the wrong things and missing the bigger picture.

 

Attractive Things Work Better

I found this reading surprisingly relatable (although initially with the 3 teapots, I was a little confused). Norman’s main point that beauty and usability aren’t opposites and that they can co-exist, really made me rethink how I view design. He talks about how our emotions directly affect how we perform tasks. For example, negative affect (like anxiety) actually focuses the mind, which I never thought about before. I used to assume all anxiety was bad, but Norman explains that in situations where quick focus is needed, like immediate problem-solving, that stress can actually help.

What also stood out to me was the idea that people are more forgiving of poor design when they’re in a positive mood. I’ve totally felt that. When I’m calm, I barely notice small glitches on Brightspace, but when I’m stressed,  like submitting an assignment at the last minute, the same delay feels ten times longer and way more frustrating.

I liked his reflection about beauty too, especially the part about how true beauty isn’t just surface-level. A product can look good, but to be truly beautiful, it has to work well and make sense to use. That reminded me of how we say “beauty is in the character” for people; Norman’s basically saying that the same applies to design. Beauty in products has to go deeper than aesthetics, it has to come from function, usability, and how it makes us feel.

Overall, this reading made me realize that emotion is not a distraction in design, it’s actually a tool. How we feel shapes how we interact, and that’s something I’ll keep in mind whenever I evaluate or create something from now on.

Her Code Got Humans On The Moon — And Invented Software Itself

I really enjoyed this reading, especially the part where the author points out that one of the “founding fathers” of software was actually a mother. I thought that was both funny and powerful. It highlights how Margaret Hamilton broke stereotypes in a field that was (and still is) dominated by men. The story captured how she managed to fit into that environment, joking around with her colleagues and saying she was “one of the guys”,  but also how she stood out because of her intelligence and persistence. What struck me most was how her higher-ups ignored her idea for error checking, insisting astronauts were “too well-trained to make mistakes.” It reminded me of a previous reading where we discussed how engineers often think so logically that they expect others to be perfect, almost machine-like. But humans aren’t machines, and Hamilton proved that. When an astronaut actually made the very mistake she had warned about, it became her “I told you so” moment,  except it came with nine hours of problem-solving that could’ve been avoided.

As a computer science major, I found it fascinating that error checking wasn’t considered intuitive back then. Today, we’re taught to expect mistakes and build systems that can handle them, but that mindset didn’t exist yet. Hamilton’s work showed that great engineering isn’t just about logic, it’s about anticipating imperfection, because humans are imperfect anyways.