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.

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).

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?

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).

App flow

App flow - listening to music and viewing data

Flow for collecting music:

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.

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: