Specifications

P5 – Initial Results
As our project revolves around completion of a somewhat complex web application, we’ve primarily focusing on wiring up the application this week.  However, we have done some casual user experience testing, and we plan on bringing the full application online for testing this week.

Features completed last week (mostly on backend, so no links available):
  • Added FB connect
    • Users can use FB connect to sign in
    • FB connect allows access to friends (which is mainly what we need)
  • Adding dares
    • Added a persistent database of users to dares
  • Sharing dares with friends
    • Dares can generated and sent to other friends
  • Get most recent dares in public timeline
    • Users can view recent dares in their area (browsing/joining/upvoting dares)
  • Get most recent dares from friends
    • Given the group of friends from FB connect, users can view what dares their friends have taken/have outstanding
  • Get most recent dares by category
    • Users may sort dares by categories (events, restaurants, etc)
  • Vote up functionality
    • Users can vote up a dare that they think is popular, a feature that is meant to put pressure on the dare recipient
    • Also makes it possible to go viral
  • Delete a dare ( rejecting a dare )
    • Users can accept or reject dares that they receive, and the dare creator will be able to see the results
  • Finishing a dare (by check in ) 
    • Alternatively, a user can prove that he or she finished a dare by checking in using geolocation (if applicable to the dare and if the dare creator specified check in as the confirmation method)
  • Prototyping flow of dare creation/viewing/acceptance on webapp
    • Have determined how the webapp will flow, all that’s left is to hook in the actual webapp to the database
Lessons learned:
  • Decided to use word Dare
    • We were initially concerned that the word Dare gave off connotations that would confuse the user
    • Discussed the flow and naming of the “challenge” feature with potential users
    • Concluded that, given the correct first-time use flow, calling the challenges Dares would not be confusing, and after the first time a user will have picked it up
  • Users want to see a choice between Truth and Dare in the very beginning
    • Originally we had categories first, then a choice between Truth or Dare
    • Tested the prototype on users, found that users were confused, because they expected a choice between Truth or Dare
    • Changed app so that Truth or Dare is the first thing a user sees.  Also makes sense, since the Dare portion is where we expect the most usage to take place.
  • How to collect analytics data from Dares
    • Initially concerned that Dare data could not be aggregated in a useful
    • Set up database such that we can collect information about Dares (such as who Dared who, how long it takes to complete a Dare, etc)
By Importance:
  • FB Connect
    • Obviously, without FB Connect we have no user base, no pre-defined friend graph, no nothing
  • Backend  Dare creation/copmletion
    • Involved careful thought about what to include in a Dare, how to present a Dare to the user
    • The backbone of our application
  • Dare viewing (browsing by area, timeline, friends, etc)
    • Makes the experience more complete for the user
    • Lets the user explore what everybody else is doing, instead of being stuck in their own world
  • Flow of application
    • Initial flow a cause of great concern for our user experience friends
    • Current prototype much more user friendly, encouraging of the creation of dares
What needs to be done for P6:
·         Completion of webapp (and hopefully a mobile platform as well)
·         Get users onboard, get them to start making Dares (generating data)
·         Collect and analyze data for the subsequent social graph

P4 – Progress Report
Features Done:
  • Set up database for all public info
  • Set up scrapers for all public info
  • Running scrapers in cron jobs every day
  • Set up fields in database for data to gather for each category / dare
To do for next week
  • Set up database for users to create dares / take dares
  • Hook-in fb connect, as well as integrate a friends friends from fb
  • Set up collection of analytics data
Summary: Right now our project is moving along pretty well. Our project is extremely ambitious (we are essentially creating a new framework for a social network) and we are a little worried about being a little too much for the class, as we want to launch on two mobile platforms as well as a webapp. But we feel that we can get a good chunk of it done by this week and then focus on deploying it and collecting data from it.  Since we are not analyzing an existing repository of data, but instead building a new framework to generate new data (followed by an analysis), we will also have to work hard to get enough user activity by the end of the quarter.  To be honest though, since we feel the project is innovative to make an impact even outside of the course, we’re generally optimistic about its use after we’re finished.
Concise Description of Project Goals
For our project, our high level goal is to investigate how various social behaviors affect a user’s decision making process when deciding between taking a truth or a dare. A few metrics that we plan on investigating are:
·         How time factors into the decision making process.
 We’re curious to see whether or not the time of day or day of week affects the frequency of truths versus dares that are taken by users. To do this we would simply add a field into our database that keeps track of when each truth or dare was taken by our users.

·         How the entertainment category affects the decision.
Since our application contains categories of things users can do, ranging from baking recipes all the way to movies and video games, we’re interested in finding out whether or not the type of entertainment affects the user likelihood of taking a truth or a dare. To do this we simply need to keep track of which category was clicked and whether a truth or a dare was taken from that category. Then at the end we would just need to use statistics to see whether or not the frequencies between the categories were significant.

·         Why people choose truths versus dares.
 Obviously one extremely interesting thing to hear from the users is why they chose to take a truth as opposed to a dare (and vice versa). This user feedback would most explicitly provide us with the necessary insight into the decision making process when choosing between a truth or dare, but it also forces us to be the most explicit when asking for this information. Whereas the other metrics we will use can all be obtained implicitly through keeping track of certain pieces of data, we plan on obtaining this data through some kind of user survey.

·         How number of votes affect user likelihood in taking a dare.
One feature that our dares will support is the ability for someone nearby geographically to “like” your dare and vote it up. We are interested in seeing whether or not the number of “likes” or votes a dare has affects the time it takes the user to complete the dare. To do this we simply need to keep track of how many votes a dare had with the time it took for the user to complete the dare.

·         How friends’ versus strangers’ votes affect user likelihood in taking a dare.
As a subset to the previous goal, we’d like to see whether or not the source of the “likes” affect the user’s likelihood of taking a dare. Namely, we’d like to see if a friend’s vote weighs more heavily in convincing a user to finish his dare than compared to a stranger’s vote, and if so how much more. To do this we would need to keep track of who “likes” a user’s dare and we can do this by simply using Facebook ids.

·         How friends versus strangers giving dares affect the likelihood of accepting the dare.
One last feature that we would like to implement is allowing users to essentially “share” their dares with other users. Given this, we’d like to see how important the actual content of the dare is, compared to the source of the dare. In other words, if the dare came from a friend, will the content matter as much? How would a user behave if that same dare came from a stranger? These are all interesting questions we’d like to address to ultimately help us understand how a user approaches this decision making process and what kinds of factors affect a user’s decisions.

Expected Results
After implementing everything and seeding our application to a group of friends, these are some of the results we’d expect (and/or hope) to see:

·         How time factors into the decision making process.
We think that time will not play a significant role in the decision making process, but we believe that there may be a slight increase in user’s taking dares later in the day as opposed to earlier in the day (i.e. at night).

·         How the entertainment category affects the decision.
We think that user’s will be more likelihood to take dares for certain categories. For instance, often people might want to try and bake something new and might want to take a dare. Or people might want to be a little gutsy and try a new restaurant. We think that these sorts of behaviors will be more frequent than someone wanting to play, for instance, a random video game.

·         How number of votes affect user likelihood in taking a dare.
We think that dares with more votes – regardless of source – will compel a user to finish it. We think that peer pressure will play a large factor in the decision making process.

·         How friends’ versus strangers’ votes affect user likelihood in taking a dare.
We think that a friends’ dare will have considerably more weight in pushing a user towards finishing a dare than a random strangers’ dare. Again, this is just a common case of peer pressure and how people a user is closer to tend to have a higher influence over that user’s decisions.

·         How friends versus strangers giving dares affect the likelihood of accepting the dare.
We think that a dare forwarded by a friend will have a higher acceptance rate than a dare forwarded by a stranger.

Timeline of milestones / work
·         May 7th - Finish Truth Aspect of Application
o        Hook into Android App
o        Hook into Web App

·         May 11th - Work on Integrating dare aspect into application
o        Hook in facebook connect
o        Add to database all test fields we want to collect

·         May 14th – Finish up Dares
o        User can create dares (geo location / time / category tagged)
o        User can share dares with friends or public
o        User can vote up dares

  • May 18th – Testing / QA
    • Make sure all aspects of application are bug free
    • Start designing user test flow
    • Gather users for testing
  • May 25th – Gather Data, Do analysis
    • Gather up all user data submitted
    • Run analysis on data (with R or Python code)
    • Write up conclusions, analyze based on initial assumptions and expected Results
Risk Factors
  • Lack of Useful Data – Data we collect has no patterns or meaning
    • Create a strong set of predetermined metrics
    • Make sure the data collection process is solid and accurate (quantitative as well as qualitative)
  • Cannot complete application in time
    • Work hard on it =)