This article was a great introduction to limitless possibilities of interaction design. In my first project, i felt very clueless  as to what I should build as I couldn’t get creative. However, these projects gave me a lot of ideas for my upcoming projects.

At first glance, this article seems like  simple list of all many interesting projects on physical computing. However, when reading it, I noticed that writer also talks about why the interaction in a  given project makes sense. For example, he says “Musical instruments are great physical interaction projects because you can;t think about your actions when you make music, you have to think about the music.” He proceeds to describe some music based projects that use gloves and force sensors that facilitate intuitive interactions. By contextualizing an interaction, we can give meaning and substance to the interactive projects that we build instead of just making it for the sake of building something “cool”.

This article reminds me of a group class project that I had worked on for Communications Lab. It was an interactive comic in which, a mouse hover gives motion to a comic. 

My team members and I spent a lot of time and effort in perfecting the user interface (conceptually and practically). When it came to demonstrating our work during class, we confidently asked a volunteer to experience our project prototype. Once the user sat down, she just proceeded to scroll down the comic without realizing that the mouse hover causes a response from the website. All of us members were confused. We were so enticed by this simple interaction that we did not realize that it contradicts the intuitive interaction that surfaces when people see a comic on the screen – to scroll down. I feel like if, in our presentation, we had demonstrated how to use the interactive comic ourselves, we would not have made this subtle discovery. I am glad that we allowed a user to interact with our project event  if it const us a few points. 

CONCEPT:

It is an tech-based  imitation of a wooden labyrinth. The maze is controlled by two potentiometers and it rotates on the x and the y axes. 

BEHAVIOR: 

The maze is composed of popsicle sticks and a cardboard. It is placed in a frame which has a servo that rotates the board on the x-axis. Then, there is a larger frame which contains the inner frame and rotates its contents (the maze + the inner frame) on the y axis. The two servos are connected to a  arduino board which takes values of two potentiometers and maps it to the angles that the servos can rotate to. 

As such, when the two red knobs are used, the servos rotate the maze as needed to get the steel ball from one end to the other.

My project meets all the requirements of this midterm project as I am working with two inputs and two outputs. I also have some algorithmic processing in my code as it I take the input values which range from 0 to 1023 and map it to 0 to 50 (x-axis) and 0 to 20 (y-axis). (These values were determined through testing. As a result, the maze does not rotate all the way to 180 degrees but only as much as needed to move the ball.). Moreover, to eliminate any delayed response I used the milis() function. 

SCHEMATIC: 

PROGRAM: 

// constants won't change. Used here to set a pin number:
const int ledPin =  LED_BUILTIN;// the number of the LED pin
#include 

Servo innerServo;  // create servo object to control a servo
Servo outerServo;  // create servo object to control a servo
int innerFrame = 0;  // analog pin used to connect the potentiometer
int outerFrame = 1;  // analog pin used to connect the potentiometer
int inner;    // variable to read the value from the analog pin
int outer;

unsigned long previousMillis = 0;        // will store last time the servo was updated

// constants won't change:
const long interval = 5;           // interval at which to blink (milliseconds)

void setup() {
  // set the digital pin as output:
  Serial.begin(9600);
  innerServo.attach(9);  // attaches the servo on pin 9 to the servo object
  outerServo.attach(10);  // attaches the servo on pin 9 to the servo object
}

void loop() {
  unsigned long currentMillis = millis();

  if (currentMillis - previousMillis >= interval) {
    // save the last time you blinked the LED
    previousMillis = currentMillis;
    inner = analogRead(innerFrame); // reads the value of the potentiometer (value between 0 and 1023)
    outer = analogRead(outerFrame); // reads the value of the potentiometer (value between 0 and 1023)
    
    inner = map(inner, 0, 1023, 0, 50);     // scale it to use it with the servo (value between 0 and 180)
    outer = map(outer, 0, 1023, 0, 20);     // scale it to use it with the servo (value between 0 and 180)
    Serial.print("inner");
    
    Serial.print(inner);
    Serial.print(", outer");
    
    Serial.println(outer);
    innerServo.write(inner);                  // sets the servo position according to the scaled value
    outerServo.write(outer);
  }
}

PROBLEMS: 

I miscalculated the position of the maze within the inner frame. The maze is not centered because some space is required to fix the servo on the inside of the inner frame. As a result the center of gravity is not at the center. As such, when I was placing the entire thing inside the outer frame, it kept rotating to the side. Therefore, I used a stretchy nylon purple string to hold the frame up. I could have avoided this if I had measured the size of the servo before hand and included that in my measurements. 

As Michael pointed out, my final prototype has three pieces  (the maze, the control panel and the arduino board) instead of being a put-together whole. Perhaps if I had used a container of some sort or a wooden board  to place my breadboard and arduino, my project would not be in “pieces”. 

LESSONS LEARNED:

This is my first project this semester in which I used wood for the structure. Thanks to the tool training I was able to use the hand saw and the glue gun. I also understood the importance of incremental testing. Because I religiously applied this in my process, any issues that came up were resolved on a step by step basis and I never ended up in a problem-accumulated crisis. 

GALLERY:

In A Brief Rant on the Future of Interaction Design, the author describes the superiority of physical interactions over digital interactions. However, the author seems to have reduced digital interactions to just screens and there other modes of interactivity out in the world like displayed in the following video: 

However, despite this fallacy I understand why the author talks about screens specifically. She does so because it is the predominant mode of interaction at this age. I think this is true because, it has become very easy for web developers and software engineers to build things that can be used in this interface. People who do not necessarily understand  the systematic components of a tablet or a computer,can materialize their products as long as they are literate in NodeJS and ReactJS.

For example, the device in the above video is not easily programmable, I will probably have to understand the lingo and the intricacy of the hardware components and then try to build it. So you do not really see David down the road playing ping pong with it. 

On the other hand,  screen technology has empowered so many people to build new software technologies and as a result has become more accessible. It is clear why it is prevalent . At the same time I understand that the author is trying communicate the unfortunate trade-off between empowering the production of new software and exploring and appreciating different modes of interactivity. 

In this book the author discusses the responsibility of a failed interaction. Does it lie on the user or does it lie on the designer? He starts with using the example of doors. While reading this example, I remembered a very similar case which led to deaths of many people because of bad design. 

Unfortunately, I could not unearth the details of this specific flight crash. However, from what I remember, the pilots were not able to notice the drop in altitude because the display  on the panel. There were three issues :

• The display was not visible to the eye and it was placed in a way that faced away from the pilots direct line of sight
• There was no indication or warning of this sudden altitude drop in any way  – red light, sounds
• The display on the panel was not clear and confusing to read. 

Many ten to blame it on the carelessness of the pilots. However, it is important to consider that the design of this small but non-trivial feature could have prevented this. 

The Author spends the first chapter defining Interactivity. In summary he says that Interaction has to be a two sided three step process which includes thinking, listening and speaking.  I like that the definition for this has been narrowed down to include these conditions. However, based on his argument there is nothing that proves that it is true. All his example are based on the premise that the definition is true.

For the sake of argument, let’s say that this is the correct definition. He also argues that interaction could be a spectrum with several levels. Although it is possible to casually say that one thing is more interactive than the other. I am confused as to how you can quantify this based on the three requirements  – thinking, speaking and listening. 

Although the author mentions that all of them should be on an equal level, that is not always the case. Is it possible to develop this idea by providing sub-categorizations of interaction based on these three modes. 

CONCEPT:

This project is an upgrade from my project (Red or Green?)from last week. The concept is the same. Four LEDs will be blinking (in a random fashion) and you must use the push button  to catch a colour or your choice. You may use the potentiometer to change the speed of the blinking to make the game harder or easier for yourself. 

BEHAVIOUR:

The assignment states that I must use one digital input and one digital output to control at least two LEDs in a digital and analog fashion respectively. The push button (digital input)  is used to pause the entire system and in a sense catch a colour. Because of its binary nature, it satisfies the digital input requirement of the assignment. Moreover, the potentiometer is used to control the speed on 6 different levels. As such, the range of values satifies the analog input requirement. Finally, as I am using more than 4 LEDs, I have also satisfied the more than 2 LEDs requirement.

SCHEMATIC:

PROBLEMS: 

I had a problem with the push button last week because I had not used a resistor with it. After clarifying the issue in class, I managed to set up the circuit. 

PROGRAM:

int red = 2;
int yellow = 3;
int blue = 4;
int green = 5;
int pushButton = 6;
int analog = A0;
int value = 0;
int sensorValue = 0;
int randomNo = 0;
int ledState = 0;
unsigned long previousMillis = 0;

int speedConstant = 100;
void setup() {
  // put your setup code here, to run once:
  pinMode(red, OUTPUT);
  pinMode(yellow, OUTPUT);
  pinMode(blue, OUTPUT);
  pinMode(green, OUTPUT);
  pinMode(pushButton, INPUT);
  Serial.begin(9600);
  randomNo = random(2, 6);
}
void loop() {
  // put your main code here, to run repeatedly:
  value =  digitalRead(pushButton);//reading from digital input
  Serial.println(value);
  //if the push button is pressed down, do not move onto the next LED
  if (value) {
  }
  else {

    //reading values from analog input
    sensorValue = analogRead(value);//reading from analog input
    sensorValue = map(sensorValue, 0, 1023, 0, 6);


    unsigned long currentMillis = millis();//blink without using delay function
    //LED blinks
    if (currentMillis - previousMillis >= speedConstant * sensorValue) {
      // save the last time you blinked the LED
      previousMillis = currentMillis;
      if (ledState) {
        digitalWrite(randomNo, LOW);
        randomNo = random(2, 6);
        digitalWrite(randomNo, HIGH);
      }
      ledState = !ledState;

    }

  }
}