App Store Update

Last week, we were finally able to submit Audible 1.0 to the App Store - our code was finally in a stable and bug-free state (or so we believed) with all of our desired functionality included!

Unfortunately, we got this very confusing reply from the App Store today:



Basically, Audible was rejected from the App Store, because the app completely failed to launch! We are working to figure out how this could have happened - we have never encountered this problem before.
We are also working on improving some of the UI aspects of the app, and will combine these with the fix to this launch issue in Audible 1.0.1 which will hopefully be up on the App Store soon!

Audible's First Launch

Last week, we did our first small-scale launch of the Audible application!

We haven't submitted the app to the AppStore yet (but hope to in the next few days), so we used TestFlight to distribute the app to 3 different groups of people who might enjoy Audible: a 6-person group that writes short stories together, a 3-person group that goes kayaking together on weekends, and a 3-person family that drives around together often.

Overall, although the TestFlight process was very cumbersome, and definitely not something we want to have to use for future launches (see here for a better understanding of the TestFlight process) we were able to get some valuable insights from our data. Based on our Contract of Deliverables that we submitted two weeks ago, we established 6 metrics that we think are valuable indicators of the progress and success of the app:

• Timestamps of when user entered and exited universal library, and timestamps of each song added from library - this will tell us how much time the user spends in the universal library per song added.

Goal: 5 seconds/per song added

• Cumulative time spent engaging with the app*

Goal: 15 minutes

• Proportion of users in a group that contribute to the queue*

Goal: ½

• Cumulative time spent pushing/pulling to sync universal library

Goal: 5 seconds/user

• Timestamps of the beginning and ending of the group creation / role choosing process = this will tell us the total time a user spends in this process before they start listening to music

Goal: 2 minutes/user

• Rate the app in the following categories:

1) Overall rate the app

2) How easy was the app to use?

3) How likely are you to recommend this to a friend?

Goal: average score of 3 in each category

During our launch, we kept track of all of these categories, by embedding code into the app that sent information to our databases. To see how we did, take a look at our Launch Data summary presentation, complete with graphics about user engagement, performance, and virality!

Breakathon!

Today, we had a Breakathon in class, where we paired with "The Ultimate Coding Machine" (the BMW team) and got to see them explore the current Audible application. This was overall a really fun and informative experience - we exposed bugs that we never knew about, saw how real users interacted with the different screens, and got a lot of good feedback about our design and programming decisions.

We came into the Breakathon with a pretty clear idea of what we wanted to accomplish (you can see our planning/instructions worksheet here) and this really helped us to get lots of organized and thorough feedback. We started by giving the team no instructions, so we could see how intuitive the app was to navigate. We were happy to see that without any confusion, the "driver" created a group, everyone joined the group, and they all worked together to create a queue and play songs through the driver's phone.

However, while the basic functionality of the app ran pretty smoothly, we got a lot of feedback about the process. 

Here are some notes that I took about each aspect of the app while the team tested:

Group creation

- this should more graphic and interactive role choosing screen. A slider?

- passengers should be able to see existing groups in your area

- it should be clear who is in your group, and the group creator should be allowed to kick people out

- notifications about adding + removing people from the group

- have a “cancel” button on the group name screen

Universal Library

- what if when you tap a song, you have to tap to add to queue, and then when you hold down your finger, then you get a menu of other things to do (i.e. “add to front of queue”)

- name it something else

- enable searching & an a-z slider

- tag songs by their owners

Play Queue

- race conditions

- don’t like the slider

- who submitted the songs is important and should be evident

- maybe if there are 20+ songs in the queue, we don’t need to see all of them, just the next 5-10

- be able to reorder the queue, but only one person should be able to

- pausing & removing?

- when you turn the phone sideways, things don’t center

Autogeneration Tab

- “have an ADD ALL” button, the + is too ambiguous

- adding a bunch of autogen songs should wipe out the existing queue

General

- tutorial or help button

- a home screen that says “Welcome to Audible” or something

- back and forward buttons (be consistent about them)

- instead of cover art, have an indication about who added

- don’t need to have the slider

After this more general round of testing, we did a more thorough "Bug Hunt" where we tried to perform slightly unusual actions on the app (ex. two passengers clicking the same song at once) to see whether any race conditions or unexpected behaviors were evident. This was one of the most productive parts of the Breakathon, and we are planning to make a lot of improvements in the next week based on this feedback. 

My bug hunt notes:

- the cover art changes randomly when clicking the songs in the universal library multiple times

- when you tap a song 14+ times in the universal library, it disappears?!

- if you switch back and forth between the driver and passenger roles, sometimes the passenger's phone will play the song out of the phone (something that should only happen on the driver's phone)

- a lot of times, songs don’t get added to the queue if you add other songs right after in short succession

- if you are on the host queue and it empties, and someone else adds a song to it, it doesn’t play on the host phone unless you move back and forth between screens

So, while we have a lot to be proud of, we definitely have a lot to work on in the next few days before we launch Audible for the first time!

Big Code Update!

We just finished our SGM and pushed out another huge code update. :) We now have our Autogeneration playlists that we have been planning to do since our initial prototyping and needfinding! Now, when you click on the "Autogen" tab on the far right of the menu bar, it brings you to a page with a list of all genres of tracks in the universal library.

• Our "+" button on the Autogenerated tracks page, when clicked, will add all of the tracks in the given genre to the queue. This is to provide maximum opportunity for passive listening and ease of use for the driver (one-click task completion). 
• Alternatively, users can select a single track on the genre page and it will add only that track to the queue. This is to provide more flexibility for users who only want to hear certain songs 

 

In order to account for different groups of people using our app, we have also introduced group functionality. Now, when you first launch the app, you are prompted to type in the name of your group (or listening session name) so that you only get the tracks in your universal library of the other members in your group. Below, you can see screenshots of both the host and guest views typing in the names of the groups. 

Code Update!

It has been a while since our last update, but we've been working hard! We had another SGM yesterday and Jay was very happy with all the progress we have made.

• We did a complete overhaul of our code to no longer use multi-peer technology, but instead rely entirely on our Parse database - this has solved a lot of our initial issues, and the app is now working a lot more reliably
• Queue is now sync'd on everybody's phone (whether user is signed as guest or host)
• As soon as a song finishes, it is removed from the database and updates each song's metadata as soon as the previous song finishes
• The host's view updates the scrobber bar to show the progress in the song 
• The universal library now pulls and shows all local songs from each user's phone

We are still running into some threading issues, which we hope to figure out this week. We are also currently working on a draft of our contract of deliverables to send to the Audi liaisons and the teaching team. 

Small Group Meeting #7

Here are the notes from our meeting:

• next week: new hire assignment
• put out some media characterizing the culture - about us as a team
• email our ideal candidate description to teaching staff
• make a 5 minute pitch next Thursday during LGM to a hypothetical candidate
• 2 things to do:
• think about who we want to hire
• e.g. these are the last 5 minutes before they walk out
• if we could hire two people on our team, what kind of people do we want
• graphic designer
• sales person
• alum will come in and play the role
• make the case for why they should work here
• do more user testing - observe the ideal users of our software

We also had a reflection of our performance as a team last quarter.

• what did we do best?
• what do we need to do better?
• what do we want to accomplish this quarter?

Below is our self evaluation:

How much have we taken advantage of the following?	Self rating (0 = not at all, 9 = as much as humanly possible)	How much can/did this help our project? (0 = no help, 9 = huge help)	Notes
Agile programming methodologies (sprint concept, frequent short status meetings)	8
Rapid prototyping	6
If your team's maximum capability as a unit all working together is 10, what kind of output score would you say you had in Winter? What do you feel like is a realistic expectation for this score given that unlike in the real world, not everyone is primarily committed to this project over other professional responsibilities?	7	N/A	There were some lulls. Really good with a deadline.
Group dynamics theory/practice (Did you use these to resolve conflicts, reflect about how to work better, etc?)	5
Tools - Source control (branching, code review)	9
Tools - Issue tracking (e.g., Github)	6
Tools - Collaboration (Blogs/FB/Google groups/group messaging etc) to enhance internal and external communications	9
Use of media (photos, video, etc.) to capture IP, team culture and to generally communicate effectively	7
Meeting with human beings who are likely targets for your software	4.5
Observing use of your software in person	N/A		Increasingly important
Observing use of your software via analytics	0		Valuable for this quarter
What did we do best?
What was our weakest point?
What do we want to accomplish this quarter?

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.