%eiip – P2 (Interviews)

Group Number: 18

Names:

Mario Alvarez ’14, Valya Barboy ’15, Bonnie Eisenman ’14, Erica Portnoy ’15.


Problem and Solution Overview:

Organizing books, finding them, and remembering where specific books are can be difficult. It becomes exceedingly difficult as the number of books grows, and as people begin using books both for work and pleasure. Moreover, people who have multiple locations that contain books (multiple rooms, home and office, etc.) have trouble remembering which books are where, and continually end up needing a book that is inaccessible. Our solution is a bookshelf that has an RFID scanner on it. Each book on the shelf has an RFID tag placed on it. The shelf knows which books it contains, and can inform the user that a book is on it when a user queries a software system. An important aspect of our system is that it doesn’t require the user to make lasting modifications to their books, which was a concern of most of the potential users we interviewed.


Descriptions of Users Observed:

The tar­get user group we ended up inter­view­ing were researchers who own a lot of books. The idea behind this tar­get user group was to have peo­ple who use books in mul­ti­ple ways, and could there­fore have more spe­cific orga­ni­za­tional needs. Moreover, these users tended to have mul­ti­ple loca­tions for stor­ing books — at home, in the office, study car­rels — and tended to also have bor­rowed books, which would need to be returned. This makes it more prob­lem­atic if they lose or mis­place books. We ended up inter­viewing some grad­u­ate stu­dents, in math­e­mat­ics and physics, and some pro­fes­sors of com­par­a­tive lit­er­a­ture, Eng­lish, and com­puter sci­ence. We wanted to see how peo­ple in dif­fer­ent dis­ci­plines use books. For example, we noticed that those in the arts tended to have sig­nif­i­cantly larger num­bers of books (by orders of mag­ni­tude), and there­fore were forced to already have estab­lished orga­ni­za­tional systems. Addi­tion­ally, users in tech­ni­cal fields favored e-books for plea­sure read­ing, but avoided them for research due to imprac­ti­cal­ity; the users we inter­viewed in the arts and human­i­ties expressed extreme dis­like for e-books. Based on this, we real­ized that our sys­tem would be bet­ter for a tar­get audi­ence of peo­ple who own no more than a few hun­dred books.


CI Interview Descriptions:

We observed two mathematics graduate students in their respective offices. They both kept their math books in the office, and their pleasure reading at home. The first student had some problems remembering which of her books were at home and which were in her office. The second graduate student had everything perfectly organized — fiction was organized by what he had or hadn’t read and then by author; mathematics was organized by subject — and knew exactly where everything was. He generally can locate a book without a problem (and demonstrated this by finding any book we asked for), but sometimes forgets he has certain books and buys multiple copies. Both used e-books only when the material was otherwise inaccessible, or when traveling, but preferred to do their reading using physical copies. Both also kept their library books on a separate bookshelf, so as not to misplace them. Finally, both said that an organizational system would be nice to have, especially to remember which books are where, but that they do not want to take the time to scan or otherwise document every book they own.

We also observed a professor of Visual Arts who has thousands of books. He had them organized by topic, language, and time period. He could find any given book within seconds. He also had an expansive library at home, which he used for research and for pleasure. The books he kept in his office were those that could be relevant to the classes he teaches. A problem he acknowledged having was moving books from one location to another (i.e. from his house to his office), but he was very good at remembering where his books were. He also never borrows books, and keeps his library books separate from everything else. Next, we observed an English professor in his home, where he keeps his largest collection of books (he has several personal libraries across his residences and offices). He keeps his books using a loose, informal system of organization, with books roughly organized by topic, and books he is currently using stacked on or near his desk. His book collection is so important to him personally – and he spends so much time with it – that he is more or less able to keep track of where everything is. This is a feat, since he estimates he has a few thousand books in his home alone. This system appeared to work well for him: for instance, after he mentioned Turing in passing, we asked him if he could find a book about Turing for us, and he was immediately able to show us where the book had been, as well as recall that he had moved it to one of his offices some time ago. He feels that strict organizational schemes “demystify” the process of finding books, and that the serendipity of finding a book different from the one he was originally looking for is important to his research.

We also went to the Princeton Public Library and observed people trying to find books on the shelves. They would look up a book on a computer, look along the edges of the bookshelves to find the section, and walk along the aisle until they found the right first number, and then they would look more closely once they were nearby. In order to find the specific book, people looked very closely at the titles and numbers on the shelves. We then observed people shopping at CVS, and noted that they had a very similar tactic: they would look at the aisle sections to determine which aisle to go to, and then look more closely once there. One thing we noticed was that when people look for things they tend to physically run their fingers along the spines, shelves, or objects. If they don’t want to touch the objects, they’ll hover next to them, scanning physically as well as visually.


Answers to Eleven Task Analysis Questions:

1. Who is going to use the system?

Our system could be used by anyone with a personal collection of books. However, we envision it being most useful to people who use physical books for research in technical fields. There is very little chance that people who already have thousands of books will catalog all of them, so they would be less likely to use our system; our system will likely be more amenable to a medium-size collection (up to a few hundred books) than to an extremely large collection anyhow. Though we are designing the system with researchers in mind, it will likely be useful to those outside research fields as well.

2. What tasks do they now perform?

Our target group performs a few key tasks while interacting with their book collections. They search for books that they know are in their collection (though they may not know the books’ exact location). After they are done using a book, they need to be able to return it to their collection. They sometimes need to go through their collection to determine whether they own a particular book. Finally, they need to be able to add new books to their collection. All of these tasks generally operate within the frame of a particular organizational scheme; therefore, implicit in each action is that the user should be able to do it while maintaining the invariants necessary to keep their organizational scheme usable. If they do not do this, the tasks of finding books become difficult.

3. What tasks are desired?

Essentially, the users desire to perform the same set of tasks more efficiently. It can take a long time for a user to determine whether they already own a book, since, without a comprehensive catalog of their collection, they need to examine all their books to determine that they do not have a particular one. Additionally, users need to be able to find books consistently and efficiently; as mentioned above, this is not always the case. Finally, researchers tend to have their book collections spread across multiple locations (for example, their home and their office), so determining which books are in which locations is another important task (this was particularly true of the English professor we interviewed).

4. How are the tasks learned?

Currently users employ some combination of two complementary strategies in order to keep their books organized (i.e., learn and remember where books are). First, they can impose a formal system of organization, grouping books together based on commonalities (as the film professor we interviewed did). In an extreme case, they might use an industrial-strength system such as Dewey Decimal. Second, they can use spatial memory, connecting these groups of books to the parts of the space in which they are stored for more rapid retrieval. Both have drawbacks: maintaining a formal system requires discipline and an investment of time each time a book is stored or retrieved, while using spatial memory effectively requires an intimate familiarity with one’s collection and the space that collection occupies, which can take years to develop.

5. Where are the tasks performed?

Wherever the users keep their book collections – so the home and office, at a minimum; possibly other locations for users whose collections are spread across other locations.

6. What’s the relationship between user & data?

In this case, the data is the set of books the user owns, and where those books are. Users have an expectation of privacy for their book collections, as these can be highly personal in nature. Though sharing the full list of books users own will not be required, users may want to be able to share certain information about their collections with friends (for instance, if their friends want to borrow a book from their collection). Users should be able to access data about their own collections remotely – for example, if a user is at a bookstore, she should be able to look up whether she already owns a copy of a book before buying a new one.

7. What other tools does the user have?

The user currently has standard bookshelves. The user may also have software applications to aid in cataloging, such as BookCrawler, but as the film professor we interviewed mentioned, their utility is questionable because they are not tightly integrated with the physical locations of the books like our system is. Additionally, the user may use a traditional cataloging system (such as Dewey Decimal) in order to precisely specify the correct location for each book; however, this requires knowledge of the system and a large amount of effort to maintain, with the result that few actually use such systems.

8. How do users communicate with each other?

Users may borrow books from each other and lend books to each other. Additionally, they must negotiate with others who share their space to ensure that their system of organization is maintained properly. In the case of the home, this may be with other family members who share shelf space (and who may share the collection, making them users as well). In the case of the office, this may be with co-workers or colleagues (researchers in particular often have shared office space.) Communication tends to be informal, verbal, and in-person.

9. How often are the tasks performed?

This varies greatly from user to user and from collection to collection, depending on the user’s habits and the purpose of the collection (for instance, whether it serves as an archive of old, seldom-used material or an active repository for currently-relevant research). Generally, the tasks of storing and retrieving books already in the collection are performed more frequently (several times a day to a couple of times a week) than adding books or checking whether a book is in the collection (a couple of times a week to a few times a year).

10. What are the time constraints on the tasks?

There are no time constraints per se, but if it takes too long to find a book, the individual may give up (although some, like the English professor we interviewed, value the experience of finding a different book than one originally sought). Doing research efficiently depends on finding research materials quickly, so time is likely most important for professional researchers, who want to free up time to do actual research rather than looking for books.

11. What happens when things go wrong?

If the system is used and then stops working (or stops being used), the user’s book collection may become extremely disorganized. As a result the user may not be able to find her books any longer. This is not a catastrophic result, but may make it difficult for the user to do her job if she is a researcher. The user may also lose books if their organizational system loses track of them. This is a potential problem with our system: since it does not require a particular physical layout of books, if users rely on our system and no longer organize their book collection in conventional ways, their collections will be left in a state of disarray if our system stops working.


Description of Three Tasks:

1. Retrieving a book from the collection

The difficulty of this task currently depends on a number of factors, such as how many different places the user keeps books. None of the users we talked to used a strict organizational scheme, though many had their books roughly sorted based on whether or not they were for research, as well as by topic or by time period. With such a scheme, most users are able to find books with moderate difficulty.

Under our proposed system, the user would be able to simply query our system for the book, which would then indicate its physical location. Our system would therefore make it easy to perform this task.

2. Shelving a new book, or returning a book to the collection

Currently, the difficulty of this task is proportional to both the user’s number of books and the strictness of their organization system. If their system is lax and flexible it might be easy to file a book – but this will make retrieving books difficult. If their system is strictly organized, keeping it organized requires significant effort and planning on the user’s part. On average, this tends to be a moderately difficult task.

Our system would keep track of where each book is, so you can put them wherever you like – either maintaining a conventional organizational scheme on top of BiblioFile, or not. The task becomes easy.

3. Determining if you own a book, or if a borrowed book is in your possession

Currently, if you do own a book, determining that you do own it is as easy as retrieving it – that is, of moderate difficulty. However, if you don’t own the book, you have to go through your entire collection to make sure that it is not in your collection at all, as opposed to simply being present but out of place. In this case, the task becomes hard.

With our system, once a user has entered all her books into the system, she can know with confidence whether or not she already owns a book, simply by looking that book up using our interface. This task is now easy.


Interface Design:

Provide a text description of the functionality of your system. What can a user do with it, and how?

Our system keeps track of a user’s books and their locations. A user can ask the system for the approximate location of a book, and the system will indicate where on the shelf it can be found. Additionally, a user could ask the system whether or not they own a particular book. We envision the user interacting with our system through a web application that lets them search for books as well as view all books in the collection. To add a book to the bookshelf system, we envision the user adding a physical “tag” to the book, which will then allow the book/tag combo to be automatically registered via our website.

2. What benefits does the application offer to the user? What is the scope of functions offered? How will your idea differ from existing systems or applications?

Our application allows the user to quickly find their books and determine what books they own without using rigid cataloging systems. Traditional organizational schemes are hard to maintain, and even harder to reconfigure. Our system allows users to place their books in any configuration within the special bookshelf, which gives the users more flexibility. Existing systems require the user to either adhere strictly to an organizational scheme such as Dewey Decimal, or to perform some specific action each time a book is moved (such as scanning a barcode).

3. Provide 3 storyboards. Each one should show how someone would use your system to accomplish one of the three tasks you chose above. Show motivation for using the system, as well as steps the users will go through to accomplish the task.

Photo Mar 10, 4 21 30 PM

Thanks to his Biblio-File system, this user is easily able to find and return his friend’s copy of Ender’s Game.

Photo Mar 10, 4 21 18 PM

Freed from the constraints of a rigid organizational system, this user lets his imagination run wild!

Photo Mar 10, 4 20 49 PM

Using his Biblio-File system, this scholar is able to quickly find the esoteric works he needs to conduct his research productively.

4. Provide a few sketches of the system itself. What might it look like? How might a user interact with it?

Hardware – Shelving: Our system will consist of one or more stacked modular shelves. Each shelf will contain an RFID sensor that will detect books contained within in, and transmit that information to the central server. It will also contain LED lights that will light up when a user selects a book in the software.

A modular shelving unit for BiblioFile

Hardware – RFID Stickers: The books’ presence will be sensed via RFID stickers that can be placed either inside a book (if the user owns the book) or on a bookmark that is placed inside the book (if the user does not own the book). These RFID tags can be disassociated with books after they are permanently removed from the collection and reused with other books.

Usage of the RFID stickers

 

Software – Lookup: Using an interface similar to that of Music on iOS, users will be able to search the collection or browse by any of several types of metadata that the system tracks for each book. When they find the book they want, they tap its title, and its shelf will light up underneath its approximate location. To edit the collection (delete books), users tap the edit button.

Software – Adding a Book: The system will initially try to use OCR to get the book’s information from the cover, after which the user will have the opportunity to edit or add information. The user then places the book on the shelf, so that the system knows which book is associated with which tag.

Interface mockup for looking up a book and for adding a new book to the collection

Software – Locating a Book: When a user taps on the book from the Lookup screen, she will be taken to a page containing the book’s information and tags associated with the location of the shelf that it is currently on. If the user desires, she may tap the illuminate button to have the shelf light up.

Interface mockup for locating a book in the collection

  

 

Lab 2 – Team Chewie (Chewbacca)

Team Members
Stephen Cognetta (cognetta@)
Eugene Lee (eugenel@)
Jean Choi (jeanchoi@)
Karena Cai (kcai@)

Group Number: 14

Description
Our musical instrument was a head-banging music maker. The accelerometer, which is attached to a hat, detects when the user has done a sudden motion (like head banging). When this motion is detected, the tempo of the song that is playing will match the rate at which you are banging your head. By varying the location of touch along a linear sensor, the pitch of the song can also be changed. We thought that our project was a success because we were able to become familiar with the accelerometer while also making a cool project that created music with the motion of the user’s body. As an extension of this project, we could somehow attach the accelerometer to someone’s feet so that when they exercised, the beat of the music would match the rate at which they were running. We also thought that our design could be improved so it was less visible and less bulky.

PROTOTYPE 1 : Ambient Music Generator
http://www.youtube.com/watch?v=_C6pe1Skn1w
This instrument by default emits an ambient noise. When a sudden jerk in the accelerometer is detected, it will emit a dolphin noise. Such a device could be attached to children’s toys that make playing with toys even more fun!
Used CHuck and Processing.
PROTOTYPE 2 : Two-Dimensional Music Player

This instrument uses a two-dimensional sensing technique to change both the pitch and the tempo of a song. If force is applied to the FSR, the tempo decreases. Meanwhile, by sliding the FSR along the soft potentiometer (linear sensor), the pitch will vary.

Head-Banging Music Maker. Final project for this lab. We created a hat that would respond to the movements of the head, if the head jerks fast, the music would play faster, and vice versa. It won’t play at all if the head isn’t moved.

List of Parts
– Arduino Uno
– jumper wires
– accelerometer
– Buzzer
– Hat

Instructions on how to recreate the Head-Banging Music Maker
We attach the buzzer and accelerometer to the device as shown in the picture below. (basically, the accelerometer is wired in as was done in Step 5 of the lab, using the AREF pin, and the buzzer is hooked up to the arduino board). Then attach to the hat as shown. Most of the work is performed in the code, which is shown below.

ttt

hat

Head Bangin’ Source Code

/*
  Graph

 A simple example of communication from the Arduino board to the computer:
 the value of analog input 0 is sent out the serial port.  We call this "serial"
 communication because the connection appears to both the Arduino and the
 computer as a serial port, even though it may actually use
 a USB cable. Bytes are sent one after another (serially) from the Arduino
 to the computer.

 You can use the Arduino serial monitor to view the sent data, or it can
 be read by Processing, PD, Max/MSP, or any other program capable of reading 
 data from a serial port.  The Processing code below graphs the data received 
 so you can see the value of the analog input changing over time.

 The circuit:
 Any analog input sensor is attached to analog in pin 0.

 created 2006
 by David A. Mellis
 modified 9 Apr 2012
 by Tom Igoe and Scott Fitzgerald

 This example code is in the public domain.

 http://www.arduino.cc/en/Tutorial/Graph
 */

// ******************************************************
// CHORD INITIALIZATION
// ******************************************************

const int C = 24,
          D = 27,
          E = 30,
          F = 32,
          G = 36,
          A = 40,
          B = 45,
          C2 = 48,
          H = 0;

int twinkleStar[] = { C, C, G, G, A, A, G, H,
                      F, F, E, E, D, D, C, H,
                      G, G, F, F, E, E, D, H,
                      G, G, F, F, E, E, D, H,
                      C, C, G, G, A, A, G, H,
                      F, F, E, E, D, D, C, H};
int songLength = 48;
int songStep = 0;

int singleNote[] = { 1, 1, 1, 1 };
int majorChord[] = { 4, 5, 6, 0 };
int minorChord[] = { 10, 12, 15, 0 };
int seventhChord[] = { 20, 25, 30, 36 };
int majorChordLength = 3;
int *chords[] = { singleNote, majorChord, minorChord, seventhChord };
const int chordsLength = 4;

int chordType = 0;                // changes between chords[]
int arpStep = 0;                  // changes between chord frequencies

// ******************************************************
// INPUT INITIALIZATION
 // ******************************************************
const int linPin = A1;
const int xPin = A5;
const int yPin = A4;
const int zPin = A3;
const int tonePin = 10;
const int groundpin = A2; // analog input pin 2
const int powerpin = A0; // analog input pin 0
const int proxPin = A6; // analog input pin 6

// ******************************************************
// MAIN LOOP
// ******************************************************

unsigned int tempo;
unsigned int frequency;
unsigned int chordFrequency;
int currentBang;
int bangInterval = 0;
int minimumBangInterval = 70;
int maximumBangInterval = 200;

void setup() {
  // initialize the serial communication:
  Serial.begin(9600);

  pinMode(groundpin, OUTPUT);
 pinMode(powerpin, OUTPUT);
 digitalWrite(groundpin, LOW); 
 digitalWrite(powerpin, HIGH);
}

int prevX = 400;
boolean rising = false;
boolean falling = false;
int mini, maxi, diff;

void loop() {
  int linReading = analogRead(linPin);
  int xReading = analogRead(xPin);
  int yReading = analogRead(yPin);
  int zReading = analogRead(zPin);

  // send the value of analog input 0:
  //int potReading = analogRead(potPin);
 // int btnReading = digitalRead(btnPin);
  // send the value of analog input 0:

  // wait a bit for the analog-to-digital converter 
  // to stabilize after the last reading:
  delay(2);

  int x, y, z;
  x = xReading;
  y = yReading;
  z = zReading;
  if (prevX < x) {
    rising = true;
    falling = false;
  } else {
    rising = false;
    falling = true;
  }
  prevX = x;
  if (falling == true)    mini = x;
  if (rising == true)     maxi = x;
  diff = maxi - mini;

  /*Serial.print(x);
  Serial.print("\t");
  Serial.print(prevX);
  Serial.print("\t");
  Serial.print(mini);
  Serial.print("\t");
  Serial.print(maxi);
  Serial.print("\t");
  Serial.println(diff);*/

  int * chord = twinkleStar;

  //measure the time
  if (bangInterval < maximumBangInterval)     bangInterval++;   //when head bang is detected      if (diff > 80 && bangInterval > minimumBangInterval) {
    currentBang = bangInterval;
    bangInterval = 0;

  //  Serial.print(tempo);
  //  Serial.print(",");
    Serial.println(chordFrequency);

    unsigned int tempo = currentBang*2;
    unsigned int duration = tempo - tempo / 20;

    float chordFactor = (float)chord[songStep] / (float)chord[0];
    if (linReading < 1020)
      frequency = 500;
    chordFrequency = frequency * chordFactor;
    tone(tonePin, chordFrequency, duration);

     Serial.print(songStep);
    Serial.print(" ");
    Serial.print(chordFrequency);
    Serial.print(" ");
    Serial.print(chordFactor);
    Serial.print(" ");
    Serial.println(currentBang);

    delay(tempo);
    songStep = songStep < songLength - 1 ? songStep + 1 : 0;

     chordFactor = (float)chord[songStep] / (float)chord[0];
    /*if (linReading < 1020)
      frequency = linReading;*/
      frequency = 500;
    chordFrequency = frequency * chordFactor;
    tone(tonePin, chordFrequency, duration);

    Serial.print(songStep);
    Serial.print(" ");
    Serial.print(chordFrequency);
    Serial.print(" ");
    Serial.print(chordFactor);
    Serial.print(" ");
    Serial.println(currentBang);

    songStep = songStep < songLength - 1 ? songStep + 1 : 0;
  }

}

Slider Piano: group 24

Andrew Ferg
Bereket Abraham
Lauren Berdick
Ryan Soussan

Group 24

Before we tell you about our amazing resistor piano, we just wanted to show you this awesome picture of the acceleration picked up by the accelerometer in Part 5.

Data picked up from the accelerometer

Three ideas:
– Make a drum out of the piezo. The piezo readings can be run through processing to play a tune/melody each time the piezo is hit.

IMG_0433

– a therimen made from an accelerometer. As you rotate the accelerometer through an angle theta, the pitch changes. As you rotate through a different angle, the tempo changes.

IMG_0221

– A piano made out of a slimpot. As you press different areas of the slimpot, the buzzer plays different notes.

Piano Slider

Final result:

In the end, we chose the piano. However, for the final design we ditched the buzzer and played the notes through the computer. Using the serial port, we sent the notes to a processing script. Using the SoundCipher library, we were able to play computer generated notes and simulate the piano keys visually. We thought it was a success. The graphics synced well with the hardware and it sounded realistic. We did have some issues with the “debouncing” of the keys — if you held a key down it played the note twice. But it was not that noticeable.

IMG_2054

Parts used in final system

Arduino
Wires
Slimpot
Resistors

Instructions to recreate

A slimpot has variable resistance when the user presses different areas of the slimpot. Seeing this, we decided to segment the resistances, so each resistance was assigned an interval. Each interval corresponded to a different piano key. We sent this piano key number to Processing over the serial port. We then downloaded Soundcipher library off the internet which plays notes given a frequency. This allowed us to play the keys. We used rectangles to visualize the keys of the keyboard on the screen (using Processing for the graphics). The keys dimmed in colour when they were pressed. The 32bit Processing had to be downloaded in order to use the serial port.

Source code

Arduino Code:

// these constants won't change:
const int pin1 = A0; // the piezo is connected to analog pin 0

// Voltage thresholds of the piano keys
// 15,20,33,50, 130, 200,
// these variables will change:
int sensorReading = 0;      // variable to store the value read from the sensor pin

void setup() {
 Serial.begin(9600);       // use the serial port
 
}

void loop() {
  sensorReading = analogRead(pin1);    
  
  if (sensorReading > 200) Serial.write((uint8_t)0);
  else if (sensorReading > 130) Serial.write((uint8_t)1);
  else if (sensorReading > 50) Serial.write((uint8_t)2);
  else if (sensorReading > 33) Serial.write((uint8_t)3);
  else if (sensorReading > 20) Serial.write((uint8_t)4);
  else if (sensorReading > 15) Serial.write((uint8_t)5);
  else if (sensorReading > 2) Serial.write((uint8_t)6);
  else;
  
  delay(100);  // delay to avoid overloading the serial port buffer
}

Processing Code:

import arb.soundcipher.*;

SoundCipher sc;
int keysNoteMap[] = {59, 60, 63, 64, 65, 67, 69};
import processing.serial.*;
Serial myPort;  // The serial port

void setup(){
  sc = new SoundCipher(this);
  //keysNoteMap = new int[7];
  
  //keysNoteMap[7] = {59, 60, 63, 64, 65, 67, 69};
  size (250,150);
  println(Serial.list());
  myPort = new Serial(this, Serial.list()[0], 9600);
  println("starting....");
}

// keep processing 'alive'
void draw() {
  boolean pressed = false;
  int note = 9;
  while (myPort.available() > 0) {
    note = myPort.read();
    pressed = true;
    println(note);
    sc.playNote(keysNoteMap[note], 100, 1);
  }
  
//white tut 
  fill(255);
  if( pressed && note==6){
    fill(204);
  }
  rect (10, 10, 30, 100);
    
  fill(255);
    if( pressed && note==5){
    fill(204);
  }
  rect (40, 10, 30, 100);
    fill(255);
    if( pressed && note==4){
    fill(204);
  }
  rect (70, 10, 30, 100);
    fill(255);
    if( pressed && note==3){
    fill(204);
  }
  rect (100, 10, 30, 100);
    fill(255);
    if( pressed && note==2){
    fill(204);
  }
  
  rect (130, 10, 30, 100);
    fill(255);
    if( pressed && note==1){
    fill(204);
  }
  
  rect (160, 10, 30, 100);
    fill(255);
    if( pressed && note==0){
    fill(204);
  }
  
  rect (190, 10, 30, 100);
  
  //black tut
  fill(0);
  rect (32,10,15,60);
  fill(0);
  rect (62,10,15,60);
  fill(0);
  rect (122,10,15,60);
  fill(0);
  rect (152,10,15,60);
  fill(0);
  rect (182,10,15,60);
  
  if(pressed){
    sc.playNote(keysNoteMap[note], 100, 4.0);
    delay(100); 
  }
  pressed = false;
}

L2- TFCS

Dale, Colin, Farhan, Raymond – 4

We decided to build a Glove that controls the pitch of a song as it is being played. It was a real time interactive control on the music which allowed the user to create dubstep like effects on the music stream. The final system implemented the desired control well and mapped the up and down gestures to the pitch of the music. One improvement could be a more continuous mapping to the pitch, instead of the up and down motion corresponding to step shifts in the pitch, we could have a more fine control using the movements of the hand. We would also like to add gestures for controlling the wobble effect on the music (a left right twist of the wrist or such).

 

Instrument 1 – Scream Box (aka The Egg from Harry Potter):

The first instrument we designed was a box that starts making high pitched noise when you open it. As you try to cover the top with your hands, the pitch of the sounds goes down and to shut it off you close the lid of the box. The aim was to make a system that is a standalone musical object that has a very real-world mapping to it – you try to cover  as much of the box to make it quieter. The device uses a photo-sensor to measure how covered the top of the box is.

Instrument 2 – Touch Sensing Piano:

The aim was to recreate a piano like instrument with capacitive sensing aluminium foils as the keys. The mapping to create sound is natural, and the use of capacitive sensing makes the interaction feel natural and unobstructed.

Instrument 3 – Pitch Controlling Glove:

This instrument tries to map physical gestures to pitch control on music. The device uses an accelerometer to recognize motions of the hand and maps them to controlling the up of down pitch of a song. This can be used to recreate the “dubstep” effect on songs.


Final Instrument: Pitch Glove

We decided to refine the pitch glove because it afforded a very novel kind of interaction with the music and allowed control over a parameter of the music with gestures. The refining process was mainly dealing with mapping the accelerometer data to correct gestures and making the piping to the pitch control software work.

Parts List:

  1. Arduino Uno
  2. Processing Software

Instructions:

  1. Download the code for the processing of the music.
  2. Attach the Arduino either to your wrist using a strap, or hold it in your hand.
  3. Enjoy the music move with your gestures.

Code:
Arduino Controller

const int groundpin = A2; // analog input pin 2
const int powerpin = A0; // analog input pin 0
const int xpin = A5; // x-axis of the accelerometer
const int ypin = A4; // y-axis
const int zpin= A3; // z-axis
void setup()
{
//initialize the serial communications:
Serial.begin(9600);
// Provide ground and power by using the analog inputs as normal
//digital pins. This makes it possible to directly connect the
//breakout board to the Arduino. If you use the normal 5V and
//GND pins on the Arduino, you can remove these lines.
pinMode(groundpin, OUTPUT);
pinMode(powerpin, OUTPUT);
digitalWrite(groundpin, LOW);
digitalWrite(powerpin, HIGH);
}
void loop()
{

if(analogRead(zpin) > 440)
{
  Serial.print("h");
}
else if(analogRead(zpin) < 280)
{
  Serial.print("l");
}
else
{
  Serial.print("n");
}

}

Music Controller

// Parts of this code were based on Sampling_03.pde from Sonifying Processing tutorial

import beads.*;
import processing.serial.*;
AudioContext ac;
SamplePlayer sp1;
Gain g;
Glide gainValue;
Glide rateValue;
Glide pitchValue;
Serial myPort;
float rate;
float pitch;
char serialVal;
int bufferSize = 0;

void setup()
{
  String portName = Serial.list()[0];
  myPort = new Serial(this, portName, 9600);

  size(512, 512);
  background(0); // set the background to black
  stroke(100);
  line(width/2, 0, width/2, height);
  line(3*width/4, 0, 3*width/4, height);
  line(0, height/2, width, height/2);
  text("", 100, 120);

  ac = new AudioContext();
  try {  
    sp1 = new SamplePlayer(ac, new Sample(sketchPath("") + "music.mp3"));
   }
  catch(Exception e)
  {
    println("Exception while attempting to load sample!");
    e.printStackTrace();
    exit();
  }

  sp1.setKillOnEnd(false); // we want to play the sample multiple times

  pitchValue = new Glide(ac, 1, 30);
  sp1.setPitch(pitchValue);

  rateValue = new Glide(ac, 1, 30);
  sp1.setRate(rateValue);

  gainValue = new Glide(ac, 1, 30);
  g = new Gain(ac, 1, gainValue);
  g.addInput(sp1);
  ac.out.addInput(g);

  ac.start();  
}

void draw() {

  //read value from serial port.
  if ( myPort.available() > 0) {  // If data is available,
    serialVal = myPort.readChar();         // read it and store it in val
    bufferSize++;
  }

 if(bufferSize > 10)
 {
   myPort.clear();
   bufferSize = 0;
 }
 float dRateValue;
 if(serialVal == 'h')
 {
   dRateValue = 0.01;
 }
 else if(serialVal == 'l')
 {
   dRateValue = -0.01;
 }
 else
 {
   dRateValue = 0;
 }

  println(serialVal);
  // calculate the mouse position on screen as displacement from center, with a threshold
  // TODO: feed in the accelerometer values here
  //float dRateValue = ((float)mouseX - width/2.0);
  //float dPitchValue = ((float)mouseY - height/2.0);

  //if (abs(dRateValue) < 10) dRateValue = 0;
  //if (abs(dPitchValue) < 10) dPitchValue = 0;
  /*
  if(serialVal == 10)
  {
    dPitchValue = 0;
  }*/

  // adjust the rate and pitch depending on the X and Y position of the mouse, drawing a trace
  stroke(100);
  point(rate*width/10.0 + width/2.0, pitch*height/10.0 + height/2.0);
  rate += dRateValue;
 // rate = 2*dRateValue/width;
 // pitch = dPitchValue/height/10;
  stroke(255);
  point(rate*width/10.0 + width/2.0, pitch*height/10.0 + height/2.0);

  // print and set output
  println("Rate: " + rate + "; Pitch: " + pitch);
  rateValue.setValue(4.0*rate);
  pitchValue.setValue(-2.0*pitch + 1.0);
  sp1.setPitch(pitchValue);
  sp1.setRate(rateValue);

  delay(10);
}

void mousePressed() {
  rate = 0;
  pitch = 0;
}

 

A2 Free Food Finder

Lauren Berdick I paper prototyped an app that uses the freefood listerv in order to display and give information about where to find free food on campus.

Observations:

I observed people in-between lectures. People entertain themselves with an eclectic mixture of habits. Some people munch on food, either snacks or two course meals they got from late meal. Others, most likely those who have not been tired out for the week already, start to flip through a textbook, or lecture slides of the class to come. Many immediately take out their computer and start facebooking, playing random games, checking their Princeton gmail. The teachers, if they get there early, are generally setting up their computer for use with the projector, making sure their slides are organised. Some who arrive quite early may strike up a chat with a nearby student, or perhaps one of their TAs. I observed and then interviewed the following people directly to find out what they generally do, and some things they might feel would broaden their experience in these few minutes.

 

Nicole Loncke

She has one class before which she has a 10 minute break. They are both in McCosh, so she isn’t running frantically. She usually chats with some people if she sees anybody she knows. She’ll walk over slowly, get a good spot and then sit around. It is a music class, so the professor has music playing before class. She may talk to the person next to her if she knows them. Or, she may grab a snack. If she has a little more time, she will go to late meal. Alternatively, she will call her parents or a friend she hasn’t talked to in a while. If there are comfy chairs, she’ll take a nap, but at least 20 minutes are needed.

 

Daniel Brooker and Kaleb Bradford

Dan usually checks his email, because he is perpetually forgetting about things, events, etc. Kaleb calls relatives, friends to chat. He also checks facebook, emails. He may go over material for class that he is about to go to, but generally only if there is a quiz. Both also wanted to take naps. Dan likes music, so he would go for something in entertainment, music related, maybe play some game. Kaleb and Dan are sports fans, so they would check sports news, team scores. Kaleb would prefer to be able to follow specific teams. Dan feels he would want to check news, current events, etc, because he thinks Princeton students seem isolated from the daily goings on. They would prefer not to work during that small break, because they already spend most of their time outside class working, and then of course the time for the class lectures, precepts, labs. They don’t want to do more work during those 10 minutes. They need a break.

 

Brainstorm:

  • FreeFoodFinder: app to find food using the freefood listserv. Find food near you!
  • CallMe! : app that gives you an alert of who you haven’t called recently (but you have the ability to ignore that alert if you want)
  • OrganiseMe! : integrated with google calendar. Tells you what assignments you should start working on
  • Reminderapp: tells you what assignments you haven’t worked on for a while. “Why don’t you do a questions from this problem set?”
  •  Sleepify: app to show you where comfy places are to sleep/sit. (possible name) “Nooks and Crannies”
  • app integrated with blackboard, so has practice quizzes. Gives you a practice quiz question
  • Or practice LSAT, MCAT  question a day, or when you open app
  • FunnyBone: app that you can enter funny moments with your friends and so when you are bored, open the app and say, “Show me a funny moment in my past”, and then it will pull up a random memory
  • Scan emails for keywords, make a calendar out of it, and then you can check it what’s coming up
  • NapTaker, say I want to nap now, wakes you up 10 mins later.
  • Nap schedule, shows graphic of when can you take a nap
  • Filters for news, so you can be alerted of those kind of things in that area of news
  • Name game. Get to know your neighbours
  • A collaborative art project, maybe facebook photos that people contribute to
  • One tough problem that everyone contributes to

I chose free food because I had been wanting to do something like this for a while. Also, it may be a stereotype, but I hear Princeton students love free anything, especially food. This is what I got user feedback on. I also chose the CallMe app, because it seems like a lot of students like to call people they have not spoken to in a while during that break time.

Prototype: 

App loading and title page

FreeFoodFinder – app that finds free food on campus for you, using the freefood listserv

In the field:

Ajibike looking at loading page

 

Nicole looking at the Food Neat You! screen. Screen showing your current location as a red dot and food locations as blue dots. Food near you shows food locations in a certain radius surrounding your location.

 

Screen which shows all food choices on campus, regardless of your location.

Screen showing menu options for users. The buttons lead to the following screens.

 

Kwaku, another user, deciding to look for free food

Kwaku selecting Food for You! This will bring him to the map page showing his current location and free food spots within a certain radius

 

Screen giving specific details on food: where, when, what. One way to get here is to select one of the blue food dots on the map.

 

Greg looking at the AlertMe! screen. This alerts you when there is food in certain locations (locations that the user previously set as a Favourite).

Greg selecting a location to find food in.

 

April checking out what her free food will be

 

 

Settings page — where the user can set preferences, e.g. “Favourite” locations that the user wants alerts from

 

Feedback

Ajibike Lapite

  • –wants background music
  • –“I like it”
  • –would definitely use it

 

Kwaku Ohemeng

  • –is there a way of making availability of food in real time?
  • –How much food is left?
  • –in settings, be able to change colour. Personalise app
  • –Main concern: Can we reserve food? If we ran and not there anymore would be a waste of time
  • –but it is cool
  • –would use it
  • –wants extra features available to independent students
  • –because they might be most likely to use this

 

April Liang

  • –What is the time? Because most free food emails say “food right now!” So would have to use email timestamp instead of finding time in email
  • –Select location should include a radius set by user
  • –Yes would use it

 

Greg Owen

  • –Might use, but probably not every day
  • –Would be great app if I had more time, like 30 mins in between class, because might have to go out of my way
  • –Definitely use Alert Me at a given time feature, because I know regularly when I am craving some food

HCI Lab 2 — Do you even lift?

Names
Andrew, Peter, Adam, Matt

Group Number
12

What we built

We built a “magic wand,” similar to a conductor’s baton. We attached an accelerometer to the end of the wand to detect the downbeat, which triggered playing a note. We included our potentiometer prototype to allow the conductor to control what note will be played. We believe our project achieved a fair degree of success — it was intuitive enough that Adam was able to play “Twinkle Twinkle Little Star,” the “ABC’s”, and “Baa Baa Black Sheep”” with only three minutes of practice. Originally, our prototype played notes at a constant interval with no rests, so the introduction of the wand to control the timing of the notes was a large improvement. The wand interface worked well, and there’s little we would change about it. However, the potentiometer was difficult to use to control pitch, and sometimes resulted in the wrong note being played. This is the same for any musical instrument, but a better interface may have made it easier to play.

Prototype

1 — Simple Potentiometer. We built a simple circuit to assess how easily a potentiometer could be used to control pitch (and by extension, a flex sensor, a soft potentiometer, etc.) The arduino played a note of fixed duration at a fixed time interval

2 — Light Flute. We built a cardboard housing with three LEDs inside, and two slots insert cards into. When cards were inserted, they blocked the light, changing the amount of light that fell on the photosensor, which determined the pitch.

3 — Light Flute, version 2. We weren’t happy with having the notes be fixed duration. We included a flex sensor, where the amount of flex controls the duration of the note. We also added semi-transparent cards, to allow a broader array of notes to be played.

Video

You can see Adam playing “Twinkle Twinkle Little Star”. The downbeat of the wand controls when the note is played, and the position of the potentiometer controls the pitch.

Parts List

  • Breadboard
  • Wires
  • Arduino
  • Accelerometer
  • Rotary Potentiometer
  • Buzzer
  • Cardboard
  • Tape


Instructions

  1. Roll cardboard into tube. Mount breadboard and accelerometer on end of wand. Make sure the wire is long enough to allow for a free range of motion. Connect accelerometer to arduino with wires. (see tutorial here, but plug Vin to 5V instead of A0) Reinforce with tape.
  2. Attach buzzer to arduino (see tutorial here, connect to pin 8)
  3. Attach potentiometer to arduino (see tutorial here, connect to A0)
  4. Send below code to arduino


Code

(see code here)

 

L2: Team Colonial — The Muuzi

Team #7
John O’Neill: jconeill@
David Lackey: dlackey@
Horia Radoi: hradoi@

Project Description

Our main project aimed to create a pointer device which enables the user to obtain a different sound based on the position of the nozzle of the gun – a musical uzi, or, as we have affectionally called it, The Muuzi. The idea came to us after we saw initial P1 brainstorm. We decided to use the accelerometer to determine the position of the gun’s x orientation, which we mapped to a range of pitches using an Arduino mapping function. The range we chose to map to was found via trial an hour; the one we settled one was the most relatively desirable, and thus, consider this version of the project to be a success. We managed to solve an issue with our intervals by performing integer division and multiplication (in order to normalize the intervals and avoid having two different noises being played at the same position.) In the future, we might expand the project to a 2- or 3-dimensional space.

Materials

  • 1 One Plastic Gun
  • 1 Accelerometer
  • 1 Arduino
  • 1 Piezo Sensor
  • 1 Breadboard

Instructions

First, place the breadboard on one side of the plastic gun and the Arduino on the opposing side. Orient and attach the accelerometer as it appears in the included photos so that any movements of the gun will correspond correctly with the provided code. Next, wire it such that the ground pin leads to A2, the power pin leads to A5, and the x-axis pin leads to A5. Now add the buzzer to pin 8, the Piezo sensor to A3, and complete the rest of the circuit as demonstrated in the accompanying photos.

Videos

gundave-480p
gunhoria-480p

Pictures

IMG_5629

The breadboard, featuring the accelerometer and the buzzer.

IMG_5628

The Arduino, attached to our musical uzi.

IMG_5635

A close-up view of the Piezo sensor, located behind the actual trigger (since the actual one generates a noise itself.)

IMG_5633

A user testing the Piezo sensor as a firing mechanism.

Source Code

const int groundpin = A2; // analog input pin 2
const int powerpin = A0; // analog input pin 0
const int xpin = A5; // x-axis 
const int xmin = 396;
const int xmax = 620;

void setup()
{
 // initialize the serial communications:
 Serial.begin(9600);

 // Provide ground and power by using the analog inputs as normal
 // digital pins. This makes it possible to directly connect the
 // breakout board to the Arduino. If you use the normal 5V and
 // GND pins on the Arduino, you can remove these lines.
 pinMode(groundpin, OUTPUT);
 pinMode(powerpin, OUTPUT);

 digitalWrite(groundpin, LOW); 
 digitalWrite(powerpin, HIGH);
}

void loop()
{
 int val = 0;
 int xreading = analogRead(xpin);
 // if the gun is pointed downward
 if ((xreading - xmin) < 20) {
   val = 0;  
 }  
 else {
   val = map(xreading, xmin, xmax, 1000, 5000);    
   val = val / 500;    
   val = val * 500;  //make values more discrete
 }    
 int x = analogRead(A3);  // read in sensor behind trigger
 if (x > 10)
   tone(8, val, 1000);
 delay(100);
}

Prototype #1: Slide Machine

This project created a music instrument in which the pitch varies according to a resistive slider. It succeeded in making the pitch vary by using a slider. It involved an led which lights up according to the power put up by the pwm. But because it was pointless, we did not include it in the final version.

slider-480p

IMG_5641

Mapping a slide sensor to different pitches. 

Prototype #2: Holy Tones

This prototype used two photocells, as well as a custom-made box which two holes, which allowed us greater control over the light that the sensors encountered. We built it as a way of developing a non-contact musical instrument, and found it moderately successful.

redbox-480p

IMG_5624

The base of our prototype, which houses two photocell sensors.

IMG_5625

The box that went over our breadboard, which had a divider to help isolate the light on each side.

Sensor Wonderland

Group #6: Gene Mereweather, Alice Fuller, Phillip Oasis and Rodrigo Menezes

Our final instrument used a whammy pedal and a slide sensor to modify the pitch and length of each buzz on our buzzer. The user would control the whammy pedal with their feet and the slide sensor with their finger on the desk. We were pretty satisfied with the overall results, especially with the functionality of the whammy pedal. If we put more effort into it, we would try to find a more natural way to change the time between buzzes.

Prototype 1: Whammy Pedal

This prototype used an empty box, a whiteboard eraser, a light sensor, a big spring and a buzzer to create a “whammy pedal”. When the box is pressed down, the light sensor recognizes that there is less light in the box. The code in the prototype uses the change in light to modify the tone and frequency of the buzzing. We used both a Piezo sensor and buzzer for sound.

Prototype 2: Light-ccordian

To continuing playing around with the light sensor, we put holes in a rectangular box down the center. The less light received by the light sensor, the smaller the pitch of each buzz emitted by the buzzer.

Prototype 3 and Final Instrument: Slide Pitch + Whammy Pedal

We added an additional touch sensor to prototype 1 and re-worked the software, so that the light sensor would control the length of each buzz and the slide potentiometer would control the pitch. It worked really well and we were able to perform with it, so we chose this to be our final instrument. We kept adapting the code until we were satisfied with the musicality. In the following video, Gene performs with our final instrument:

List of parts used

  • Arduino, wires, two breadboards
  • Slide potentiometer
  • Buzzer + 330 Ohm resistor
  • Piezo sensor
  • Light sensor + 10k Ohm resistor
  • Box, whiteboard erase marker, spring and duct tape (for the whammy pedal)

How to build it

We put the spring on the whiteboard erase marker using duct tape, and placed it within a small square box. The light sensor was placed with the 10k Ohm resistor in one breadboard within the box. Wires connected this to our analog reads. We put the slide potentiometer, piezo sensor and buzzer on the other bread board. The buzzer required a 330 Ohm resistor and was connected to a digital pin. The slide potentiometer was in another analog pin and the piezo sensor was connected to another digital pin.

View post on imgur.com

View post on imgur.com

View post on imgur.com

Source code

const int lightAnalogPin = 0; // FSR is connected to analog 0
const int slideAnalogPin = 1;
int slideReading;    // the analog reading from the slide pot
int lightReading;    // the analog reading from the light resistor divider

const int piezoPin = 9;
const int buzzerPin = 5;

int duration; // time that each note lasts
const int betweenNotes = 0; // time between notes

void playTone(int tone, int duration) { // adapted from Arduino tutorials
  for (long i = 0; i < duration * 1000L; i += tone * 2) {
    digitalWrite(piezoPin, HIGH);
    delayMicroseconds(tone);
    digitalWrite(piezoPin, LOW);
    delayMicroseconds(tone);
  }
}

void setup(void) {
  pinMode(piezoPin, OUTPUT);
  pinMode(buzzerPin, OUTPUT);
  Serial.begin(9600);
}

void loop(void) {
  lightReading = analogRead(lightAnalogPin);
  slideReading = analogRead(slideAnalogPin);
  Serial.print("Analog reading = ");
  Serial.println(slideReading);

  duration = map(lightReading, 0, 1023, 500, 10); // low light = shorter note

  // adapted from Arduino tutorials
  int buzzerValue = map(slideReading, 0, 1023, 16, 7902); // low light = low pitch
  tone(buzzerPin, buzzerValue, 100);
  int piezoValue = map(slideReading, 0, 1023, 1915, 956); // low light = low pitch
  playTone(piezoValue, duration);
  delay(duration);
}

Assignment 2 – Collin Stedman

Observations:

I would have to say that there really wasn’t any time during the day when I failed to observe the people around me. I suppose that I was particularly careful to observe people’s activities while waiting for my Computer Networks lecture to start. Classroom settings gave me the opportunity to observe both undergraduates and professors. I decided not to spend much time observing graduate students or TAs. I also observed people walking to and from classes as I traveled between Forbes and my classes. I observed people mostly between classes, but I also decided to observe my own routine as I got ready for my first class each morning. I also paid attention to the way people behaved when entering and leaving dining halls.  I generally conducted my observations alone, as I don’t often walk to classes with friends or sit near other people. A few of my ideas were inspired by fortuitous conversations with friends, as I will describe below.

My first fruitful idea came when I observed my Computer Networks professor, Michael Freedman, before class. Professor Freedman holds office hours immediately before class, which I realized was quite unusual. Most of my professors spend the first ten or so minutes before class preparing for their lecture. I realized that Freeman didn’t have to worry about setting up for lecture because he uses PowerPoint to teach his material. I then realized that my math and physics professors don’t have this same luxury because of the difficulty of displaying complicated math in PowerPoint. It occurred to me that math and physics professors might like it if they could digitally save the notes they write on whiteboards and return them to the whiteboard at a later time. In other words, the whiteboard would be a screen with memory. Once an old whiteboard is loaded, it should be editable just like any normal whiteboard. This technology would allow professors to load previously created notes to a whiteboard in seconds.

My second idea came as I was walking through Wilson on my way to the E-Quad. I saw one boy ask another, presumably his friend, if he could borrow the other’s bike. Did this boy not have his own bike? If he did, was it broken or else unusable? While I do not know the answer to this question, it made me think about the possibility of Princeton having community bikes which could be shared among the entire student body. The bikes would be checked out of special racks using our proxes, and they would then be usable for a certain period of time before they would have to be returned at the risk of incurring charges on our proxes. I assume that these bikes would mostly benefit undergraduates, as they often need bikes to get to classes on time. Graduate students usually make use of the university buses, but they may also find the bikes useful from time to time. I imagine that these bikes could save students from being late to class or even exams!

The last observation I will list here took place when Jean Jacque, one of my friends, mentioned to me after our classics class that he needed to run two errands before his next precept. He wanted to grab coffee from the café in East Pyne, but he also needed to buy a ticket to a student theater production of No Exit / The Chairs. I decided that both of these errands needed to be made faster and easier to complete within ten minutes. Rather than going to Frist to purchase tickets to student performances, one ought to be able to purchase the tickets online from one’s phone. As a frequent theater-goer myself, I know that such an app would certainly benefit me. In fact, I suspect such an app would benefit both theater-goers and theater-producers, as making ticket purchases simpler would likely increase student attendance at shows.

Online purchasing could also make it easier for students like Jean Jacque to get their morning coffee. I envision an app which allows one to place an order for coffee to pick up from numerous café locations around campus, such as Small World, CaFe, or Starbucks. In order to prevent the student body from overwhelming these establishments with online orders, a quota would have to be put in place. However, given that the establishment of your choice is accepting online orders, one could select the coffee of one’s choice and then have it ready by the time one goes to pick it up and pay for it.

Brainstormed Ideas:

  1. A flashcard app which connects to your notes and converts them to cards
  2. A shared bike service with NFC or prox checkout
  3. A bike locator app
  4. Printing documents from a phone
  5. App for rating lectures and  sending the results to professors
  6. App which alerts you to friends walking in the same area of campus
  7. App which takes pictures you snap with your phone and uploads them to a remote digital photo frame
  8. Bluetooth umbrella which flashes a light when the weather is rainy
  9. A battery which charges when you ride your bike and can plug into laptops
  10. App for remotely checking out books from Princeton libraries
  11. In-class social networks for meeting people in your classes
  12. Whiteboard screens which save and load what is written on them
  13. App for purchasing tickets to student productions
  14. Coffee app which lists available locations and allows for remote ordering and fast pickup
  15. A Princeton encyclopedia of eating clubs, extracurricular clubs, sports teams, classes, etc.

Paper Prototyped Ideas:

  1. I chose to paper prototype my flashcard app because I think there ought to be a way to transform the notes I take in class into a format that is more amenable to quick, piecemeal use between classes and at meals.
  2. I chose to paper prototype the app for uploading pictures to a remote digital photo frame because I often want to update my parents on how I am doing or what I am up to despite being too pressed for time to have a meaningful phone conversation.

Prototypes:

Notecard app:

The main screens of FlashNote. The left screen is simply the main screen. The middle screen is the screen of decks available to study prior to searching for new decks. The right screen is the screen of decks available after searching for new decks.

The COS 436 deck, showing both sides of each card.

The mythology deck, showing both sides of each card.

The various popup screens which alert the user to such events as the results of a search for decks or the completion of a deck.

The photo-frame app:

 

The main screen of the app.

 

The photo-taking interface. The left card shows the basic interface, including a target box, a slider for zoom, and a button to see the image currently displayed on the remote photo frame. The second card from the left shows the same interface with a man in focus and the zoom all the way out. The third card from the left shows the same man but with zoom all the way in. The card furthest right shows what the user sees when a photo has been snapped successfully.

 

The displayed images as seen on the app and on the photo frame. The first card from the left shows the picture that will be saved as the current image once the user takes the photo. The second card from the left shows the picture that is saved as the current image right now, before the user has taken the picture of the man. The third card from the left shows the picture of the man as it will be displayed in the remote photo frame. The card on the right shows the picture of the flowerpot as it is currently displayed in the remote photo frame.

User Testing:

Michelle Tan:

 

Michelle chose to study the COS 436 deck before searching for new decks. She then selected the mythology deck, completed that deck, and then exited the app. Michelle checked both sides of each flashcard before moving to the next.

Nate May:

Nate started by adding the mythology deck. He then studied COS 436, though he did not view both sides of each card. After viewing only the one deck, Nate exited the app.

As you can see from the second photo, Nate was confused by what to do with the first card he saw. Not only did he slide the card in the wrong direction, he never even flipped the card over.

Christina Noya:

Video of Christina

Christina first studied for COS 436, viewing both sides of each card before moving to the next. She then searched for the mythology deck and studied it, again viewing both sides of each card before moving on. After studying both decks, Christina exited the app.

As you can tell from this video, Christina didn’t understand how to interact with the flashcards either. I had to encourage her to slide finished flashcards to the left.

Insights:

  • Users did not realize that they were supposed to slide from one flashcard to the next by swiping their fingers from right to left.
  • Users were confused by what happened when they reached the end of the deck. Specifically, Nate didn’t understand that the deck ended automatically after each card had been flipped past.
  • Users confused by not being able to go back to old cards. Nate wanted to be able to go back and see skipped cards.
  • Users didn’t know if they could quit the deck early
  • Confused by where decks came from / relationship to notes taken
  • Users unsure why main screen existed

If I were to go back and make a new prototype, I would make sure to include on-screen instructions for how to flip between cards. I would also allow users to flip between cards in both directions and return to skipped cards. I would add an ‘X’ to the cards which would be the only way to exit the deck. I would also expand the entire demo to make it obvious that the decks “found” during searches are constructed by the app from the user’s very own class notes. Not a single one of my testers understood the main point of the app because my prototype only demonstrated the GUI. I would consider making the user manually feed files to the app to be converted into flashcards. Though this may seem like a step backward, given that the app currently adds new decks automatically, the functionality of the app is so mysterious currently that it probably require instructions teaching the user to drop notes into a particular folder a la Dropbox. By having the user add decks manually, there is no longer any confusion.

A2 Jonathan Neilan

Observations:

Person 1 – Early student – chats with friends, goes on facebook or gmail, etc.

Person 2 – Late student – does not/cannot do much other than find a seat and wonder what happened the first few minutes (came from Frick chem lab to COS building)

Person 3 – TA – chats with fellow TAs and reviews outline of today’s lecture or how many people e-mailed ahead for visits during office hours.

Brainstorm:

1-      Game review of last lecture or any previous lecture material

2-      Trivia quiz of next lecture or any future lecture material

3-      An app that updates when assignments announced in that class are posted

4-      An app that updates when lecture slides for THAT LECTURE DAY are posted

5-      An app to show dining hall food, how full it is, and where/when friends plan to eat

6-      Top (world) news in 10 minutes

7-      Social networking, an app you enter info about yourself and your seat, and it will suggest to you and others to seat next to each other (based on something you have in common)

8-      A program that prompts you to message someone you used to be close to (or your mother)

9-      A quick 10 minute analysis of how well you are faring on accomplishing your daily goals so far. Tracks what has been accomplished, what is there still to do, etc.

10-  Something that reminds of only one of your goals, and in the 10 minutes you have to brainstorm how you will incorporate it into your day.

11-  Something that tracks what you do on your laptop every minute over a period of time, then during that 10 minutes, you can review how you ACTUALLY spend your time

12-  An interactive program to cheer you up, e.g. make you acknowledge good weather, or show you pictures of cute animals, etc.

13-  For irregular journal keepers: a mini-diary that provides prompts, something totally writeable in 10 minutes or less.

14-  Creative writing, but based on prompts that encourage positive thinking (to relieve stress)

15-  An app that provides a quick overview of your google calendar events, meetings, appointments, etc. remaining for that day.

 

2 Favorite Ideas:

1-      #8 – A program that prompts you, perhaps weekly, to write to family, friends, loved ones, etc.; why? Because I’m so bad at remembering to do that which disappoints mother, and that 5-10 minute time is perfect for writing a quick message to keep in touch with those you care about!

2-      # 7; why? Because it’s a new and funny way to potentially find new friends in a class you may not know anyone in, especially if it is out of your department. Potential study buddies!

Weekly Letter Reminder

Weekly Letter Reminder

Class Potential Friend Finder

Class Potential Friend Finder

 

From User Testing of Weekly Letter Reminder:

From early student:

– Works great, but 8-10 minutes doesn’t seem like enough sometimes

– Most people he keeps in touch with regularly on facebook anyways, but the reminder is nice.

From late student:

– no love…but she likes the idea

 

From TA:

– Enjoys it for keeping in touch with colleagues.

– Downside is there’s no point if you do it regularly already via e-mail, etc.