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.