Saturday, March 23, 2013

User Study for Paper Prototype #2

We went to Rabin Square in Tel-Aviv to test our second prototype and see how people react to it. Apart from it being an incredibly hot, hazy, dusty, windy day, we got some important insights about our design, the most notable one being that our affordance isn't good enough at the moment. People looking at the map didn't understand it's about music, and 2 users actually thought it's a station for information about the city.
We started out with a musical note icon, and on the second prototype moved to an earphone icon. A combination of the two might be needed to further clarify the use of the map.

Videos of 3 of our users:

User 1 from Itamar Gilon on Vimeo.


One conducted in English:

User 2 (in English) from Itamar Gilon on Vimeo.


User 3 from Itamar Gilon on Vimeo.

Monday, March 18, 2013

Displaying info

On Sunday we thought of a way to display info about the song that's being played in an MPOI.
We suggested a "Door" that will enable the user to "peek" into the musical world of a neighbourhood.

Here is a prototype of this experience:

Sunday, March 17, 2013

Presenting our prototype

On Sunday, we presented our prototype in class







Here's a short video of our presentation:



Saturday, March 16, 2013

Building a first prototype

We all met on Saturday morning at Ran's house to build our first prototype. 


Noam working

Noam and Ran




Some technical sketching


The screen that will display music information


Printing the map














Trying it out!




Hardware Solutions & Data Flow

Below are 3 possible designs for the physical display and a few advantages and disadvantages for each of them.
Design one shows a dedicated device for each output on the map. This "Station" accesses the Web Server and gets it's specific playlist from there. It then outputs the audio via an Audio Jack and the song & artist name via an Arduino connected to a 16X2 display.
Design two has a PC at the physical display. This PC controls all 16X2 displays via Arduino boards to show song and artist names. This PC also controls all the audio outputs via Arduino boards.

Design three has a PC that, similarly to design two, controls the 16X2 displays via Arduino boards. The PC in this design houses a professional grade audio card with several outputs. The control of what audio channel goes to which output is managed via dedicated low-level software (Java).

Overview of the data flow:
The main DB and Server are cloud-based and are accessed by dedicated REST functions. The types of clients are the "Stations" at the physical display (or the physical display if other solutions are chosen) and the Android App.


Friday, March 15, 2013

Database

Below is a DB diagram for the server DB that holds all collected data for playback and statistical analysis purposes. Key icons indicate Primary Keys and orange lines indicate Foreign Keys.
The DB is accessed solely by the WebServer which in turn publishes the relevant functions for each client (the "Stations" at the physical displays and the Android App).



Wednesday, March 13, 2013

Meeting with Noa

Participated: Noa, Sharon, Itamar & Omri.

Noa mentioned that we should be ready on Sunday for a short demo of what we have.
We should also try to start working with the 7 segment displays.

Emphasized that for next paper-prototype we should take a closer look at whether people understand that what they're listening to is live and what (if any) differences do they expect from different locations?

Sunday, March 10, 2013

Class summary



During class we decided on several issues and received help from Oren, Oran and Orad. 

  • We agreed that we have 2 powerful parts to our experience: The device and the app.
  • Suggested to separate between a "tourist" use case and a "resident" use case.
  • Suggested to try and get a sponsorship from an audio importer.
  • Suggested to add a physical switch at each output jack to allow users at the device to toggle between songs, increasing their perceived control.
  • Started discussing what is a good way to divide the city (and therefore be able to define each area in the division, musically).
  • Suggested another form of user study: stopping people with headphones in the street and ask them what they're listening to.
  • Discussed adding a critique of YouTube's licence agreement by adding a split-screen of videos or any other form of video display.
  • Decided that demographics should be collected, but we still need to decide on the specific measures. 
  • Suggested adding a button to toggle between 2 songs at each output of the map.
  • Decided to have another paper-prototype study, with a better model of our product.

Next steps are:

Communications: 
Add music to App interaction flow 
Prioritize all the features 
Correct flow according to Orad's comments 
Map design - MPOIs (Musical Points Of Interest), Switches, 7 segment display.
Decide which measures to display on the map.
Application mockups

CS:
Decide on core technologies for actual device
Package App for distribution (depends on reactivating Azure server)
Add tactile/notification feedback to App 
Check battery consumption of the App 
Remind Oran that we need Android boards and ADKs/IOIO boards

Psychology:
Revise theoretical background + add element of control to it
Think about possible demographics for control & get user feedback for it 

And:
Design and implement second paper-prototype study
Perform street study (As Oren suggested).

Saturday, March 9, 2013

App flow


App flow - listening to music and viewing data


Flow for collecting music:


Wednesday, March 6, 2013

Meeting with Noa

Participated: Noa, Itamar, Ran, Noam & Omri.

Bottom line on top - Action Items:
  • Communications - Sharon & Itamar:
    • Interaction flow for person at device
    • Interaction flow for App
    • Decide whether another paper-prototype study is required
  • CS: 
    • Ran- 
      • Reactivate Azure
      • Package App for user testing
    • Noam:
      • Check feasibility of multiple audio signals from one computer (assisted by Omri; already in the works)
  • Psychology - Omri:
    • Check feasibility of finding/creating a bus-stop or bus-stop equivalent
    • Observe a bus-stop to see how long people wait there
    • Update theoretical review
Noa emphasized that during the 2nd semester each team within the group must work on their own side of the project in full speed.
Presented the results of yesterday's paper-prototype study.
Discussed how the multi-user experience should be designed. To be decided by Sharon & Itamar.
Discussed the idea of placing the StreetBeat device at bus-stops:
  • It's a good pass-time
  • It's a good reason not to have any screens
  • It has a clearly defined population
  • It is better integrated as an experience
  • It can be integrated with existing "smart" bus stops.

Tuesday, March 5, 2013

Paper Prototype User Study

Today Itamar, Sharon and Omri went out with a paper prototype to check-out some potential user responses.
Our prototype of Streetbeat is a cereal box:









This device emulates the experience of viewing a city-map with embedded microphone jacks. While letting users play with it, we purposefully did not mention the Android app.

We interviewed a total of 8 students/research-personnel at the IDC campus. Below is a summary of recurring comments and otherwise significant feedback regarding the user experience:


  • The look & feel of the actual device is important as that will most likely have an effect on the degree to which people will approach it.
  • About half of the participants understood roughly what to do.
  • Some commented that they would feel "silly" standing next to this for a long while.
  • A song list/local chart/"new entries" is a good addition, it should be part of the device (and not exclusively on an app)
  • Being able to "take" the music from the device is a generally desired feature
  • A "Share" or more communal feature should be added (like knowing who is the person that listens to the song being played, not just knowing where it's from)
  • About half testified the experience was all-in-all fun
Negative parts of the experience:
  • Finding only music you don't appreciate
  • Just the musical experience has no added value from listening to music on a phone/player
  • Two participants said the geographic part isn't really connected with the musical experience
  • Not everybody carries around ear/head-phones all the time
  • Jacks are outdated. There's newer, nicer technologies
  • One participant commented that she prefers not to be "active" (she would like for the music to be played via speakers or something of the sort)

Some videotaped responses:









Monday, March 4, 2013

A few insights

Oren commented on our idea to include a touch screen below the map. 
  • The screen below/beside the map is a turnoff. Screens are out, everybody use them, touch is everywhere - Wood or 3d printed map. As large as you can.
  • LEDs for data feedback, and you can add 7-segment text display, like a ticker, to show the song name etc. 
  • More statistics info - too technical and not poetic like the rest of the experience, but if you insist - it should be on the users mobile phone, like augmented reality above the map, I direct my phone to an area on the map and see the stats visualization on my little screen. That way, you do not need to bring the screens. But the stats is an overkill. Priority 4...
  • Dive deeper into the flow details.
  • How do I tag to an area, what if I'm between areas, how do you deal with GPS uncertainty, what feedback do I get for tagging, what incentive do I have to contribute.

We decided not to include touch screens for now. 

Sunday, March 3, 2013

Lesson Notes


These are our action items and feedback:

Oren's feedback:
  • Oren pictures the map as analog and made of old fashioned wood, with multiple metal jacks per area. 
  • We agreed on the map's scale- blocks/neighborhoods/squares within a single city. 
  • We need to decide if we want the experience to be targeted at a single user or multiple users.
  • We need to somehow indicate that a specific location contains content (songs), an LED is recommended.
  • Regarding our flow- we have two parts, data collection (this is the part we already have) and the listening experience.
  • Touching the wall doesn't have the same affordance as jacking in with your headphones.
  • We should thoroughly research similar projects.
Orad's feedback:
  • We need to decide if we are targeting our project for the street or for a museum/show. We decided on the street.
  • Statistics are secondary to the listening experience. We should focus on listening first, and display the previous ~10 played songs as a first step.
  • Physically connecting headphones to Florentin (for example) is a much stronger experience than putting your hand on it and blocking it from your sight, and has a better affordance.
  • The application that enables you to listen to the songs on your phone is secondary to the experience and should not be focused on.
  • We should focus on the map and be very loyal to our definition of the experience: "Connecting to the musical world of people in our environment" 
Production: 
  • We talked about a secondary screen that will display additional information below the map, we still haven't decided if it needs to be a touch screen (probably ideally), a tablet or an LCD.
  • We need a PC/laptop that controls the screen
  • Azure user- we've sent a mail to Noa regarding this
  • We will need the map to be printed on canvas/wood, we still haven't discussed size.
While working on the flow and user experience ,we've encountered some issues:
We like the analog "operator" style jacks idea, but think it's gonna be problematic because of the following reasons:

1. If we go with an analog map, it means we can't display complex information on it. We are limited to the jack connection, and an LED that informs the user of new songs entering the queue, and maybe some indication of the number of songs in the specific location's queue. 
 2. This is the implication #1: If we think additional information about the songs is important, such as: the song's name (very important in our opinion), the list of songs in the queue, and additional statistics about listening patterns in a specific location, then an additional display is needed. That was the direction we were going in, a secondary screen below the map that will contain that information.
However, if we want the experience to support multiple users, we're having a hard time visioning the design. Will we have n screens (tablets?) for n locations? Will we have a single display that will automatically toggle between locations or display all locations at once? Will we allow only a single user to control the screen and decide what's showing?
Ideally, we would have combined a touch screen with the jacks and displayed the additional information on the map itself as popups next to the location. Although, we think that touch screens will ruin the magical experience of our product.