I’m sick. Sort of.

Friday, November 19th, 2010

Being sick for me is not a big deal. It’s usually a 2-day thing, some light fever, headache, and the occasional sneeze — and then it’s all over. Although I don’t feel like I’m about to die right now, my brain is not ready for the heavy school assignments that are lined up. So. I do silly things I never do normally, like painting my toe nails even though it’s November.

Come to think of it, maybe I can use nail polish for my flowery Craft and Communications project? I think that was a pretty bad idea. Such a slow brain. I’ll sleep on it.

Lab #9 Serial

Wednesday, November 17th, 2010

So, this was the most interesting thing we did in this lab – letting Arduino and Processing work together in perfect harmony.

But it all started when we…

CONNECTED A POTENTIOMETER
We attached the potentiometer’s outer red and black wires to power and ground, and connected the middle wire from the potentiometer to the Analog input pin 0 on your Arduino board.

SENDING SERIAL OUTPUT
Used the following Arduino program to send serial output of the values as bytes out to the computer:

int analogPin = 0;
int analogValue = 0;

void setup()
{
// start serial port at 9600 bps:
Serial.begin(9600);
}

void loop()
{
// read analog input, divide by 4 to make the range 0-255:
analogValue = analogRead(analogPin);
analogValue = analogValue / 4;
Serial.print(analogValue, BYTE);
// pause for 10 milliseconds:
delay(10);
}

CHECKED SERIAL OUTPUT
We opened the Arduino serial monitor and using the default settings of parsing at 9600 baud, we played with the potentiometer to see the output (or scrolling) of ASCII values.

Turning the potentiometer at different speeds affected the output (numerals, versus capital and lowercase letters). Click here to see it in action.

VERIFYING SERIAL PORT
We loaded a Sensor Graphing Sketch program to Processing. But first, before putting it into action, we verified the correct serial port.

MAKING A GRAPH
After verifying, we played the graphing program in Processing. This program basically demonstrated how serial output can be used to drive communication between different software components (in this case Arduino and Processing). And here’s the result:

Lab #8 Motors

Wednesday, November 17th, 2010


Parts we used:
H-bridge, diode (brownish red colored little fellow), TIP-120 transistor (three legged black square), small DC motor, 10 µF capacitor (the black cylinder). We also used the breadboard, hook up wire, Arduino, potentiometer, switch, 1K Ohm resistor, 10K Ohm, resistors (or similar), wire stripper, multimeter.

HOOKING UP ARDUINO BOARD, ADDING POTENTIOMETER
Hooked up the Arduino to the breadboard, and then we added a potentiometer with the middle “output” wire connected to analog pin 0.

ADDING MOTOR
We soldered wires to the motor, and connected the motor wires to power and to the center collector pin of the TIP120 transistor. Then we connected the output end of an LED to the same center collector pin of the transistor. Then we added a diode with the input end of the attached to the right-side emitter pin of the transistor. This diode will prevent a spinning motor’s “blowback” current from shorting out the circuit.

We connected a 1K ohm resistor to the left-side base pin of the TIP120 transistor. We wired the other end of that resistor to Arduino digital pin 9. To reduce noise in the circuit, we put a 10µF capacitor between the power and ground rails of the breadboard. The circuit was completed by connecting the right-side emitter pin of the TIP120 to ground. This is what it looked like:

UPLOADED CODE
Uploaded the following code to translate the analog input into digital output that moves the motor.

int motorPin = 9; // motor connected to digital pin 9
int analogPin = 0; // potentiometer connected to analog pin 0
int val = 0; // variable to store the read value
void setup()
{
pinMode(motorPin, OUTPUT); // sets the pin as output
}
void loop()
{
val = analogRead(analogPin); // read the input pin
analogWrite(motorPin, val / 4); // analogRead values go from 0 to 1023, analogWrite values from 0 to 255
}

LOOK, it works, and we made a 6 seconds video to prove it!

ADDED A SWITCH
Removed all components except the motor and the wires connecting power between Arduino and the breadboard, and then hooked up a regular switch (SPST) to the breadboard.

ADDED AN H-BRIDGE
By adding a bunch of wires to different places on the breadboard all of a sudden an H-bridge was hooked up. Amazing. This is what such an H-bridge looks like all wired up:

This H-bridge combined with the code below was supposed to let us control the motor to go in different directions depending on the switch being in ON or OFF position. We didn’t actually make it happen, and we are not sure why – even after troubleshooting for a while. However, we are pretty sure the answer is hidden somewhere within the delicious spaghetti of wires surrounding the H-bridge.

const int switchPin = 2; // switch input
const int motor1Pin = 3; // H-bridge leg 1 (pin 3, 1A)
const int motor2Pin = 7; // H-bridge leg 2 (pin 7, 2A)
const int enablePin = 9; // H-bridge enable pin
const int ledPin = 13; // LED
void setup() {
// set the switch as an input:
pinMode(switchPin, INPUT);
// set all the other pins you’re using as outputs:
pinMode(motor1Pin, OUTPUT);
pinMode(motor2Pin, OUTPUT);
pinMode(enablePin, OUTPUT);
pinMode(ledPin, OUTPUT);
// set enablePin high so that motor can turn on:
digitalWrite(enablePin, HIGH);
// blink the LED 3 times. This should happen only once.
// if you see the LED blink three times, it means that the module
// reset itself,. probably because the motor caused a brownout
// or a short.
blink(ledPin, 3, 100);
}
void loop() {
// if the switch is high, motor will turn on one direction:
if (digitalRead(switchPin) == HIGH) {
digitalWrite(motor1Pin, LOW); // set leg 1 of the H-bridge low
digitalWrite(motor2Pin, HIGH); // set leg 2 of the H-bridge high
}
// if the switch is low, motor will turn in the other direction:
else {
digitalWrite(motor1Pin, HIGH); // set leg 1 of the H-bridge high
digitalWrite(motor2Pin, LOW); // set leg 2 of the H-bridge low
}
}
/*
blinks an LED
*/
void blink(int whatPin, int howManyTimes, int milliSecs) {
int i = 0;
for ( i = 0; i < howManyTimes; i++) {
digitalWrite(whatPin, HIGH);
delay(milliSecs/2);
digitalWrite(whatPin, LOW);
delay(milliSecs/2);
}
}

That’s NOT trash!

Monday, November 15th, 2010

THE CONCEPT
It’s not always easy being green. A lot of recyclable materials end up being disposed of as waste because citizens don’t fully understand the complex recycling system… That’s NOT trash! is the app about when, where and how to handle your waste and recyclables to help the citizens of NYC make their city a greener apple. The app will give the user an updated collection schedule based on where the citizen lives. It will also encourage the citizens to reduce waste and recycle more — by explaining how the recycling system works, by revealing recycling rates for the different neighborhoods, and through the general tone of voice of the app. The user can also manage notifications to get a reminder of when to take the trash or recyclables out.

THE PROCESS
But it all started three weeks ago, when I first came up with the idea for this recycling app. I made three wireframe sketches, using Skitch to get a rough look, and to prevent myself from going into too much detail.

I got good feedback on those sketches, and decided to go further the second week by adding more screens, and make the design a bit closer to the look and feel I wanted. I also got all the screens into a model called a wire flow, and mapped this flow to the different data sources I would use. This second week I did all work in OmniGraffle – the program I am most comfortable using.

I got a lot of useful feedback from my classmates after this second iteration. We discussed how to make the notification settings more minimalistic, how to better integrate all the features I wanted in the WHERE-section, and finally we talked about in what way it would make most sense to share an app like this.

I did not want this app to alert all social media every time the user recycled something, because that would probably be very annoying for both the user and his or her social circle. I consciously made the decision to put the Share this app-feature in a less intrusive location (in the ABOUT-section). My classmates thought no one would really share the app just like that, and wanted the context of the user’s green actions connected to the sharing. With their input, I did something in between – I still let people share the app out of context from the ABOUT section. But in addition to this, I will make the sharing option appear after the user has received a notification; not every time, but maybe about once a month. This way the user will not be too bothered, and the user’s friends will not get all spammed by the user’s green actions. In this wire flow, I fixed all these issues, to be ready to go on with the visual stuff:

Basically, what I did the second week of this process is how far I would normally go when it comes to the visual design. Then a graphic designer would be my savior. This time, however, I was left on my own to finish up the whole thing. I downloaded an iPhone kit for Photoshop, took a deep breath, and dived into the art of photoshopping to try to make the app all smooth and fancy. In the beginning it took me forever to find the different functions, but by forcing myself to go through all the screens, I got more efficient. I took a few short cuts by importing some elements from my OmniGraffle file, though… So the design might not be that fancy, but I do feel more comfortable using Photoshop now, which was my goal for this part of the assignment. This is a little sneak peek of the smooth and fancy version of my app:

To see more visuals, this pdf is the place to look.

Lab #7 Processing revisited

Saturday, November 13th, 2010

These people are freaked out. Why? Unless you click on the picture, you will never find out! In addition to these freaked out people, I have also made bouncing squares, blinking squares, squares that change color and snow men. It’s all here:

SquareLights
RaceTrack
ColorSquares
Bounce
Snow man
Freaked out creatures

The nine year old art director

Wednesday, November 10th, 2010

We got a short brief for this final project from the people behind the after school writing program 826NYC last week. Our mission is to redesign the blog Fish slaps a baby to meet their students (age 6-18) demand for a nicer looking, more flexible website that will better support the different kinds of formats and content they want to publish. In the future blog, the children will be able to choose between different, carefully designed templates to illustrate the feel of their blog post. These templates will be based on the students own creative ideas.

Our first meeting with the students happened tonight in their workspace, and we were all set for a creative brainstorming and moodboard session where the 826NYC students were in charge, and the SVA students their humble and curious assistants. Armed with paper scissors, I was helping several students finding the magazines and images that would best illustrate their ideas. The concept I will work with for the next weeks, is one that fits me quite well, considering that I’m a garden owner miles away from my garden. So why not grow a digital garden template based on these instructions:

CONCEPT IDEA: BEAUTIFUL FLOWERS
Flowers in gardens, especially roses. Favorite color is pink, but lilac and yellow is OK too. And sparkling things. Like her bracelets. One time when she played with her friends in a garden, she hid a bunch of rocks and the others had to find them. She also likes eggs and chickens, and she has seen someone kill a chicken once. With a knife. But that’s another story, and another concept all together.

Having a nine year old art director has been lots of fun. So far. We’ll see if I meet her expectations as the process evolves. I believe she was pretty happy with my paper cutting abilities, at least…

Spelling Magic

Sunday, November 7th, 2010

We needed to find a problem in the world, and then fix it through the use of physical computing. Our problem is that we simply hate spelling mistakes. To make people spell correctly you need to get to them early. We made a simple game for kids to play with, that will give them immediate feedback on whether they are spelling right or wrong. In the short video below we are spelling the word ART. This is a prototype, which means some other 3 letter words can be spelled, but unfortunately not all words. The game is limited because we have not made enough contacts in each letter space for all letters of the alphabet to be used.

THIS IS HOW IT WORKS

THIS IS OUR LITTLE SECRET

AND THIS IS THE MIGHTY GAME BRAIN
…or the code behind it if you like. Except that in this code example, the user has to spell the word CAT instead. I guess CAT is a bit more kid-friendly than the word ART. Anyway. Game brain coming up:

//PIN FOR THE LED LIGHTS CONNECTED TO PLACES ON BLOCK TRAY

#define LED 10 // the pin for the LED for first letter block
#define LED2 11 // the pin for the LED for 2nd letter block
#define LED3 12 // the pin for the LED for 3rd letter block

//THE CONTACT SPOTS ON THE BLOCK TRAY

#define P1X 2 // the input pin where the contact for block 1 is connected
#define P1Y 3 // the input pin where the contact for block 1 is connected
#define P2X 4 // the input pin where the contact for block 2 is connected
#define P2Y 5 // the input pin where the contact for block 2 is connected
#define P3X 6 // the input pin where the contact for block 3 is connected
#define P3Y 7// the input pin where the contact for block 3 is connected

//STORING STATE OF THE INPUT PINS FROM LETTER BLOCKS

int placeX = 0; // val will be used to store the state of the input pin
int placeY = 0; // val will be used to store the state of the input pin
int place2X = 0; // val will be used to store the state of the input pin
int place2Y = 0; // val will be used to store the state of the input pin
int place3X = 0; // val will be used to store the state of the input pin
int place3Y = 0; // val will be used to store the state of the input pin

//THE WORD THE USER MUST SPELL

String theword = “CAT”; // using a constant String

void setup() {
pinMode(LED, OUTPUT); // tell Arduino LED is an output
pinMode(LED2, OUTPUT); // tell Arduino LED is an output
pinMode(LED3, OUTPUT); // tell Arduino LED is an output
pinMode(P1X, INPUT); // and contact is an input
pinMode(P1Y, INPUT); // and contact is an input
pinMode(P2X, INPUT); // and contact is an input
pinMode(P2Y, INPUT); // and contact is an input
pinMode(P3X, INPUT); // and contact is an input
pinMode(P3Y, INPUT); // and contact is an input
}

void loop(){
//READING EACH OF THE LETTERS IN THE WORD
int letter1 = theword.charAt(0);
int letter2 = theword.charAt(1);
int letter3 = theword.charAt(2);

//READING EACH OF THE LETTER BLOCKS
placeX = digitalRead(P1X); // read input value and store it
placeY = digitalRead(P1Y); // read input value and store it
place2X = digitalRead(P2X); // read input value and store it
place2Y = digitalRead(P2Y); // read input value and store it
place3X = digitalRead(P3X); // read input value and store it
place3Y = digitalRead(P3Y); // read input value and store it

//CHECKING LETTERPLACE 1
// CHECK whether input from the block is HIGH-HIGH (A)
if (placeX == HIGH && placeY == HIGH) {
if(letter1 == ‘A’) {
digitalWrite(LED, HIGH); // turn LED ON
}
}

// CHECK whether input from the block is HIGH-LOW (T)
else if (placeX == HIGH && placeY == LOW) {
if(letter1 == ‘T’) {
digitalWrite(LED, HIGH); // turn LED ON
}
}

// CHECK whether input from the block is LOW-HIGH (C or R or F)
// Made the same pattern underneath the C, R and F letter blocks
// The child can then play with different words that can be spelled with _AT
else if (placeX == LOW && placeY == HIGH) {
if(letter1 == ‘C’) {
digitalWrite(LED, HIGH); // turn LED ON
}
}

//CHECKING LETTERPLACE 2
// CHECK whether input from the block is HIGH-HIGH (A)
if (place2X == HIGH && place2Y == HIGH) {
if(letter2 == ‘A’) {
digitalWrite(LED2, HIGH); // turn LED ON
}
}

// CHECK whether input from the block is HIGH-LOW (T)
else if (place2X == HIGH && place2Y == LOW) {
if(letter2 == ‘T’) {
digitalWrite(LED2, HIGH); // turn LED ON
}
}

// CHECK whether input from the block is LOW-HIGH (C or R or F)
else if (place2X == LOW && place2Y == HIGH) {
if(letter2 == ‘C’) {
digitalWrite(LED2, HIGH); // turn LED ON
}
}

//CHECKING LETTERPLACE 3
// CHECK whether input from the block is HIGH-HIGH (A)
if (place3X == HIGH && place3Y == HIGH) {
if(letter3 == ‘A’) {
digitalWrite(LED3, HIGH); // turn LED ON
}
}

// CHECK whether input from the block is HIGH-LOW (T)
else if (place3X == HIGH && place3Y == LOW) {
if(letter3 == ‘T’) {
digitalWrite(LED3, HIGH); // turn LED ON
}
}

// CHECK whether input from the block is LOW-HIGH (C or R or F)
else if (place3X == LOW && place3Y == HIGH) {
if(letter3 == ‘C’) {
digitalWrite(LED3, HIGH); // turn LED ON
}
}

//CHECKING IF BLOCK IS REMOVED

if (placeX == LOW && placeY == LOW) {
digitalWrite(LED, LOW); // turns the LED off*/
}
if (place2X == LOW && place2Y == LOW) {
digitalWrite(LED2, LOW); // turns the LED off*/
}
if (place3X == LOW && place3Y == LOW) {
digitalWrite(LED3, LOW); // turns the LED off*/
}
}

App in the making

Friday, November 5th, 2010

So I shared the museum app concept I made with my wonderful group last week. I can now add that all the concepts my classmates made are published here at the course website — with presentations and all. We are now in the process of making another app. Individual assignments this time. Am I excited about creating yet another iPhone app? Not really. But I do like my working title on this project; That’s NOT trash! It’s an app supposed to help New York citizens recycle, deal with special waste and so on. I might come back to you when I have more than some silly OmniGraffle icons.

And don’t get me wrong. Recycling is important, and I’m sure(?) apps can help change the world. But right now I feel I’m more in a reading/reflecting/researching mode. And it’s Friday night and I simply have to PRODUCE. Gah. I totally forgot what being a student really means. No real weekend, that is.

So. I might come back to you when I have more than some silly OmniGraffle icons — and hopefully I’ll also be in a better mood :/

How to take Kristin out for dinner

Tuesday, October 26th, 2010

The last weeks I have tried to analyze myself, my general behavior, and more specifically my relationship with food. Why? We got a flowchart assignment from Chris Fahey where he asked us to make an extensive functional specification for a human being. We were to imagine that the resulting document could be used by an actor who had to imitate the human. I figured that I could skip a lot of research by choosing myself as the “Human”, and my family and friends as my “Users”.

What a stupid idea! I know myself so well that creating a spec where I really am sincere about all possible decisions and choices running through my head during a scenario, turned out to be very hard. I ended up taking some short cuts and made myself more one-dimensional and strict than I really am, just to get through this. I still feel that the essence of my preferences when it comes to restaurants, transportation and food is being conveyed. I also had to think about how my friends and family usually “experience” me in the scenarios; what they like or don’t like about my human behavior. I took the liberty of putting words in their mouths for this part, as well as using their Facebook profile photos to make the spec more interesting.

Here’s a little snapshot of how I and my “user” typically would decide on a place to eat:

Click the image to get the whole How to take Kristin out for dinner-specification. That pdf will take you through the following steps:

OVERVIEW
A short presentation of the “Human” (me) and some of my users.

01. DECIDE ON PLACE TO EAT
How will users interact with Kristin to agree on a place to go out to eat? Which inner desires are hidden behind Kristin’s reply to various restaurant suggestions?

02. DECIDE ON TRANSPORT
Food is not just about the making or eating. For Kristin, getting to the place where the food is served is a part of the experience. If time and budget allows it, transforming hunger into an opportunity to explore a new place is simply perfect! Don’t think transport. Think field trip.

03. AT THE RESTAURANT
This final step focuses on the way Kristin decides what to order — what she looks for in a menu. The fact that she wants to keep the menu on the table during the whole dinner, and that she prefers to bring the menu with her home afterwards, is another story.

SORRY, friends, if you feel I have portrayed you all wrong. If you’re very, very mad because you got a stupid quote, next dinner is on me ;)

So… Would you like to act as me for a night, being all picky about restaurants, and eat lots of blue cheese? Or do you just wonder how you should take me out for dinner in a way that makes me very happy? Either way, study this spec. Yup.

MoMENT (III) Prototype

Sunday, October 24th, 2010

PROTOTYPING
We fired up my favorite program of all times, OmniGraffle, to create something that was a bit more comprehensible than our cafe sketches. These wireframes were then printed out to become a very low-fi prototype to use when testing our concept on other people.

USABILITY TEST
We conducted the usability test by letting four people go through some scenarios on the paper prototype, and encouraging them to speak out loud about their thoughts and experiences with the app. Considering that these four people were from our class, they weren’t all a perfect match with the personas we had created. We still feel we got many valuable insights from the test, and could improve our app based on that.

In general, we got a lot of positive feedback on the app. Some of our users even claimed that this app would increase the probability of them doing more research about their favorite artists when they get home after the visit. However, users were insecure about the sharing experience, and they wanted more clarity about privacy settings. Some users found the Our MoMA concept a bit difficult to understand too. Considering that this concept relies heavily on animation, doing usability test on this with a paper prototype was a bit difficult.

REFINING THE PROTOYPE
Based on the usability test, we could refine our prototype before our final presentation. We could even add some smooth PowerPoint animations to get the feel of how the Our MoMA concept would work. Here are some key screen shots from the prototype:

Click on the photo to view them larger, or view the MoMENT prototype in a PowerPoint format with animations and all!

Read more: To read about my overall reflections about the MoMENT project, go to the main post about the project: MoMENT: Concept development through research.

Blog

Racing Heart

In January 2010 I attended a concert with Mathias Tjønn in Oslo. It was one of those excellent concerts that I even blogged about! And as it turned out, Mathias is a nice guy too. We both live in the same hood in Brooklyn now, and I have attended quite a few more shows with [...]

Search the blog

...or browse through the archives.