“So if you’re new to physical computing and thinking to yourself “I don’t want do to that, it’s already done,” stop thinking that way!”
This line felt like it was yelling at me! I spend a long time thinking of ideas just to find that it is done before so I give up on it! The entire blog itself also gives me mixed feelings because projects like gloves and “things that you yell at” are certain things I’ve been thinking about and I’m getting more confident in wanting to actually try making something like that and giving my own twist to it.
It was interesting to look at projects and ideas people usually gravitate towards. I’ve noticed that most of them gravitate towards a magical-factor, like gloves to move something, tilting or sensors give some kind of feedback. It makes us feel as if we’re some kind of wizards, experiencing something that we deem is futuristic or magical. This may be part of why we find interactive installations and pieces so interesting and fun.
The blog got me thinking about audience interactions with art in general although they are speaking specifically of interactivity. I believe leaving area of ambiguity in all forms of art is necessary because we as humans like to fill in the gaps and when an art piece leaves room for interpretation the artist themselves may view it as their own self-expression but audiences would as-well since by interpreting it they insert a part of themselves into it through the restrictions the artist would make.
On another note, viewing these interactive pieces as performances gives me a new perspective on what makes effective and engaging interactive projects because there’s a difference between being an observer and looking at a painting and actually interacting with, for example, sensors and lights exhibition. Projects that make their audience feel like they’re also making something meaningful that they are in control can be the core of an interactive art experience and its memorability and enjoyability. The artist themselves can take the audience interacting with a piece of art in and of its self.
The concept is of a magical fairy’s garden. A fairy is very shy and when someone touches her hand she gets embarrassed and turns red from blushing. The fireflies in her garden blink with her blushing.
Behavior:
When the fairy is touched, her hand specifically, the FSR sensor behind her is touched. Based on the pressure of the sensor the red LED that’s behind the fairy gets brighter. When the sensor is touched the LEDs behind her also start to blink and they stop when you take off your finger from the sensor/fairy.
I used the input from the sensors to control the LEDs algorithmically through mapping the sensor value to the red LED and blinking the fireflies when touched.
Project:
Schematic:
Program:
//Fairy's sensor pin and value
const int fsrPin1 = 0;
int fsrValue1;
//LED pins, red for blushing on a PWM pin speicifically so it can fade
const int REDPIN = 11;
const int LED1 = 10;
const int LED2 = 9;
const int LED3 = 7;
const int LED4 = 6;
const int LED5 = 5;
const int LED6 = 4;
const int LED7 = 3;
//Boolean to see when the LED lights are on and off to be able to make them blink effectively
bool ledisoff = true;
//Millis, to get the time delay for blinking the LEDs
unsigned long previousMillis = 0;
const long interval = 1000;
void setup() {
pinMode(REDPIN, OUTPUT);
pinMode(LED1, OUTPUT);
pinMode(LED2, OUTPUT);
pinMode(LED3, OUTPUT);
pinMode(LED4, OUTPUT);
pinMode(LED5, OUTPUT);
pinMode(LED6, OUTPUT);
pinMode(LED7, OUTPUT);
}
//function to turn on LEDs instead of having to type it out multiple times
void turnON() {
analogWrite(LED1, 255);
analogWrite(LED2, 255);
analogWrite(LED3, 255);
analogWrite(LED4, 255);
analogWrite(LED5, 255);
analogWrite(LED6, 255);
analogWrite(LED7, 255);
}
//function to turn off LEDs
void turnOFF() {
analogWrite(LED1, 0);
analogWrite(LED2, 0);
analogWrite(LED3, 0);
analogWrite(LED4, 0);
analogWrite(LED5, 0);
analogWrite(LED6, 0);
analogWrite(LED7, 0);
}
void loop() {
//reads sensor input
fsrValue1 = analogRead(fsrPin1);
//maps sensor input to an LED light spectrum so when you put pressure on the sensor the spectrum of values is the same as the red LED's spectrum
fsrValue1 = map(fsrValue1, 0, 980, 0, 255);
//if the fairy is being touched
if (fsrValue1 > 0) {
//the red LED that makes her blush is equivalent to the sensor value
analogWrite(REDPIN, fsrValue1);
//starts counting milliseconds
unsigned long currentMillis = millis();
//if the period interval passes and the led is off it turns it on and if its on it turns it off
if (currentMillis - previousMillis >= interval) {
// save the last time you blinked the LED
previousMillis = currentMillis;
if (ledisoff == true) {
turnON();
ledisoff = false;
} else {
turnOFF();
ledisoff = true;
}
}
}
// if the function above stopped while the sensor wasn't being touched, it turns the LEDs off
if (fsrValue1 == 0) {
turnOFF();
}
}
Issues faced and lessons learned:
I found working with mills very difficult, I spent a lot of time trying to figure that out only to realize that it wasn’t working because of silly mistakes such as using a “=“ instead of a “==“. Although this is I also accidentally short-circuited one of the LEDs because of the exposed metal at the top where I soldered so I ended up putting tape to avoid that.
I also learned how people can interact with a project different than I would’ve imagined. To me the project was simple but when people were interacting with it a gathered new insights, this ranges from how people would interact with the fairy by touching, tapping or in other ways. I was also asked some questions that I didn’t think of like if the fireflies would blink faster the more you touch the fairy which wasn’t something that ever popped into my mind. I also would’ve loved to add tone if I had more time where magical music would play when you touched the fairy’s hand.
Side Note:
Although it’s fairly straight forward I used this website to figure out how to use the sensor:
“A Brief Rant on the Future of Interaction Design”
The hand usage on our phones is very intuitive, all of the gestures ranging from swiping to tapping feel natural. These “pictures under the glass” give feedback in the form of visuals, sounds and sometimes vibrations. These interfaces are so intuitive that even children that are 1-2 years easily figure them out, these objects don’t disconnect us from what we’re doing but rather makes it easier to achieve whatever we want to achieve more efficiently. Victor calls it “a handheld device that doesn’t use our hands” but the way these phones and tablets are used again, focus on the natural ways we’d use our electronics. It is the same reason the iPhones were made, shying away from using actual keyboards and styluses that cause a disconnect between the user and the electronic but rather have it all seamlessly work together.
That was my response after only reading the rant itself and while reading the responses I agree with almost all of them. Although I don’t view the lack of tactile feedback an issue, I do not really agree with his rant in general. However, there are so many ways technology can go and if it does stop at just the way we use touch screens now, that would indeed be disappointing.
Interactivity is indeed hard to define because it is used in so many different ways as the author mentioned. His definition is very useful and puts a specific meaning to the kind of interactivity we are striving for as Interactive Media students. Commenting on some of what he said, a book can be turned into an interactive experience as is seen in the choose-your-own-adventure books, you choose what happens to the character while reading. The same idea goes to recent movies and TV shows. However, all of these could be interpreted as interactive games instead. Through trying to go against his definition of books and movies I’ve proved his point. The movies or books as they are are not interactive, but they can be if you had made changes that include his definition of interactivity. This includes the 3 parts of the conversation speaking, thinking and talking.
I found the first chapter of the Design of Everyday things intriguing. I started off defending everyday objects that are not that simple to use because, in the end, it could be the designer prioritizing form over function. But the more I read, the more I agreed with the author’s point of view. This is also because no matter how great a design aesthetically looks, no matter the number of features it contains if people cannot understand it or find it too complicated they would just give up on using it.
However, I still don’t entirely agree on how every design needs to feel natural or help people quickly understand it, given the constraints designers have. Achieving equilibrium between form, function, and understandability is what I believe a designer should strive for. It’s like he said in the end, “one discipline argues that it must be usable and understandable, another that it must be attractive, yet another that it has to be affordable.” Therefore, his initial argument throughout the chapter was black and white while in real life there’s a lot of gray areas.
For this second assignment, I opted into making a simple traffic light. Started with coming up with a solid idea on how I’m going to make it and decided on using three LEDs, green, yellow and red, a button and a light sensor. The light sensor recorded the light. The idea was that if an object were close (an imaginary car, for example) the amount of light hitting the sensor would decrease and make the green LED to go on. It’s there to turn the traffic light green if there we’re supposed cars driving in. On the other hand, the button served as the pedestrians “wait” button, where they click it to make the traffic light go red.
With that idea in mind, I started by making a schematic:
Next up, I built that on the Arduino:
At first, I had lots of wires going from the resistor to the ground lane, but then I opted to remove that and try just using the resistors alone directly connecting the LED to the ground lane, and it worked. Another thing I faced was the button was giving me random readings at times but it ended up being that I didn’t connect it to 5 volts.
After having the circuit done and testing each input and output to see if they’re working, I wrote the code while referencing code written in the Arduino examples, like the analog button and blinking, we did in class to help with getting the syntax right as well as to know what to write to get all I/Os to work.
This is the code I ended up with:
//variable that are constant, setting the pin numbers
const int buttonPin = 14; //the push button pin
const int lightSensor = 15; // light sensor
const int greenLED = 6; //led pins
const int yellowLED = 5;
const int redLED = 3;
int buttonState = 0; //button status
int sensorState = 0;
void setup() {
Serial.begin(9600);
//OUTPUTS
pinMode(greenLED, OUTPUT);
pinMode(yellowLED, OUTPUT);
pinMode(redLED, OUTPUT);
//INPUTS
pinMode(buttonPin, INPUT);
pinMode(lightSensor, INPUT);
digitalWrite(greenLED, HIGH);
}
void loop() {
int buttonState = digitalRead (buttonPin); //state of the button being from an analog input
int sensorState = analogRead (lightSensor); //state of light sensor
if (buttonState > 0){ //if the state is high/ if the button is pressed
digitalWrite(redLED, LOW); //turn of red LED if its on
digitalWrite(greenLED, HIGH); // turn on green
delay(1000);
digitalWrite(greenLED, LOW); //turn off green LED
digitalWrite(yellowLED, HIGH); //turn on yellow LED
delay(500); //pause for a bit
digitalWrite(yellowLED, LOW); //turn of yellow LED
digitalWrite(redLED, HIGH); //turn on red LED
}
if (sensorState < 600){ //if the sensor gets an input more than 0
digitalWrite(redLED, LOW);
digitalWrite(greenLED, HIGH);
}
}
I’ve had to edit the light sensor’s code depending on the place I was in because it wasn’t consistent in different places.
The final result:
Assignment 3:
I’ve already explained the concept above in assignment 2. I made a few changes for this one, instead of a light sensor I used a distance sensor. I also added twice the amount of LEDs for aesthetics.
The digital input is from the distance sensor while the analog input is from the button. As for the LEDs, the digital inputs are the red and green LEDs while the yellow ones are the analog. When the LED’s are on, the red and green just go on and off and the yellow blinks.
const int trigPin = 11;
const int echoPin = 13;
const int greenLED = 6;
const int yellowLED = 5;
const int redLED = 3;
const int buttonPin = 14;
long duration;
int distance;
void setup() {
pinMode(trigPin, OUTPUT); // Sets the trigPin as an Output
pinMode(greenLED, OUTPUT);
pinMode(yellowLED, OUTPUT);
pinMode(redLED, OUTPUT);
pinMode(buttonPin, INPUT);
pinMode(echoPin, INPUT); // Sets the echoPin as an Input
Serial.begin(9600); // Starts the serial communication
digitalWrite(greenLED, HIGH);
}
void loop() {
// Clears the trigPin
digitalWrite(trigPin, LOW);
delayMicroseconds(2);
// Sets the trigPin on HIGH state for 10 micro seconds
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);
// Reads the echoPin, returns the sound wave travel time in microseconds
duration = pulseIn(echoPin, HIGH);
// Calculating the distance
distance = duration * 0.034 / 2;
Serial.print("Distance: ");
Serial.println(distance);
int buttonState = digitalRead (buttonPin);
bool inMotion = false;
if (distance < 7) { inMotion == true; digitalWrite(redLED, LOW); //delay(500); digitalWrite(greenLED, HIGH); delay(100); } if (buttonState > 0 && inMotion == false) {
inMotion = true;
delay(500);
digitalWrite(redLED, LOW); //turn of red LED if its on
digitalWrite(greenLED, LOW); //turn off green LED
for ( int counter = 0; counter <= 2; counter++) {
analogWrite(yellowLED, 255);
delay(500);
analogWrite(yellowLED, LOW);
delay(500);
}
digitalWrite(redLED, HIGH);
//analogWrite(yellowLED, 255);
// delay(1000);
//analogWrite(yellowLED, 0);
//delay(1000);
}
}
An interactive experience I’ve found on campus is the process of getting your mail from the mailroom. When you get a parcel, they send you an email, and you have to go pick it up from the room. In there you interact with the employees. You tell the worker you received a parcel, and then they look for it in the piles of mail and boxes. After finding and giving it to you, you sign a page and leave.
This appears to be simple enough, they receive your page, and you go to pick it up.Most of the times, you can get your package within a few minutes. However, other times, they can take more than 15 minutes searching for it. The parcels get the receiver’s names written on them but its often hard to find straight away because of the sheer amount of packages. Scheduling a time for getting a package could be helpful since they could find and leave aside the packages. They could also organize them with numbers, for example, so they could find groups if parcels straight away, making the process faster and more intuitive. Especially since they close at 5 pm organization and scheduling could help it become more convenient for both sides of the interaction. However, It could be that the simplicity of the current design makes it easier on the employees since it doesn’t require additional time to schedule and organize. They also have the restraint of space since they provide other services.
