Serial Output from the Arduino

comment 1
Physical Computing

This week we are testing the serial output by the Arduino. This specific example has a nice graphical representation that visualizes the serial output that changes according to the potentiometer’s knob turning.

To start, we will need the following materials:

what-i used-text5

 

We will follow this schematic map in order to wire the components together:

LabSerial_schem

This is what the end result should look like:

setup-img

 

Once everything is wired, use this code in Processing

import processing.serial.*;
float xPos = 0; // horizontal position of the graph

void setup () {
 Serial myPort;
 size(800, 600); // window size 
 println(Serial.list()); // List all the available serial ports

String portName = "/dev/tty.usbmodem1421";
myPort = new Serial(this, portName, 9600);

background(#081640);
}

void draw () {
 // nothing happens in draw. It all happens in SerialEvent()
}

void serialEvent (Serial myPort) {
 // get the byte:
 int inByte = myPort.read();
 // print it:
 println(inByte);

float yPos = height - inByte;
// draw the line in a pretty color:
stroke(#A8D9A7);
line(xPos, height, xPos, height - inByte);

// at the edge of the screen, go back to the beginning:
 if (xPos >= width) {
 xPos = 0;
 // clear the screen by resetting the background:
 background(#081640);
 }
 else {
 // increment the horizontal position for the next reading:
 xPos = xPos + .5;
 }
 
}


Run the code and turn the potentiometer knob. You should see something similar to this!

pot-gif

User Experience Observations: Buttons

Leave a comment
Physical Computing

On Wednesdays I work in a building on Jay st in Brooklyn that must have one of the slowest elevators in the city. Everytime I enter the building I look at my watch and calculate another 6 minutes (at least) — I know there is still some time left between me and my final destination. Each time it’s almost an identical experience: someone will ride the elevator with me and press one of the numbers indicating a floor in the building. Although these buttons have an LED light fixed into them, none of the buttons seem to light up as a result to pressing them, leaving the user (the now very confused elevator rider) extremely frustrated. Interestingly enough, this minor hiccup in technology is surprisingly meaningful and an acute step in completing the User-Experience cycle.

“Feedback — sending back to the user information about what action has actually been done, what result has been accomplished — is a well-known concept in the science of control and information theory.Imagine trying to talk to someone without hearing your own voice, or trying to draw a picture with a pencil that leaves no mark: there would be no feedback.” Donald A. Norman, The Design of Everyday Things

Feedback is one of the key stages in assuring your design is communicative and understood. Without it, the user is just left to guess or assume that everything up until a certain point is going as intended.

In human-machine interaction, buttons have a huge role. We have been taught that buttons are an easy and simple way to operate things. “All you have to do is press a button” and it works. But what will happen if I press a button and get no immediate feedback? Here’s a glimpse at some of the button-operating objects I observed this passed week and dissected, with an emphasis on people’s reaction to feedback (or the lack of it):

Elevator button


Goal
To get the elevator to the floor you’re on
Feedback
LED light inside button indicating the button was pressed, sometimes there is a soft chime as well. If the LED in the button does not light up, this can cause huge frustration and result in pressing the same button multiple times in an abusive manner.

 

Blender button


Goal
To get the blender to start working or “to blend”
Feedback
Upon pressing the button, which is usually a big button (the convention, if it is a hidden or small button it is probably poorly designed) the blender immediately starts working.

 

Doorbell


Goal
To get someone on the other side to open the door
Feedback
Doorbells generally have audio feedback — a ding dong, a chime, a sound. However, when the button is pressed and there is no sound, something similar can happen as in the case with the elevator button not lighting up: the user may become frustrated, assume the button is not working and as a result continuously press the button repetitively.

 

Button to change stoplight for pedestrians


Goal
To control traffic which will result in the change of the stop light, allowing pedestrians to cross safely
Feedback
None! Once this button has been pressed the user has no indication that the command has been sent, or is in some kind of process. Once again, this leaves the user frustrated and button-abusive.

 

Umbrella


Goal
To open the umbrella
Feedback
The umbrella is released from it’s lock and the structure opens up (immediate feedback).

 

Remote control


Goal
To control a digital function (ex: turn something on/off, high/low, etc.)
Feedback
The expectation for change in a digital function is immediate. However, when things become slow and the response is weak (occasionally showing feedback) there is generally a rise in anxiety and anger taken out on the button.

 

From these tiny observations, I’ve noticed a few remarkable behavior patterns. When feedback is given immediately and the feedback is the actual goal for action, the user is always satisfied. However, when the expected immediate feedback does not appear in these situations, it is immediately assumed the device is broken or will not work. Ex: If a hand blender is plugged to electricity and the button is pressed yet the blender doesn’t work, the immediate assumption is that the blender is broken.

In cases where feedback appears but the goal is not met or vice versa we can find a lot of frustration on the user’s end. The lack of feedback will often result in obsessively trying to retrieve feedback (which is psychologically an interesting case to investigate in itself). Ex: User will press an elevator button, there was no indication the elevator was coming his way but eventually it appeared.

In the opposite case, an operation was successful but no feedback was given. This can cause great confusion and leave the user puzzled as to how to repeat the action next time (“How did I get this to work?”).

To conclude, design meant for engagement that does not respond, lacks more than just feedback — it lacks thought, consideration and a flow of events. Technology can be wonderful and many developments can genuinely simplify our lives — but if the design is poor, the technology will be missed. A clever designer is one who knows to combine form and function, one who knows the user and knows the experience. I hope people get a chance to make small observations from time to time and value good design, because quite often, a good designer is undermined for “just” designing and interface or experience, even though in real life there is brilliance and deep thought behind the product. Design that seems effortless and is intuitive is usually the result of a long process which includes various prototypes and user testings. In a team of many professionals collaborating on a product, and as said perfectly by Norman, I believe this to be true: “The designer may be able to satisfy everyone.”

 Photo by Cory Doctorow 

Lighting the LED

Leave a comment
Physical Computing

After becoming more familiar with the various parts in the Arduino kit, I started experimenting with some elements and code.

Here are some parts that are good to start with:

parts-what-i-used

This week, I lit up some LEDs, have a look!

potentiometer-ani-4

And here’s some fun I had with the LED colors:


 

Last but not least, here are some more electronic parts I became familiar with this week:

parts-all-2

See you next week!

 The image above (main image of LEDs) was taken by AFrank99. 

An Invitation to Interact

Leave a comment
Physical Computing

Two years ago I joined a friend for one of the most extraordinary experiences in theatre I have ever had. We arrived to The McKittrick Hotel an hour prior to the announced time, and there had already been a noticeably long line. Sleep No More was rumored to be “an experience like no other”, but I admit that I was sceptic this would be a significantly different experience. Taking into consideration this was theatre at the end of the day, I wasn’t able to imagine anything beyond the familiar structure of audience vs actors. I was in for a big surprise.

All visitors (subsequently the audience) are required to wear (and keep on) a Venetian carnival-style mask throughout the entire experience. You are asked not to speak upon entrance, however, you are encouraged to poke around in corners and trunks and bookcases. Though you are asked not to touch the performers, they may approach and interact with you. These encounters can be as minor as a call for quick favor, or may also result in vanishing with you through a secret door that leads to a secluded room and a one-on-one experience with a character. At the end, you will have to figure your way out back to the rest of the crowd.

Although the general narrative stays the same, it is known that no two of these theatrical experiences are identical. The evolving of the plot is very fluid and based a lot on the audience’s reaction.

Sleep No More is a perfect example for exploring the boundaries of interaction. In The Art of Interactive Design, Chris Crawford describes a system representing interaction:

Input → Process → Output

The thing I find to be key in this system is the fact that “process” allows for unexpected transformation and interpretation of the information previously received. This as a result, may lead to a number of possible reactions. It may be safe to say that this kind of unexpected translation or transformation is more common in human to human interaction, and less in human to computer interaction, where essentially, the machine is programmed to react accordingly, making it the process and output limited.

In The Design of Everyday Things, Donald A Norman highlights scenarios where design has failed to communicate the way an object should be used. These mistakes in design, which happen more often than we may think, are likely to be a result of the designer thinking of the end user more as a machine and less as a user. It is crucial for design to be revisited and questioned multiple times, as well as testing and close observations prior to releasing the actual design. Norman also addresses a system similar to the one described earlier, only more specific:

Designer  System  User

When designing anything for the use of others, one of the most important things to keep in mind should be feedback. Allow your user to know if they are on the right track when engaging with your design. Is everything OK? Should something in the use of the device be changed? We are often challenged by poor design, leaving us as the end users in a vague scenario, having to guess ways of operation. Norman is not shy to put this responsibility solely on the designer. He points out 4 principles that should be considered by every designer before the release of an item or technology:

  • Visibility : the user can see the areas for action
  • Conceptual model : the operations are clear to the user
  • Mappings : the relationship between action and result, cause and effect, is clear
  • Feedback : the user receives constant feedback on the results of his/her actions

Keeping these principles in mind, I believe more thoughtful forms can be modeled, leading to less misuse and confusion. After all, interaction is a dynamic form of communication, and if the other side is not comprehending, you are the one to be questioned first.

 

 The image above was taken from Katerina Kamprani’s project: The Uncomfortable

Hello Arduino!

Leave a comment
Physical Computing

This is my first post on using the Arduino! Although we have met before, this time I’m going to dedicate more time documenting things I learn and come across, like parts, techniques, success and failure.  So let’s begin — have a look at the image above and meet Arduino!

It just looks scary, all it really is is a tiny computer, or a microcontroller. Arduino will soon become very helpful, but before we explore what it can do, let’s see some of the parts it will work with:

parts-all-1

There are MANY other parts, and I will try my best to document them as we go along and make stuff. If you have a kit open it and explore the parts. If you don’t know what something is find the tiny numbers on the piece and Google it! You are bound to find the answer shortly. 🙂

 

Processing a Raccoon

Leave a comment
ICM

This is my first post for ICM — Intro to Computational Media! In class we discussed some basic ideas about Processing and learned that Processing is a library/environment based on Java. We were given an assignment to build a screen drawing using only 2D primitive shapes – arc, curve, ellipse etc. (Whaaaat?!)

This is what some of my first attempts looked like: 

sketch-raccoon-trials

raccoon

View Code Here