Tag Archives: IxD

Responding to Igoe

Igoe’s point in Making Interactive Art: Set the Stage, then Shut Up and Listen brought me to reconsider a persistent comment made by our professor about my midterm: it should have an on-off switch. I disagreed, pointing out that pressing the reset button on the arduino or simply removing a battery would reset the machine. Now, however, I realize that both of those things require the user to interact with the background, to move outside of the immediate interaction using context they may not have. Without a clear place to turn the machine on and off or reset it, one person would solve the lock, and it might never be used again. This is a small moment, but an important idea. Designers often fall prey to the trap of creating a design which is too clever for its own good; so seamless that it not only goes unnoticed, but completely unused. Avoiding this trap means empathizing as much as possible through creating user personas and running usability tests as is feasible. While Igoe does not go into these practices specifically, he proceeds to analyze common physical computing projects based upon how clear and stable the interaction is, rather than how clever the technology or mechanism behind it is.

In this analysis Igoe also offers the point that interactive art students should not dissuade themselves from executing a project because it has been done before, and should focus instead on expanding upon unique themes. I appreciated this point and how it is applied in the design of this course. While the frustration of the freedom to do whatever I can with what we have learned so far is palpable at the beginning of each build, by the end it is satisfying to be able to work on a concept I chose rather than one imposed on me. I do, however, have reservations about conceptual art due the unintended consequences. Igoe covers this well in the first text, with how ideal ignorant users will interact unexpectedly. It’s important, then, to strike a balance between behavior constraints and conceptual hindrance.

Move or Die

Leave a reply

Victor’s rant brought to mind the work of Ido Portal and the community surrounding him. Anyone familiar with his work understands that even dancers have a limited understanding of human movement, lacking attention to the development of, among other aspects, hanging. The popular specialist approach to movement, paralleling the other highly specialized industries of our society, provides little guidance for integration and development of movement into everyday life (in the same way nutrition research fails to communicate a guide to developing a healthy relationship with food). As a result of this deprioritization of movement, which Victor briefly mentions when referring to the high frequency of sitting, our most common interactions require little from our body. This reflects the idea of good design as design which requires minimal effort and thereby assumes that effort, stress, and difficulty are all to be avoided. It follows that interaction designers moving into the three-dimensional spaces rendered by AR and VR would benefit from a direct and experimental study and practice of movement as well as a serious confrontation with the fear of risk that makes our daily life monotonous and boring in the name of largely fantastical notion of “safety.” We have to start asking if we want a world where humans are reduced to drooling mouths attached to fingers or fully capable bodies able to create passwords consisting of a series of acrobatic moves, throw our digital essays at our professors for them to grade, or build collaborative three dimensional digital models in real space.

Victor also points out the mistake of glorifying design for children. I want to reiterate this point. Making addictive and repetitive tasks easily accessible to children is a crime. We ought not limit a child’s ability to function in the world because they test our patience or our temperaments. Coddling them and distracting them is the worst thing one can do not only to the child, but the entire human race and the environment in which we exist. We need focused, intelligent, emotional, strong, and capable problem-solvers. Not distracted, dumb, apathetic, weak, and paralyzed attention-seekers.

Build Week 3: Cleaning Up the Interaction

Leave a reply

Concept

After reading this week’s content, I wanted a cleaner and clearer interaction with this build than with my last one. This build behaves as a visual rhythm board, mimicking the interaction of a sound artist with their mixing table, but with light instead of sound.

Circuit

Circuit diagram for visual rhythm board

Code

int red = 9;
int yellow = 6;
int green = 5;
int blue = 3;

int redButton = 12;
int yellowButton = 11;
int greenButton = 10;
int blueButton = 8;

int toggleSwitch = 7;

int potentiometer = A0;



void setup() {
  pinMode(red, OUTPUT);
  pinMode(yellow, OUTPUT);
  pinMode(green, OUTPUT);
  pinMode(blue, OUTPUT);

  pinMode(redButton, INPUT);
  pinMode(yellowButton, INPUT);
  pinMode(greenButton, INPUT);
  pinMode(blueButton, INPUT);
}

void loop() {
  int redButtonState = digitalRead(redButton);
  int yellowButtonState = digitalRead(yellowButton);
  int greenButtonState = digitalRead(greenButton);
  int blueButtonState = digitalRead(blueButton);

  int toggleState = digitalRead(toggleSwitch);

  float potValue = (float) analogRead(potentiometer);
  //set potetiometer to regulate brightness
  float brightness = (float) map(potValue, 0.00, 1023.00, 0.00,
  255.00);
  //set potentiometer to regulate delay
  float blinkDelay = (float) map(brightness, 0.00, 255.00, 1023.00,
  0.00);

  //set toggleState for 0
  if (toggleState == LOW) {
    //tie buttons to LEDs
    if (redButtonState == HIGH)
      analogWrite(red, brightness);
    else (digitalWrite(red, LOW));
    if (yellowButtonState == HIGH)
      analogWrite(yellow, brightness);
    else (digitalWrite(yellow, LOW));
    if (greenButtonState == HIGH)
      analogWrite(green, brightness);
    else(digitalWrite(green, LOW));
    if (blueButtonState == HIGH)
      analogWrite(blue, brightness);
    else(digitalWrite(blue, LOW));

  } //set other toggleState (1)
  else if (toggleState == HIGH) {
    //tie buttons to blink LEDs individually
    if (redButtonState == HIGH) {
      analogWrite(red, brightness);
      delay(blinkDelay);
      digitalWrite(red, LOW);
      delay(blinkDelay);
    } else (digitalWrite(red, LOW));
    if (yellowButtonState == HIGH) {
      analogWrite(yellow, brightness);
      delay(blinkDelay);
      digitalWrite(yellow, LOW);
      delay(blinkDelay);
    } else (digitalWrite(yellow, LOW));
    if (greenButtonState == HIGH) {
      analogWrite(green, brightness);
      delay(blinkDelay);
      digitalWrite(green, LOW);
      delay(blinkDelay);
    } else (digitalWrite(green, LOW));
    if (blueButtonState == HIGH) {
      analogWrite(blue, brightness);
      delay(blinkDelay);
      digitalWrite(blue, LOW);
      delay(blinkDelay);
    } else (digitalWrite(blue, LOW));
  }
}

Behavior

The four LEDs are all controlled with analog and digital sensors. The push buttons provide a digital input indicating whether an LED is on or off. The toggle switch provides an analog input which determines the overall behavior of the LEDs and the potentiometer, another analog input. When the toggle switch is in the zero position, the LEDs turn on as long as a push button is pushed, and the potentiometer regulates the brightness. When the toggle switch is in the one position, the LEDs blink as long as a push button is pushed, and the blink rate and the brightness is regulated by the potentiometer.

Discussion

Within the first few minutes of coding, I could not control my LEDs with the push buttons. I double checked the functionality of everything, ensured all of the code was proper, replaced a 330 ohm resistor with a 10k resistor, and still nothing happened. To troubleshoot, I opened a new code page and reduced my circuit to one push button with one LED. After a bit of frustration, I just started moving the variables around into different parts of the program and testing. When I placed

int redButtonState = digitalRead(redButton)

into the loop, it worked. I remembered the bit about global variables in the previous class and realized that Arduino was not continuously checking the pin for the red push button. As a global variable, this integer was checked once and, thus, was defined as whatever state the pin for the red push button was in when the program started. Once I dropped it in loop, the state of the pin was checked repeatedly. As a result, when the push button was pressed or released, the Arduino could read the change.

Besides these initial issues, there were not many problems. However, one extension I’ve been thinking about would be independently modulating the states of each LED. That is, I press the red button when the toggle switch is in the zero position, and the red LED comes on at the brightness setting from the potentiometer. Then, holding the red button, I press the blue button, which comes on, at first, in the same state and brightness as the red LED. However, if I turn the potentiometer, it’s brightness changes independently, and if I switch the toggle state to the one position, then the blue LED begins to blink while the red LED remains constantly on (both corresponding buttons are still pressed), and the potentiometer will also regulate the speed. I think the easiest way to do this might be to set a zero state, either on or off, for all of the LED’s, and then create conditionals where the pressing of the corresponding button does not activate the LED, but activates the potentiometer and the toggle switch for the corresponding LED. Another option might be to experiment with the BlinkWithoutDelay code, but I am unsure at the moment how this would look.

Responding to Crawford and Norman

Leave a reply

Crawford
I appreciated Crawford’s connecting of the previously disparate, from describing interaction as a spectrum rather than a duality to encouraging interdisciplinary collaboration instead of disciplinary arrogance. In that same vein, I want to expand and connect two of Crawford’s ideas: interaction as a spectrum and interaction as requiring at least two participants. When the latter concept is added into the former model, the spectrum expands from uni-axial to multi-axial, the number of axes representing the number of involved entities. Each axis would represent the amount of action taken by each participant, resulting in two-dimensional spectrum that shows relative action. This model might be more useful to designers in evaluating interactions in order to understand which part of the interaction requires attention.

Norman
The poor quality of the design of the everyday interactions of our campus is astounding. Doors with pull signifiers that push; arrows which do not point to their location or point to nowhere at all; and high line paths which feel forced at best and illogical at worst, combine to make everyday life here unnecessarily stressful. While Norman might qualify these interactions as poor and in need of redesign, this qualification may rest upon an improper assertion of values into a context to which they do not belong . What if that which Norman might inhibited affordances and poor signifiers might result from an emphasis on the value of security over freedom (or freedom through security)? When I read Norman’s work, while I am being educated about the basic concepts surrounding action, I am also reflecting on the author’s and the discipline’s own fundamental values, and how those shape the moral judgments underpinning the writing. If my concern is phrased as a question, it might be: how does one create good design when the judgement of good design means judging the users’ values as bad? If a signifier which is intended to confuse successfully confuses users, is it good design?

A Little Game

Leave a reply

This circuit began with two different codes, two LEDs, and a potentiometer. At one point, my circuit looked like this:

A terrible circuit.

I was confused as to why I could not properly read the button. I should have brought my notebook to work. A few hours of tinkering and figuring out how the conditional statements and operations worked, and a game had emerged. This is the end result:

A better circuit.

The goal of the game is simple. Turn on the green LED and only the green LED. Push the button, cover the light sensor, and turn the dial. Cheat codes are below.

Don’t Drink Your Coffee Alone

Leave a reply

At 7:00 AM on a Sunday morning, my all-too awake and cheerful teammates greet me as I step into the NTSI lab.

“Good morning, Will!”

“Mph.”

My bags hit the ground, and my feet carry me out. Water fills up a gooseneck kettle and starts to heat up. With an obnoxious whir the coffee grinder turns beans into a not-so-fine powder. A filter opens itself and falls into a decanter. The grinder turns off. The water, now boiling, pours over the filter and then back into the kettle. Coffee grounds fall into the filter. A small amount of water wets the grounds. A larger amount of water pours into and on top of the grounds. The coffee drips and drips . . . and drips . . . and drips. Five agonizing years later, the coffee pours into my mug. I take a sip.

“GOOD MORNING Y’ALL!”

I am a proud coffee heretic. I grew up drinking pour over coffee, and to the chagrin of every European friend I’ve ever made, I will die drinking pour over coffee. However, I have come to appreciate what they call making a coffee, where you press some buttons on a machine attached to some water and it gives you a concentrated shot of hot, brown, and bitter deliciousness. The Engineering and Design Studio, like many work spaces on the NYUAD campus, has one of these magical devices (see photo). After over a year of doing nearly all my class work and side projects in this space, I know what one button on the entire machine does, the one that provides coffee at 2:00 AM. To help eliminate my own ignorance, I observed several people making coffee using the machine when I was working in the space over the last few days.

Rancilio Silvia coffee machine in the EDS.

The most common frustrations with the machine revolved around the confusing interface. The buttons are either unmarked or marked with unfamiliar icons, intimidating users who lack prior knowledge. However, each person I observed used the machine with ease. It turns out that once users understand the functions of each feature, the layout of these features makes intuitive sense. When asked how they learned to use the machine in the first place, each person told me that they learned it from someone in the space, showing them the process and enjoying coffee with them after it was done. In a stressful work environment prone to isolating people with individual tasks, this small barrier to interaction drives users to share knowledge and enjoy a much-needed moment to breathe. What first struck me as poor interaction design turned out to be a driver of positive social interaction. For this reason, I am not going to tell you how to use the machine; you will just have to ask someone. As for the features I still did not understand, they are used to steam milk. As a member of the majority human group who cannot digest milk in adulthood, I will not be using these buttons. However, all is not lost; I can now make coffee with milk for a friend.