Month: March 2026

A paragraph that stood out to me in the reading on Margaret Hamilton was the one discussing how programmers used to write, run, and test code. Nowadays, we simply use a text editor to write code, compile it, and run it in a matter of seconds. Back then, however, code had to be punched into paper cards, fed into a machine to be compiled and run, which could take hours, and then, to insert the code into the spaceship, wires had to be hand-woven through rings. This made me reflect on how far the software industry has advanced since then.

As a current computer science student, I cannot imagine how difficult my university experience would have been if I were a student in the 1960s. Today, I can easily make changes to my code and test them immediately, which allows me to focus on efficiency, functionality, and aesthetics. Reflecting on the second reading about how attractive things work better, I imagine that in the 1960s, since code was much more difficult to develop, software engineers likely had to prioritize functionality over aesthetics. If they had to prioritize both, it would have made their work even more challenging than it already was.

Additionally, a large part of making software aesthetically pleasing involves constantly editing and testing the placement and design of elements such as buttons and images. Adjusting even a single button can require hundreds of recompilations and test runs. This process would have been extremely difficult in the 1960s, when every small change required going through the entire process of punching holes into cards, feeding them into a machine, and waiting hours for results.

The software industry is constantly evolving and improving. More recently, we have seen groundbreaking advancements in generative AI, which can assist in developing and running code. Many software engineers now use AI to address the challenge Don Norman discusses in “Attractive Things Work Better.” By using AI to help build the front end, they can shift more of their focus toward the functionality and theoretical aspects of software. This also speeds up the development process by providing a visual starting point.

I really enjoyed reading Norman’s text, especially his idea that things that look pleasing actually work better, are easier to learn, and lead to a better result. That idea really stuck with me, because I also noticed this in my own habits. When my space is messy or cluttered, I can’t focus well, so I usually clean up first and make everything feel more comfortable. Once things look better, I feel more organized and a lot more productive. It becomes easier for me to work, think clearly, and learn better when I’m studying. I also liked how he talked about how a design needs to match its purpose rather than just looking good. In more serious or stressful situations, design should not be too complicated because it can slow someone down or get in the way, making things harder and disrupting their progress.

McMillan’s story about Margaret Hamilton and the Apollo mission connects to Norman’s text in a different but just as meaningful way. Her work showed how important it is to think ahead and build systems that actually help people. The software she worked on wasn’t just meant to function. It was thoughtfully designed to handle mistakes and still keep everything running smoothly, even when things didn’t go as planned. After reading both of the texts, I realized that good design isn’t just about how something looks. It’s also about how well it works and how efficient it is for people in different situations. Whether it’s something small like fixing my space or something much bigger, what really matters is understanding people’s needs and being thoughtful about what will help them succeed.

Play in full screen :  https://jamayccaaa.github.io/Midterm_IntroToIM-Moreno/

CONCEPT

While thinking about a concept for this project, I initially wanted to create something like a puzzle game with character movement. I explored multiple ideas before deciding on this one, mainly because it felt more doable while still being engaging. I chose to go with a chill vibe because I wanted the game to be child-friendly, something players can easily understand, explore, and enjoy. The interface is designed in a way that encourages players to read and follow the instructions first. Without doing so, they could lose the game right away or even win without fully understanding how.

The main goal of the game is to hang exactly 10 pieces of clothing on a clothesline before the 1 minute is up, without exceeding the line’s strict weight limit of 2000 grams. Each piece of clothing has a different weight. Hoodies weigh 400 grams, pants weigh 300 grams, shirts weigh 200 grams, and shorts weigh 100 grams. Players will not know in advance which item they will get from the laundry basket, which adds unpredictability and requires careful decision-making. If they are unsure, they can temporarily place a piece of clothing in the “for later” basket. However, this basket can only hold up to 6 items, and exceeding that limit will also result in a loss.

HOW THE PROJECT WORKS AND WHAT PARTS I’M PROUD OF

The project works by placing the player in a timed game where their decision-making is challenged. They must select and hang pieces of clothing while managing both a strict weight limit and limited storage. The player should interact with the items from a laundry basket and decide whether to hang them on the clothesline or save them for later. In order to win, the player must hang exactly 10 pieces of clothing before the timer runs out, without exceeding the clothesline’s maximum capacity. Going beyond the limit will cause the line to snap, resulting in a loss.

Even though some parts of my original concept did not go as planned, I am still proud of how the game turned out. The part I am most proud of is the dragging mechanic, especially how the clothes snap and stick onto the clothesline. This took a lot of trial and error, and I spent a lot of time experimenting, searching for tutorials, and studying sample codes to make it work properly. It was challenging but also one of the most interesting parts of the process. I am also proud of the overall visual design of the game. I worked on everything using Canva, p5.js, and VS Code, and I like how the final output looks polished. Seeing all the elements come together after all the revisions made the process feel worth it.

PROBLEMS AND IMPROVEMENTS

One of the main ideas I originally wanted to include was a character holding the basket, along with a rain feature that would appear halfway through the game. The plan was for it to start raining after 40 seconds, requiring the player to control the character and move to a shaded area. The rain would also increase the weight of both the clothes and the clothesline, adding another layer of challenge. However, due to time constraints, I was not able to do this feature. Instead, I adjusted the game by shortening the timer and lowering the clothesline capacity to maintain a level of difficulty. If I were given more time, I would like to revisit this idea and add more challenges to make the game more engaging and competitive, as I do believe that there is a lot to improve to make the game better.

Another challenge I faced was designing the “for later” basket. My initial idea was to have the clothes disappear into the basket while still keeping track of how many items were stored. However, this required more complex logic than I expected, and I had to spend additional time researching and looking for tutorials. To manage my time better, I decided to simplify the feature. Instead of hiding the items, I made the clothes stack visibly on top of the basket. If the stack reaches more than 6 items, the player immediately loses the game. I think this solution still communicates the rule clearly and reinforces the importance of following the instructions.

REFERENCES

Tutorials:

https://www.youtube.com/watch?v=h8dHw1-WbAY – timer tutorial

https://www.youtube.com/watch?v=4fWStxYepE0 – drag and snap tutorial

https://www.youtube.com/watch?v=YcezEwOXun4&list=PLRqwX-V7Uu6aFcVjlDAkkGIixw70s7jpW&index=2 – sound explanation

https://www.youtube.com/watch?v=7A5tKW9HGoM – mouseX, mouseY explanation

Other References:

https://ko-fi.com/s/b7b1607f14 – Where I got the music

https://p5js.org/reference/ 

Class Slides & Past Classworks

USAGE OF AI

A. ClothesLine – Together with the Drag and Snap tutorial by Rob Duarte, I initially had a hard time figuring out how to properly place the clothesline and make the clothes snap to it horizontally, since the snapping in the tutorial was different. To solve this, I asked ChatGPT for help in creating fixed “slots” where each clothing item can align, giving the visual of the clothes being snapped onto the clothesline.

What I understood from the code is that instead of relying on the clothesline image, I needed to set exact positions in the code. So I created an array to store these positions and set a starting point (startX) along with a fixed y value so everything stays in one horizontal line. The code also includes a loop that creates multiple slots across the clothesline, with equal spacing so they form a straight line from left to right. With this, each clothing item can detect and snap to the nearest slot, making the placement look more organized instead of in random places.

clothesLine = []; //clothes array


 let startX = width / 2 - 200; // where the clothesline snap starts
 let y = height/ 2;
 let maxSlots = 10; // 10 clothes only on the line
 let spacing = 60;


 for (let i = 0; i < 10; i++) { // 10 slots in the clothes line
 clothesLine.push(createVector(startX + i * 80, y));
}

For the snapping part, I also asked ChatGPT for help in figuring out how to compute which part of the clothesline the clothing should snap to. From the code, I understood that it first checks which slot is closest to the clothing by looping through all the points in the clothesLine array and measuring the distance. It keeps track of the nearest one by comparing the distances.

Then, it checks if the clothing is within the snap range. If it is close, the code counts how many clothes are already placed on the line to make sure it doesn’t exceed the limit. Once there’s space, it positions the clothing based on the next available slot using consistent spacing, while also adjusting the y position so it sits properly on the line. If the clothing is too far, it doesn’t snap and just stays where it is. This helped me understand how snapping works more clearly, especially how distance and positioning are used.

//finding the closest point on the line
   let closest = null;
   let minDist = 9999;

   for (let p of clothesLine) {
     let d = dist(c.x, c.y, p.x, p.y);

     if (d < minDist) {
       minDist = d;
       closest = p;
     }
   }

   // if the clothes are close, it will snap onto the clothesline
   if (minDist < 80) {

     // count how many are already placed
     let placed = game.clothes.filter(cl => cl.onLine).length;

     if (!c.onLine && placed < maxSlots) {

       let startX = clothesLine[0].x;
       c.x = startX + placed * spacing;
       c.y = closest.y - c.size / 2;

       c.onLine = true;
     }

   } else {
     c.onLine = false;
   }

B. Fixing errors and debugging – For checking errors and debugging, I used ChatGPT when my code started getting too long and I couldn’t figure out which part was causing the game to break. When I transferred everything to Visual Studio Code, it took me a while to identify what was not working because I was more used to p5.js, where errors are shown more directly. In VS Code, I had to rely more on the console, which I wasn’t as familiar with.

Because of that, I asked ChatGPT to help check my code and explain the errors in the console whenever I didn’t understand them. It also helped point out possible causes of the issue, which made it easier for me to track down what was breaking the game and fix it step by step.

C. Game Idea – For the game idea, ChatGPT helped me both in completing and brainstorming the concept. It suggested different ideas, and as I continued developing the game and adding my own, it also guided me on what was possible to implement. It helped me think through important parts like the winning and losing conditions, which made the overall design clearer and more structured.

The Margaret Hamilton reading honestly made me think about how often people say “that would never happen” just because it’s easier than actually dealing with the possibility that it might. Like the people around her weren’t necessarily careless, but they were comfortable, and that comfort made them dismiss things that didn’t fit their expectations. What I liked about Hamilton is that she didn’t rely on that kind of thinking at all, she kept imagining worst-case scenarios even when no one else wanted to. When she talks about picturing “headlines in the newspapers… and it would point back to me,” it didn’t feel dramatic, it just felt like she understood responsibility in a very real way. It made me realize that being “good” at something isn’t just about skill, it’s also about how seriously you take the possibility of things going wrong. And I feel like we don’t really do that anymore, we trust things like apps and technology without thinking about what’s behind them or who had to sit there and think through all the ways things that could fail.

The Norman reading felt a bit weird to me at first because his whole idea that “attractive things work better” sounded almost too simple, like something you’d see on a Pinterest quote or something, but then the more I thought about it, the more I realized he’s not really talking about the object itself, but about us and how easily we’re affected by how something looks or feels. The part that actually stuck with me was when he says we “overlook design faults” when we’re in a positive emotional state because that just felt very true in an uncomfortable way. Like if something looks nice or feels smooth, we’re way less likely to question it, even if it’s not actually working properly. And that kind of made me disagree with him a little, because it’s not just that beauty helps, it also kind of distracts. It made me think about how often we trust things just because they look polished, and we don’t even realize we’re doing it.

When I put both readings together, they didn’t feel like they were saying the same thing at all, but they still connected in a weird way. Hamilton is so focused on not overlooking anything, even the smallest possible mistake, while Norman is basically saying that we, as people, do overlook things all the time, especially when something feels good or looks nice. And I think that difference between the two readings is what made this interesting for me, and at the same time created that connection in my head of the bigger picture of both readings.

Arduino file on GitHub

Arduino Set-up:

Arduino Illustration:

Project Demo:

IMG_9952

Concept

For this project, I wanted to create a switch that isn’t like a traditional button. Instead of pressing something with my fingers, I used my body as the interaction. I ended up designing a switch using my elbow.

The idea is simple. I placed two pieces of aluminum foil on both sides of my inner elbow. One piece is connected to pin 5, and the other is connected to ground. When my arm is straight, the two pieces of foil don’t touch, so the circuit is open and the LED stays off. When I bend my arm, the skin folds slightly and the two pieces of foil press together, turning the LED on.

Code Snippet I’m Proud Of

const int switchPin = 5;

void setup() {
  pinMode(switchPin, INPUT_PULLUP);
  pinMode(LED_BUILTIN, OUTPUT);
}

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

  if (state == LOW) {
    digitalWrite(LED_BUILTIN, HIGH);
  } else {
    digitalWrite(LED_BUILTIN, LOW);
  }
}

This part looks simple, but it took me a while to understand why it works. Using INPUT_PULLUP was the key because it keeps the input stable when nothing is touching it and flips to LOW when the foil is touched, connecting the pin to ground. Once I understood that LOW actually means pressed, everything started to make sense to me.

Problems Encountered

The biggest issue I had was that the LED kept blinking randomly, even when I wasn’t touching anything. At first, I thought my wiring was wrong, but the problem was actually the input pin floating. Without INPUT_PULLUP, the Arduino couldn’t decide whether the input was HIGH or LOW, so it kept switching between them.

Another problem was the foil itself. I initially wrapped the foil around the wires, which caused constant and unstable connections. This made the LED either stay on or flicker all the time. I had to learn to keep the foil flat and only tape the wire at one edge.

I also got confused by the lights on the board. I kept looking at the green power light instead of the LED connected to pin 13, which made debugging way harder than it needed to be.

Reflection

This project was definitely frustrating at first, but it helped me understand how circuits actually work. Before this, I didn’t fully understand how important small details are, like which row you use on a breadboard or how stable a connection needs to be.

If I were to improve this project, I would make the foil setup more durable, neater, and less sensitive to unintentional contact. It works now, but it can definitely be cleaner and more organized.

Overall, I feel like I for sure moved from just following instructions to actually understanding what I’m building, and I’m really proud of myself.

Emotion & Design: Attractive things work better

I found Norman’s reading quite interesting, especially his argument that emotions affect how well we use objects. From the previous readings we have done in this class, I just assumed good design was mainly about functionality and usability. I also thought that even if the object is not as aesthetically pleasing, if it works well, then everyone would use it. I did not realize how much emotional appeal plays a role in the design. Norman claims that attractive designs can actually improve how people think and solve problems. When people feel positive emotions, they are more flexible, while negative emotions make people more focused but also more stressed. This made me realize that design is not only about making something work well with clear directions, but also about how it makes people feel while using it.

I liked the example of the three teapots. Each of the teapots emphasized something different. Even though one of them is harder to use, he still keeps it because he enjoys how it looks. This made me understand that objects can have an emotional value. I started thinking about how many objects I own for the same reasons. I sometimes choose things because they look nice or match my mood, even if they are not the most practical option.

This reading also made me realize how much of the visual design, like the color and layout, might help determine how people interact with it, beyond just making it usable. The reading definitely changed how I think about design by showing that usability and aesthetics should be combined, especially to have that emotional appeal. But I wonder if something can ever be too beautiful, can an object’s attractiveness ever get in the way of its function?

 

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

The reading about Margaret Hamilton’s work really inspired me. The fact that the concept of software did not even exist when she started working on the Apollo missions is crazy. I never thought about how much space travel depended on programming. It made me realize how much courage and creativity it must have taken to build something new, especially in a male-dominated environment and time, while even being a mother. Not only did she lead her team successfully, but she also fought to have her ideas heard, even when people initially dismissed her concerns.

I was amazed by the story of the Apollo 11 landing, where the computer started giving error messages. But because Hamilton designed it to prioritize the most important tasks, the module still landed safely. She showed how important it is to anticipate problems before they even happen.

This reading made me reflect on how many of the innovations we have today have been taken for granted and built by people who fought the system in their time. It also makes me wonder how many people today contribute to so much work but stay unrecognized, or their credit is handed over to someone else. Hamilton’s story shows the importance of visibility and persistence in tech and in life, something that we should all take note of.

https://github.com/skyorachorn/Intro-to-IM/blob/cd17b870a87cc39315260f98a0846555e5ce6a13/Week8_UnusualSwitchassignment.ino

See VDO:

https://youtu.be/OVTbmxnJp2E?si=spcco5jThT1CARs4

Concept:

This project explores a hands-free switch using facial movement. Instead of using hands, I used eyebrow movement as an input. When I frown, the system detects it and turns on a sad red face. When I relax my face, it switches to a happy green face.

How it works:

The system uses a digital input to detect whether the switch is ON or OFF. This input is controlled by copper tapes to contact triggered by eyebrow movement.

If the input is HIGH, the green LEDs (happy face) turn on.

If the input is LOW, the red LEDs (sad face) turn on

Handwritten Sketch Diagram:

Circuit:

https://youtu.be/OVTbmxnJp2E?si=spcco5jThT1CARs4

 

Each LED is connected to a digital pin with a 330Ω resistor to limit current.
Red LEDs and green LEDs are connected to separate pins so they can be controlled independently.

⸻

Code that I proud of:

if(state == HIGH){
  // Normal face → Green LED lip 
  for(int i=0;i<7;i++){
    digitalWrite(greenPins[i], HIGH);
    digitalWrite(redPins[i], LOW);
  }
} else {
  // Angry face → Red LED lip
  for(int i=0;i<7;i++){
    digitalWrite(greenPins[i], LOW);
    digitalWrite(redPins[i], HIGH);
  }
}

 

Problem encountered:

Initially, I tried connecting multiple LEDs to one pin, but I learned from Professor Aya’s lecture that Arduino pins have current limits. I solved this by using multiple pins and resistors.

Reflection:

This project helped me understand how digital input works and how the human body can be used as an interface. It also taught me polarity and about current limitations and proper LED connections. I found it interesting that something as simple as facial movement can be turned into an interactive system.

Connecting to the other article, for this article I found a fascinating contrast between emotional design and highly technical engineering  . Hamilton’s work on Apollo software emphasised much more on reliability, error prevention, and anticipating human mistakes, especially in stressful situations where users (astronauts) could not afford confusion. This aligns with the idea from the design reading that in high-pressure contexts, systems should prioritize clarity and function over aesthetics. However, both readings highlight the importance of understanding overall human behaviour whether it is just emotions affecting usability or human error affecting software systems. Personally, this connection made me rethink of design as not just visual or technical, but deeply resonating with human creativity and thinking. It also made me appreciate how Hamilton’s foresight in error-handling actually reflects a kind of “design thinking,” even in engineering. Together, the readings suggest that good design whether it’s interfaces or software comes from anticipating and seeing how humans actually act, think, feel, and make mistakes.

Another aspect of the Hamilton reading that I found particularly meaningful was how her work challenged both the technical and social assumptions about software and who could create it. At the time, software wasn’t even considered a central or prestigious part of engineering, and yet Hamilton insisted on its importance, eventually creating the term “software engineering.” This made me reflect on how new fields or ideas are often undervalued until their impact becomes undeniable. I also found it significant that she anticipated human error such as the famous Apollo incident where the system prioritised critical tasks during overload which directly connects to the idea of designing for real human behaviour rather than ideal users. This raises a broader question for me which is how many current technologies today are still being designed under unrealistic assumptions about users? Overall, this reading reinforced my understanding that innovation isn’t just about technical skill, but also about challenging norms and recognising problems that others overlook.

In the reading on design and emotion, The idea that “attractive things work better”, caught my attention not because they’re objectively more functional, but because they change how we think and feel while using them  . This challenged my assumption that usability is purely logical and efficiency-based. I realized that whenever I feel relaxed or positive, I would actually be more creative and tolerant of small problems, which aligns with the author’s argument about positive affect enhancing breadth-first thinking. This made me reflect on my own experiences with technology and even on my own projects as sometimes I focus too much on making things technically correct and being a perfectionist rather than enjoyable. It also raises a question for me was that if aesthetics can make users overlook flaws, is there any risk that designers might rely too much on appearance instead of improving actual functionality? I think the reading suggests a balance, but it leaves open how far that balance should go in real-world design.

Another idea from this reading that stood out to me was the contrast between positive and negative affect in shaping how we process information. The author explains that negative emotions can actually improve focus and depth of thinking, especially in stressful situations. This made me reconsider my assumption that feeling “good” is always better for performance. In fact, I can relate this to moments when I am under pressure such as before exams or deadlines where I become more focused and detail-oriented. However, this also raises a question that how can designers intentionally design for both emotional states? It seems difficult to create a system that supports both creative exploration and precise decision-making at the same time. This tension made me realise that design is highly dependent on context, and that there is no single “best” design and that only the designs that are appropriate for specific emotional and situational conditions.

Hamilton wanted to add error-checking code to the Apollo system that would prevent this from messing up the systems. But that seemed excessive to her higher-ups. “Everyone said, ‘That would never happen,’” Hamilton remembers.

But it did.

This really begs the question of whether or not they would’ve taken her concerns more seriously had she been male. It’s insane to think that, despite the extent to which she had already proven her competency, they still dismissed her – especially when her concerns turned out to have been very reasonable.  Even today, women have to work harder than men in most places to be perceived as equally competent – and I think plenty of women would understand what I mean here. So I can’t imagine how much more difficult it must have been back in the 60s.

Stereotype threat is a psychological phenomenon defined as the pressure a person feels to disprove negative stereotypes regarding a group they identify with – be it race, gender, class, etc. Studies have proven that stereotype threat (ironically) has a significant negative impact on a person’s performance. Even being reminded of the stereotype before a task can change the outcome. It’s a vicious self-fulfilling prophecy that further perpetuates negative stereotypes and can hurt a person’s self-esteem, which then further affects performance.

Being a woman who grew up in a misogynistic environment, I really struggled with this cycle for almost as long as I remember. I have so much respect for Hamilton given what she must have had to overcome to thrive as she did.