Summary of Code Architecture to date

Similarly, in order to better illustrate the software architecture that we have settled on at this point, we put together this flow chart of how the Audible application functions.

Red represents databases or APIs used for synchronization or querying. Blue represents Guest users of the applications while yellow represents Host users (i.e. the driver whose device is connected to the AUDI Multimedia Interface via bluetooth). Green represents actions that all users perform. 

Summary of User Testing to date

In order to consolidate all of our user testing findings from the past quarter into a more digestible form, we put together this table of the relevant takeaways. Ultimately, we categorized the feedback that our users provided according to features of interest to us. We plan to act on these comments and use them to inform our next iterations of development in the coming weeks.

Snapshots of Berlin

United at our hostel!

Hookah Lounge with ornate decorations

Justin on the U-Bahn

German Handmade Truffles

A random (and beautiful) waterway

Glass Cup Symphony

Roman Gates at the Pergamon Museum

Pergamon Golden Disk

Museum Island District

Excellent Falafel from Baharat

Saturday Flea Market

Hot applesauce crepes

Graffiti at the Berlin Wall

Berlin Wall Memorial

Nature Conservatory at Dusk

Salty, soft potato fries

German Chocolate Soup + best churros ever

Holocaust Memorial

Checking up on other luxury cars (i.e. Mercedes)

Brandenburg Gate

Persian Food

Radu Lupu and the Berlin Philharmonic

The Kaiser Wilhelm Memorial Church

Polar Bear Family at the Berlin Zoo

Potsdamer Platz

"Three Meatballs" at Imbiss 206 - indescribably good

Famous Moustafas Doner

A Stradivarius violin (right) at the Musical Instruments Museum 

Nun-operated Korean Restaurant: Ixthy

Audible gals walking around

Garden of Eden at Gemaeldegalerie, the Art Museum

Ethiopian Platter

Baklava unlike anything you've ever tried

Another random waterway

Looking at the BaxPax hostel once last time

Sunny on the U-Bahn

Working on Audible at the Tegel Airport

Goodbye to Berlin!

Audi Presentation

The presentation at the Volkswagen Offices in Wolfsburg, Germany went very well! Along with the two other Audi teams, our team consisting of Justin and Sunny, gave a clear depiction of the major Audi in the design and development processes that took place last quarter. Our audience was the Volkswagen Connected Car and Infotainment Team. Our presentation materials can be viewed here.

Response to our presentation was favorable. In particular, our concept of utilizing the RDio API for streaming songs to the driver (whose phone would be connected to the AUDI Multimedia Interface via Bluetooth) impressed the AUDI Connected Car and Infotainment team; they felt the architecture was clever, since it would be scalable across multiple platforms, while maintaining relatively few assumptions and avoiding very complex synchronization issues.

Below are some pictures from our trip to Wolfsburg!

The little villa area where the Audi presentation was held.

Audible member Sunny in the AUDI office lobby.

Scenic river by the Wolfsburg train station.

Liaison Check-in

Before the big presentation at AUDI in Wolfsburg, Germany, we had a final meeting with Jake and Nathaniel. Here are the notes from the meeting:

Update Jake and Nathaniel on code progress

• we basically rewrote the code to where it was, but now using the RDio api
• made progress on the queuing features of the application

Comments about the presentation

• convey the transitions of the screens so there is context in the presentation
• connectivity of the wifi or mobile is very shoddy in the conference room
• backup plan can be a skit, although we opted not to use a skit
• speak as though you’re speaking to the professor, explaining what the application
• don’t assume that they understand the context or background of your project
• write out acronyms explicitly so there is no issue of difference in pronunciation confusing the communication
• do mention the design thinking/user testing as it influenced your decisions on the feature set of your app and then you can talk about what was required to accomplish that. 
• paint a clear and compelling picture of the design as it solves an emotional problem (e.g. I don’t want to give away my PIN to unlock my phone while I’m driving)
• the engineering solution then provides the structure and “meat and potatoes” of the presentation so that it is no longer in the realm of blue sky thinking (e.g. this is what we have done and what we will do forthcoming is technically feasible)
• make sure to have the presentation saved in a deprecated format (PDF for example) as a redundancy, in the event PowerPoint malfunctions, etc.
• presentation tips
• project your voice, speak slowly and clearly, and leave a moment at the end of a busy slide to let your audience process the information

HUGE code update!

After our SGM this week, we did a complete overhaul of our code. In the past 48 hours, we have done a ton of coding and implemented not only the previous functionality we had last week (when attempting to stream audio data using the multipeer connectivity session), but also additional functionality. Now, our app includes the following features:

• A database in the cloud to keep track of the tracks added to the queue, so that everybody in the car can simply pull from the DB and keep their individual queues up to date
• "Host" (person who invites others) can choose any songs from his/her local library to add to the queue, which will then show up in everybody's phones
• As soon as "Host" clicks a song on his/her queue, it will begin streaming out of the "Guest" device (which will be the one hooked up to the car via Bluetooth) 
• When a song is finished playing, it will automatically start playing the next song on the queue

We finished all of this in time for our software demo in class today. We are extremely proud of ourselves, considering that only 2 days ago, we were not expecting to have the same functionality with our new code in time for the software demo. We worked incredibly hard over the past few days and got very familiar with the Rdio API, and are excited to build upon our new codebase. 

A Guide for New Hires

We now have a first draft of a guide that will help new Team Audible hires get up to speed on our project, which can be found here. 

Small Group Meeting #6 and Robot Jake

Here is a quick summary of our sixth small group meeting with Jay and Noam:

Right now, our team is in the middle of making a big decision - whether to stick with our iOS7 multipeer connectivity streaming model or to use a music streaming API like Rdio or Spotify that would allow us to avoid streaming local music files altogether (see our last post for the explanation behind our potential switch). 

Our modified architecture idea (using Rdio) that we explained to Jay and Noam is as follows:

• We will still use multipeer connectivity to establish a connection between the phones over WiFi (we already have this working)
• All phones will push the metadata of their local music files (song name, artist name, etc.) into a cloud database, and then all phones will pull this information to create a universal library
• All users can use the universal library to add songs to the queue. The queue will be stored in a database that all phones pull from often.
• When a song is about to be played in the queue, the phone connected to bluetooth (and with an Rdio subscription) will use the metadata of the song to make a call to Rdio and get the associated track key. Then, the phone connected to bluetooth will stream the song.

Jay and Noam were supportive of this idea, and told us that assuming that one phone in the car has an Rdio subscription (the phone connected to bluetooth) is completely acceptable while we are trying to reach an MVP. We are optimistic about this new approach, and if we pursue it, we will fortunately not have to scrap too much of our old code, particularly the UI and connectivity elements. 

Jay mentioned to us that we should keep making software development progress, but not to put too much pressure on the Thursday software demo. He also encouraged us to make a "New Hire Guide" - something to get a new hire up to speed on our project. Because we've done so much blogging, this may be as simple as creating an organized index into the different pieces of our blog.

--------------------------------------------------------------------------------------------------------

After our small group meeting, we had a chat (via robot!) with Jake Hercules from Audi to get his thoughts about our new approach.

Robot Jake

We explained our modified architecture idea to Jake, emphasizing that while we are not actually streaming local music files, the user experience will remain completely the same. Jake was excited about our idea, particularly because it would give the appearance of streaming local files without all of the associated latency issues. He also mentioned that the sound quality might even be better, because APIs like Rdio always have the most recently remastered versions of songs while many people's MP3s are 12 or 15 years old. However, he warned us to be mindful of how much data our application uses in the streaming calls to the Rdio API.



For the next couple of days we will be continuing development with our new Rdio-based architecture. Based on how much progress we make, we will either be demoing this new architecture or our old multipeer architecture for the software demo on Thursday.

Code shift

Our focus this week has been figuring out how to get queueing working for our next SGM and the software demo on Thursday. After a full day of cranking away yesterday, we got our app to stream 3 songs in succession (chosen by another phone). However, this behavior did not occur reliably, and while the metadata updated immediately from phone A to phone B (it automatically updates the title and artist names),  the music would begin streaming sporadically with very high latency. Given our current model of using the iOS 7 multipeer connectivity functionality, it seems as though we have to create a new session every time we want to play a new song, as it looks like we are unable to stream multiple songs using the same session.

Feeling pretty blocked, we reached out to an iOS developer who has done something similar, as well as to Paul Hegarty for help. We have been thinking for awhile about utilizing the Spotify API to bypass a lot of the issues we've been experiencing in dealing with local media items. We discussed this strategy as a team and then brought it up with the teaching team, who agreed it would be a good idea to switch to using a 3rd party API to take the path of least resistance to reach an MVP. Jay also mentioned that supporting streaming would be more future-friendly, so we have decided to switch to supporting streaming functionality, and will likely start off with the Spotify API.

Small Group Meeting #5

We made significant progress on the Pink Bagel front and also have started to use Trello much more as a vehicle for documenting our code thoughts; while we have benefited greatly from daily communication and in-person work sessions, we think Trello can be a possible complement to what we already believe is solid team communication and collaboration.

Perhaps most significantly, this week was gratifying in terms of providing much confidence with regards to coding - we built out a core piece of Audible's functionality: the peer to peer media streaming. While we have much to do with regards to polishing and integration of this functionality into our application, what we managed to check in was certainly our biggest milestone to date. In addition, to providing a foundation upon which the rest of our project functionality will build, our code progress this week gave us a lot of confidence to flesh out our application moving forward.

Below are the notes from our meeting.

Discussed code progress and demoed current functionality:

• users can pick host or guest roles
• the host can search for and invite guests on the same wifi network
• guests can accept invites and join the session
• the host can select a song from their queue and stream to guest
• guest hears song playing on their device and sees metadata about song (e.g. title, artist, duration)
• Jay seemed satisfied with our code development for this week

Discussed code goals for next week:

• allow better control of music from the queue
• pause/play
• queuing multiple songs between users
• universal library synced across multiple user devices

Regarding Software Demo:

• try to share an experience that is convincing
• e.g. illustrate context with a car setting
• hook up the iPods to jamboxes
• have users
• rhetorical question: what would it take to have users in class host their songs to the guests
• would be unscalable to port the builds to each member of the audience, but would be a compelling demo

Check in with Liaisons

Today we had a Google hangout check-in session with Jake and Nathaniel about the progress of our application. Overall, they were pleased with our progress. Here are the notes we had from our conversation.

• Clarify our programming functionality right now
• we can stream from host to guest
• Great next steps would be to allow controlling of the song (i.e. play/pause) from another device
• Told them that we can run the app on devices, not just iOS simulator
• Jake mentioned he has access to the Audi mobile apps dev guide, so he can give us feedback to help us conform to Audi's app standards
• They want to go through the blog and follow up with our progress right now
• Demoed our functionality
• they were impressed with how we achieved the bulk of our product
• impressed with how we developed quickly
• Regarding the presentations onsite in Germany in two weeks
• think about how to tell a story 
• think about how to differentiate yourself from the other AUDI teams
• format:
• time is flexible, be a little on the shorter side (German-style)
• Take a look at how to skin application so it’s user friendly/don't rely on stock iOS buttons
• iOS buttons are hard to click, particularly for an environment like cars
• decide where you want to go in terms of visual language 
• think about using wireframes to validate your UI decisions from here on out
• Regarding notes from the first liaison meeting
• update on the auto generating/radio stations - still planning on implementing, but will likely not get to it until spring quarter
• update on queue voting - thinking about shelving that feature due to user testing
• they agree with that decision from their own personal standpoint

Code Update!

We just finished a huge code update! After several days of pair programming, we have finally implemented the ability to have user A choose a song to play from the queue, and have it play on user B's phone. Now, the first screen we have is a choice for choosing whether the phone should act as a "Host" or a "Guest."

If the user selects the "Host" option, they then have the ability to invite guests. The screenshots below show the flow. Once the devices are connected, the users can each go to their queue view. When the host selects a song to play, the track will stream from the guest's phone. This is huge news for us, as we now have a working MVP!

 

First Round of Pink Bagel Results

For the last week, we have been running 3 parallel ad campaigns on Facebook, each of which emphasized a different aspect of our application. We wanted to see which features were the most appealing to our audience, and thus resulted in the most likes and clicks to our page.

We started by targeting just one audience with these initial campaigns - the "young urban professional" that we have been referring to as our target audience. To be more specific, we were looking to send our ads to 16-25 year olds who have smartphones and have indicated an interest in music on their Facebook profiles. These ad campaigns ran from 2/24 to 2/28 and had a budget of $20 each. All three ad campaigns featured the same picture, but three different text captions:

• Campaign #1: "Audible is a new way to share your music with your friends in the car!"
• Campaign #2: "With the new Audible application, everyone in the car gets to be the DJ!"
• Campaign #3: "Find a playlist to fit your mood with just one click!"

Here is what one would look like in the News Feed of one of our targeted audience members:

This gave us a lot of good data - now our Facebook page has a total of 74 likes, and a total of 70 people clicked through to look at our Facebook page. To our surprise, each of these three ad campaigns produced a different response from this targeted audience. 

Campaign #2, which emphasized the fact that Audible allows everyone to have control over the music selection, was by far the most popular. Campaign #3, which emphasized Audible's auto-generated playlist, was the least popular. Campaign #1, which emphasized the music sharing aspect of the app, landed somewhere in the middle. 

Here's how the likes and clicks broke down:

What can we conclude from this? People were most interested in an application that let multiple people "be the DJ" in a car - a feature that isn't in many existing products. The idea of auto-generated playlists was not as appealing, perhaps because it is a feature of many widely-used products like Pandora and iTunes. 

Moving forward, we are going to run several more Facebook campaigns in the next few days. We want to test more aspects of the application (whether people want to vote in the queue, for instance) and also want to see if our target audience is truly our target audience by pushing some of these ad campaigns to an older audience. Stay tuned to hear more results!