“My child can’t tie his shoelaces, but can use the iPad.”

I would like to write about the problem of using touch screens starting from the young generation these days. In the passage, the interesting part for me was that ” A child can’t understand Hamlet, but can understand Cat In The Hat. Yet, it’s Shakespeare, not Dr. Seuss, who is the centerpiece of our culture’s literature.” Today, tools that are dumbed down for children’s minds or children’s bodies are called “toys”. The younger generation using iPads more than books comes with a few concerns. Firstly, reading on screens might not be as good for understanding as reading from a real book. Also, the quick and fun stuff on iPads can make kids want more instant rewards, possibly leading to addiction-like behavior. iPads can make it easy to switch between apps and do many things at once, which could make it hard for kids to focus. The lack of a real, hands-on experience with books means missing out on a unique way of learning. Lastly, relying too much on iPads might limit kids from experiencing different things. I believe it is important to find a balance between screen time and other activities for healthier development.

Thus, to solve this kind of problem coming from touch screens, creating brain interfaces for kids should focus on making learning fun and balanced. These programs should help with reading, thinking, and problem-solving, while also making sure kids don’t spend too much time on screens. It’s important to give rewards in a fair way, so kids feel good about their achievements without getting too hooked. Making the programs interactive and including things to see and hear can make learning more exciting. Encouraging movement and using different senses is also good for helping kids develop important skills. These programs should cover a lot of different subjects and work together with teachers to make sure they’re helpful for learning. Parents should be able to check on what their kids are doing and guide them, making sure they use the programs responsibly. And most importantly, these programs should be for everyone, considering the different ways kids learn and where they come from so that every child can enjoy and learn from them.

 

Piano / Synthesizer

For this project, our goal was to craft a musical instrument within the constraints of limited resources. Despite the restricted options, we brainstormed various concepts and ultimately settled on developing a hybrid piano/synthesizer. To accomplish this, we repurposed buttons as keys by integrating two types of sensors, analog and digital. Using a breadboard, we configured the keys and delved into the coding phase. Each button was programmed to generate distinct notes, connected to a borrowed speaker from the IM lab for clearer and better sound quality.

As we progressed with the initial setup, the need for an analog sensor arose. We incorporated a potentiometer, not to alter the current, but as a knob to modulate the notes produced by the four buttons. The potentiometer’s range was segmented into three sections, and within the programming loop, an ‘if-else’ construct acted akin to cases, adjusting the notes played in response to the potentiometer’s adjustments.

THE VIDEO

The Code

#include "pitches.h"


const int speaker = 12;


const int tone_G = 2;
const int tone_A = 3;
const int tone_B = 4;
const int tone_C = 5;
const int tone_D = 9;
const int tone_E = 10;
const int tone_F = 11;




int buttonState_G = 0;
int buttonState_A = 0;
int buttonState_B = 0;
int buttonState_C = 0;
int buttonState_D = 0;
int buttonState_E = 0;
int buttonState_F = 0;


int potPin = A0;
int potVal = 0;




void setup() {
 // iterate over the notes of the melody:
 pinMode(tone_G, INPUT);
 pinMode(tone_A, INPUT);
 pinMode(tone_B, INPUT);
 pinMode(tone_C, INPUT);
 pinMode(tone_D, INPUT);
 pinMode(tone_E, INPUT);
 pinMode(tone_F, INPUT);
 
 }


void loop() {
 // no need to repeat the melody.


 potVal = analogRead(potPin);




 buttonState_G = digitalRead(tone_G);
 buttonState_A = digitalRead(tone_A);
 buttonState_B = digitalRead(tone_B);
 buttonState_C = digitalRead(tone_C);
 buttonState_D = digitalRead(tone_D);
 buttonState_E = digitalRead(tone_E);
 buttonState_F = digitalRead(tone_F);


if (potVal < 341)  // Lowest third of the potentiometer's range (0-340)
 {   
 if (buttonState_G == HIGH) {
   // play the sound
   tone(speaker,NOTE_G4);
 }
 else if (buttonState_A == HIGH) {
   // play the sound
   tone(speaker,NOTE_AS4);
 }
 else if (buttonState_B == HIGH) {
   // play the sound
   tone(speaker,NOTE_F4);
 }
 else if (buttonState_C == HIGH) {
   // play the sound
   tone(speaker,NOTE_C3);
 }


 else
  {
   noTone(speaker);
   }
 }


 else if (potVal < 682)  // Lowest third of the potentiometer's range (0-340)
 {
   if (buttonState_G == HIGH) {
   // play the sound
   tone(speaker,NOTE_A4); //random note not matching the name
 }
 else if (buttonState_A == HIGH) {
   // play the sound
   tone(speaker,NOTE_B4); //random note not matching the name
 }
 else if (buttonState_B == HIGH) {
   // play the sound
   tone(speaker,NOTE_C4); //random note not matching the name
 }
 else if (buttonState_C == HIGH) {
   // play the sound
   tone(speaker,NOTE_D4); //random note not matching the name
 }


 else
  {
   noTone(speaker);
   }


 }


 else
 {
   if (buttonState_G == HIGH) {
   // play the sound
   tone(speaker,NOTE_AS4);
 }
 else if (buttonState_A == HIGH) {
   // play the sound
   tone(speaker,NOTE_FS4);
 }
 else if (buttonState_B == HIGH) {
   // play the sound
   tone(speaker,NOTE_GS4);
 }
 else if (buttonState_C == HIGH) {
   // play the sound
   tone(speaker,NOTE_CS3);
 }


 else
  {
   noTone(speaker);
   }
 }
  
 }

 

 

A Brief Rant on the Future of Interaction Design:

Main points

• We take for granted the importance of touch and how much we rely on our hands. Touch is one of the, if not the most important sense out of all five of our senses. 
• Interactivity shouldn’t be confined to the press of a finger, but rather engage our entire bodies. Only then will we be able to progress into an era of true interactivity.

Follow up article:

• From what I could gather in the response article, the author was emphasizing the importance of further developing the technology already at our disposal. Technology cannot remain stagnant, it needs to develop and advance with us. 
• Again the author highlights that we must NOT neglect our bodies, allowing ourselves to create a future of total immobility. We should engage all aspects of our being and ensure that we give ourselves the chance to experience true interactivity. 

Personally, I find myself extremely scared of our future. The author mentions the possibility of complete immobility in the future due to our lives becoming too heavily reliant on external technologies. To me this is so dystopian to even think about. I don’t want every aspect of my life to be consumed by technology. I want to feel HUMAN and be HUMAN.

 

 

CONCEPT:

For this project, our goal was to craft a musical instrument within the constraints of limited resources available. Despite the restricted options, we brainstormed various concepts and ultimately settled on developing a hybrid piano/synthesizer. To accomplish this, we repurposed buttons as keys by integrating two types of sensors, analog and digital. Using a breadboard, we configured the keys and delved into the coding phase. Each button was programmed to generate distinct notes, connected to a borrowed speaker from the IM lab for clearer and better sound quality.

 

As we progressed with the initial setup, the need for an analog sensor arose. We incorporated a potentiometer, not to alter the current, but as a knob to modulate the notes produced by the four buttons. The potentiometer’s range was segmented into three sections, and within the programming loop, an ‘if-else’ construct acted akin to cases, adjusting the notes played in response to the potentiometer’s adjustments.

 

Code:
#include "pitches.h"


const int speaker = 12;


const int tone_G = 2;
const int tone_A = 3;
const int tone_B = 4;
const int tone_C = 5;
const int tone_D = 9;
const int tone_E = 10;
const int tone_F = 11;




int buttonState_G = 0;
int buttonState_A = 0;
int buttonState_B = 0;
int buttonState_C = 0;
int buttonState_D = 0;
int buttonState_E = 0;
int buttonState_F = 0;


int potPin = A0;
int potVal = 0;




void setup() {
 // iterate over the notes of the melody:
 pinMode(tone_G, INPUT);
 pinMode(tone_A, INPUT);
 pinMode(tone_B, INPUT);
 pinMode(tone_C, INPUT);
 pinMode(tone_D, INPUT);
 pinMode(tone_E, INPUT);
 pinMode(tone_F, INPUT);
 
 }


void loop() {
 // no need to repeat the melody.


 potVal = analogRead(potPin);




 buttonState_G = digitalRead(tone_G);
 buttonState_A = digitalRead(tone_A);
 buttonState_B = digitalRead(tone_B);
 buttonState_C = digitalRead(tone_C);
 buttonState_D = digitalRead(tone_D);
 buttonState_E = digitalRead(tone_E);
 buttonState_F = digitalRead(tone_F);


if (potVal < 341)  // Lowest third of the potentiometer's range (0-340)
 {   
 if (buttonState_G == HIGH) {
   // play the sound
   tone(speaker,NOTE_G4);
 }
 else if (buttonState_A == HIGH) {
   // play the sound
   tone(speaker,NOTE_AS4);
 }
 else if (buttonState_B == HIGH) {
   // play the sound
   tone(speaker,NOTE_F4);
 }
 else if (buttonState_C == HIGH) {
   // play the sound
   tone(speaker,NOTE_C3);
 }


 else
  {
   noTone(speaker);
   }
 }


 else if (potVal < 682)  // Lowest third of the potentiometer's range (0-340)
 {
   if (buttonState_G == HIGH) {
   // play the sound
   tone(speaker,NOTE_A4); //random note not matching the name
 }
 else if (buttonState_A == HIGH) {
   // play the sound
   tone(speaker,NOTE_B4); //random note not matching the name
 }
 else if (buttonState_B == HIGH) {
   // play the sound
   tone(speaker,NOTE_C4); //random note not matching the name
 }
 else if (buttonState_C == HIGH) {
   // play the sound
   tone(speaker,NOTE_D4); //random note not matching the name
 }


 else
  {
   noTone(speaker);
   }


 }


 else
 {
   if (buttonState_G == HIGH) {
   // play the sound
   tone(speaker,NOTE_AS4);
 }
 else if (buttonState_A == HIGH) {
   // play the sound
   tone(speaker,NOTE_FS4);
 }
 else if (buttonState_B == HIGH) {
   // play the sound
   tone(speaker,NOTE_GS4);
 }
 else if (buttonState_C == HIGH) {
   // play the sound
   tone(speaker,NOTE_CS3);
 }


 else
  {
   noTone(speaker);
   }
 }
  
 }

 

 

 

Concept :
For our musical instrument, we decided to craft an innovative instrument using an Ultrasonic sensor, a button, and a Buzzer. To kick off the musical vibes, just gently hold down the button. Now, here’s where it gets interesting when you wave your hand in front of the ultrasonic sensor at varying distances it unveils a different array of notes!

 

IMG_4039

 

 

 

 

Code snippet :

int trig = 10;
int echo = 11;
int buttonPin;
long duration;
long distance;
void setup() {
pinMode(echo, INPUT);
pinMode(trig, OUTPUT);
Serial.begin(9600);
}
void loop() {
digitalWrite(trig, LOW); //triggers on/off and then reads data
delayMicroseconds(2);
digitalWrite(trig, HIGH);
delayMicroseconds(10);
digitalWrite(trig, LOW);
duration = pulseIn(echo, HIGH);
distance = (duration / 2) * .0344; //344 m/s = speed of sound. We're converting into cm
int notes[7] = {261, 294, 329, 349, 392, 440, 494}; //Putting several notes in an array
// mid C D E F G A B
buttonPin = analogRead(A0); 
if (distance < 0 || distance > 50 || buttonPin < 100) { //if not presed and not in front
noTone(12); //dont play music
}
else if ((buttonPin > 100)) { //if pressed
int sound = map(distance, 0, 50, 0, 6); //map distance to the array of notes
tone(12, notes[sound]); //call a certain note depending on distance
}
}

 

 

 

Challenges:
I wouldn’t call this one a challenge but more of a hiccup really was that we found ourselves repeatedly unplugging and replugging them due to connectivity issues and the Arduino kept on giving errors.

A Brief Rant on the Future of Interaction Design

This guy really doesn’t like screens, so much so that he calls screens “Pictures Under Glass”, meaning that they provide no connection to the task that one is performing. And to be honest, that is true. Even while typing this response, I can feel the keys under my fingertips, knowing where each key is without looking at it. I can tell exactly how much pressure I need to apply on each key for it to type something. I hear a clicking sound whenever I press a key, and I can anticipate which key produces which sound before I even press it with my fingers. I honestly love my keyboard because of how it feels to the touch, even though it’s not exactly very dynamic. I can’t say the same for my phone screen.

This guy suggests that screens were never meant to be the final all-encompassing technology of interaction design, but they are merely a transitional technology. After all, what else in the natural world do we use the gesture of sliding our fingers for? Even the act of making a sandwich requires more interaction than screens, the supposed Interface of the Future.

I find this vision of the future of interaction design very interesting, because I’ve never really thought about how much screens on handheld devices actually ignore our very hands before. I am curious to explore some other visions and ideas that consider this incapacity of screens and provide other exciting possibilities for the purpose of interaction design.

 

Responses

This guy mentions the idea of finger-blindness here which really caught my eye. Finger blindness, as he puts it, is when you don’t use your hands to their full potential for doing what they were meant to do (not swiping away at screens) making it harder to attach meaning and value to the act of touching something, which is a scary thought. Other than that, I love how this guy addresses these responses with humor and also makes sense at the same time. He reiterates that screens aren’t necessarily bad – for now. It’s just that we shouldn’t be limiting ourselves to just screens when we think about future advancements in technology but come up with other receptive devices that appreciate the intricacy of our hands. After all, humans deserve so much more than just screens.

Weekly Response

We’ve made significant strides in achieving much of what was demonstrated, but it hasn’t reached the level of convenience we hoped for. Take Siri on iPhones, for instance. Despite its heavy advertisements, it’s not as frequently used in reality and isn’t convenient enough to be  highlighted as an important feature. Its limited usability in public or noisy settings restricts its practicality. Similarly, the flashy concept of drawing in the air showcased in the video lacks real-world applicability. In professional settings, more practical, industrial-grade alternatives would likely be preferred.

However, considering the video was made nine years ago, it serves as a benchmark for our progress toward the creator’s vision. The idea of a singular device for all tasks is closer to reality today. Many functionalities showcased, like summoning a taxi, scheduling appointments, using voice commands for messages, and even unlocking a Tesla car, are now accessible through modern phones. While data isn’t projected on transparent glass yet and smart glasses aren’t widely available, we’re moving towards more advanced technologies where convenience triumphs over merely looking impressive. The focus is shifting to inventions that truly serve convenience rather than flashy devices with limited practicality.

Concept

Our assigment idea was sparked by a common scenario we all encounter – parking a car in reverse. In discussing the challenges of accurately judging the distance, my partner and I realized the potential hazards and the lack of a reliable solution. Considering how much we rely on the beeping sensor in our own cars for safe parking, we envisioned a solution to bring this convenience to everyone. Imagine a situation where you can’t live without that reassuring beep when you’re reversing. That’s precisely the inspiration behind our assigment – a beeping sensor and a light that mimics the safety we’ve come to depend on, implemented with a car toy to illustrate its practical application.

Required Hardware

– Arduino
– Breadboard
– Ultrasonic distance sensor
– Red LED
– 10k resistor
– Piezo speaker
– Jumper wires

Schematic Diagram:

Circuit Diagram:

 

Setting Up the Components

Ultrasonic Distance Sensor Connections:
VCC to 5V
TRIG to digital pin 9
ECHO to digital pin 10
GND to GND on the Arduino

Speaker Connections:
Positive side to digital pin 11
Negative side to GND

LED Connections:
Cathode to GND
Anode to digital pin 13 via a 10k resistor

Coding the Logic

// defines pins numbers
const int trigPin = 9;
const int echoPin = 10;
const int buzzerPin = 11;
const int ledPin = 13;

// defines variables
long duration;
int distance;
int safetyDistance;

// Define pitches for the musical notes
int melody[] = {262, 294, 330, 349, 392, 440, 494, 523}; 

void setup() {
  pinMode(trigPin, OUTPUT); // Sets the trigPin as an Output
  pinMode(echoPin, INPUT);  // Sets the echoPin as an Input
  pinMode(buzzerPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  Serial.begin(9600); // Starts the serial communication
}

void loop() {
  // Clears the trigPin
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);

  // Sets the trigPin on HIGH state for 10 microseconds
  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;

  safetyDistance = distance;
  if (safetyDistance <= 5) {
    // Play a musical note based on distance
    int index = map(safetyDistance, 0, 5, 0, 7); // Map distance to array index
    tone(buzzerPin, melody[index]); // Play the note
    digitalWrite(ledPin, HIGH);
  } else {
    noTone(buzzerPin); // Stop the tone when not close
    digitalWrite(ledPin, LOW);
  }

  // Prints the distance on the Serial Monitor
  Serial.print("Distance: ");
  Serial.println(distance);
}

 

Hardware Implementation:

 

Video Illustration:

Video Illustration 2 (using melody)

Working Explanation and Conclusion
The ultrasonic distance sensor measures the gap between the car and the sensor on the breadboard. When the distance diminishes below a predefined threshold (5 units in our design), the buzzer emits a warning sound, and the red LED illuminates, acting as a clear visual cue for the driver to halt. This Arduino-based system seamlessly combines hardware and software, offering an elegant solution to a common problem. In creating this assignment, we’ve not only simplified the process of reverse parking but also contributed to enhancing overall safety, turning our initial conversation into a tangible, practical innovation.

Concept

Our assigment idea was sparked by a common scenario we all encounter – parking a car in reverse. In discussing the challenges of accurately judging the distance, my partner and I realized the potential hazards and the lack of a reliable solution. Considering how much we rely on the beeping sensor in our own cars for safe parking, we envisioned a solution to bring this convenience to everyone. Imagine a situation where you can’t live without that reassuring beep when you’re reversing. That’s precisely the inspiration behind our assigment – a beeping sensor and a light that mimics the safety we’ve come to depend on, implemented with a car toy to illustrate its practical application.

Required Hardware

– Arduino
– Breadboard
– Ultrasonic distance sensor
– Red LED
– 10k resistor
– Piezo speaker
– Jumper wires

Schematic Diagram

Circuit Diagram

Setting Up the Components

Ultrasonic Distance Sensor Connections:
VCC to 5V
TRIG to digital pin 9
ECHO to digital pin 10
GND to GND on the Arduino

Speaker Connections:
Positive side to digital pin 11
Negative side to GND

LED Connections:
Cathode to GND
Anode to digital pin 13 via a 10k resistor

Coding the Logic

// defines pins numbers
const int trigPin = 9;
const int echoPin = 10;
const int buzzerPin = 11;
const int ledPin = 13;

// defines variables
long duration;
int distance;
int safetyDistance;

// Define pitches for the musical notes
int melody[] = {262, 294, 330, 349, 392, 440, 494, 523}; 

void setup() {
  pinMode(trigPin, OUTPUT); // Sets the trigPin as an Output
  pinMode(echoPin, INPUT);  // Sets the echoPin as an Input
  pinMode(buzzerPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  Serial.begin(9600); // Starts the serial communication
}

void loop() {
  // Clears the trigPin
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);

  // Sets the trigPin on HIGH state for 10 microseconds
  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;

  safetyDistance = distance;
  if (safetyDistance <= 5) {
    // Play a musical note based on distance
    int index = map(safetyDistance, 0, 5, 0, 7); // Map distance to array index
    tone(buzzerPin, melody[index]); // Play the note
    digitalWrite(ledPin, HIGH);
  } else {
    noTone(buzzerPin); // Stop the tone when not close
    digitalWrite(ledPin, LOW);
  }

  // Prints the distance on the Serial Monitor
  Serial.print("Distance: ");
  Serial.println(distance);
}

 

Hardware Implementation

Video Illustration (Initial idea with beeping sound)

Video Illustration 2 (using melody)

Working Explanation and Conclusion
The ultrasonic distance sensor measures the gap between the car and the sensor on the breadboard. When the distance diminishes below a predefined threshold (5 units in our design), the buzzer emits a warning sound, and the red LED illuminates, acting as a clear visual cue for the driver to halt. This Arduino-based system seamlessly combines hardware and software, offering an elegant solution to a common problem. In creating this assignment, we’ve not only simplified the process of reverse parking but also contributed to enhancing overall safety, turning our initial conversation into a tangible, practical innovation.

The first reading, “A Brief Rant on the Future of Interaction Design,” delves into the future of technology and how Bret Victor has a problem with it. Victor reveals how the future they are portraying consists of swiping through a touchscreen for every task. He believes that this limits the use of our hands as we aren’t doing anything with them other than swiping. Victor wants to see a future where we can grab, throw, hold, and feel technology rather than just swiping through a screen. Reflecting back on this reading, I completely disagree with Victor’s narrative. The whole point of technology innovation is to make things more accessible and user-friendly. It is supposed to make tasks easier to do and faster as well. If all we’re doing with our hands is swiping, is that really a bad thing? Victor’s issue is that we’re not using our hands enough. In reality, we’re using our hands to do a lot of other things like cooking, laundry, making our bed, etc. So if we’re using our hands to do all these things, is it really bad that the innovation of technology means all we’re doing with just technology is swiping? Moreover, Victor also fails to take into account that technology, where we don’t require using much of our body, is beneficial to several people of determination who may have a hard time interacting with limited mobility or cognitive function.

The second reading, “Responses: A Brief Rant on the Future of Interaction Design,” is a response posted by Brent Victor where he responds to the questions he received after posting the initial rant. However, his responses to most of the questions don’t even look like responses but rather an angry teenager responding to hate comments. By mentioning that he is no longer going to respond to any more questions, it is as though he has turned off the comments on his Instagram post due to fear of being shamed by the public. One question someone asked was about using voice for more interactive technology. Victor responded by saying that we should just use our voice for asking questions and issuing commands. With that logic, one could respond by stating that why don’t we just use our hands as well for doing tasks like cooking, laundry, etc.? Why do we need to use more of them for interactive technology? The whole rant by Victor made no sense and it is not a surprise that he no longer works in making such technology.

The main connecting factor between both these readings is that it was written by Brent Victor, who only thinks that he is right and everyone else is wrong. In both these readings, Victor wants the future of technology to be less user-friendly and more handsy. It is as though Victor thinks the future of technology revolves around his needs and desires alone rather than the needs and desires of the rest of the world.