A quick note about DRM-protection

My iOS provisioning profile is finally working!
I loaded all of my iTunes music onto the Audible app, added songs to the queue, pressed on one of them...and the application crashed. This was surprising and frustrating, because Justin and Amanda had not been having any trouble playing songs in the app on their devices.

But after debugging for a while, I realized that these songs were purchased on the iTunes music store prior to 2013 and are therefore DRM-protected, which means they cannot be valid MPMediaItems (the structures we have been using to represent our music files so far).

The iTunes music store is a popular place to buy music, so if we ever expanded Audible, we would certainly need to address this issue if we continued to use MPMediaItems. However, for now, as we build our MVP, we are going to make the assumption that all of the songs on all devices in the car are not DRM-protected (songs uploaded from CDs and bought in iTunes after 2013 should work just fine).

Small Group Meeting #4

We had a great meeting today and discussion about our progress. Starting now, we want to pick up the pace a bit on our coding. For next week, we want to continue refining our pink bagel test, make peer-to-peer communication among phones (make the same universal library show up on separate phones, etc.), and figure out the provisioning profile for Sunny so we can have 3 iOS developers! Jay also mentioned we are allowed to make lots of assumptions (WiFi, whatever we need), in order to take the path of least resistance, and we can worry about hooking up the app to Bluetooth closer to the end. 

More user testing

We performed some more user testing this week using our interactive prototype. Here are the highlights:

• Some were confused about the smartlists, and thought they were simply playlists they had made themselves. 
• Potentially rename to something along the lines of "auto-generated playlists", or maybe this will just be a feature users don't understand at first but quickly grasp (like iTunes Genius) with a quick tutorial or tip-sheet
• Some people were confused about where the music in the universal library was coming from. 
• Understandable, as the interactive prototype had static songs listed - would be different once people use on their own devices
• But, potentially rename to "shared library" or something more indicative of the shared aspect 
• Voting was not a huge hit: 
• Some thought it would require too much effort to set up (going through an entire queue and up/downvoting every song is quite time-intensive)
• Also mentioned it might only be useful on a long road trip - otherwise, it takes too much of the overall time in the car to rate every song
• Some thought it just didn't make sense in this context (driving in a car involves very few people - mentioned that it would be a great feature for a frat party, for instance)
• One person also mentioned it would simply encourage antisocial behavior in the car (with everybody too focused on looking at their own phones and voting instead of interacting), which defeats the purpose of people spending time together with music as a fun addition 

After this next round of user testing, we have decided to kill the voting feature. Instead, we want to simply add music into the queue while incorporating the case our liaison mentioned of one particular DJ dominating the listening experience. To prevent this, we will sort the queue by cycling through everybody's choices in order, mirroring a turntable.fm-like experience without the need for constant attention (which the case study we found stated was a large contributor to its ultimate failure). 

Increasing Visibility - new Facebook page, website, and advertising campaigns

In preparation for our Pink Bagel heat test, where we will use parallel ad campaigns to track what different audiences find appealing, Audible has become a lot more visible online this week!

We now have a Facebook page that can be found here. After only several hours of running tester ad campaigns on Facebook, we have 20+ likes from people around the world.

We have also launched our official website at www.audibledj.com.

Several people have already stumbled onto the website through our Facebook page, and have left their contact information with us to stay updated with our progress. One even expressed interest in participating in user testing before our June launch!

Over the next couple days, we will ramp up our Facebook ad campaigns and start several campaigns with Google AdWords, varying our text and images to see what people are more compelled to click on. We hope that this helps us further refine our product vision and discover more about our target audience.

Code Update

We have been quite busy over the past few days and have now implemented the ability to 1) add songs to the queue from the universal library, and 2) play songs from the queue!

Now, when you click on any song in the Universal Library, the song gets added to the Queue (the center tab)

This is the Queue view. These are all songs that have been added from the Universal Library, sorted by time added to the queue (most recent is first)

When a song is clicked from the Queue view, the user is (for the time being) brought to a page of the cover art as the song begins to play.





















Currently, once the song stops playing, the music ends. These are our goals for next week:

• Figure out how to keep all the songs in an ongoing queue, so that as soon as songs are added, music automatically starts playing. Also, once music has been played, we will remove the item from the queue, and potentially back to the universal library.
• Merge multiple libraries into the universal library table.
• Stretch goal: begin to communicate via bluetooth with Jambox devices so that music can be played from our phones.
• Stretch goal: allow user A to play/pause the music on user B's device

Small Group Meeting #3

Code updates:

• core database is built
• app can read music files from local phone’s storage
• goals for next week:
• play music from phone
• create the music queue
• enable functionality to add music to the queue from the library

UX updates:

• starting user tests with the interactive prototype
• initial feedback casts doubts on the necessity for queue voting features
• discussed the intention of pink bagel exercise:
• use ad to drive traffic to a page
• it’s better if you can get it to a point where you don’t have to ask a question
• Facebook ads lets you surface things to very specific type of user
• Google ad words is about people who searched for particular key words

Logistical details:

• status on iOS provisioning profiles
• reflection on our team’s working dynamics
• hope to participate in a music conference aside from the AUDI presentation while in Germany

User testing on Interactive Prototype

We began doing user testing of our interactive prototype this week. Overall, it seemed that the interactions on our prototype were pretty intuitive, as people generally understood how to navigate from place to place, and what each screen represented. The most contentious part of the prototype was actually the up/down-voting portion of the queue. Some comments:

• "If there are 3 people in a car that each take the time to first add songs to the queue, I can't really see anyone saying, 'I don't want to hear the song that somebody chose,' to anything in the queue."
• "I don't actually think the up/down voting makes it more anonymous - it just seems like a more passive aggressive way of saying 'no' to a song. And that's kind of an awkward interaction when there are so few people in a car."
• "The thumbs are a bit misleading - they've become synonymous with likes, so I thought it was rating after the fact whether or not I liked the song. Maybe an up and down arrow would be more clear."

These were very good points that have made us start to reconsider the voting feature. In truth, we were quite excited about the idea of using the app at a sports game or something of the sort, like Jay mentioned in our SGM last week - the voting feature would work especially well in a setting like this. However, within a car setting in which there are likely only 3 or 4 people together, this type of voting interaction might not make the most sense. It also seems that allowing for this up/down voting feature might not be the best way for the driver to express his/her opinion, especially since they should be watching the road. After discussing these results and new insights, we decided we would do more user testing using the prototype before we make a final decision on the voting feature.

Our chat with Noam + Reflections

Our Chat with Noam

Last Wednesday, Team Audible had a follow-up meeting with Noam to get some advice about our application's infrastructure, next steps, and how to make the best product that we can in these two quarters. Noam thought that our team was doing well so far, particularly with our focus on the user experience side of things, and gave us lots of valuable advice that boiled down to these two points:

1. Keep it lean - focus on a minimal viable product (MVP) 

This was definitely something we needed to hear, particularly after spending so much time making minor decisions about which type of database to use and which extra features to add on to our app. Noam emphasized that if we remained consistent in our work, made simple short-term goals, and tried to accomplish every goal as easily as possible, we would have a much higher chance of delivering a successful product. He recommended that we hold off on creating databases for right now, and just focus on the critical initial steps: loading the phone's music library into the application, then adding songs to the queue, etc.

2. Try to do code commits and user testing in tandem
Noam warned us not to get so caught up in the programming of the application that we forget to continue user testing. He recommended that every time we add a small feature in the code, that we follow it up with some user testing (with photos and videos!) and then analyze this feedback before moving forwards. This would save us lots of time that might be spent programming features that are not well received by our audience.

Our talk with Noam really refocused our thinking away from all of the minor details we were fixated on, and got us excited to start creating a successful minimal viable product. Following that meeting, we've made a lot of progress (particularly the developing of our interactive prototype and our first significant code commit), and following Noam's advice, we expect to do a big round of user testing this week!

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

Reflections

Now that we're about a month into our project, we took some time to reflect on our experience working as a group so far and think about where we are headed. Here are some thoughts from each of us:

Justin: "I think our team works well together, complementing each other's creativity and working diligently to make tangible improvements to our user experience, needfinding insight, and code base each week. I like that we all have been taking the initiative to accomplish tasks we see that need attention without being necessarily asked or directed. I think that we're good about communicating quickly with each other (e.g. recognizing good ideas and each other's needs). Moving forward, I think we should focus on developing innovative approaches to reaching MVP, even if it means compromising some of our original concepts."

Sunny: "I am really pleased with our team dynamic and the way we work together so seamlessly, with each of us picking up tasks that we are interested in and communicating efficiently with the others about our progress. And we have fun too! Amanda and I had some homemade fondue on Thursday night after prototyping and Justin and I took my puppy for a walk before programming on Saturday. I think that this is our strength as a team - we enjoy constantly communicating with each other and we are genuinely excited to work together on this project. As we start to tackle the meat of this project, my hope for our team is that we don't lose this excitement - even though programming isn't always as thrilling as presenting to VCs and making pretty prototypes."

Amanda: "I've been very happy with how well our team works together. I feel we all take turns taking the lead at various points to push our project forward, and never miss the chance to take initiative when someone else is having a busier day. We all have very different personalities and tend to prefer different working styles, but it helps to keep us in check. We communicate openly and well so that while we may have disagreements, we always know that the others are thinking, and make sure to take their opinions into account as well. I truly look forward to working with Sunny and Justin over the remaining few months to see how our product comes into fruition."

Overall, all of us are happy with how we work together and communicate, and we like that whoever has the lightest schedule on a given day will take more initiative on the project. We're doing well so far, so hopefully if we keep this up we'll see a successful product in a few months!

Code Update

We have been aiming to develop a minimal viable product. The task for this week was to build a preliminary database and to figure out how to extract songs from the user's device (i.e. the songs from the native iOS Music application). Both tasks have been accomplished! A model was created using Core Data and songs were imported from the local device into Core Data. Below are a couple screenshots of several of the components that have been developed.

Show a table of songs pulled
from the user's device

Enable viewing of a song's cover
art from the universal library

The next task is to implement the ability to play the songs in addition to extracting meta data about the songs stored locally. The next logical step would be to combine multiple users' libraries into a single table.

Interactive Prototype

We used InVision to put together an interactive prototype for our small group meeting. We plan to use this new, higher-fidelity version of the prototype in a new round of user testing. You can find a link to the prototype here. Below are some screenshots:

Small Group Meeting #2

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

Overall, it was a productive meeting! We came in with a lot of implementation-based questions about our application, particularly focused on the issues of bluetooth connection, streaming, and data storage. Jay and Noam gave us a lot of good ideas about our application's infrastructure and encouraged us to start programming as soon as possible!

Where and how should the music be stored?

Over the past week, we have been thinking through the many possible ways to store music, considering the tradeoffs between performance, licensing limitations, and "clunkiness" for the user. 

We thought about storing the universal library of songs in the local storage on each phone, but we would probably run into music licensing issues with Apple by going this route. We also considered a system where we scrape through each person's library to identify the songs in their local storage and then actually stream a digital version of each song from Spotify/Rdio/etc. However, this would require each user to have a Spotify Premium account, and there are many songs that users could have in local storage that are not available on Spotify.

Jay recommended that we try a model in which all songs appear to be accessible on each device (i.e. everyone can see them in their universal library, add them to the queue, etc.) but in reality, the streaming of the current song just "points" to a song in the local storage of the device that it actually exists on. 

A quick whiteboard sketch of this model:

This would require us to store metadata (title, artist name, etc.) for each song in a collective database. We are still deciding between using Rails or just SQLite for this purpose, but we are meeting with Noam tomorrow to discuss it further!

How do we bluetooth-stream songs from multiple phones while having only one phone paired to the bluetooth in the car?

Jay told us that this will probably be one of our biggest challenges in creating this application. At first, maybe we will need to hook up wires between the phones in the car. We may also have to make a lot of assumptions about what is available in the Audi cars - for example, Jay pointed us to the Zigbee specification. How we are going to resolve this issue is still a bit of a mystery though...

Other ideas that came up:

• Our Audi liason Jake Hercules encouraged us to think about giving the driver of the car special permissions (i.e. volume control, veto power for songs). Jay noted that because our application could very well fit outside the scope of cars, we should generalize this idea to have different permission settings for different listeners. For example, if a group of friends was throwing a party but wanted everyone's input on the music, this group could give themselves veto power but allow everyone to add songs and vote on them in the queue. 
• Pre-caching of song data can be used extensively to create a more responsive, customized experience for the listeners. We should think more about the different contexts in which we can do this (i.e. if a certain group of friends drives around together a lot).
• We should consider integrating our application with the Last.fm API, which has a large collection of album cover art and is useful in many other ways.

Tomorrow we are going to start programming, and we have a list of goals that we hope to accomplish by next week (see our Trello here). 

Next up, you'll see the next iteration of our prototype!

VC Pitch

Today was our opportunity to pitch Audible to several VCs. Our presentation can be found here. We went last, but it went great! They appreciated our extensive research, were excited about our direction, and told us to look into the Rap Genius API, and even encouraged us to look into the gamification aspects, though our liaisons had discouraged us. It was short, but felt good to put all of our thoughts together and present a cohesive story about our product. Overall a successful day!

First Liaison Meeting

Yesterday afternoon was our presentation with our Audi liaisons, Jake Hercules and Nate Lugassy of the Electronics Research Lab at Audi. Our slides can be found here.

Afterwards, we had a really valuable conversation with them about potential things to think about. A few of the highlights are below:

• Gamification: we mentioned in our presentation that this would be a potential stretch goal for us. They brought up the good point that while VW brands itself as more of a quirky brand, Audi still strives to come off as professional, classy, and refined. They did not forbid this idea by any means, but told us to keep this in mind when considering whether or not we pursue this route.
• Up/down voting: they asked us to really consider the reasoning behind us including this - they were not entirely convinced of the value of using this voting system, given that a car will at most be probably 4-5 people. 
• If everybody wants to hear a song, they will all play. But is 3 votes really that much more of an impact than 2 votes?
• Jambox: they encouraged us to use our team budget to purchase a Jambox to use for testing. Great idea and a lot cheaper than purchasing a new Audi :)
• Documentation: they would like us to provide lots of documentation throughout the project - justifications for our design choices, why we chose to implement things the way we did, etc. 
• Low friction: they both saw this as, by far, our strongest goal. 
• How is our product going to emphasize this?
• How do all other features we add enforce this? Make sure the features we add don't take away from this (up/down voting for the driver will be difficult, for instance)
• Should there be different interfaces based on context?
• Functionality: they are much more interested in functionality than in beauty - UI comes secondary 

Ultimately, they said the thing they care most about is how the seamless listening experience we create will impact the experience of driving in a car. Overall, it was an extremely helpful conversation to have, including many points we had not previously considered. 

Jay also mentioned other teams have already started using their budgets to have team dinners! Justin is not on board yet, but we will work on it. 

More Brainstorming and First Prototypes

Our need-finding survey results helped us refine our brainstorming to the most important needs of our audience:

1) The app should be as low friction/as hands-free as possible
This led us to design our initial prototype with very few gestures and buttons - making it possible for music to start playing with just one click.
2) The app should be collaborative
To satisfy this need, our initial prototype contains a "universal library" - a combination of the music from everyone in the car from which music is selected. Additionally, everyone in the car has the same amount of influence on the music selection.
3) Everyone should be able to influence song selection, but not have to pick every song that plays
This led us to design a "queue" and up/down voting system, where every person can put songs into a queue and then vote on whether they should be played soon.
4) Both passive and active listening should be possible
To accommodate both of these listening styles, we designed both the option to automatically populate the queue based on genre/mood/theme (passive listening) and the option to manually add songs (active listening).

Putting all of this together, we constructed our first paper prototypes of the Audible application!

This initial prototype has three main screens: "Universal Library", "Queue", and "Auto-Generate". The "Universal Library" screen is the combined collection of music from everybody in the car, that everyone can search through and select songs from. These selected songs will be listed on the "Queue" screen, which shows what is going to be played next in the car. It also includes an up/down voting system, which moves songs up or down in the queue based on how many people want to listen to them.

The "Auto-Generate" screen offers a quick way to populate the song queue with songs centered around a particular theme, mood, or genre. Users can either pick a popular playlist (i.e. "Energize") or search for a specific tag.

After developing these low-fidelity prototypes, we did our first round of user testing to get some feedback on our design. We wanted to see what was intuitive, what was confusing, and whether users could navigate the application to use all of the included features. Because our application is targeted to Audi's younger market (the "young urban professional") we thought that Stanford students might be a good starting point.

We got a lot of useful feedback from our first group of user testers!

Some positive feedback included:

• "I like that I can get music to start playing after just one click"
• "If I press something it gets highlighted, that's good. Otherwise I wouldn't be sure if it worked"
• "I like that you can see the scores of each song! It makes it kind of like a game."
• "Depending on my mood, I either like to choose my own music and listen to a specific song or just let something else do the choosing, so I like that this app lets me do both."

Some aspects of the app that our users found confusing included:

• "Why are there next/previous buttons? Who controls them?"
• "Who can change the volume? Anyone? Because that wouldn't make sense, right?"
• "The tag thing doesn't really make sense to me. I wouldn't expect something to just start playing when I pressed a tag."
• "What happens if multiple people pick autogeneration tags simultaneously?"

Overall, we think that we are on the right track, but definitely have lots of feedback to consider when developing our next iterations of the prototype. Next up, you'll hear about our meeting with Audi liason Jake Hercules!

Survey Results

We got 50 users to take our survey and saw some great results! This helped us do some more brainstorming about what our eventual product should emphasize (ease of use, collaboration, etc.), whether we are on the right track (do people even listen to music in the car using their phones?) and will definitely help us inform future design decisions. Below are the key takeaways with some visuals

• 67% of surveyed people listen to music on their phones daily 

• iTunes still has the majority hold on source of music on phones, but is followed closely by YouTube, Spotify, and Pandora

• When listening with friends, most people prefer to influence the song selection (or just picking the songs themselves) 

• Everybody listens to music in the car

• Most people now listen to music using phones in the car (whether through Bluetooth or AUX cables)

• 37% of users didn't care who chose the next song, but from our qualitative results, we saw that people simply wanted everyone to be happy 

• Location and time of day did not have nearly as much impact on song preference as mood and surrounding people 

• We also gathered a lot of useful information on current services that people enjoy using and what they feel are the most important aspects of a collective listening experience in the car
• Songza, 8tracks were mentioned several times for ease of use and passive listening
• The three most important factors mentioned were that the experience be fun, that everyone is happy with the choices, and that the overall process be easy
• Several people mentioned that it should be handsfree and as low friction as possible given that focus should be on the experience
• Some people also mentioned disliking the pressure of choosing the perfect song for a car full of people and feeling bad if somebody didn't like their song choice 

All of these results helped us think through what the most important aspects of our app should be:

• Low friction/low cognitive load/as hands-free as possible
• Collaborative 
• Ability to influence song selection without offending others 
• Allow for both passive and active listening to cater to both audiences 

Benchmarking and Brainstorming - Round 2

Today we had another productive session of benchmarking and brainstorming!

One of our focuses today was on understanding the younger Audi consumer who we want to target with our music sharing application. We were surprised to learn that around 25% of Audi customers are in the 16-35 year-old age range, which is the largest percentage among luxury car brands. According to a recent NPR article ("Bringing Audi Back for a Younger Audience"), Audi has become the new "status car for young urban professionals." In the last several years, Audi has been targeting younger consumers through social networks like Twitter and Facebook and viral marketing campaigns featuring young celebrities.

While we were researching the other social music applications in the market, we realized a clear distinction between "active" and "passive" music listening, with apps tending to cater to either one or the other. Active listening is a form of listening where users are actively choosing every next song that will be played. This can happen through either creating your own playlists (in which case the work is front-loaded), or by continuously choosing the next song (as with Spotify). Passive listening, on the other hand, is best demonstrated by a service like Pandora, where users simply input a key (an artist, song, etc.) and are then only one click away from a stream of music, and the act of having to choosethe next song completely disappears.

Applications like Spotify and iTunes cater to active listeners, who know exactly what they want to hear and actively create their own playlists. Applications like Pandora and Songza cater to passive listeners, who select general filters based on genre and mood and then rely on the app to form playlists. We read an interesting study of Turntable.fm, a once-popular social music application that recently shut down ("Users Stop Using Turntable.fm"). Turntable.fm chairman Seth Goldstein speculated that the reason for the application's failure is that it required too much input and engagement from users, who would have also preferred the option to listen to a playlist more passively.

We decided that to avoid the same fate, we definitely want our application to give users both the options of active and passive listening, which we will do with two "modes" - one that automatically generates playlists based on genre/keywords, and one that allows the members of the car to manually select songs.

Based on our research today, we also discussed some of the features that we want to include in our app, as well as a general idea of the user flow. We are going to be making some paper prototypes and testing them tomorrow to refine our ideas for our liason meeting this Tuesday!

Audible Task Management Application

After trying out Todoist, Asana, and Trello, team Audible is committed to using Trello for future task management!

Visit our organization and boards here!