“Turning on the light is easy if you know where the switch is” – Colin Wilson

Concept:

Finally we have reached the Arduino era of the class. So to start out, we were tasked to make a analog switch and a digital switch to turn on two LEDs in a digital and analog fashion. But as well, to add a bit of spice to it. Now being honest it took me some time to get my footing with Arduino as this is my first time using and tinkering with it. But I’ve managed to make something at least a bit fun. I’ve been fond of escape rooms and locks, and I thought, what if I make it so depending on where you twist the lock, the LED will shine.

Sketch:

Digital Circuit:

How it’s made:

In terms of designing, the Blue LED is a simple circuit, featuring a resistor set at 220 olms, and wires connecting it to the Ground and Power. The key thing added is a simple switch that the user can interact with to turn the LED on or off.

However the Red LED has instead a potentiometer. I chose it as it’s use as a dial is going to be key to solving what random value the LED is in. Basically, I have a random function that generates a random value between the lowest and highest value of the potentiometer. Then we read the current value of the potentiometer which uses the function analogRead(). And finally we use a simple if else statement to check if the value is the same, and if so the LED will shine. I’ve added a buffer just so it’s not too difficult to guess.

Highlighted bit of Code I’m proud of:

Outside of the regular struggles with making the digital design, I struggled figuring it out why the random value wasn’t truly random. It was confusing as I assumed somehow it was reading the value of the potentiometer and using that variable as a constant. But that wasn’t the case, so I was a bit dumbfounded as the result variable in the code below isn’t tied to anything.

I did a bit of googling and found out that if I use the random function then it will give me a random number. But, it will repeat everytime, practically serving as a constant, and that wasn’t helpful everytime I would start the simulation. So apparently, you are supposed to add a seed to a code to make it unique and it must be on a unconnected pin as it picks up different static which determines the randomness. Really interesting honestly, but a pain to figure that quirk out.

randomSeed(analogRead(A0));
result = random(0, 1022);

Reflection

Overall I’m pleased with my tinkering for now. I feel like just making the digital design on tinkercad was an experience in itself but also trying to find some sort of creative spin for the LEDs. I think potentially I could add more to it, but I’m fine this being a simple game and hopefully as the weeks go, we can try out different things.

Full Code:

int inputPin = 0;
int outputPin = 2;
int result = 0;

void setup(){
  
  Serial.begin(9600);
  
  randomSeed(analogRead(A0));
  result = random(0, 1022);
  
  pinMode(outputPin, OUTPUT);
  
}
  
void loop(){
 
  int potentialVal = analogRead(0);
  Serial.println(potentialVal);
  Serial.println(result);

  if (potentialVal >= result - 20 && potentialVal <= result + 20){
    digitalWrite(outputPin, HIGH);
  }
  else{
  	digitalWrite(outputPin, LOW);
  }
  
}

 

Physical Computing’s Greatest hits and misses

I really enjoyed going through the different themes of physical computing in this article. I felt that I got a lot of inspiration and ideas about possible project ideas, and the explanations provided for each concept really simplified how implementing this idea in practice would look like. Looking through these examples felt like when I would look through past student’s projects on this WordPress. And I’ve also felt that everytime I see an idea that’s been done, it feels like I can’t do that idea anymore either. However, as the author pointed it out, it’s always nice to re-imagine ideas in new contexts, think of new interactions, and as a lot of us did for our midterm projects, link it back to our identity and cultures.

Some themes especially stuck out to me from this article, and I hope to be able to implement them in some way in my work in the future. First, Floor Pads! I love it when a coding project goes way beyond the screen or the usual hardware of wires and buttons. Especially when something is more prominent and unusual, it definitely captures more attention. And something like Floor Pads where there’s movement and a lot of viewer interaction involved can be especially fun. Likewise, Body-as-cursor and Hand-as-cursor are two other themes that stuck out to me for similar reasons. Finally, Things You Yell At was another fun theme, and something I’ve seen a lot at previous IM Showcases. I feel like another common aspect among these themes is that there is no learning curve to understand how it works, you kind of just experiment with it till you get it, usually it’s pretty straightforward.

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

This article made some great points, throughout this class, we’ve spoken a lot about interactive art, what makes it interactive and how to guide users through these interactions. I really appreciated the points it made about allowing your viewers to experiment with the art, rather than force them into the interactions you’ve planned out, allowing them to discover it themselves can be more fun. As the author states, an important part of interactive art is to listen. I think it can be eye-opening to see how viewers look at your art. Especially as most artists spend hours and hours just looking at their work, editing every little detail, and creating everything from scratch, it can be hard to zoom out and see the bigger picture and experience the art through fresh eyes. Hence why it’s important to see how others interact with your work, take it as feedback, maybe just by watching how others interact, you can get new ideas and make edits to your work.

Don’t Dim Your Light

Concept:
I wanted to work with LED lights and experiment with different objects to create a dimming effect. I was also inspired by lights and spotlights in general -ever since I was a kid but I also remember Professor Mang mentioning how lights work and function which made me think about it more because I always wondered the same thing too. For this project, I focused on creating a light setup that explores control and brightness through the use of a potentiometer (dial) and a push button. The user gets to decide when the light turns on and how bright it becomes. The idea connects back to choosing when to let your own light shine instead of dimming yourself for others.

Image: Link

Hand-drawn schematic:

How this was made:

Setup: I started off by putting my resistors and LEDs on the breadboard and choosing the amount and colors of each which I used one red LED and one green LED with 220Ω resistors for both so I could protect the current and flow. After the LEDs were set and connected to Pins 3 and 9 so I could control their brightness, I focused on connected the push buttons and connecting the potentiometer to A0 and the push button to Pin 4. I also watched this video a while ago when we were first introduced to Tinkercad which I found was actually helpful: Tinkercad Circuit Diagram.

Code: While I was doing that, I also focused on the code, which surprisingly was the easiest part. I learned how to use analogRead() to read the potentiometer values and understand the overall idea of how to use the kit. I found out that the potentiometer gives values from 0 to around 1023, but the LED brightness only goes from 0–255 which is why I divided the value by 4 so the brightness would match correctly. For the [INPUT_PULLUP] code, I looked at this example (https://www.tinkercad.com/things/gfxVutEZ1QQ-inputpullup-example), which helped me learn and understand how to use the push button with the code. It made things easier because I didn’t need an extra resistor for the button since the code uses the Arduino’s built-in pull-up resistor.

full code

// C++ code
//
void setup()
{
  pinMode(3, OUTPUT); //the button pin for Red LED
  pinMode(9, OUTPUT); //the button pin for Green LED
  pinMode(4, INPUT_PULLUP); //the pushbutton to make it easy to wire
}

void loop() //for when the button is pressed
{
  int dialValue = analogRead(A0); //to read the dial
  int brightness = dialValue /4; //make the green light match

  if(digitalRead(4) == LOW) {
  analogWrite(9,brightness); //light brightness -green
  analogWrite(3,brightness); //light brightness -red
  } else {
    digitalWrite(3, LOW); //button will be off if not pressed
    digitalWrite(9, LOW); //button will be off if not pressed
  }

  delay(10); //Wait for 10 millisecond(s)
}

 

The hardest part out of all this was definitely the schematic. For some reason as a visual person I found this so confusing. I think because I’m used to thinking first, during, and after, the schematic required me to think and “brain dump” during the process, which is something I don’t usually do which is why I referred back to some Zoom call recordings and Collin’s Lab: Schematics. I also used an image of “cheat codes” to help me with the symbols since they’re different from the actual circuit.

Overall, I did look at some research before experimenting by myself because its our first time doing this I didn’t want to mess anything up so I practiced, did some tutorials, looked over examples before I did my final work. I watched videos about each part I wanted to work with, like the buttons (Pushbutton Digital Input With Arduino in Tinkercad) and also the potentiometer (TinkerCad Potentiometer with LED).

Reflection:

Making the schematic was honestly the hardest part because it forced me to understand the circuit as a system instead of just colored wires connected together. At first I found it really confusing but I actually started to like writing schematics because they helped me understand Arduino better and made me understand my own project more clearly. For future improvements, I would like to make the LEDs react differently instead of both doing the same thing? so maybe one LED could fade in while a few others fade out, or I could add sound so the project feels more interactive and creates more of a sensory experience.

Tom Igoe really presents some interesting messages surrounding about our own projects. Firstly, a core message of not being discouraged if an idea has “been done before”. I like a lot of his submissions that he showed off and how we require the limitations part of our projects (and also the feedback that Mang presents for us 😊). I can see this in this in light of my own work in content creation for YouTube.

Much of the time I struggle with determining an idea for a video, especially in the niche community that I’m in where most ideas have already been “made before”. But sometimes I like taking a different approach and look at an idea from a different prism. It helps me build on the ideas that the original creator has made, and of course providing credit, whilst injecting my own spin on the idea and creating a different product in the end. Our imagination isn’t a limitation, the critical thinking we don’t do is.

And his next message is around not interpreting our own work. Honestly, after visiting multiple art galleries and even being an usher for Abu Dhabi Art Exhibition 2025 for an Interactive Media artist, I can definitely agree with this.

For some context, I was a volunteer for the Abu Dhabi Art Exhibition 2025, held at the Manarat Al Saadiyat Gallery, with my task being to usher people to an exhibition hosted by reImagined Art. Now, even though the person there only gave me the responsibility to usher people, I also decided to talk to the guests about the artworks and give them a bit of background.

The artworks mainly revolved around the Ethirium blockchain and represented it in different forms (I’ll upload some pictures below 😉). And as guests were coming in, they were astounded by some artworks. I didn’t want to intrude into their experience of the artworks and wanted to give them time to sink in.

Later, some would come up to me and ask for me to explain to them what the artwork meant. I gave them a decent rundown but also was a bit ambivilous as most aren’t tech savy to know about blockchain (I mean they hear crypto or bitcoin and everyone goes “ahh”). Still I can say that they definitely felt astounded as to how something like a ledger for records can be art.

And I think with this, I let more so the guests the agency to interpret the work, rather than letting me being the post it note describing it in detail. So definitely we should be a bit ambivilous in what we say about our work and let others experience it. That in of itself is the crux of imagination, seeing our world from a different prism of thought.

• Physical Computing’s Greatest hits and misses

Physical computing here is not really about using random sensors just because they look “cool” but TIGOE explains that physical computing allow us to create meaningful interactions. Just this idea of giving computers or devices a body to sense everything around and then be able to respond is fascinating, like the waving hand example where you can make music just from the movement of your hands, I wonder if I can try to create something like this using tinkercad. I honestly started thinking more about design and structure, specially focusing on how things were made and how important it is to design something where the action feels natural but at the same time connects to the purpose of the project.

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

I really liked reading about how artists do not need to explain everything to the audience because the creation and space should allow people experience it for themselves. This is also my favorite part about interactive media because it’s about feelings, experiences, perspective, and understanding. In my Understanding IM class I actually created a lot of different art projects related to specific modules which is why I love learning about IM through the artist perspective and the participants. At the same time while its better to just create the experience, I do tend to want to explain to people everything just because I really want them to understand, but even after my midterms I realize that there is no need for all that because sometimes the discovery is part of the experience.

Both readings connect a lot to working with Arduino and Tinkercad because they remind me that the goal is not just building a circuit that works, because I should look at the experience side of it. So when I use sensors, LEDs, buttons, or sounds, I always like asking myself why and how because this way I can remove myself from just being an artist and creator to the participant.

Norman,“Emotion & Design: Attractive things work better”

It is really nice to hear that Don Norman who is making a big emphasis on usability also care a lot about design and aesthetics.
The part that stuck with me most was the teapot example: how he owns three completely different ones depending on his mood and the context. It made me realize that “good design” isn’t this one-size-fits-all thing. Sometimes you need efficiency, sometimes you need beauty, sometimes you need practicality. And the fact that aesthetic appeal actually makes people more tolerant of design flaws is wild to me. It’s not shallow to care about how something looks since it genuinely changes how we interact with it.
I think what Norman’s saying challenges this weird guilt that exists around caring about appearance. Like, designers (or developers, or whoever) sometimes act like prioritizing beauty over pure function is superficial. But he’s providing actual evidence that positive emotion broadens our thinking, makes us more creative, more forgiving. A pleasing interface isn’t just nice to look at, it actually changes your cognitive state, and I believe it is really important to remember when creating designs and art pieces.
The contrast between tools for stressful situations versus relaxed ones was helpful too. I hadn’t thought about it that way before, but it makes sense that your design goals shift based on context. This really shifts the understanding of usability: thinking about how people feel when they’re using something can completely change the interaction in the first place. I believe this is something really usable lesson for us to consider when creating our designs and art pieces.

Her Code Got Humans on the Moon

I really liked this text. Not only because it tells an encouraging story about a woman in a field that is still male-dominated, even decades after the Apollo program, who was a key contributor to something as important as Moon travel, but also because it teaches valuable lessons.

One part that stood out to me was when her daughter accidentally discovered a “bug” in the code. I think error-handling is something that doesn’t get enough attention. If users were perfectly rational and never made mistakes, just like astronauts were assumed to be, then systems wouldn’t need to handle unexpected behavior. But in reality, humans are unpredictable and encountering errors is inevitable.

I think developers don’t always fully account for these cases, which is why serious issues, like the P01 mode problem, can be overlooked sometimes. This shows how important testing is, especially as technical field is growing so much now. Today, developers run huge beta tests for games, and I can’t even imagine how huge testing must be for projects as critical as the Apollo mission that Hamilton worked on.

The fact that such a serious issue was discovered accidentally by a child, and that the assumed “perfection” of astronauts didn’t prevent it, shows that systems should be designed to anticipate anything. There should always be built-in behavior to handle errors, no matter how unlikely they seem.

Her Code Got Humans On The Moon

The story of Margaret Hamilton was really inspiring. I was especially intrigued by her resilience to work even though she had a little daughter and she brought her to the lab to do her work. Her story about leaving a party to make a correction is something I can relate to. I recall countless times I have been at social events and a new idea or a realization on something I am working on just pops to my head. I may not be as enthusiastic about my work to leave the event but I really admire her for that.

This reading highlighted the difference between a computer and a human in when it comes to making mistakes. NASA trusted their astronauts not to make a mistake and be “perfect” but as Hamilton’s instincts proved right, one can make mistake irrespective of the training they have received so she designed a way out even though her superiors said that would never happen. This is something we will take into account when designing future projects. It should be based on the assumptions that the user is not perfect and can make some mistakes so a fail safes or a way out should be designed to ensure the program or device works as it is supposed to.

Looking back at the Artemis II mission launched a few days ago, I can only imagine the sophisticated software and computing used in this mission. If Hamilton and her team were able to design a whole software with such limited memory and storage and they were still successful I wonder what would be designed for the current mission with all the computing power and artificial intelligence available to the team. I am sure it will also contain groundbreaking innovations can usher humanity into a new age just as Hamilton’s “software” did.

 

Norman,“Emotion & Design: Attractive things work better”

The reading spoke about something which is usually unspoken of. The design element of objects. These designs if done right can make a user overlook all the flaws of a product or completely change the idea the user has over the product. Take for instance, popular brands like apple. Although there is no substantial change in the yearly iphones they released, when they change the colour of the phones or just position to camera in a different way, they are able to appeal to the beauty sense of the customer and ride on this to sell their products.

Reflecting on this reading, I go back to the first half of the semester where I used to design programs just for the sake of working. I did not pay much attention to the beauty and aesthetics of the program. Which the first encounter a user will have with my project. A boring interface can push a user away eventhough the logic or idea behind the program is amazing. This can also be seen in flashy adds and flashy designs companies make on their products. These are all strategies to reel customers in and focus their attention on exactly what they designers what them to focus on and overlook all the possible flaws of their program a

Her Code Got Humans on the Moon

I really enjoyed this reading, learning about Margaret Hamilton and her impressive contributions to the field of software engineering, especially at such a young age is truly inspirational. As someone who semi-aspires to be a software engineer, but sometimes feel that it’s not a welcoming environment for women, this reading really changed my perspective and gave me some hope and motivation. A few things stood out to me in this reading. First, Margaret felt a lot of pressure to avoid any mistakes. Mistakes are normal, but obviously, in such a high stakes environment, any mistake can be catastrophic. More than that, if she made a mistake, it would only worsen the image about women in “male-dominated fields,” and it would set a bad impression for future women scientists. For instance, the reading mentions a time where she suddenly remembered a bug in the code one late night, and immediately went to fix it, out of fear that any mistakes in the code would be blamed on her is a sad, but plausible scenario. Despite it being a team effort working on the Apollo software, any mistakes would’ve most likely pointed back to her. Luckily, that didn’t happen!

Another thing I found interesting is her attention to detail, implementing back-up plans for any scenario. Even when others on her team claimed that no astronaut would make such mistake, she still insisted on planning for every worst-case scenario. And it paid off. This reminds me of whenever I if-else statements, sometimes even though there are only two possibilities (true or false, for example), I still feel the need to write the second statement as an else if, JUST IN CASE. Obviously, this isn’t the same thing, but this two situations kind of related in mind.

Norman,“Emotion & Design: Attractive things work better”

This reading made me reflect on a lot of everyday things that we use. While I cannot think of any examples of the top off my head, I’m sure there are so many times where I’ve chosen the more aesthetic item, even when it is not functionally better. I think social media trends also contribute to these phenomena nowadays. Overall, I think Norman brings up some great points about how there sometimes always a trade-off between functionality and aesthetics, even though that is not necessary. His example about tools used during hazardous and stressful situations make sense, I guess that’s probably why emergency exits and fire extinguishers all look the same and work the same. Most emergency exit doors are “push” doors because that’s the fastest way to get everyone OUT, and it’s important that any tools needed to facilitate this escape are standardized and straightforward to use (fire extinguishers, ‘hammers’ in buses to break the window, etc.).

However, the balance between functionality and aesthetics still stands in calmer situations. Let’s say someone wants to pick up a new hobby and they buy a pottery kit. The packaging is aesthetic, the brand is well-known and trendy, and everything LOOKS good. Then, they go home and try to start working on their new pottery and nothing makes sense. The instructions are so short because they were trying to keep a minimalist aesthetic, and everything is organized really well but the user does not understand how to use anything. Now, this calm situation has become a frustrating one because what was supposed to be a relaxing, unwinding evening is now a confused, annoyed evening. This might not be what Norman meant by his explanations, but this is kind of what I understood. And this continues to apply in so many aspects of life, when an app developer makes a new app, the interactions should be built on user standards and shouldn’t require the user to think twice, or else the user will just delete the app and go back to what they know. The learning curve to adapt to something new shouldn’t be so high that the user abandons the experience.

I agree with all of the author’s points that everything has a time, place, and purpose, especially when it comes to design. Sometimes, we need something that balances utility, aesthetics, and practicality. The author highlights that “design is preferable depending on the occasion, the context, and above all, upon my mood.”

The author also emphasizes that in cases of emergency, when people are stressed, they tend to forget how to use things effectively. In this situation, functionality plays a bigger role, which supports his point that design depends on occasion and context. Context plays a major role in many things—it determines how different aspects are prioritized. For example, when designing an emergency exit door, should I focus on making it visually appealing, or ensure that it works effectively in an emergency and does not cause an accidental stampede due to a design flaw?

I do not think the author is biased at all; in fact, I find his ideas and explanations quite objective. My beliefs largely align with his. However, I also think that aesthetics sometimes fail to consider usability. In many cases, we need both. For example, in Qatar, some cities are inspired by European architecture, such as outdoor restaurants or cafés. However, since the weather is not suitable for outdoor seating most of the year, these spaces often go unused about 90% of the time. My question would be when would be a time where functionality is not need or not important in our daily lives?