Ambient Etch-a-Sketch

Connie Wan (cwan), Angela Dai (adai), Kiran Vodrahalli (knv), Edward Zhang (edwardz)

Group 13 (aka CAKE)

We built a pseudo Etch-A-Sketch emulator that modifies its appearance based on the user’s environment – the temperature and light conditions. Instead of only drawing horizontal and vertical lines, we can draw curved lines by changing the slope of the current line to be drawn. We use two potentiometers to serve as the knobs of this “Curve-A-Sketch” and use Processing to display the user’s drawing. The ambient light level controls the color of the drawing, while the temperature controls the width of the stroke. This project was a lot of fun to play with because of the nostalgia of playing with a childhood toy, enhanced with the novel control of changing its color and stroke width – for example, we could change colors simply by touching the temperature sensor, and width by moving our head over the photoresistor. We also wanted to blow on the temperature sensor to change color, but it didn’t quite work out because of some bugs with a clear button. The clear button only worked sometimes, because the circuit was a bit buggy– quick changes in resistance messed up the data we sent from the Arduino to processing.

Sketches

Ambient Etch-A-Sketch: Remember the Etch-a-Sketch? This lets you do everything the Etch-a-Sketch did, and more! The features of your cursor , such as color and pen width, change based on your ambient environment conditions (temperature and light).

 

The upper half of this image shows an LED light array that lights up in concert with the location of your finger. With an added control for color, you can create a mini light show using just your hands.
The lower half shows our Smart Nightlight. As its basic function, the tricolor LED will be brighter if the room is darker (we put a screen between the LED and the photoresistor to eliminate feedback). The user can change the color and the overall brightness of the nightlight.

 

Storyboard

Ambient Etch-A-Sketch Storyboard

Final System


This video demonstrates the features of our Ambient Etch-a-Sketch. It shows the user controlling the color and pen width with the photoresistor and thermistor, respectively.

List of parts

  • 2x Potentiometer (rotary)
  • 1x Arduino Uno
  • 1x Push Button
  • 1x Photoresistor
  • 1x Thermistor
  • 3x 10KΩ Resistor
  • 1x Breadboard
  • Wires
  • Computer

Instructions

  1. Plug the two potentiometers into opposite sides of the breadboard. Fix an orientation – the one on the left controls the horizontal coordinate, and the one on the right controls the vertical coordinate. Attach the middle pin of the right potentiometer to A0 and the middle pin of the left potentiometer to A1. Attach the side pins of both potentiometers to 5V and ground.
  2. Connect one side of the thermistor to 5V, and the other side to A2 and ground through a 10KΩ pull-down resistor.
  3. Connect one side of the photoresistor to 5V, and the other side to A2 and ground through a 10KΩ pull-down resistor.
  4. Connect one side of the push button through a 10KΩ resistor to 5V and the other side to D2 and ground.
  5. Run the Arduino code, and then start the Processing application
  6. Draw! The extreme settings of the knobs correspond to the sides of the Processing window. You can adjust the color by shadowing the photoresistor (e.g. leaning over so your head blocks some light), and change the stroke width by changing the temperature (the easiest way is by pressing the thermistor between your fingers).

Source Code

Arduino Code

/*
 Ambient Etch-a-Sketch!
 Lab 1
 COS 436: Human-Computer Interfaces
 February 20, 2013
 
 */

//variables 
int y; //y coordinate of etch-a-sketch
int x; //x coordinate of etch-a-sketch
int temperature; //temperature of the room 
int light; //light ambience of the room 
int clearButton; //clear Button 

//pins
int pinY = 0; 
int pinX = 1; 
int pinTemperature = A2; 
int pinLight = 3; 
int pinClearButton = 7;

void setup()
{
  // initialize the serial communication:
  Serial.begin(9600);
  
  // initialize the clear button as an input 
  pinMode(pinClearButton, INPUT);
  
}

void loop() {
  // read data on every loop 
  x = analogRead(pinX);
  y = analogRead(pinY);
  light = analogRead(pinLight);
  temperature = analogRead(pinTemperature);
  clearButton = digitalRead(pinClearButton);
  
  //test it works
  //Serial.println("Scaled x: \n");
  if((x < 1024) && (y < 1024) && (light < 1024) && (temperature < 1024) && (clearButton <= 1)) {
    Serial.println(x); 
    Serial.println(y);  
    Serial.println(light); 
    Serial.println(temperature);
    Serial.println(clearButton);
  }
  delay(100);
}

Processing Code

//Lab 1: Resistance 
//Connie Wan, Angela Dai, Kiran Vodrahalli, Edward Zhang 
//Feb 27, 2013

import processing.serial.*; 

Serial myPort;
float dx; //change from controls
float dy; //change from controls
float old_dx; //check prev
float old_dy; //check prev
float x; //curent position 
float y; //current position
float light;  //current lighting
float temperature; //current temperature 
int clearButton; //clearButton 
String input; //get data from Arduino 

static final int X_WIDTH = 400;
static final int Y_HEIGHT = 400;
static final int UNIT_DRAW = 20; 

void setup() {
  //init
  myPort = new Serial(this, Serial.list()[4], 9600);
  println(Serial.list());
  x = 200;
  y = 200;
  size(X_WIDTH, Y_HEIGHT);
  colorMode(HSB, 255, 255, 255);
  background(0, 0, 255);
  stroke(0); 
  myPort.clear();
  if(myPort.available() > 0) {
    input = myPort.readStringUntil('\n');
    if(input != null){
      String xval = trim(input);
      old_dx = Integer.parseInt(xval);
      println(dx);
    }
    
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String yval = trim(input);
      old_dy = Integer.parseInt(yval);
      println(dy);
    }
   
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String lval = trim(input);
      light = Integer.parseInt(lval);
      println(light);
    }
  
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String tval = trim(input);
      temperature = Integer.parseInt(tval);
      println(temperature);
    }
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String cval = trim(input);
      clearButton = Integer.parseInt(cval);
      println(clearButton);
    }
  }
  myPort.clear();
}

void draw() {
  
 while(myPort.available() > 0) {
    input = myPort.readStringUntil('\n');
    if(input != null){
      String xval = trim(input);
      dx = Integer.parseInt(xval);
      //println(dx);
    }
    else {
      return;
    }
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String yval = trim(input);
      dy = Integer.parseInt(yval);
      //println(dy);
    }
    else {
      return;
    }
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String lval = trim(input);
      light = Integer.parseInt(lval);
      //println(light);
    }
    else {
      return;
    }
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String tval = trim(input);
      temperature = Integer.parseInt(tval);
      //println(temperature);
    }
    else {
      return;
    }
    input = myPort.readStringUntil('\n');
    if(input != null) {
      String cval = trim(input);
      clearButton = Integer.parseInt(cval);
      println(clearButton);
    }
    else {
      return;
    }
    myPort.clear();

    if(clearButton == 1) {
      background(0, 0, 255);
    }
    
    //scaling
    
    
    dx = UNIT_DRAW*((dx/1023.0) -0.5);
    dy = UNIT_DRAW*((dy/1023.0) - 0.5);
    
    light = light/1023.0;
    temperature = (temperature - 500) *(255.0/100.0);
    if(temperature  255) {
        temperature = 255;
    }
    
    println(temperature);
    //change color
    stroke(temperature, 255, 255);
    //change thickness
    strokeWeight(10*light);
      if(x >= X_WIDTH) {
          x = X_WIDTH;
      }
      if(y >= Y_HEIGHT) {
          y = Y_HEIGHT;
      }
      print("x: " + x + "\n");
      print("y: " + y + "\n");
      
      if(((dx  old_dx -.01))){
        dx = old_dx;
      }
      if(((dy  old_dy -.01))){
        dy = old_dy;
      }
      
      if((dx != old_dx) || (dy != old_dy)){
        line(x, y, x + dx, y + dy);
        x = x + dx;
        y = y + dy;
     
        old_dx = dx;
        old_dy = dy;
      } 
  } 
}

L1: Expressive Drum Pad

Krithin Sitaram (krithin@)
Amy Zhou (amyzhou@)
Daniel Chyan (dchyan@)
Jonathan Neilan (jneilan@)
Thomas Truongchau (ttruongc@)

Group 11

Expressive Drum Pad

We built a drum pad that can play a range of pitches controlled by a softpot (touch sensitive slide), along with a range of amplitudes controlled by a FSR. The harder a performer strikes the FSR, the louder the buzzer sounds. Sliding towards the right will cause an increase in pitch, while sliding towards the left will cause a decrease in pitch. Combining the two controls, a performer can play a variety of virtuosic pieces that require a single voice. We decided to build the Expressive Drum Pad because we all appreciate music creation and wanted to contribute to the creative musical process. The Expressive Drum Pad turned out nicely as it allows the performer to control pitch and amplitude rather effectively through an intuitive, yet unpolished interface. Future improvements would include having an enclosure to hold down the sensors.

Parts Used
– 1 Arduino
– 1 FSR
– 1 softpot (touch-sensitive slide)
– Buzzer (replaced by computer speakers for additional volume)
[Reid approved this substitution.]

Connect the softpot to 5V, Ground, and an Arduino analog input pin. Connect the buzzer (computer speakers) in series with the FSR as part of the circuit from an Arduino digital output pin to ground. Angle the breadboard such that the softpot and FSR lie flat on a table.

Source Code:

int OUTPUTPIN = 3;
int FSRPIN = 5;
int SOFTPOTPIN = 0;
int MINSOFTPOT = 0;
int MAXSOFTPOT = 1024;
int MINPITCH = 120;
int MAXPITCH = 1500;

void setup() {
pinMode(OUTPUTPIN, OUTPUT);
Serial.begin(9600);

}

void loop() {
int frequency = map(analogRead(SOFTPOTPIN), MINSOFTPOT, MAXSOFTPOT, MINPITCH, MAXPITCH);
tone(OUTPUTPIN, frequency);
delay(2);
Serial.println(analogRead(FSRPIN));
}

Sensor-Based Authentication

1) Names: Philip Oasis, Alice Fuller, Gene Merewether, and Rodrigo Menezes
2) Group Number: 6
3) We built a sensor-based authentication system. The idea behind it is that you enter in a code the first time, and then on subsequent uses you have to enter in the same code. We had three sensors: two potentiometers which had to be turned the correct degree and one slide sensor which had to have your finger placed in the correct position. The end result was really great. The correct position, given a small amount of error could be found again, but a knowledge of the initial code was still needed. When you got the code correct a green light went off, and when you got it wrong a buzzer went off. I enjoyed the fact that you had to have your finger in the correct position on the sensor while you pushed the button, the multiple tasks reminds me of cool authentication systems that you see in movies. It might have been nice to have things in a prettier display; we could have obscured the wires better, had the sensors further apart to improve ease of movement, had written instructions. This would have also been much better if there was an actual lock to unlock.

4)

This is a simple reaction game in which the buzzer sounds, the user hits the button as quickly as possible, and the LED then lights up to give them feedback on how quickly they reacted.

 

This is a memory game in which the user hits buttons to recreate the order the LED’s flashed, and the sequence gets one light longer for each round the user gets correct.

 

 

 

This is a racing reaction game in which the LED flashes red, yellow, and green and then the user tries to hit the button as soon as possible after a green.  The buzzer would go off in the event of a false start, and the LED would light up with a color to indicate the reaction time.

5) Storyboard:

6) Demo Video: Lab 1

7) Parts List

  • 2 potentiometers
  • 1 slide sensor
  • 1 button
  • 1 buzzer
  • 1 green LED
  • 2 bread boards
  • 1 arduino
  • 2 330Ω resistor
  • 1 10kΩ resistor

8) Directions

Attach these all on one breadboard:
Attach one potentiometer to pin 0 on the arduino, the other to pin 1. Attach the button to pin 2, the buzzer to pin 3, and the led to pin 5. There should be a 330 ohm resistor attached with the led and the buzzer, and a 10k ohm to the button. The two potentiometers should be next to each other at the front, the button should be just behind them, and the buzzer and led are at the back of the breadboard. On the separate smaller breadboard place the slide sensor and connect it to pin 2.

9) Source Code

const int potentialPin1 = 0;
const int potentialPin2 = 1;
const int slidePin = 2;

const int buttonPin = 2;
// pull-down resistor; LOW is not pressed
const int buzzerPin = 3;
const int ledPin = 5;

const int tolerance = 64;
const int buzzerTone = 20;

int lock1 = -1;
int lock2 = -1;
int lock3 = -1;

void setup()
{
pinMode(buttonPin, INPUT);
pinMode(buzzerPin, OUTPUT);
pinMode(ledPin, OUTPUT);
Serial.begin(9600);

while (digitalRead(buttonPin) == LOW) // wait until button is pressed
{
delay(100);
}

// enter in lock code
lock1 = analogRead(potentialPin1);
lock2 = analogRead(potentialPin2);
lock3 = analogRead(slidePin);
digitalWrite(ledPin, HIGH);
Serial.print(“Potentiometer1 = “);
Serial.println(lock1);
Serial.print(“Potentiometer2 = “);
Serial.println(lock2);
Serial.print(“Slide sensor = “);
Serial.println(lock3);
}

void loop()
{
int buttonState = digitalRead(buttonPin);
int potentialState1 = analogRead(potentialPin1);
int potentialState2 = analogRead(potentialPin2);
int slideState = analogRead(slidePin);

Serial.print(“Potentiometer1 = “);
Serial.println(potentialState1);
Serial.print(“Potentiometer2 = “);
Serial.println(potentialState2);
Serial.print(“Slide sensor = “);
Serial.println(slideState);

if (buttonState == HIGH) // pressed
{
if ((potentialState1 < (lock1 + tolerance)) &&
(potentialState1 > (lock1 – tolerance)) &&
(potentialState2 < (lock2 + tolerance)) &&
(potentialState2 > (lock2 – tolerance)) &&
(slideState < (lock3 + tolerance)) &&
(slideState > (lock3 – tolerance)))
{
digitalWrite(ledPin, HIGH);
delay(1000);
}
else // not correct code
{
digitalWrite(ledPin, LOW);
analogWrite(buzzerPin, buzzerTone);
delay(1000);
}
}
digitalWrite(ledPin, LOW);
analogWrite(buzzerPin, 0);
}

Lab1

Group Members: Matthew Drabick, Adam Suczewski, Andrew Callahan, Peter Grabowski

High Level Description:

Access to inexpensive, portable medical equipment is a serious problem in many developing countries. There are currently solutions available, but many ignore the diagnosis of neurodegenerative disorders. We aim to provide a compact, easy to use package to aid in the diagnosis of such diseases using 3 basic tests.

First, our diagnostic suite includes a spirometer to measure lung capacity and expulsion rate. This is an important metric, for shortness of breath can be an indication of increased brain pressure, stroke, or tumors (Shortness of Breath).

Second, our diagnostic suite includes a measure of reaction time. Many patients with Parkinson’s disease have difficulty initiating movement, and as a result exhibit an increase in reaction time (Movement Disorders). This test can help diagnose some of those cases.

Third, our diagnostic suite includes a digital strength test. Difficulty with finger movements or strength can be an indicator of polyneuropathy (Physical Examination). Our strength test attempts to give a more honest evaluation of finger strength.

Physicians or volunteers can use our simple device to as a preliminary test for many neurological conditions. While the diagnosis is no means certain, it can be a useful tool to identify patients who are good candidates for further diagnostic testing. Below is an image of the system.

 

A look at the final product

 

Works Cited

Bozkurt, Biykem, and Douglas Mann. “Shortness of Breath.” Shortness of Breath. N.p., n.d. Web. 23 Feb. 2013.

“Movement Disorders.” American Association of Neurological Surgeons, n.d. Web. 23 Feb. 2013.

“Physical Examination: Diagnosis of Brain, Spinal Cord, and Nerve Disorders.” Physical Examination: Diagnosis of Brain, Spinal Cord, and Nerve Disorders: Merck Manual Home Edition. Merck, n.d. Web. 23 Feb. 2013.

Story Board:


High Level Design Process:

During the brainstorming stage we came up with a few ideas including:

-A system to control a lamp based on lighting in the room (turn the lamp off if the room is light, turn the lamp on if the room is dark)

-A system to detect different types of coins using an FSR.

-A flex sensor controlled etch a sketch that draws to a computer monitor.

We decided to go with the medical testing suite because it’s flexible, potentially useful, and uses a wide array of the resistive sensors in our arsenal.

Our initial design looked something like this:

The idea was to have the 3 tests stationed radially on a platform. We would then have the user select a test using the pot in the center of the 3 tests. After writing our code though and implementing the tests on breadboards, we soon encountered difficulty with this setup. The challenge was that without soldering, we could not connect wires to our circuit components. To overcome these design issues, we changed our design to something more similar to the sketches below using several breadboards. In this setup, we moved the pot off to the side, and gave each test its own independent “station.”

 

The tests are spread out as far as possible using 3 breadboards. The pot is used to select the test.

Another design sketch when were realized we needed to rearrange circuit components.

The reaction time test “station”

Though this implementation was not as smooth or intuitive as the one we imagined, we were satisfied with the implementation given the materials we were working with. It took a bit of tweaking and trying different layouts to get our system in order, but in the end the system was structurally stable, functional, and reasonably easy to understand.

In addition to the physical layout of the testting system, we also had to work out the design of the tests themselves. We had the most trouble getting the spirometer working. Sometimes, the spirometer would not register when a user started blowing, while other times, it would think the user had stopped blowing when the user had not. To overcome these problems we tried directing the user’s breath through tubes, changing the position and width of the spirometer fan, and playing with the delay right before the start of the test. In the end it took the right modification of each of these factors to get the test working. Aside from the spirometer, we also had some difficulties detecting when the user is not touching the softpot. These difficulties were mitigated to some degree by adding a 10K resistor between the ground and output.

Overall, we were pleased with the way they way the design process went. By testing a series of different layouts, we think that we’ve arrived at an interface that provides a straightforward method of interacting with the system. We think the project could use a little more polish in order to make it more intuitive for first time users, but that much of this polish would come with being able to solder and permanently install the components into some housing.

Technical Design Description:

Reaction Time Test:

In the reaction time test, the user places their finger in the center of a softpot. Then, one of two LEDs placed the right and left of the softpot turn on. The user must move their finger in the corresponding direction as quickly as possible. If the user is quick enough and passes the test, the green feedback light flashes. It the user is too slow and fails the test, the red feedback light flashes.

Basic information on softpots can be found here: http://bildr.org/2012/11/touch-sliders-with-a-softpot-arduino/

Spirometer:

In the spirometer test, the user blows on the flex sensor for as long as possible. Our device times how long the user can keep the flex sensor bent beyond some minimum threshold. If the user blows long enough, hard enough, and passes the test, the green feedback light flashes. It the user fails the test, the red feedback light flashes.

Basic information on flex sensors can be found here: http://bildr.org/2012/11/flex-sensor-arduino/ 

Strength Test:

In the strength test, the user squeezes the FSR as hard as possible and our device measures the the maximum reading. If the user squeezes hard enough and passes the test, the green feedback light flashes. It the user fails the test, the red feedback light flashes.

Basic information on FSR’s can be found here: http://bildr.org/2012/11/force-sensitive-resistor-arduino/

Test Selection:

The device detects which test the user selects by reading the value from the pot. The range of pot values is divided into 3 sections, each of which correspond to a test.

Basic information on a pot can be found here: http://www.arduino.cc/en/Tutorial/Potentiometer

How to:

1) Install the FSR, pot, softpot, and flex sensor on a breadboard using the tutorials linked to above. Test each sensor by printing its value to Serial output.

2) Install 4 LEDs to be used in the tests. Write test code to make sure each one is wired correctly. (Refer to the Blink tutorial if help needed).

3) Upload the code below, making sure the input pins of your sensors and LEDs correspond to the pins in the code.

4) Test the system. If everything is set up correctly, the system should work as it does in the video. If it does not work, check your wire connections. If all of your wires seem to be connected correctly, write Serial.print() statements in the code to help debug your system.

5) Make your interface more usable by constructing housing out of cardboard or other material, and adding any other features such as a fan for the spirometer.

The Code:

typedef enum {
  LUNG_MODE,
  REACTION_MODE,
  SQUEEZE_MODE,
} 
game_mode_e;

game_mode_e gameMode;
int time_msec;

int redLedPin = 2;
int greenLedPin = 3;
int slideRightLedPin = 4;
int slideLeftLedPin = 5;

int flexPin = 0;
int flexReading;

int maxDelay = 30;
int delay_ms;

int maxFlexThresh = 315;
int flexTarget = 315;

int middleOfRT = 600;
int minRT= 100;
int slideLeftThreshold = 100;
int slideRightThreshold = 900;
int targetRT = 150;

int slidePin = 1;
int slideReading;

int potPin = 2;
int potMax = 1023;
int numChoices = 3;

int randChoice;

int squeezeReading;
int squeezePin = 3;
int maxSqueezeThresh = 400;
int squeezeTarget = 400;

// flash a given led
void flashLed (int ledNum) {
  analogWrite(ledNum, 0);
  delay(50);
  analogWrite(ledNum, 255);
  delay(200);
  analogWrite(ledNum, 0);
  delay(50);
}

void readPot() { 
  int potReading = analogRead(potPin);

  if (potReading < 340) {
   gameMode = LUNG_MODE;
  }
  else if (potReading < 681) {     gameMode = REACTION_MODE;   }   else {     gameMode = SQUEEZE_MODE;   }   Serial.print("Game Mode: ");   Serial.println(gameMode); } void setup(void) {   // We'll send debugging information via the Serial monitor   Serial.begin(9600);   gameMode = REACTION_MODE;   flashLed(redLedPin);   flashLed(greenLedPin);   randomSeed(analogRead(0)); } void loop(void) {   readPot();   switch (gameMode) {   case LUNG_MODE:     flexReading = analogRead(flexPin);       Serial.print("Flex reading = ");     Serial.println(flexReading);     // detect blowing start     while (flexReading > maxFlexThresh){
      Serial.println(flexReading);
      delay(50);
      flexReading = analogRead(flexPin);  
    }
    time_msec = 0;
    while (flexReading < flexTarget){
      delay(100);
      time_msec += 100;
      flexReading = analogRead(flexPin);  
    }
    if (time_msec < 1000){
      flashLed(redLedPin);
    } 
    else {
      flashLed(greenLedPin);
    }
    break;
  case REACTION_MODE:
    flashLed(slideLeftLedPin);
    flashLed(slideRightLedPin);
    slideReading = analogRead(slidePin);  

    // wait for them to put their finger in the middle
    while (slideReading < minRT){       slideReading = analogRead(slidePin);         flashLed(redLedPin);     }     // ready to go     flashLed(greenLedPin);     flashLed(greenLedPin);     delay(500);     // calculate random delay     delay_ms = random(maxDelay) * 100;     time_msec = 0;     delay(delay_ms);       randChoice = random(2);              // based on previously calculated randomness       if (randChoice == 0){         flashLed(slideLeftLedPin);       // while their finger isn't all the way on the left       while (slideReading > slideLeftThreshold){
        delay(10);
        time_msec += 10;
        slideReading = analogRead(slidePin);  
      }
    } 
    else{
      flashLed(slideRightLedPin);

      // while their finger isn't all the way on the right
      while (slideReading < slideRightThreshold){
        delay(10);
        time_msec += 10;
        slideReading = analogRead(slidePin);  
      }
    }

    // if they beat the target time
    if (time_msec < targetRT){
      flashLed(greenLedPin);
      flashLed(greenLedPin);
    }
    else{
      flashLed(redLedPin);
      flashLed(redLedPin);
    }

    break;
  case SQUEEZE_MODE:
    squeezeReading = analogRead(squeezePin);  
    // detect blowing start
    while (squeezeReading < maxSqueezeThresh){       delay(50);       squeezeReading = analogRead(squeezePin);       }          time_msec = 0;     while (squeezeReading > squeezeTarget){
      delay(100);
      time_msec += 100;
      squeezeReading = analogRead(squeezePin);  

    }
    if (time_msec < 3000){
      flashLed(redLedPin);
    } 
    else {
      flashLed(greenLedPin);
    }
    break;

  default:
    Serial.println("Unsupported mode");
  }
  delay(250);
}

L1

Names:
Farhan Abrol
Dale Markowitz
Collin Stedman
Raymond Zhong

Group Number: 4

Description

The interface consists of a force sensitive resistor, which the user either taps or holds to send dots or dashes, respectively. A piezo sensor beeps to provide feedback; a short pulse tells the user they have hit the FSR with enough force to trigger it, and a long pulse tells them they have held it down long enough to enter a dash.

Morse code is tricky to interpret, because not all characters are the same length (i.e. one letter might be a single dot, while another is several dots). In order to get around this, we set up a time interval for which dots or dashes a user enters are considered a single character. This is denoted by four LEDs that “count down” to indicate how long the user has to enter the next dot or dash within the same character.

Assessment

When deciding on what to build for this assignment, our team thought of many options involving interacting with sound through touch. We wanted to build something that was both simple and fun to play with. We went through many ideas involving sound synthesis (especially a drum simulator). Ultimately, we decided on a Morse code interpreter, because we felt it fit well with the supplies we had at hand.

All in all, we were very happy with the way our morse code converter turned out. Although the description sounds complicated, the device is intuitive once you sit down in front of it — and we had fun typing letters on a screen. Perhaps the thing that we are unhappiest with about our device is that it is not super relevant today (what a shame! it’s so fun to play with). It’s a device that might only be appreciated by specialists or true nerds. Whatever those are. 🙂

Storyboard

Photo Feb 27, 12 50 29 PM

Sketches

Photo Feb 27, 12 49 07 PM Photo Feb 27, 12 49 12 PM  Photo Feb 27, 12 50 52 PM Photo Feb 27, 12 50 59 PM Photo Feb 27, 12 51 04 PM

Parts List

Breadboard, wire, wire cutter/stripper
Arduino Uno
Force Sensitive Resistor
3 Red LEDS, 1 Yellow LED, and appropriate resistors for 5V source (varies by LED)
Piezo speaker
Computer and source code

Make it yourself!

Only requires everyday prototyping parts!

1. Obtain a force-sensing resistor, an Arduino microcontroller, an electronic breadboard, as well as several LEDs and appropriate resistors for each component.
2. Attach the force-sensing resistor to the center of the breadboard, in such a way that it can be taped onto the edge of the top of the breadboard.
3. Connect the FSR to the analog sensing port of the Arduino, using a pull-down resistor connected to ground.

circuit1

3. On the opposite side of the breadboard, attach a row of LEDs, connecting them to digital output pins on the Arduino through 330 ohm resistors.
4. Tape the FSR onto the breadboard so that it can be easily tapped or held with a finger.
5. Set the FSR pin, the first LED pin, and the number of LEDs used in the Arduino program.
6. Download the Arduino program, and run the keyboard filter on your computer.

Congrats, you can now type in Morse code!

Arduino Code

/* FSR simple testing sketch. 

Connect one end of FSR to power, the other end to Analog 0.
Then connect one end of a 10K resistor from Analog 0 to ground 
*/

int fsrPin = 0;     // the FSR and 10K pulldown are connected to a0
int fsrThreshold = 20;
int fsrReading;     // the analog reading from the FSR resistor divider
int delayTime = 10;
int buzzerPin = 6;

// number of delay loops for each symbol
int dotLength = 1;
int dashLength = 20; // 200ms
int letterSepLength = 100; // 1000ms
int pauseLength;
int tapLength;

// length of tones emitted for each button press
int dotToneLength = 30;
int dashToneLength = 100;

// LED status display
int firstLEDpin = 8;
int numLEDpins = 5;

void setup(void) {
  Serial.begin(9600);   
}

void sendLetterEnd() {
  Serial.println("2");
}

void sendDot() {
  Serial.println("0");
  tone(buzzerPin, 440);
  delay(dotToneLength);
  noTone(buzzerPin);   
}

void sendDash() {
  Serial.println("1");
  tone(buzzerPin, 1000);
  delay(dashToneLength);
  noTone(buzzerPin);
}

void lightLEDs() {
  for (int i = 0; i < numLEDpins; i++) {
    digitalWrite(firstLEDpin + i, 1);
  }
}

void dimLEDs() {
  for (int i = 0; i < numLEDpins; i++) {     if (pauseLength > i*letterSepLength/numLEDpins) {
      digitalWrite(firstLEDpin + i, 0);
    }
  }
}

void beep() {
}

void loop(void) {
  fsrReading = analogRead(fsrPin);  

  if (fsrReading < fsrThreshold) {     if (dashLength > tapLength && tapLength > dotLength) {
      sendDot();
      lightLEDs();
    }
    if (pauseLength == letterSepLength) {
      sendLetterEnd();
    }
    dimLEDs();
    tapLength = 0;
    pauseLength++;    
  } else {
    if (tapLength == dashLength) {
      sendDash();
      lightLEDs();
    }
    pauseLength = 0;
    tapLength++;
  }
  //Serial.print("Analog reading = ");
  //Serial.println(fsrReading);     // the raw analog reading
    delay(delayTime);
}

Processing Code:

github.com/dalequark/morsecode

[kaltura-widget uiconfid=”1727958″ entryid=”0_0e1153da” width=”400″ height=”360″ addpermission=”” editpermission=”” /]

Assignment 2 – Bereket Abraham

Assignment 2
Bereket Abraham

1. Saw the IDEO video.

2. Observed 3 people before CS 436 lecture on Tuesday. There were two guys that looked like COS majors sitting next to each. The third person was a girl sitting by herself (unknown major). I noticed that most people either talked to their friends or procrastinated on their computers. By procrastinating I mean they were checking their email, facebook, reddit, etc. I figure that between smartphones and laptops, most people in class are internet connected. This opens the door to class wide apps and online collaboration. Sometimes the professor was busy preparing for class and not necessarily available to engage in a group activity. The last reminding group of people is students arriving late. I think it would be hard to help this group, because most of them are hurrying from other classes across campus. Even if they had smartphones, most of them are probably too busy rushing to engage in some kind of activity.

3. Brainstorming group members: Bereket Abraham, Andrew Ferg, Ryan Soussan, Lauren Berdick

Note: For late people, we can’t have anything mandatory or that affects your grade at all. We want something relatively fun and relaxed, as a break between two mentally intensive lectures / class periods.

1. name game, get to know your neighbor

2. talent show

3. professor story time

4. joke telling contest

5. applications/videos of what you’re are going to learn in order to generate interest

6. crowdsourced music making. everyone gets to contribute a beat to a song, entire thing gets compiled

7. Current events related to the class. Example, speakers, new books, important figures, etc

8. One tough problem that everyone collaborates on and if they get it then the entire class gets extra credit

9. Crowdsourced, collaborative art project that everyone contributes to

10. Personal subreddit for the class.

11. Class votes on interesting questions for the professor, i.e. about his work or life experiences

12. Professor gives a brief summary / update of his current research or the state of his research field.

13. Riddle of the day, Google interview questions

14. class wide scrabble game

4. Top Two

1. Professor gives a brief summary / update of his current research or the state of his research field.
Description: A scheduled time when the Professor talks with the students about cutting edge research in the subject, possibly as simple as a brief description or a demo.

Something that points curious students in the right direction. One thing people always say about Princeton is that our professors are the best in their field. However, if you are in an intro class it hard to find out more about the more complicated / interesting stuff. Also, this is probably what interests the professor most. Finally, most grant seeking professors had a wealth of advertising or informational material about their work.

2. applications/videos of what you’re are going to learn in order to generate interest
Description: Over the course of the semester, students post and rank cool, class-related videos, links, news articles, and research papers.

Less motivated or interested students can browse the reddit-like aggregator before class. The problem here is that most students learn how to do something, but not why it is done. Giving real world examples will motivate them and give purpose to their work. The professor or TA will have to moderate the links, and students will post under their real names.

5. Picked #2 (course-related social aggregator)

DSC00657
Card 1: frontpage

DSC00646
Card 2: registration page. Added for realism.

DSC00647
Card 3: Menu of links

DSC00648
Card 4: List of scholarly papers.

DSC00649
Card 5: List of cool videos

DSC00650
Card 6: List of related news articles. Like / dislike functionality is shown.

DSC00651
Card 7: Submit window for a new link.

6. Tested prototype on 4 people. They included Ryan Soussan, Brandon Lewiston, Katie Knorr, and Sherene Agama.
Ryan instantly understood the interface and commented that he was familiar due to his experience with reddit.
Sherene got pretty far but didn’t realize that content was user-generated. She was also worried about trolls.
Brandon (a politics major) dully flipped through the links, but expressed interest in a version for his American politics class.
Katie (a lit major) also was un-interested in physics links, and wasn’t sure how the site could be adapted for a literature based class.

DSC00654
Image of Ryan Soussan, one of my test subjects.

7. Feedback

The feedback I received is divided into two camps: what I saw people doing wrong and what I they told me about their experience.
When I handed people my cards, everyone was able to register, login, and navigate through the various menu options. However, the finer points of the website were lost on most people (3/4). Most people knew it was a links / news aggregator, but few of them realized that the content was meant to be student-generated. Thus, only 2 people understood what the submit button was for, probably because they were familiar with reddit. As a result, I added cards 8 and 9. Card 8 occurs when you’re clicking the more button and finally run out of links. It asks you to submit more links to share with your classmates. I also redesigned the submit button into one that says Add a Link with a big plus sign (Card 9). Hopefully that is more self-explanatory.
The other thing I noticed is that very few people used the like/dislike arrows, even when they had clicked on the link. 3 out of 4 said they knew what they were for, either from reddit, princetonfml, or facebook. They all suggested color coding the like vs dislike option, and showing how many votes each link had. That would probably help with the 1 person who didn’t know what they were for.
Finally, one person cited lack of interest in the links. To be fair, my example person was in intro physics and had only physics related links. Everyone expressed interest in links related to their area of expertise, but were a bit blasé about other areas. On the plus side, everyone wanted to post stuff related to their own major. Also, everyone at least wanted to click on fun stuff like the videos.
One person brought up the fact that trolls might create fake email accounts to sign up and post ridiculous content. However, I pointed out that the system would be like piazza, where you’re email address determines what classes you can sign up for. People have to sign in with their real name and the TA or professor will probably moderate.

DSC00655
Card 8: New more page. Highlights the fact that content is user-generated.

DSC00656
Card 9: New submit button. More clearly communicates its purpose.

L1 – SoundBox

Group #1

  • Avneesh Sarwate (asarwate@)
  • John Subosits (subosits@)
  • Joe Turchiano (jturchia@)
  • Kuni Nagakura (nagakura@)
  • Yaared Al-Mehairi (kyal@)

Ideas and Sketches

  1. Squat Coach – Detects the depth of your squats and assesses your form.

    Flex sensor is positioned to run up the back of knee joint

    Flex sensor is positioned to run up the back of knee joint

  2. Etch-A-Sketch – Arduino version of Etch-A-Sketch game.

    Users control stylus with 2 rotational potentiometers

    Users control stylus with 2 rotational potentiometers

  3.  Adaptive Lighting – LED changes brightness depending on lighting of room.

    Photo cells connected to LED vary brightness of light emission based on surrounding light

    Photo cells connected to LED vary brightness of light emission based on surrounding light

  4. SoundBox – Musical instrument with a simple interface for intuitive interaction and immediate results.

    Users can control amplitude with FSR (force sensing resistor) and pitch with slider

    Users can control amplitude with FSR (force sensing resistor) and pitch with slider

We decided to choose idea #4. While we liked our other ideas, we felt creating a SoundBox would be the most feasible and rewarding endeavor.

Project Description

We built a musical instrument, called the “SoundBox”. The “SoundBox” allows users to create notes by applying pressure to a force sensing resistor. The amount of pressure applied determines the volume of the note and users can control the pitch of each note they create with a SoftPot Membrane Potentiometer (slider). When users create notes, a python program reads the incoming signals from the USB port (which the Arduino is speaking to). Our python program then feeds these signals to ChucK, an audio programming language, which then creates the sounds you hear. We are definitely pleased with the result of our project. The intuitive and simple nature of the “SoundBox” interface allows any user to create a variety of sounds and patterns. Thus, in giving the gift of music (albeit limited) to users, we feel that our project is successful. One thing we could certainly improve is the limited functionality of our “SoundBox”. For example, we could add a switch to the Arduino which would enable users to toggle through ChucK instruments (as of now the default instrument is the mandolin). Furthermore, we could add multiple sliders to enable users to play multiple notes at once. What’s more, we could speak to any MIDI receiving Audio Software, such as Ableton Live or Logic (which have extensive sound libraries), to fashion sounds out of user input. As such, there is definitely a lot of room for improvement in our design, which would seriously enhance the functionality of the “SoundBox”.

SoundBox

SoundBox

Storyboard

Loves music but can't play any instruments

I love music but I can’t play any instruments

This instrument is really easy to play!

This instrument is really easy to play!

'Making music'

‘Making music’

Wow, that was so easy!

Wow, that was so easy!

Photos and Video

SoundBox interface closeup

SoundBox interface closeup

SoundBox interface connections

SoundBox interface connections

Arduino setup

Arduino setup

Breadboard setup

Breadboard setup

Arduino and breadboard

Arduino and breadboard

Whole system

Whole system

Movie on 2013-02-26 at 21.36

Evaluation

The FSR was quite effective at picking up varying pressures and gave a
pretty convincing and natural feeling “pluck” that was sensitive to
tap intensity. The Softspot was adequate, but would sometimes behave a
bit unpredictably. We weren’t sure whether this was because of
hardware issues or simply our own clumsiness with a controller that
required very precise motions. Regardless, it was very intuitive to
use. Next time, we would have possibly added some kind of visualizer
to see what note you are at on the Softspot, or maybe added the
functionality to “bend” notes by sliding on the Softspot after
pressing the FSR to “pluck” a note.

List of Parts

  1. Arduino
  2. Breadboard
  3. Force Sensing Resistor
  4. Soft
  5. 10 kΩ Resistor
  6. Wires
  7. Alligator Wires
  8. Cardboard Box (to mount resistance)
  9. Electrical Tape

Circuit

"SoundBox" Circuit Diagram

“SoundBox” Circuit Diagram

Instructions

  1. Place sensors on cardboard box at comfortable distance and clip the alligator clips onto the ends. Use electrical tape to hold down the wires to the box. 
  2. Connect SoftPot Potentiometer to 5V port on one end and ground on the other. Input goes to Port A0 on the Arduino. (follow pictures and circuit diagram)
  3. Connect Force Sensing Resistor in series with 10kΩ resistor. Input to Port A2 on the Arduino. (follow pictures and circuit diagram)

Code

SimpleMidi.ino

#include <MIDI.h>

/* FSR simple testing sketch.

Connect one end of FSR to power, the other end to Analog 0.

Then connect one end of a 10K resistor from Analog 0 to ground

For more information see www.ladyada.net/learn/sensors/fsr.html */
int sliderPin = 0; // the FSR and 10K pulldown are connected to a0
int fsrPin = 2;

int sliderReading; // the analog reading from the FSR resistor divider
int fsrReading;
int pitch;
int velo;

void setup(void) {
// We’ll send debugging information via the Serial monitor
MIDI.begin(0);
Serial.begin(9600);
}

boolean touched = false;

void loop(void) {

sliderReading = analogRead(sliderPin);
fsrReading = analogRead(fsrPin);
pitch= map(sliderReading, 0, 1023, 0, 20);
velo = map(fsrReading, 0, 1023, 0, 127);
// the raw analog reading

if(velo > 5 && !touched) {
MIDI.sendNoteOn(pitch,velo,0);
//Serial.print(“FSR reading = “);
Serial.print(velo);
Serial.print(” “);
Serial.println(pitch);
touched = true;
}
if(velo <= 5) touched = false;
// if (MIDI.read()) {
// // Send a Note (pitch 42, velo 127 on channel 1)
// Serial.println(“YO!”);
// delay(1000); // Wait for a second
// MIDI.sendNoteOff(42,0,4); // Stop the note
// }

delay(5);
}

run.py

import serial
import OSC
import time

ser = serial.Serial(‘/dev/tty.usbmodemfa141’, 9600)

client = OSC.OSCClient()
client.connect( (‘127.0.0.1’, 6449) )
vel = OSC.OSCMessage()
vel.setAddress(“vel”)
pitch = OSC.OSCMessage()
pitch.setAddress(“pitch”)

while 1:
line = ser.readline()
# line = “50 13″
# print line
if ” ” in line:
print line
vel.append(int(line.split(” “)[0]))
pitch.append(int(line.split(” “)[1]))
client.send(vel)
client.send(pitch)
vel.clearData()
pitch.clearData()
# time.sleep(1)

chuckOSC.ck

// create our OSC receiver
OscRecv recv;
// use port 6449
6449 => recv.port;
// start listening (launch thread)
recv.listen();
// create an address in the receiver, store in new variable
recv.event(“vel, i”) @=> OscEvent vel;
recv.event(“pitch, i”) @=> OscEvent pitch;

Mandolin m => dac;

[0, 2, 4, 5, 7, 9, 11] @=> int scale[];

40 => int root;
3 => int octaves;
int pitches[octaves * scale.size()];
for(0 => int i; i < octaves; i++) {
for(0 => int k; k < scale.size(); k++) {
root + i*12 + scale[k] => pitches[i * scale.size() + k];
}
}

while(true) {
vel => now;
vel.nextMsg();
vel.getInt() => int v;
pitch => now;
pitch.nextMsg();
pitch.getInt() => int p;
<<<v, pitches[p]>>>;
v / 128.0 => float v2;
p + 60 => int p2;
Std.mtof(pitches[p]) => m.freq;
v2 => m.noteOn;
}

 

 

Princeton Waiting Time – Farhan Abrol(fabrol@)

Observations:

The first thing I realized when I was trying to think of whom to interview was that Computer  Science undergrads are not the typical end-users and most of the Princeton undergraduate population that has Princeton Time to spare isn’t from this specific demographic. So I decided to interview people in other disciplines and majors – Economics, EEB, Politics to get a better understanding of how they utilize this time.

  • Christine – At the end of previous class, find people who are in last class/who are going to similar place to walk over with. Like to get to class early , mostly play games on my phone and respond to urgent emails if I have any. More mindless the games the better.
  • Estelle – Browse facebook on the walk between classes, like getting to class on time. In class, Use the time to check email for managing schedule for rest of day – tutoring students, meeting for club, dinner with friends. No facebook in class.
  • Russell – On the phone while walking to class, reads news, emails (only reads, does not respond to any on my phone) Tries to find coffee/tea to pick up Get announcements/slides and reading for next lecture.When in class, respond to urgent emails, no facebook
  • Adoley – Chat/text friends to relax and disengage with class for a bit. Go to the bathroom and freshen up. Try and get reading/slides in order for the next lecture, take out notebook, pdf’s, pencils, silence my phone. Get prepped and in the zone for class

These interviews gave me an idea of the kind of users and the problems that they face. I also made independent observations of people in classes –

  • Reading today’s lecture, reviewing past notes
  • Bringing up slides of the lecture on their computer and their note taking program, lot of people would go to the course web page/blackboard, and the syllabus, and then find what they needed for this lecture.
  • Listen to music
  • Browsing Facebook, Reddit, news (no active creating of content)
  • Check calendars and schedule appointments
  • Browse email. Not many people were actually writing emails
  • Eating/drinking (mostly coffee)
  • Chatting with friends in class
  • Looking at flyers
  • Relaxing with their eyes closed
  • Playing games on cell phone or computer
  • Doing homework for other classes
  • Go to the restroom

Based on these interviews and observations I think i want to design an interface for the organized student who tries to prepare for lecture. I want to help this user be better prepared and organized for lecture. This is deliberately broad since this can be approached in many different ways, which will be explored in the next section –

Brainstorm Ideas: (with Kuni Nagakura)

  1. Meditation Helper: An application that plays soothing and calming songs to help students meditate and prepare for the class
  2. Brown noise emission that blocks out sounds so you can take a nap, and wakes up before lecture.
  3. Food/Coffee based path generator – Finds routes to next class which have coffee/free food places on the way so you can pick up on the way to class.
  4. Best Path Finder: Maps out the best route to the next class, looking for diversions etc. on the way
  5. Flashcard generating app for reviewing the material covered in last lecture and preview of concepts coming up.
  6. Class organizer: A simple lists of tasks you need to do before each class – call someone, open certain pdf’s, silence your phone, check laptop battery.
  7. Syllabus condenser – App that generates a list of all the readings for a day from the syllabi of different classes and let’s you access them quickly in one location without having to go through other places. Also print them.
  8. PrePrinter – Be able to send the readings for the next class to a printer cluster right at the end of the current class, and then show the nearest cluster where you can pick them up. Use 10 minutes to get your readings on the way to class.
  9. Outline reader – Professors create quick outlines that early students can access from mobile app.
  10. Survey for research, paid -Fill out quick 5-7 minute surveys and even split longer surveys across different Princeton Times and get paid for taking them.
  11. QuickMeetup – Find friends in other classes around you, and in your class, to walk together to your next class.
  12. 10 minutes around the world. an app that shows you a different country every time you’re early to class
  13. MealPlanner – Easily coordinate lunch/dinner plans for the week from one location with easy input for people you meet on the way and say that you should catch-up and get a meal sometime.
  14. Language Learner – 10 minute lessons. Listen to conversations/ lessons on handheld while waiting. Served in small bits so doesn’t get boring and still has good retention.
  15. Estimated Travel Time Calculator – Pools in information from number of people in class around you, construction/diversions and calculates the estimated time it will take to get to the next class. Includes maps for display
  16. Turntable.fm for class – Have classroom playlists that people can access and play the music on the class speakers before lecture as a community builder to meet people, and encourage not sitting with personal headphones.
  17. InTouch – Reminds people how much time they have gone without calling specific members of their family and helps them use the 10 minutes between class to stay in better touch with people back home.

Ideas chosen to Prototype:

  1. MealPlanner – This solves a very frustrating problem faced by many students, including myself and this scenario is one of the most commonly faced during the 10 minutes between class.
  2. Syllabus Condenser – Widespread use-case across all majors and disciplines which drastically improves and speeds up access to information used on a daily basis.

Prototypes:

Meal Planner

Syllabus Condenser

User Testing:

User 1: Eleanor

User 2 - Danielle -> Could not understand the reason for other sources besides Blackboard. -> Got confused about what to do after setup. Pressed the new of the class and not the Go To Today button. -> Tried to swipe down for next page.

User 2 – Danielle
-> Could not understand the reason for other sources besides Blackboard.
-> Got confused about what to do after setup. Pressed the new of the class and not the Go To Today button.
-> Tried to swipe down for next page.

User 3 - Megan  -> Could not understand the options for adding courses, and faltered in choosing. -> The Upload text option was unclear -> Asked if " Choose Source " meant "import from" -> Flicked page down to go to next page. -> Tried to find the other readings from the current reading by looking for a small list in the botton left.

User 3 – Megan
-> Could not understand the options for adding courses, and faltered in choosing.
-> The Upload text option was unclear
-> Asked if ” Choose Source ” meant “import from”
-> Flicked page down to go to next page.
-> Tried to find the other readings from the current reading by looking for a small list in the botton left.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Insights:

  • On the overall all users felt like the app solved a problem that they faced on a daily basis.
  • There was a concern raised by some people about the source of information for the app. Some classes don’t have strict syllabi on blackboard, but a website where the professor posts readings. Revision could use webpage-scraping as well as a source for the readings instead of just Blackboard.
  • The “Choose Source” page was a problem for many users. They found it hard to understand what the various choices represented since the idea of the syllabus is inherently only linked to Blackboard. The original design idea was to source the syllabus and readings from Blackboard, the schedule from ICE or SCORE, and allow for an option for the user to upload the PDF or text file for courses that didn’t have it up on the web. User feedback suggests that I should redesign this page to have a “import syllabus from” label which has Blackboard/Course Website/upload file, and a separate “import schedule from” label which has ICE/SCORE/Google Calendar option.
  • On the View Courses page that comes next, one user got stuck and did not understand that the next step was to click “Go To Today”, and clicked on the class. In the revision, clicking on the class should go to the next occurrence of the class in the calendar.
  • Most users (All of whom were Iphone owners and very used to the Iphone style of navigation) intuitively swiped down to go the next page of the reading. The current mapping has that swipe for going between readings and should be modified to match user intuition which has left-right swipe for navigation between documents and up-down swipes for going between pages.
  • Some users also were seeking a way to jump to a certain reading when viewing another reading. The revision could have a simple pop-up list that shows the list of readings with the current reading highlighted and easy one-click navigation to any reading.

Yaared Al-Mehairi – Assignment 2

Netid

  • kyal@

Observations

I conducted my observations during the 10 minutes before COS 333 (11:00 – 12:20pm) on Tuesday February 19th, PHI 322 (1:30 – 2:50pm) on Thursday February 21st, and COS 340 (3:00 – 4:20pm) on Monday February 25th. I arrived early to these classes on said days and noted the behavior of my fellow students and professors. In the process, I was able to interview a number of students.

General Activities

  • Students talking amongst themselves
  • Professor playing classical music and taking pictures (B.W.K.)
  • Students checking and responding to email
  • Professors trying to set up equipment/distribute materials for lecture
  • Students getting out notebooks and pens for lecture
  • Students sleeping
  • Students staring into space (i.e. relaxing)
  • Students listening to music
  • Students texting/making phone calls
  • Students doing/reviewing homework
  • Students surfing the web (on laptops and phones)
  • Students shopping online (mostly female students)
  • Students and professors reading (academic/non-academic materials)
  • Students drinking coffee/eating snacks
  • Students eating meals (mostly graduate students)
  • Students charging phones/laptops
  • Students checking dining hall/eating club menus
  • Students playing games (on laptops and phones)

Subject Interviews

  • Student 1 arrived early to COS 333. When I asked Student 1 what he/she did during 10 minutes before class, he/she indicated, “Not much apart from checking emails and surfing the internet.”
  • Student 2 arrived late to PHI 322. When I asked Student 2 (after lecture) what he/she did during 10 minutes before class, he/she indicated, “Nothing, usually it is hard to utilize the 10 minutes before 1:30 class because it is lunch time, there is much dining hall/eating club traffic and it takes some time to get from dining halls/eating clubs to class buildings.”
  • I passed Student 3 (whom I know is in COS 340) on the way to COS 340. Student 3 was a smoking a cigarette outside the lecture building. When I asked Student 3 what he/she did during 10 minutes before class, he/she indicated, “I usually require the 10 minutes to get to my next class, but sometimes I smoke a cigarette on the way.”

Review

From these observations, it is evident that people like to spend the 10 minutes before lecture in one of three ways: socializing, entertaining themselves, or working (in some fashion). Therefore, my design should look to cater to those who are looking to socialize, those who are simply bored, and those who are trying to be productive. Furthermore, my design should improve their lives by enhancing such kinds of activities.

Brainstorm Ideas (collaborated with Kuni Nagakura and McLean Shaw)

  1. “Tracktor” – An app that integrates with your music library and chooses a customizable playlist, whose duration is less than or equal to a specified length of time (perfect for your walk to/wait for class).
  2. “CourseView” – An app that integrates with ICE and offers students high-level summaries of past lectures/materials and upcoming course deadlines.
  3. “PitStop” – An app that finds food/drink (e.g. coffee shops, fast-food restaurants, vending machines) on your way to class based on tank status, which is user specified.
  4. “The Outside Initiative” – A proposal to introduce more outdoor social spaces on campus. A greater number of benches and trash cans outside (of which there are very few) on campus, for example, would allow more opportunity for socializing outside the classroom (something that is pretty tough to do in the school week).
  5. “Flag-A-Friend” – An app that integrates with ICE and your contacts so that users can let their friends know when and where they get out of class, thus enabling you to run into your friends even when swamped with class.
  6. “Docket” – An interactive device with both multiple sockets and screen interfaces that serves as both a charging dock for mobile devices (e.g. cell phones, laptops) and an info center for campus activities and schedules (e.g. dining hall/eating club menus, facility closing times, conference times, social events, student performances and so on).
  7. “BrownSound” – An app that generates brown noise (deep ambient rumble) that serves as a sleeping aid for those looking to catch some shut-eye before class.
  8. “Achilles” – An app that finds the most efficient routes from source to destination on campus including routes through buildings taking into account any congestion.
  9. “LunchBag” – An app that allows you to order meals-to-go from dining halls/Frist food gallery/eating clubs for pickup at a user specified time for students in a rush.
  10. “CampusLife” – An app that serves an info center for campus activities and schedules (e.g. dining hall/eating club menus, facility closing times, conference times, social events, student performances and so on).
  11. “ResourceFinder” – An app that finds the nearest restrooms, printers, scanners, computer clusters, convenient stores, coffee shops, vending machines, prox scanners (for updating prox privileges) and so on.
  12. “PrincetonTrivia” – A gaming app that quizes users on Princeton trivia.
  13. “PresenterFace” – An intuitive presentation interface for lecturers and preceptors that allows hassle-free pre-lecture/precept setup.
  14. “GymTime” – An app that offers 5-10 minute simple workouts that can be done in any environment.
  15. “CourseQuiz” – An app that integrates with ICE and offers multiple choice quiz questions on course material.

Favorite Ideas

My favorite ideas were “LunchBag” and “CampusLife” (#9 and #10 respectively).  I chose “LunchBag” because I think, based on my observations not only for this assignment, but also in general, a to-go food service at dining halls and eating clubs would greatly benefit students. Due to large queues and limited time, it is hard for a lot of students to get meals and to class on time. Students shouldn’t have to make this choice (especially when the majority of meal plans are paid upfront). I chose “CampusLife” because I think such an app would both serve as an extremely useful centralized resource for students and faculty alike and help to instill a greater sense of community on campus, since if people are aware of what’s going on, people are more likely to get together. Furthermore, both these apps can benefit from the student prox/netid system, thus making them rather simple to implement.

Prototypes

LunchBag

LunchBag homepage

LunchBag homepage

LB - DHalls

Dining halls page

LB - Eating Clubs

Eating clubs page

LB - Frist

Frist food gallery page

Butler menu page

Butler menu page

 

LB - Terrace

Terrace menu page (check box to select)

LB - Mexican

Mexican menu page

LB - Order

Order page (where user specifies pick up time)

CampusLife

CL - HomepageToStudent

CampusLife homepage (integrates with LunchBag)

CL - Culture

Culture page (daily/weekly student articles)

CL - Facilities

Facilities page (daily hours of operation)

CL - News

News page (University news)

CL - StreetPage

The street page (what’s open tonight + passes required)

CL - Student

Student performance page (on this week)

CL - Tigers

Tigers page (sports events on this week)

Feedback

I completed user testing with 3 different people.

LunchBag Photos

LB - HomepageToFrist

Home to Frist food gallery

LB - FristToMexican

Frist to Mexican menu

LB - MexicanToHome

Mexican menu to home

LB - HomeToEatingClubs

Home to Eating clubs

 

Eating clubs to Terrace

Eating clubs to Terrace menu

LB - TerraceToOrder

Terrace menu to Order

LB - OrderTest

Specify pick up time and submit order

 

CampusLife Photos

Home to The street

Home to The street

The street page

The street page

CL - StreetToHome

The street to home

Home to Student performances

Home to Student performances

Student performances page (on this week)

Student performances page

Users who tested “LunchBag” and “CampusLife” found the interfaces extremely simple and very easy to use. One user at first was unsure of how to go back a page on “CampusLife”, but shortly after discovered the “home” button (prototype is one level deep). Users in general remarked that they thought both apps would be extremely useful. Specifically, users indicated that “LunchBag” would be of great help to students in a rush and were confident that students would use it. In addition, users indicated that “CampusLife” could be the kind of fluid centralized service for campus activities and news in general that students are really looking for. Users also like the idea that “CampusLife” could integrate with “LunchBag”. One improvement suggested with regards to “CampusLife” was to allow users to purchase/reserve tickets for student performances and sports events. What’s more, generally users indicated that they would prefer more visually pleasing interfaces.

Insights

From the user testing, it is evident that clear layout and simple symbolization is key to the intuitiveness of a design, and therefore its accessibility. In general, users commented that both apps were successful because of their ease of use. Neither idea was particularly innovative, yet the ease of use coupled with clear organization of information seems to be of great value to the user.

Given the suggestion to allow users to purchase/reserve tickets for student performances and sports events through “CampusLife” (which I think is most definitely a good one), another point to take away from the user testing is to always remember who you are designing for. In my Brainstorm Ideas, I envisioned “CampusLife” being a kind of campus info center and as a result unknowingly narrowed the scope of the app’s functionality from an app that could provide users information and ways to use that information to an app that simply could provide users information. In any revision of “CampusLife, I would certainly add ticket purchase/reserve functionality for student performances and sports events.

Lastly, the user testing illuminated that even when using paper prototypes the aesthetics of an interface should not be completely ignored. People in general like to use things that are easy to use but also things that look nice. While, of course, when in the paper prototype stage, functionality is a designer’s primary concern, aesthetics is always a concern for the user.

 

 

A2-Joseph Bolling

I. Observation-I conducted my observations on three separate occasions before three different classes that I arrived early to.

A. Before HCI Lecture on Thursday 2/21, I observed two students speaking with each other as they unpacked their book bags and prepared for lecture. Their discussion focused on which classes they were both taking, since one had recently decided between two classes that he had been shopping. After they finished setting out their items for lecture (one had taken his computer out of his backpack, while the other had removed a pencil and paper), they sat down and continued discussing the weekend’s activities. Many people seem to use the time between classes socially like this pair. It’s possible that some method for facilitating communication would be helpful.

B. There’s a girl in my African Dance class who arrives at least 10 minutes early to every class and spends the time reading her organic chemistry textbook. I don’t actually know exactly when she arrives, but she is always sitting outside the room on a bench reading when I arrive at class. I observed her on Wednesday, 2/20, and saw that she was working on a problem from one of the chapters in her textbook. Since she is always studying the same subject, I would guess that her class schedule for orgo syncs up with our dance class such that she always has the same amount of time before her next orgo class when I see her. It’s not uncommon for students to spend their spare time between classes studying. There are, however, few assignments that lend themselves to the sort of burst studying-10minutes of work, 50 minutes of other activities-that the current class model encourages.

C. When I arrived in my COS 226 precept on Thursday, 2/21, the guy sitting in front of me had his laptop out and was clicking through emails, deleting and replying as necessary. Given the volume of email that arrives at the average Princeton.edu address each day, I would expect that checking email would be a major activity for the 10 minutes between classes. All of the subjects I observed had found useful things to do with the time between classes. This indicates to me that one way to improve the time might be to make more of it available to them, by shortening the time they spend traveling between classes.

II. Ideas:

  1. A phone application that tracks your fastest routes between classes
  2. A bike-sharing program tailored to high traffic times and areas
  3. An earpiece that lets you page through emails as you walk
  4. Recordings of textbooks that you could study as you walk
  5. Quiz questions that could be answered from the lecture hall or en route to class
  6. Concurrent lectures given in the same space using headphones for students
  7. An app that tracks your friends’ daily walking routes and plans intersections into your route
  8. An app that lets you know which of your friends are  in which dining/lecture halls
  9. A music player that selects a song based on the walking speed necessary for you to be on time
  10. A personal rapid transit network of autonomous golf carts
  11. A program that automatically downloads your lecture slides from blackboard
  12. A motorized system for carrying bikers and skateboarders to elevated parts of campus
  13. An app that tracks your sleep and recommends caffeine before classes as necessary
  14. An app that alerts you to leave based on average times to reach your classes
  15. A device that lets you review your notes as you walk

III. I chose to prototype my earpiece that pages through emails (#3), not because I felt it was my best idea, but because i had questions about the physicality of the device and how it would affect its usefulness.  I chose to prototype my app for tracking friends’ walking routes (#7), because  it seemed like the interface design would be important to the success of the app.

IV. Prototypes:

My prototype for idea 3 involved a broken coat hanger I had lying around and some paper buttons.  I tried to keep the interface as simple as possible, with only four buttons (aside from an assumed power switch).  I wanted to test whether a simple, intuitive, physical interface could still be valuable in an application that could be implemented as a phone app.

Paper cutout for prototype of idea 3.

Paper cutout for prototype of idea 3.

My creative materials source

My creative materials source

Completed prototype of idea 3

Completed prototype of idea 3

Fits like a glove.

Fits like a glove.

For Idea number 7, I prototyped by drawing up a very basic phone interface.  I went for a simple app that was designed to be used for 10 minutes at a time.

Splash screen, when user first opens app

Splash screen, when user first opens app

Friends page, which allows the user to pick a friend who is currently using the app and find them

Friends page, which allows the user to pick a friend who is currently using the app and find them

Map page.  The map displays the selected friend's location, as well as their predicted route based on their travel history at the current time of day.

Map page. The map displays the selected friend’s location, as well as their predicted route based on their travel history at the current time of day.

V. Testing

I tested my prototype for idea #3 on several students at different times:

A. Student 1 said she thought the earpiece would be useful, and complained about how much time she spent checking email each day.  She reported checking email quickly in between classes, as well as on her laptop in extended sessions.  She complained that the prototype fit loosely on her ear.  She felt that having a physical device was useful in that it would allow her to check her email intuitively on the move.

B. Student 2 said he didn’t see the point of the physical device, and felt he would prefer that the same functionality be implemented on his cellphone with a pair of headphones.  He agreed that having emails read to him via text to speech synthesis would be useful in checking email between classes, but didn’t see the use of a dedicated physical device. Student 2 said he felt “overwhelmed” by the daily volume of email he received, and did say that he would appreciate creative solutions to help him stay on top.

C. Student 3 said she thought the buttons were nice, but would probably not spend too much money to have a separate physical device when she could get the same functionality out of her phone.  When asked if she would consider using the device to write emails (via speech to text synthesis), she said that she probably would not because she would feel as if her privacy were not being protected if she had to speak her emails aloud in public.

D. Student 4 also felt overwhelmed by the amount of email she received each day. She reported checking email on her laptop between classes, in addition to spending roughly an hour each night checking her email at home. Student 4 was unique among the users tested in that she alone did not own a smart phone, and only used her laptop to check her email.  Tellingly, even she felt that the device would probably not be worth its cost when she could check her email on her laptop in class.

Student 4 examines the physicality of the prototype

Student 4 examines the physicality of the prototype

VI. Insights Gained from Testing

From my testing, I concluded that the physical headset is probably not worth the production cost in my model.  most users would prefer to use their phone and a pair of headphones.

The idea of synthesizing text to speech for email checking is sound, and could be valuable to users who like to check their email in short bursts.  Many users praised the simplicity of the interface, and said they would benefit from an application that would make it easier to check email while in transit. Thus, while the functionality of the tested design is sound, testing indicates it would be better implemented as a software application for a mobile phone.