Assignment 3: Bonnie, Harvest, Valya, Erica

Names


Bonnie, Valya, Harvest, Erica

Short summary of our discussion of each of the four discussion questions

1. Most severe problems with the app/site?

iTunes has a lot of problems with hidden options, features, and menus. Most icons don’t have any text associated with them, even on rollover, which meant that we had no idea what many of them did. To fix the UI, we recommend including more text along with the icons, as well as displaying important features like the sidebar by default. While iTunes 11 is trying to look minimalist by removing the sidebar by default, there are a lot of functions that aren’t implemented anywhere else. So, either the sidebar should be viewable by default, or there should be some sort of indicator showing that the sidebar can be expanded.

2. Which problems were made easier to find by the list of Nielsen’s heuristics?

Nielsen’s heuristics helped us realize how terrible hidden features are, and find some features that we may not even have known existed. Many of us discovered new features, including things like “play next” and “show sidebar.” We also thought that they helped us articulate why some UI issues were problems.

3. Did anyone encounter usability problems that seemed to not be included under any of Nielsen’s heuristics? Additional heuristics?

Nielsen’s heuristics are broad enough that generally everything can be crammed into one of the categories. However, Nielsen doesn’t have a clearly defined category that emphasizes user workflows; iTunes has several workflows that are too long, branch too much, or are difficult to find the correct path through; these kinds of usability issues plague many interfaces, but they don’t show up under a clear category in Nielsen’s heuristics.

4. Useful class discussion questions or final exam questions

  • How does your consideration of the heuristics change if thinking from the perspective of a disabled user?
  • What insights do Nielsen’s heuristics give you that general usage of the interface wouldn’t?
  • What happens when you can’t reasonably satisfy multiple Nielsen heuristics in a given design? Does that mean the design is fundamentally incorrect, or are there reasonable cases where a designer must choose which heuristic takes priority?

Links to individual heuristic evaluations


Erica: https://docs.google.com/document/d/1bO7fgCGKGg9M-pNOGSogmzvatyzKAcvbeYNMFblXo5E/edit?usp=sharing
Valya:
https://www.dropbox.com/s/cdkw98990o79jdz/Heuristics.pdf
Harvest:
https://docs.google.com/file/d/0B9ZsvvU1nAexM2xMenZCSTVnVWc/edit?usp=sharing
Bonnie:
https://docs.google.com/file/d/0BzHbdcSoIIg5MUVvckxmQmV2MEU/edit?usp=sharing

L2: Coin Chime

Group Name: %eiip

Group members: Mario Alvarez (mmcgil@), Bonnie Eisenman (bmeisenm@), Erica Portnoy (eportnoy@), Valya Barboy (vbarboy@)

What we built: We built a “coin chime” — a small, windchime-like instrument using a bunch of quarters and alligator clips. Some of the quarters act as proximity sensors; when they come near the other quarters (or even better, touch), they send a signal to the Arduino, which in turn causes the buzzer to make noise based on this input. We built this because we thought that windchimes are cool, and somewhat unconventional in terms of “musical instruments.” We really like our result; it’s fun to play with, even though it’s difficult to intentionally produce “music.” If we were to improve upon our design we would probably add more proximity-sensing coins (currently there are only two), and we would probably refine the code that determines what sounds are played to make it more closely mimic a set of chimes. We also would like to experiment with the proximity sensors; using the code provided, if the delay between readings is too short the sensors don’t function correctly.

Erica using the coin chime. Above, you can see the setup, including the Arduino and buzzer.

The final setup: a bunch of quarters hanging from alligator clips, an Arduino, and a buzzer. The coin pouch keeps the quarters in place. Two of the quarters are proximity sensors.

Prototype 1: Gong with Piezo.

Building the prototype of our “gong,” using the Piezo and a paper plate.

Our first prototype is a “gong”-style instrument using a Piezo. The Piezo detects vibration, and then based on the level of vibration, a short program instructs the buzzer to sound.

Prototype 2: 

We call our second prototype the “Shakey.” It creates noise using a buzzer depending on how much you shake it (which is measured using the accelerometer). The noise is pseudorandom.

Prototype 3:

This is an early version of our coin chime. The first coin is a proximity sensor; we were testing what threshold was necessary for it to sense the second coin somewhat reliably. When the proximity sensor’s output passes a certain level, the buzzer sounds.

List of Parts:

  • ~12 Quarters
  • 1 Arduino
  • 2 10 Megaohm Resistors
  •  Wires
  • Alligator clips
  • 1 Buzzer
  • 1 USB cable
  • 1 Breadboard

Instruction for Recreation:

Circuit diagram for Coin Chime

Using the above diagram, recreate the circuit; the resistors pictured should be 10 megaohm resistors, and the two circles connected to them are quarters. The quarters should be connected using alligator clips or something similar, so that they can be dangled off of a ledge. Then, attach a bunch of other quarters to alligator clips and dangle them together with the two proximity-sensing quarters. (The extra quarters needn’t be connected to the circuit.) Finally, load up the code below, and start playing with your coin chime! Optional modifications include adding extra proximity-sensing quarters.

Source code:


#include 
int speakerPin = 9;

CapacitiveSensor   cs_4_2 = CapacitiveSensor(4,2);       
CapacitiveSensor cs_13_12 = CapacitiveSensor(13,12); 

int tempo = 300;

void playTone(int tone, int duration) {
  for (long i = 0; i < duration * 1000L; i += tone * 2) {
    digitalWrite(speakerPin, HIGH);
    delayMicroseconds(tone);
    digitalWrite(speakerPin, LOW);
    delayMicroseconds(tone);
  }
}

void playNote(char note, int duration) {
  char names[] = { 'c', 'd', 'e', 'f', 'g', 'a', 'b', 'C' };
  int tones[] = { 1915, 1700, 1519, 1432, 1275, 1136, 1014, 956 };

  // play the tone corresponding to the note name
  for (int i = 0; i = thresh && total2 >= thresh) {
    playNote('b',tempo);
  }
  else if (total1 >= 900) {
    playNote('C',tempo);
  }
  else if(total2 >=900) {
    playNote('a',tempo);
  }
  // Make the delay too short, and the proximity
  // sensors won't work. :(
  delay(50);
}


 

PitchSqueak

Group: Bonnie Eisenman (bmeisenm), Mario Alvarez (mmcgil), Erica Portnoy (eportnoy), Valentina Barboy (vbarboy)

Description: We built a cardboard “robot” that responds to having its hand held and its nose tweaked. When you hold its hand, its heart glows and it burbles in robot-speak. Its nose is a potentiometer which controls the color of its eyes. We built PitchSqueak because we wanted to build a puppy, but we couldn’t with the given materials, so we figured that an interactive robot was a decent second choice. We’re all kids at heart and we like kids’ toys. (Also, we wanted to experiment with the buzzer.) While we don’t have any kids on hand to test PitchSqueak with, we all find him quite delightful, so we judge this project to be a success. Improvements we would include if possible would be making the cardboard construction better, and making the potentiometer easier to turn. Originally we had also envisioned having PitchSqueak respond to having his head petted, using the linear Softpot.

Photo Feb 20, 9 54 27 PM Photo Feb 20, 9 40 22 PM Photo Feb 20, 9 32 36 PM Photo Feb 20, 9 10 10 PM

Photos of sketches:

A mini-weather-station with sensors that record the ambient light and temperature, and periodically tweets them.

A mini-weather-station with sensors that record the ambient light and temperature, and periodically tweets them.

A "musical instrument" whose pitch and volume can be controlled using the Softpot and the potentiometer.

A “musical instrument” whose pitch and volume can be controlled using the Softpot and the potentiometer.

PitchSqueak! An interactive robot/toy whose heart glows and he babbles when you hold his hand. You can also change the color of his eyes.

PitchSqueak! An interactive robot/toy whose heart glows and he babbles when you hold his hand. You can also change the color of his eyes.

 

Storyboard:

Our storyboard. Little Timmy learns to be nice to people / robots!

Our storyboard. Little Timmy learns to be nice to people / robots!

PitchSqueak in Action:

List of parts:

  • 1 buzzer
  • 1 potentiometer
  • 1 FSR
  • 1 red LED
  • 1 RGB LED
  • 1 breadboard
  • 1 cardboard box
  • Electrical tape
  • Wires
  • Paper
  • 1 Arduino
  • 1 USB cable

Instructions for Recreation:

We constructed PitchSqueak out of a cardboard box. We cut out a rectangle of cardboard for the face, and cut holes for the eyes, heart, and nose. The holes for the eyes and heart were covered with paper to diffuse the light from the LEDs. The potentiometer was placed in the hole for the nose and secured with electrical tape. We then used a second piece of cardboard for a “shelf” between the heart and the eyes, to shield the two LEDs from each other. The red LED was taped to the hole for the heart. Electrical tape was used for connecting the wires to the potentiometer. We then cut out a second piece of cardboard for the body, as well as cardboard arms. We taped the FSR to one of the arms, and then attached the arms to the body. Next we connected the body to the face. We taped the LED for the eyes to the top of the robot’s body, inside. Finally, we connected all the sensors according to our circuit diagram with the breadboard.

Circuit diagram.

Source code:

/* Pitch squeak! */

// Pins:
int greenPin = 10;     // analog pin for the green component of RGB LED
int heart = 7;        // the analog pin for the red LED (heart)
int fsrPin = 2;       // the FSR and 10K pulldown are connected to this pin
int potPin = 0;       // the potentiometer is connected to this pin
int music = 3;        // pin that connects to music

// Input: 
int fsrReading;       // the analog reading from the FSR resistor
int potRead;          // the analog reading from the potentiometer

// Constants: 
int brightness = 255;   // the brightness the LED glows with

void setup(void) {
  // We'll send debugging information via the Serial monitor
  Serial.begin(9600);

  // Set the modes of the pins
  pinMode(heart, OUTPUT);
  pinMode(music, OUTPUT); 
  pinMode(greenPin, OUTPUT);
  pinMode(potPin, INPUT);
  pinMode(fsrPin, INPUT);
}

void loop(void) 
{
  fsrReading = analogRead(fsrPin);
  potRead = analogRead(potPin);
  /*
  Serial.print("FSR reading = ");
  Serial.println(fsrReading);     // the raw analog reading  
  Serial.print("Pot reading = ");
  Serial.println(potRead);     // the raw analog reading
  */
  int greenVal = potRead/4.0; // convert 0-255 to 0-1023
  analogWrite(greenPin, greenVal);

  // Light up heart and make noise if hand squeezed
  if (fsrReading >= 500)
  {
    analogWrite(heart, brightness);
    digitalWrite(music, HIGH);
    for(int i=0; i<10; i++) {
      int r = random(0,255);
      analogWrite(music,r);
      delay(100);
     }
     digitalWrite(music, LOW);
     analogWrite(heart, 0);
  }
  else {
    digitalWrite(music, LOW);
  }
}