Concept

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

Mechanism

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

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

Link to video demonstration

Schematic Diagram

Code highlight

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

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

 

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

Use Cases:

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

Further Enhancement

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

Conclusion

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

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

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

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

What links Donald Norman’s “Emotion and Design” and Robert McMillan’s profile of Margaret Hamilton is that both quietly insist on humanizing it, instead of just dealing with design . Norman’s argument that beautiful design makes people feel more in control is not just about colors or curves. It’s about the psychology of trust. He claims that people “perform better when they feel better,” suggesting that aesthetics aren’t superficial, but functional. I find this somewhat persuasive, but also a little idealistic. There’s truth to it, I do feel calmer using Notion than some clunky university portal, but sometimes “pretty” products mask poor usability. Attractive things may appear to work better, but that illusion can also hide deeper flaws. Still, Norman’s point stands: emotion isn’t a side effect of design rather it’s part of the system itself.

Reading “Her Code Got Humans on the Moon” right after feels like the necessary reality check. Margaret Hamilton’s code didn’t have the luxury of being “attractive,” it just had to not crash on the Moon. Yet what she achieved was, in its own way, a kind of beauty: the beauty of precision, foresight, and calm under cosmic pressure. Her work (from inventing the concept of “software engineering” to preventing the Apollo 11 disaster) captures design stripped to its core: solving human problems with clarity and empathy. I love how she described her philosophy as “preparing for the unexpected.” That’s the emotional intelligence of a designer without ever calling it that

If Norman celebrates how design makes us feel, Hamilton reminds us what design must do: sustain life when it matters. My takeaway is that emotion in design isn’t always about pleasure; sometimes it’s about responsibility. The most beautiful designs are the ones that don’t panic when everything else does.

Concept

Hogwarts Experience is an interactive web experience inspired by the whimsical world of Hogwarts.
It blends a classic sorting quiz, a maze challenge, and wand selection into one compact game built entirely in JavaScript (using p5.js).

The idea was to explore how storytelling, visuals, and interactivity could merge to create something that feels alive; something more than just a quiz or a mini-game.

Inspiration

From my fascination of JK Rowling’s use of symbols (a hat, a house, wand) in Harry Potter explores identity and choice. I wanted to capture that feeling of “who am I?” in a lightweight browser experience.

Technically, this project was also a personal experiment:
how far can I go with only vanilla p5.js, with minimal frameworks and assets, what be drawn or generated?

Visual Elements

The visuals are all hand-coded with p5.js shapes and color palettes chosen to reflect the four houses:

• Gryffindor: warm reds and golds, courage in motion
• Ravenclaw: deep blues and calm precision
• Hufflepuff: mellow yellows and earthy tones
• Slytherin: sleek greens and silvers, a hint of ambition

[I got the color codes from codepen.io]

The wand selection features small glowing particle bursts when you find your correct match, a simplified particle system I built directly into the Wand class.
It’s minimal but expressive: circles of light that rise and fade like sparks from Ollivander’s wand shop.

Interaction & Controls

• The quiz is fully clickable — each answer dynamically updates your house “weight.”
• Once sorted, you navigate a small maze using arrow keys (or WASD).
• You can activate your house ability with a single keypress (spacebar).
• The wand test responds to clicks, showing visual feedback for correct or incorrect matches.

Each stage was designed to feel self-contained but connected, a simple rhythm of choice, discovery, and action.

Sound Design

Sound is subtle but intentional.
A soft background theme plays during the game, punctuated by short cues:

• a shimmer when your wand responds,
• a gentle whoosh for movement,
• a celebratory chime when you win,
• and scary dementor sound when you fail to exit the maze.

All sound events are managed with a simple sound registry that starts, stops, and restarts based on player state. I tried to get rid of any overlaps or chaos. I wanted it to add atmosphere without overwhelming the visuals.

Code Architecture

The game is built around a few modular classes:

• Question → handles quiz text, answers, and house mapping
• Player → manages movement, collision, and ability us
• Enemy → manages the enemies in the maze
• Wand → merges wand logic and particle effects for magical feedback
• GameManager (lightweight) → controls flow between quiz, wand test, and maze

Each class does one job well.
The code favors clarity over complexity; the division into classes make it readable, flexible, and easily expandable.

Code Snippet to Highlight

test() {
    if (this.isCorrect) {
        this.glowing = true;
        for (let i = 0; i < 20; i++) {
            this.particles.push({
                x: this.x,
                y: this.y,
                vx: random(-3, 3),
                vy: random(-5, -1),
                life: 60,
                success: true
            });
        }
        return true;
    } else {
        for (let i = 0; i < 10; i++) {
            this.particles.push({
                x: this.x,
                y: this.y,
                vx: random(-3, 3),
                vy: random(-5, -1),
                life: 60,
                success: false
            });
        }
        return false;
    }
}

It’s small, but it brings the world to life, literally adding a sparkle of magic when you choose correctly.

Future Additions

• Better sprites & art direction: hand-drawn assets for characters, wands, and the maze walls
• Fullscreen adaptive display: scaling visuals gracefully across devices
• House competition system: each player’s score stored via browser cookies or localStorage, allowing a shared “House Points” leaderboard
• Integration with ml5.js: experimenting with emotion or gesture recognition to let your facial expression or hand movement influence sorting outcomes

Each of these is a small step toward a more responsive, immersive experience,  a bit closer to real enchantment.

Concept

For my midterm project, I’m building an interactive Hogwarts experience. The player starts by answering sorting questions that place them into one of the four houses. Then they get to choose a wand and receive visual feedback to see which wand truly belongs to them. After that, the player will enter their house’s common room and either explore various components in the room or play a minigame to earn points for their house.

The main idea is to capture the spirit and philosophy of each Hogwarts house and reflect it in the minigames, so the experience feels meaningful and immersive. Instead of just random games, each minigame will be inspired by the core traits of Gryffindor, Hufflepuff, Ravenclaw, or Slytherin.

Design

I want the project to feel smooth and interactive, with a focus on simple controls mostly through mouse clicks. Each stage (from sorting, to wand choosing, to the common room minigames) will have clear visual cues and feedback so the player always knows what to do next.

For the minigames, I’m aiming for gameplay that’s easy to pick up but still fun, and thematically tied to the house’s values. The design will mostly use basic shapes and animations in p5.js to keep things manageable and visually clean.

Challenging Aspect

The part I’m still figuring out and find the most challenging is designing minigames that really match each house’s philosophy but are also simple enough for me to implement within the project timeline. It’s tricky to balance meaningful gameplay with code complexity, especially because I already have a lot of different systems working together.

Risk Prevention

To manage this risk, I’ve been brainstorming minigames that are easy to build, like simple clicking games for Gryffindor’s bravery or Memory games for Ravenclaw, while still feeling connected to the houses’ themes. I’m focusing on minimal input and straightforward visuals so I can finish them reliably without overwhelming the code.

What I enjoyed most in this piece is how it drags computer vision down from the pedestal of labs and military contracts into something artists and students can actually play with. The examples, from Krueger’s Videoplace to Levin’s own Messa di Voce, remind me that vision doesn’t have to mean surveillance or soulless AI pipelines. It can also mean goofy games, poetic visuals, or even awkward belt installations that literally stare back at you. I like this take, it makes technology feel less like a monolith and more like clay you can mold.

That said, I found the constant optimism about “anyone can code this with simple techniques” a little misleading. Sure, frame differencing and thresholding sound easy enough, but anyone who’s actually tried live video input knows it’s messy. Lighting ruins everything, lag creeps in, and suddenly the elegant vision algorithm thinks a chair is a person. The text does mention physical optimization tricks (infrared, backlighting, costumes), but it still downplays just how finicky the practice is. In other words, the dream of democratizing vision is exciting, but the reality is still a lot of duct tape and swearing at webcams.

What I take away is the sense that computer vision isn’t really about teaching machines to “see.” It’s about choosing what we want them to notice and what we conveniently ignore. A suicide detection box on the Golden Gate Bridge makes one statement; a silly limbo game makes another. Both rely on the same basic tools, but the meaning comes from what artists decide to track and why. For me, that’s the critical point: computer vision is less about pixels and algorithms and more about the values baked into what we make visible.

Concept

For this exercise, I wanted to merge two things: playful interactivity and meaningful (well almost) outcome. I came up with this Tetris-like game where instead of geometric blocks, words fall from the sky. Players can move these word blocks left or right with arrow keys to stack them into bizarre sentences or whatever they like.

The sentences hardly make sense; in fact, the randomness of the generated words is something that makes the results funny. This can be perceived as a silly project but it’s fun. Stack words – make nonsense – laugh.

Inspiration

The inspiration came from two souces:

1. Tetris game
2. Text Rain (by Camille Utterback, where letters fall and interact with the human body)

I wanted to combine the two ideas intro something playful but also generative, where the player becomes either a poet or a chaotic builder (or both) depending on the words that randomly fall and where they place them.

Code Structure

Here is the list of things I implemented this with:

• Array of words (tried to include nouns, verbs, adjectives, adverbs, connectors; however, this can be modified for the code meaning user can use any array of any words they like)
• fallingWord object that moves down the grid
• blocks array to store all placed word, and collision detection so blocks stack on top of each other or store at the floor.
• Keyboard controls to move words left and right within the canvas
• A small function to resize text dynamically. This was done keeping in mind that is user wants longer words in the array and they will be able to do so as the font size will be adjusted as needed.

Every new word is randomly chosen from the array, dropped from the top, and the loop continues.

Reflection

I liked how this project was fairly simple yet becomes engaging once the player is allowed to have some control. This is a result of both randomness (of the word array) and control (the stacking mechanism).

Challenges:

• Making sure words didn’t move out of canvas. I tried to put this condition in the same one as if keyPressed but that wasn’t to work. It turned out I have to create a nested condition to implement this.
• Handling long words that wouldn’t fit in the blocks. I thought whether to allocate more than 1 blocks for long words, but i realized that adjusting the font size is much convenient.

Future Improvements

• Add scoring system: If a player completes a sentence, they get a point. This requires the rules of grammar and is too difficult for me at present.
• Make the termination case: for now, I didn’t instruct the code what to do when the canvas is full. I think this is necessary for a game, but mine isn’t yet.

Reading Norman’s The Psychology of Everyday Things made me notice how often bad designs are excused focusing on the supposed incompetence of the users. For instance, his discussion of Norman Doors was something I could absolutely relate because on multiple occasions, I personally have pushed the wrong side of a glass door only to feel clumsy and inobservant even though, as he points out, the real failure is in the design and not the user (me). That shift, blaming the design instead of the user, was oddly liberating. It reminded me that designs should communicate clearly and if I can’t figure out, the system image is broken. I started thinking about my own sketches for the weekly productions in p5: sometimes when I code and interaction, I get worried that people may not use it ‘the right way.’ But Norman’s text made me realize that I am responsible for building the right signifiers, the visual or behavioral cues that make the action discoverable.

Another part that stuck with me was Norman’s point that designers often create for how they wish people behave, and not how they realistically behave. This discrepancy, I realized, is the reason behind a lot of products failing to flourish as much as they were projected to. I found myself guilty of the same, to be frank; I oftentimes assume people will read the readme.md file or be patient enough to try different keys until something interesting happens. But in reality, users tend much more to attain instant feedback/gratification from an interactive device in this age of technology. It is far beyond ambitious to expect users to get a PhD on my product before they put their hands on that.

Norman’s framework of affordances, signifiers, mapping, and feedback gave me a checklist (literally like a cheat code) that I can use in my projects. I will ask myself upon drafting the project whether it:

• shows what’s possible through the interface
• maps actions to outcomes naturally
• provides a meaningful/satisfying feedback

I want to reimagine some of the (slightly) interactive sketches keeping Norman’s (very reasonable) propositions and later compare them with their counterparts to visualize the narrative I have already subscribed to.

For me, a strongly interactive system is one that goes beyond just reacting. Crawford’s point about how books, movies, or even a refrigerator light don’t really “interact” stuck with me; true interactivity for me now, means both sides listen, think, and respond. It isn’t enough for a system to grab attention or look slick; it has to feel like a conversation. That’s why I think of interactivity less as a switch (on/off) and more as a spectrum. The strongest systems respect the user: they acknowledge input in meaningful ways, they adapt, and they make the user feel like their actions actually matter.

When I think about my own p5 sketches, I realize they often stop at reaction. They respond to a click or a key press but don’t really “listen” deeply. To push them toward stronger interactivity, I could design them to recognize patterns in user input, remember past actions, or even surprise the user with responses that aren’t strictly predictable (sort of something we did for the production in week 2; baby steps but still). For example, instead of a sketch where shapes simply follow the mouse, I could create one where the system builds a visual “memory” of how the user has drawn before and adapts its behavior over time. Though that sounds ambitious, it would turn it from a basic reaction into more of a dialogue.

Ultimately, I think the goal is to make my sketches less like a refrigerator light and more like a partner in conversation. The best interactive systems respect the user’s role, and if my work in p5js can manage to give users that sense of being heard, then I’ll know I’m moving in the right direction.