While I found the reading’s focus on human capabilities to be a very insightful perspective concerning interaction design, I found its focus on the use of hands to be both limiting and outdated.

In the past several decades, technologies have developed with the consideration of hands as human’s main ‘capability’. We type, swipe, scroll, hold and even move devices with our hands in order to generate a given output – this has become second nature to us.

However, I believe that the future of immersive and seamless human-centred design revolves around moving beyond this. I feel that the utilisation of other physical human inputs can be used to maximised interaction design, both from the perspective of immersion and ease of use.

An example of this being used to provide seamless experiences for users is the use of facial recognition to unlock smartphones. By taking advantage of the front camera’s natural position when a user picks up their device, designers have been able to eliminate the tedious action of typing in a passcode or scanning a thumbprint.

Conversely, full-body immersion has been utilised in game consoles such as the Xbox Live and Wii. In these cases, sensors were put in use to revolutionise how players interact with games, effectively deconstructing the notion that playing video games is a lazy and inactive process. Despite the minimal success of these consoles, the application of full body immersion seen in them can be used as a reference for other interactive experiences such as installations and performances.

For this assignment, my point of departure was to experiment with creating a sense of range and tonality with the buzzer as opposed to producing singular notes. I feel that the easiest two options would have been to do so by linking the frequency (pitch) produced by the buzzer to either a light sensor or an ultrasonic sensor. As we’ve seen in class, light is very difficult to control, so I opted for the latter.

As the input taken from the ultrasonic sensor updates quickly and at small increments, the sound produced by the buzzer becomes interestingly distorted and non-standard. To me, it suited the aesthetic of a suspenseful scene in a Sci-Fi thriller film. This led me to consider adding a more mechanical sound to complement the buzzer and create an almost chaotic result. To do this, I incorporated the use of a servo motor which varies the BPM of its 180 degree movement based on the same input taken from the ultrasonic sensor.

Ultimately, I enjoyed this assignment as it acts as an example that ideas can come naturally through experimentation. One aspect I feel could be developed is the application of the servo itself as I could potentially vary the surfaces that it rotates on (as briefly shown in the video) to produce different results.

Below is the code, a video of the circuit with just the buzzer and a video of the complete circuit.

#include <Servo.h>

const int trigPin = 9;
const int echoPin = 10;
const int buzzerPin = 11;
const int servoPin = 6;

Servo servoMotor;
int servoAngle = 0;
unsigned long previousServoTime = 0;
unsigned long servoInterval = 0;

void setup() {
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);
  pinMode(buzzerPin, OUTPUT);
  servoMotor.attach(servoPin);
  Serial.begin(9600);
}

void loop() {
  // Send ultrasonic pulse
  digitalWrite(trigPin, LOW);
  delayMicroseconds(2);
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  // Measure the time it takes for the pulse to return
  long duration = pulseIn(echoPin, HIGH);

  // Calculate distance in centimeters
  float distance = duration * 0.034 / 2;

  // Map distance to BPM (Beats Per Minute)
  int bpm = map(distance, 0, 100, 100, 200);

  // Move the servo motor back and forth
  unsigned long currentMillis = millis();
  if (currentMillis - previousServoTime >= servoInterval) {
    servoMotor.write(servoAngle);
    previousServoTime = currentMillis;
    servoInterval = 60000 / bpm; // Convert BPM to interval in milliseconds

    // Increment or decrement the servo angle
    if (servoAngle == 0) {
      servoAngle = 180;
    } else {
      servoAngle = 0;
    }
  }

  // Output distance and BPM to the serial monitor
  Serial.print("Distance: ");
  Serial.print(distance);
  Serial.print(" cm, BPM: ");
  Serial.print(bpm);
  Serial.println(" beats per minute");

  // Generate buzzer tone based on frequency
  int frequency = map(distance, 0, 100, 100, 500);
  tone(buzzerPin, frequency);

}

 

As a photographer, I am inclined towards lens-based imaging. Because of this, the use of computer vision piqued my interest after being introduced to us earlier in the semester. In turn, I have decided to center my final project around the use of computer vision

Concept:

I will look to create a digital mirror which is, at first, heavily abstracted and almost visually illegible. The user is prompted to take a picture of themselves with their phone using the mirror. After raising their phone, the program will detect its presence and make the digital mirror clearer.

The work aims to highlight the common subconscious desire many of us have to take pictures of ourselves in reflective surfaces, in which case the affordance of any reflective surface becomes that of a mirror. Based on this, I present this work with the question – what if there was a mirror made only to take selfies with.

p5js and Arduino:

Naturally the computer vision, programming and ml5 implementation will all happen on p5js. I initially struggled to come up with how Arduino can be incorporated. However, considering the work’s purpose is to allow users to take selfies, I thought of wiring up a ring light (or any small, soft light source) to the Arduino in order to enhance the user’s experience. This light would be turned on only if a phone is detected by the program. In order to ensure functionality, I would need to connect the circuit to a stronger source of electricity than my computer. I also need to look into the different options that would allow me to connect the light to the Arduino physically.

For my Final Project I have thought about the Idea of creating a small boat which we would be able to control with our hands.

Okay okay I agree that is very very plain but stay with me while I explain exactly what my plan is and how I will combine the Arduino with p5.js.

My idea is to 3d print a boat bed which would accommodate the Arduino and some batteries which would be used to power a DC Motor which would have a fan on it. I want to attach the DC Motor to a Servo motor just so I am able to change directions easier.

For controls I want to use a specific Ultra-Sonic sensor which we have available in the Connect2 booking system. This will determine if the boat will go to the left or right, faster or slower.

Finally, by connecting the Arduino to p5js. I’m planning to display the speed, and direction of the boat –  kind of like a dashboard in a car.

This weeks Reading response was very interesting for me. We always say that we can’t wait to see what the future holds and that we want flying cars and simplified life but what we don’t realize is that the future is NOW. The world is shifting in a tremendous pace, I mean look at AI, ChatGPT and other AI platforms have changed our views about Information on the Internet completely in the last 2-3 Years!

The real question is, how far do we need to go? How much is too much? We have all seen those Terminator movies, Judgement day and AI and Robots taking over, but I think that those technologies are very missenterpreted in the movies. As a firm Nature Lover and at the same time a religious person, I believe that those type of thoughts or the direction of which the world is heading to is a little bit too much. Why you would ask? There is always a limit of what we can do before it comes bad / or unhealthy. What makes us connected to earth is nature and our complete sense of it. From sandy beaches to incredible jungles, snowy mountains and wonderful lakes, Earth offers us whatever we would possibly want. That is what makes us human. Now why am I saying all this, well because as the years go we are moving further and further away from mother nature. Yes I understand (and I support) human centered design that will make our lives easier but what we keep forgetting is nature. So why don’t we center our research more on nature instead of us? Why does everything have to revolve around us?

On the flip side though, we can use AI and other Technologies to make the world a better place. Like imaging having Jarvis as an assistant in your everyday life.

This can help us make life easier and access to other people and information would be much much faster but I do not support this as a reason not to become closer to nature or people. Like why do we have to replace going to the Maldives with watching the Maldives on a VR screen. Or for example seeing your family in real life and having a talk over a coffee instead of just texting on Social Media.

In Bret Victor’s rant called A Brief Rant On The Future Of Interaction Design an important element that is commonly forgotten in the realm of designing future interfaces is hands! I have never read anything that focused on something as mundane as hands this passionately but it is true! 

Victor categorizes the function of hands into feeling and manipulation, something that I was never fully aware of until it was pointed out in the rant, our hands have programmed ways of holding several different items in so many ways it is choreographed in such a way where it is efficient and functional. 

So it makes sense that the future of interaction design focuses on our hands and their function, but that doesn’t limit other sensory aspects such as eye tracking or voice user interface, of course, our hands have been our main interaction facilitator however that doesn’t mean it would continue to be so.

Russian Roulette

Introduction

Going into the final project I had a few ideas, some of which I had before the midterm. One of the ideas I had was Russian Roulette, but you get electrocuted instead of getting shot. I felt this was a much safer way of playing Russian Roulette whilst also giving each player the chance to play again if they want to. I chose electrocution because I felt the game still needed some kind of stake, otherwise it’s not nearly as exciting.

Outline

The plan is to have a two player game where each player sits across from the other on a table. To the side of the table is a screen which displays the number of lives each player has as well as an animation that will play when the round starts, when the “gun” is shot, and when the shot is a blank. The screen will also display information about who’s turn it is, and also will allow the players to see a tutorial and also allow the players to play another round. In the game there wont be a physical gun as such, the players will use buttons to control who to electrocute, themselves or the the other person, and sometimes it will be a blank. I may represent the bullets as resistors in any of the drawings just to add to the effect of Russian roulette. As for the electrocution: There will be a device upon which the player will place their hand and in the event that the player will be electrocuted the device will only deliver a small electric shock. I will not make this device myself (I do not trust myself, nor am I willing to test it), so I will search, as I already have been doing, for a small device which can deliver a small, harmless, electric shock.

Side note: The game will be properly labeled with safety signs to indicate that only people above the age of 18 can play and that there are electric shocks involved.

Concept:

For this assignment, we wanted to go with something simple. Rashed is known for his love for music so I was excited to see what we would come up with. During our brainstorming session, Rashed was doing his hobby – which is music production- on his phone on GarageBand and he noticed how he had to click on the “arrow” button to change the pitch of the piano and we decided we wanted to do something like that but with the potentiometer.

The pitch-changing arrow I was referring to on GarageBand:

Materials used:

• x11 Wires
• x4 Buttons
• x4 10k Resistors
• x1 Buzzer
• x1 Potentiometer

Production:

Writing this code was pretty challenging for us as both of us are still adapting to this new language.

We used the toneMelody example from the examples folder that we used in class to take the “pitches.h” tab from it in order to give a specific range. We collectively decided to have the buttons, by default, be the most basic notes “Do, Re, Me, Fa” also known as “NOTE_C4, NOTE_D4, NOTE_E4, NOTE_F4” which was pretty simple to implement.

However, we faced one major issue:

For some reason, the potentiometer would not cooperate at all. The buttons were working fine, but the pitch won’t budge. We, unfortunately, had to use ChatGPT to help us but it was still very helpful in helping us understand what we were doing wrong.

Here’s the code:

#include "pitches.h"

const int speakerPin = 9;  // Speaker connected to pin 9
int buttonPins[] = {2, 3, 4, 5};  // Button pins for notes
int potPin = A0;  // Potentiometer connected to A0

// Initialize an array of notes that will be used depending on the button press
int noteIndices[] = {NOTE_C4, NOTE_D4, NOTE_E4, NOTE_F4};  // Starting notes for each button

void setup() {
  for (int i = 0; i < 4; i++) {
    pinMode(buttonPins[i], INPUT_PULLUP);  // Setup button pins as input with pull-up resistor
  }
  pinMode(speakerPin, OUTPUT);  // Set speaker pin as output
}

void loop() {
  int potValue = analogRead(potPin);  // Read the current value from the potentiometer
  int noteRange = NOTE_C6 - NOTE_C4;  // Define the range of notes to span
  int noteOffset = map(potValue, 0, 1023, 0, noteRange);  // Map potentiometer value to note range
  
  for (int i = 0; i < 4; i++) {
    if (digitalRead(buttonPins[i]) == LOW) {  
      int noteToPlay = noteIndices[i] + noteOffset;  
      tone(speakerPin, noteToPlay);  // Play the note on the speaker
      delay(200);  // A short delay to help debounce the button
      while (digitalRead(buttonPins[i]) == LOW);  // Wait for button release
      noTone(speakerPin);  // Stop the note
    }
  }
}

 

 

Here’s the video of us using it:

 

Reflection:

I think, despite chatGPT’s involvement in this, we did pretty well; the concept was there, the energy and effort that was put into this is there and we’re both proud of our little creation. However, we both do with we took it a step further and maybe added more buttons or tried to use the sensor instead of the potentiometer. We really hope to get used to and adapt to this language and I think after doing

Concept: To create a gyroscope controller wearable controller that is connected to a spaceship game in which there would be power-ups and better graphics for the final project.

Objectives:
Design a Gyroscope Controller: Create a hardware prototype of a gyroscope-based controller that can detect and interpret the user’s hand motions as input commands.
Develop Interface Software: Write software that interprets the gyroscope data and translates it into game commands that are compatible with the game.
Integrate with a Space Simulation Game: Modify my existing Midterm game or develop a simple new game designed to work specifically with this controller.
– User Testing and Feedback: Conduct testing sessions to gather feedback and improve the interface and game interaction based on user responses.

Methodology
Hardware Development: Use a 3-axis gyroscope sensor to capture tilt and rotation. Design the controller’s physical form factor to be strapped around the hands.
Integrate with Bluetooth or USB for wireless connectivity with the P5js game.

Software Development: Develop software to read data from the gyroscope sensor. Convert the gyroscope data into P5js-compatible input commands.
Ensure the software supports real-time interaction with minimal latency.

Game Integration: Adapt a spaceship simulation game to respond to the new controller inputs. Implement basic gameplay features such as navigation, obstacle avoidance, and speed control using gyroscope inputs.

Testing and Iteration: Test the controller with users of varying gaming experience. Collect qualitative and quantitative feedback on usability, responsiveness, and enjoyment. Refine the hardware and software iteratively based on this feedback.