Author: Jana Pocuchova

At first I wanted to make a project that would make sounds through moving small objects – and when thinking of what would be the interactive input, I discovered the stress ball. However, talking to Aaron, who brought some insightful inspiration and ideas, pushed me incredibly in the direction very close to the final piece.

The project is a simple game that consists of two stress balls and two servo-driven boxes installed above the heads of each contestant. There is one pressure sensor on each stress ball which detects a certain range – so that the person has to press it down and release it, which counts as one press. Whoever reaches the count of 50 first, will trigger opponent’s servo and make the box tilt over their head and spill what’s inside (aluminium foil tiny balls, paper clips, pieces of paper anything). There is also a restart button included so that the game can be very easily started over.

However, there were several issues that I struggled a lot with – one of which is how fragile the pressure sensors are. I soldered wires to it to make it possible for the ball to be held in a bigger distance, taped it to a ball and sewed it in a pouch of cloth to secure the pressure sensor (and to make the ball look a bit prettier, nicer to touch as well as visually signify where to press). Yet, when I was testing it with couple of people – in the heat of the game, the soldered part was broken very easily. When it happened for the first time, I changed one sensor in terms of soldering, the second one in terms of taping. And as I found out after the class started and found one the sensors broken again – it was the way it was soldered, which put a way too much pressure on the pressure sensor (a bit of irony in that, isn’t it). Of course there were issues with getting the code as well – for example when I tried to incorporate LEDs and the servos got very lazy, but luckily there was Aaron to help me get moving.

Here is a set up of the breadboard, as well as the box and mechanism attached to a chair. 

Video of game in action:

The code:

#include <Servo.h>


//restart button SET UP
int restartButton = 2;
int prevButtonState = LOW;


//PLAYER A SET UP pressure
int pressurePinA = A0;
int pressureValueA = 0;
int prevPressureValueA = 0;
bool pressureA_enabled = true;

//PLAYER A SET UP servo
Servo servoA;
bool servoStateA = false;


//PLAYER B SET UP pressure pin
int pressurePinB = A1;
int pressureValueB = 0;
int prevPressureValueB = 0;
bool pressureB_enabled = true;

//PLAYER B SET UP servo
Servo servoB;
bool servoStateB = false;



//counting the amount of times the two players meet the pressure range ("presses the ball") - starting at 0
int triggerCounterA = 0;
int triggerCounterB = 0;



void setup() {
//  pinMode(ledPinA, OUTPUT);
  servoA.attach(5);
  servoB.attach(6);
  pinMode(restartButton, INPUT);
  Serial.begin(9600);

}

void loop() {
  

  //read what the pressure values of the pins are
  int pressureValueA = analogRead(pressurePinA);
  int pressureValueB = analogRead(pressurePinB);



  //trigger counter PRESSURE condition for PLAYER A
  if (pressureValueA >= 800 && pressureA_enabled == true) {
    triggerCounterA = triggerCounterA + 1;
    pressureA_enabled = false;
  }
  if (pressureValueA < 600 && prevPressureValueA > 600) {
    pressureA_enabled = true;
  }

  //print out the values for the trigger count and pressure of PLAYER A
//    Serial.print(pressureValueA);
    Serial.print(" ");
     Serial.println(triggerCounterA);
//    Serial.print(" | ");
//    Serial.print(pressureValueB);
    Serial.print(" ");
   Serial.print(triggerCounterB);


  //trigger counter PRESSURE condition for PLAYER B
  if (pressureValueB >= 800 && pressureB_enabled == true) {
    triggerCounterB = triggerCounterB + 1;
    pressureB_enabled = false;
  }
  if (pressureValueB < 600 && prevPressureValueB >600) {
    pressureB_enabled = true;
  }
  //print out the values for the trigger count and pressure of PLAYER B
//  Serial.print(pressureValueB);
//  Serial.print(" ");
//  Serial.println(triggerCounterB);



  //if the trigger count of PLAYER A is bigger or equal to 100, the servo B will trigger
  if (triggerCounterA >= 50) {
    servoB.write(180);
    delay(200);
//    triggerCounterB = 0;
  } else
    servoB.write(0);

  //if the trigger count of PLAYER B is bigger or equal to 100, the servo A will trigger
  if (triggerCounterB >= 50) {
    servoA.write(180);
    delay(200);
  } else
    servoA.write(0);


  //reverse the values in the end of the loop
  prevPressureValueA = pressureValueA;
  prevPressureValueB = pressureValueB;

  if (triggerCounterA >= 51) {
    triggerCounterA = 0;
    triggerCounterB = 0;
  }
  if (triggerCounterB >= 51) {
    triggerCounterA = 0;
    triggerCounterB = 0;
  }

//  //LED brightness loop
//  brightnessA = map(triggerCounterA, 0, 5, 0, 1023);
//  analogWrite(ledPinA, brightnessA);
  

  //making the button restart the whole thing
  int currentButtonState = digitalRead(restartButton);
  if (currentButtonState == HIGH && prevButtonState == LOW) {
    triggerCounterA = 0;
    triggerCounterB = 0;
  } prevButtonState = currentButtonState;
}

 

Taking a great inspiration in Zimoun’s work with random tiny objects that make natural sounds, I would like to create something similar- yet obviously on a much smaller scale. A very rough plan is to create a structure with a piece of metal (or some other material) that would be put close to a servo with a long stick attached to it. On the stick, several pieces of small objects (glass balls, metal nuts etc.) would be hanging on strings. In this way, I would like to combine servo’s analog output with an analog input of a sensor (pressure, light, motion – will see what works in the process). Therefore the sensor would trigger the servo to move – just in the right distance so the stick stops in front of the metal piece and physics will do the magic of small tiny objects moving and hitting it.

Starting very simple, but as I learned with the last project, the complexity can be added once the simple idea works.

 

 

 

I was pleasantly surprised to see how much self-reflection Bret actually demonstrated while responding to the critiques/comments to his article. He acknowledged the theoretical limitation that lacks concrete examples and elaborated a little more on the “vision” element, making ambitious inspiration for future designers  an ultimate objective of the paper.

Mentioning the relation and negative effect that technological advancements have on the physical mobility of humans is a factor that I rarely thought about as a possible consequence. Frankly, Bret’s criticism feels a little counter-intuitive, yet I can see the point. Hundreds years, people were striving for energy-saving inventions that would minimise the work and effort (and thus movement) of people, yet Bret actually points out the danger of where, if continued in the same direction, humanity might end up, painting an image that is a little frightening.

Though I agreed with his responses and mostly found them reasonable defence, I came to a point when I did not buy one of his explanations completely. Bret uses the words of Bergström to describe how not practising  with our hand due to touchscreens can lead to a disability of touch in a way similar to blindness. Obviously, such a complex topic cannot be summarised and answered within the scope of a single paragraph taken out of the context.

I just found this problematic of what consequences will be seen on our bodies and senses oversimplified, while feeling like he also dismisses the fact that while losing some skills/habits, we might gain new ones. Bret described the changes as inherently negative and that we should design technology according to what our bodies do at the current stage of development. Yet it ignores the fact that our bodies might be slowly merging with technology in a weird symbiosis, eventually opening the possibility of us not needing, the specific grabs for instance, whatsoever.

 

 

 

Bret’s article “A Brief Rant on the Future of Interaction Design” was an a very stimulating read. I really enjoy reading half-formed ideas that do not necessarily serve the purpose of strong arguments and persuasion, as much as they serve as an inspiration- which can push us in challenging the status quo in our way, regarding even such banal scales as the design of things we use daily. As mentioned in my previous posts, I struggle a lot with making myself think outside of the known forms – just because one thing was designed in a certain way, with only subtle alterations throughout the years, it does not mean that we should continue on building on the very same design of “yesterday’s technology”. Yet I need to constantly keep reminding myself.

Here I found Bret’s central point of designing technology for humans particularly useful: he articulates the struggle I already had, yet with attentive observation of human nature. Though he did not bring anything concrete to the table, his remarks regarding the sensitive use of hands, through which we can feel instant feedback of almost any object (apologies to Crawford), well highlights the need for observation of human behaviour when designing a future interaction. Technology can be mended easily, human behaviour not that much. Yet the way Bret describes it, is that this behaviour is unchangeable – and that if designed badly, the interaction will remain unsuccessful, inefficient and uncomfortable.

I immediately connected this problematic to what I ran into in last couple of weeks. I recently started drawing on a tablet with a stylus – and I could not wrap my mind around the weird sensation I experienced while using it. Though the designers put a lot of effort into making the stylus of similar shape and weight as a pen/pencil would feel, as well as decreasing the distance between the glass and tip of the pen, there was something inherently funny and unsettling about the interaction.

Yet I would not say it wasn’t tactile the way Bret describes screens – on the contrary, maybe it was a way too tactile, making my hand being very confused about the flow, friction and feedback – the whole drawing interaction, as a sudden replacement to an interaction between a hand, piece of paper and a pen. Frankly, I was not completely convinced by the argument that we changed the tactile for the visual with touchscreen- we still experience both, but as creatures of habits, we tend to get very whiney and uncomfortable when the known form we are used to changes. It made me think of what is the main obstacle we should focus on in terms of predicting human behaviour regarding interaction: is the problem habits that, however, can be changed the way technology can be mended, or is it the human nature that is unchangeable and deeply encoded within our genes?

And, to leave this with a lighter note, here is a quick meme to balance the heaviness of the text, that, however, weirdly relates to Bret’s explanation of human capability, tool and need, and the whole futuristic spirit of the article. 

Me and Nisala started very ambitiously in our brainstorming session, but learned really fast that executing the theoretical ideas is a completely different thing. Instead of having a clear vision and linearly making it happen step by step, we experimented a lot with different sensors, materials and code. The process was very enjoyable, playful and although we ended up not using many of the elements we tried, we learned a bunch of new things (and how not to use them).

One of the major problems that got us stuck in the beginning was that the Tone and Servo library did not work together in one code – we solved it by creating a little bit more of tedious work for us and declared the notes and frequencies manually.

The beauty that was born eventually is a rotating music instrument that has a lot of paper clips inside. The main part of the instrument is a cardboard box, which is rotated by a servo, consequently making a lot of … music? (who said the music needs to be beautiful, right). Then we have a set of 8 buttons that together with a buzzer serve as a C major scale and that also control the servo. The degree to which the servo turn is determined by which button is pressed (the higher the note, the smaller the angle).

Here is a demonstration:

The breadboard: 

And lastly the code:

#include <Servo.h>


#define NOTE_C4 261
#define NOTE_D4 294
#define NOTE_E4 330
#define NOTE_F4 349
#define NOTE_G4 392
#define NOTE_A4 440
#define NOTE_B4 494
#define NOTE_C5 523

int duration = 500;

const int button1 = 4;
const int button2 = 5;
const int button3 = 6;
const int button4 = 7;
const int button5 = 8;
const int button6 = 9;
const int button7 = 10;
const int button8 = 12;

Servo servo;


const int buzzer = 3;


bool servoState = false;
int toggleTime = 0;
int triggerInterval = 500;
int angle = 0;

void setup() {
  // put your setup code here, to run once:

  pinMode (button1, INPUT);
  pinMode (button2, INPUT);
  pinMode (button3, INPUT);
  pinMode (button4, INPUT);
  pinMode (button5, INPUT);
  pinMode (button6, INPUT);
  pinMode (button7, INPUT);
  pinMode (button8, INPUT);

  servo.attach(11);

}

void loop() {
  // put your main code here, to run repeatedly:

  int buttonState1 = digitalRead(button1);
  int buttonState2 = digitalRead(button2);
  int buttonState3 = digitalRead(button3);
  int buttonState4 = digitalRead(button4);
  int buttonState5 = digitalRead(button5);
  int buttonState6 = digitalRead(button6);
  int buttonState7 = digitalRead(button7);
  int buttonState8 = digitalRead(button8);





  if (buttonState1 == HIGH) {
    tone(3, NOTE_C4);
    servo.write(180);

  }


  else if (buttonState2 == HIGH) {
    tone(3, NOTE_D4);
    servo.write(160);
  }



  else if (buttonState3 == HIGH) {
    tone(3, NOTE_E4);
    servo.write(140);
  }


  else if (buttonState4 == HIGH) {
    tone(3, NOTE_F4);
    servo.write(120);
  }



  else if (buttonState5 == HIGH) {
    tone(3, NOTE_G4);
    servo.write(100);
  }


  else if (buttonState6 == HIGH) {
    tone(3, NOTE_A4);
    servo.write(80);
  }



  else if (buttonState7 == HIGH) {
    tone(3, NOTE_B4);
    servo.write(60);
  }



  else if (buttonState8 == HIGH) {
    tone(3, NOTE_C5);
    servo.write(40);
  }


  else {
    noTone(3);
    servo.write(0);
  }

}

 

After finishing my “star constellation” embroidery piece, I was very disappointed that the supposedly metallic thread almost did not show at all- so the intended contrast between white and metallic thread was completely lost. This was sort of an inspiration to make it a little more interesting with a slightly different medium. I took couple of white LEDs and tried to incorporate them into the piece to achieve the promise that metallic thread did not meet. The idea was to make them blink in a consequent line, increasing the speed if the pressure on the sensor increases.

Since my coding game is very weak, with some help of Youtubers and code forums, I managed to make it work, but it was really lacking the “unexpected element” crucial for this assignment. I had an idea of including another pressure sensor which would reverse the order the LEDs light up in, but struggled to code it. With the incredible help of Jack (thank you again!) who patiently worked with me, I learned my lesson why the “for (LEDpin = 2; LEDpin < 10; LEDpin++)” did not work, if a condition including the second pressure sensor was included.  Instead, the whole code was rewritten, leaving out the “for” command, while increasing/decreasing the LEDpin number in the end of each condition.

And in case you’re wondering- the two pressure sensors are in the two ends of the metallic thread, to demonstrate the very very deep meaning of power dynamics of the two figures.

And here is the code:

int LEDpin = 0;
int pressurePinA = A0;
int pressurePinB = A1;

void setup() {

  for (LEDpin = 2; LEDpin < 10; LEDpin++)
    pinMode(LEDpin, OUTPUT);
  LEDpin = 2;

}

void loop() {
//telling arduino to check the pressure of both pins A and B and if A is bigger then lights go from left to right
//the bigger the pressure, the higher the speed
  if ( analogRead(pressurePinA) > analogRead(pressurePinB) ) {
    digitalWrite(LEDpin, HIGH);
    delay(map(analogRead(pressurePinA), 0, 1023, 1000, 10));
    digitalWrite(LEDpin, LOW);
//telling it to move to the next pin in next loop
    LEDpin = LEDpin + 1;
    if (LEDpin > 9) {
      LEDpin = 2;
    }

//if pressure in B is bigger, the lights go from right to left
  } else {
    digitalWrite(LEDpin, HIGH);
    delay(map(analogRead(pressurePinB), 0, 1023, 1000, 10));
    digitalWrite(LEDpin, LOW);

 //telling it to move to the previous pin in next loop
    LEDpin = LEDpin - 1;
    if (LEDpin < 2) {
      LEDpin = 9;
    }

  }


}

 

 

Reading Norman’s chapter “The Psychopathology of Everyday Things” feels like finally revealing the obvious. He clearly identifies and points at something that you had right in front of your eyes the whole time, but never really thought of.

Although I have a feeling that Crawford’s definition of interaction would not succeed with most of the cases that Norman brings up as highly interactive, Norman adds another layer to all of it- and that is the triangle between the designer, product and user. While it is not a direct interaction, it is a form of communication, which is crucial to be understood in order to create a successful design.  I am still a bit conflicted about the importance of the categorization and use of specific terms in such a rigid way, yet I still agree with most of both Crawford’s and Norman’s works that critically and academically contribute to such an underrepresented and underestimated field of study.

However, I would strongly disagree with his statement that good design is pleasurable. Usually, when a design works properly, it goes indifferently unnoticed, taken for granted. One would beg to differ that since we are used to bad designs, we would be pleasantly surprised when we encounter a good one and consequently appreciate it. Yet, at least from my experience, I rarely hear someone appreciating something as a well-designed sink stopper. What, on the other hand, I keep hearing constantly, is the irritated complaints about things like bad signaling on doors or badly designed fridge temperature regulators. I would therefore argue that designers should not strive to make the experience pleasurable, as Norman suggests, but most importantly natural, make it feel the way it could not have been designed any other way- as if even no design was needed whatsoever.

What I truly enjoyed reading about is the feedback part about design. However, I would extend the idea not only to product-user interaction, but the more difficult one: designer-user one. Although in today’s world, the wall that prevented designers and users to communicate is becoming thinner and thinner with review websites and pretty much any means of communication. But does it work fast enough and are the users responsive enough? Let’s say that the refrigerator controls were designed very badly and annoy us quite a bit, but not too much. How many of us would actually bother to email the company with feedback? Since designs mostly get replicated and extended – not designed completely from scratch, this is how we end up in a world full of things that have a potential to function well, but do not.

Lastly, the cultural implication is brought up by Norman to signify, how good design is difficult, if not impossible, to create because “natural” means something else in different contexts. For me, the horrible sink stopper design he was talking about, would be a completely natural design that I pretty much grew up with. This is a problem arising with a more globalized market and that sets designers for an impossible task to satisfy everyone- alongside the manufacturers, the purchasers, the sellers and the repair services- and in any cultural context. All of this makes the job extremely difficult, yet even more pressing to give recognition and gratitude to.

I will just end with a reference for an artist that challenges the designs that we take for granted. 

The Uncomfortable by Katerina Kamprani. Source: theuncomfortable.com

 

The second assignment was to expand our initial analogue switch and make a program in Arduino that combines more digital inputs and outputs.

Since I kind of needed the shoes used in last week’s switch, I used the very same principle and applied it on a glove that somehow found a way to my suitcase after winter break.

I constructed one aluminium board which was connected to power, while middle finger was programmed as a switch to light the yellow LED up when connected, index finger made the same with the red LED and thumb was programmed to act as a legit switch that turns both LEDs on, or off.

//blinking
int ledYellow = 3;
int ledRed = 4;
int MiddleButtonPin = 2;
int MiddleButtonState = LOW;
int IndexButtonPin = 5;
int IndexButtonState = LOW;


//Thumb switch
int ThumbButtonPin = 6;
int ledYellowState = LOW;
int ledRedState = LOW;
int prevThumbButtonState = LOW;

void setup() {
  // put your setup code here, to run once:
  pinMode(ledYellow, OUTPUT);
  pinMode(ledRed, OUTPUT);
  pinMode(MiddleButtonPin, INPUT);
  pinMode(IndexButtonPin, INPUT);
  pinMode(ThumbButtonPin, INPUT);
  Serial.begin(9600);

}

void loop() {
  // put your main code here, to run repeatedly:
  
//THUMB BUTTON SWITCH ON AND OFF
  int currentThumbButtonState = digitalRead(ThumbButtonPin);
  if (currentThumbButtonState == HIGH && prevThumbButtonState == LOW) {
  if (ledYellowState == HIGH){
    ledYellowState = LOW;
  } else if (ledYellowState == LOW) {
    ledYellowState = HIGH;
  }
}
  if (currentThumbButtonState == HIGH && prevThumbButtonState == LOW) {
    if (ledRedState == HIGH){
      ledRedState = LOW;
    } else if (ledRedState == LOW) {
      ledRedState = HIGH;
    }
  }
digitalWrite(ledYellow, ledYellowState);
digitalWrite(ledRed, ledRedState);
prevThumbButtonState = currentThumbButtonState;


  //MIDDLEFINGER WITH YELLOW LIGHT INTERACTION

  MiddleButtonState = digitalRead(MiddleButtonPin);

  if (MiddleButtonState == HIGH) {
    digitalWrite(ledYellow, HIGH);
  } else {
    digitalWrite(ledYellow, LOW);
  }


  //INDEX FINGER WITH RED LIGHT INTERACTION

  IndexButtonState = digitalRead(IndexButtonPin);
  if (IndexButtonState == HIGH) {
    digitalWrite(ledRed, HIGH);
  } else {
    digitalWrite(ledRed, LOW);
  }

}

 

The field of interactivity is conceptually new and yet to be explored. And, as usual, hand in hand with everything new comes a lot of disagreement too. However, Crawford gracefully, with a lot of humour, manages to draw some crucial distinctions and definitions to help us understand what interactivity actually is and why is it important. He brings up and redefines different situations in the way I never thought of before: a falling branch, book, fridge or theatre play are examples used to demonstrate the difference between reaction and interaction and how these terms get very mixed up and misused.

Right when I was strongly disagreeing with what he was arguing in terms of the interactivity of the fridge, he brought up a sensible idea of levels of interactivity. Crawford made a dialogue analogy as an example in which all of the elements have to work 100% in order to make it successfully work, and through which he managed to convince me that the dialogue itself is the core essence of interactivity. This really made me shift my way of thinking about interaction. Yet, to be fair, there was not much theoretical foundation to begin with, as I often take the art of interaction for granted and only question it when it fails (automatic doors all around the campus, I’m looking at you).

What also draw my attention was the recognition of graphic design and the role it plays in the dialogue of interaction. I really agreed with what Crawford said about graphic design and interaction design NOT being two separate steps. I feel like that both sides fail to adapt to the pace the world is evolving in, and sticking to the old categorisation prevents them from recognising that the field of graphic design and interactive design is inevitably merging.

Overall, I truly enjoyed reading Crawford’s witty piece, thanks to which I’m getting more and more excited to explore the field of interaction from the practical, creator’s side of it.

 

As the professional dancer I certainly am (clearly demonstrated in the video as well), I built a switch that completes the circuit based on movement of the feet on a conductive “board”. I used somewhat simple techniques: I attached conductive tape to the soles of my shoes (later I added a circle of aluminium foil to get better coverage), attached wires to the end of the tape to make sure the current flows to the LEDs. For the board, I used a piece of paper with lines of conductive paint on it, to get the right texture and surface for some dancing. As you can see on the picture below, this is just a tryout (I didn’t want to waste that much of a paint, therefore I tried to figure out a way to get full circuit coverage with the least amount of paint). And although I realise that there are so many ideas/materials that would work better (but trust me, dancing on aluminium foil is not compatible… with anything, I tried), this was a lot of fun to make and a lot of learning in the process.