First Prototype Spec
Logging
Logging will be done simply. Client sends out Device ID and the stream URL or podcast URL that the user is listening to every X seconds.
The log data is transmitted to the ListenLog server. The ListenLog server application will store the log data in a database.
Data Correlation
The server side application will do all the heavy lifting to match the simple stream and podcast URLs logged from the client apps to actual program information.
Implementation will reuse a lot of the backend to Public Radio Player. We'll fork the codebase for this backend and develop it in a new direction for ListenLog/Emancipay.
Emancipay
The design of the payment system assumes the logging and correlation scheme described above.
The client application needs to feature a button to pay through Emancipay.
When the user presses the pay button (which might be the left half of an r-button, we assume that the user wants to make a donation either to the stream or podcast she is listening to or has just listened to. We also assume that the ListenLog server has been logging this listening activity up to this point.
When the user presses the emancipay button in the client application, a confirmation dialog will show up asking the user to confirm making a donation to the program she is listening to or just listened to. The dialog may also provide a form field to enter a message and a field to specify a custom payment amount. The default payment amount could be $2.
The confirmation dialog will show the name of the program and the station that ListenLog thinks the user wants to donate to, based on the data ListenLog has most recently received from this user. When the user confirms, the Emancipay/ListenLog server will record and perhaps broadcast the intention to make a payment. (See below for what will be missing.)
Social Broadcast & Real Time Analytics
Using the activity data collected above, we can broadcast listening and emancipay activity Blippy-style from the web homepage. We can also display some analytics, such as most listened to broadcast of the day, last hour, etc. We might also feature a geographical map with overlays showing ListenLog/Emancipay activity.
User Control
User can create an account on the prototype version of the ListenLog website and associate a Device ID with their account. After they create an account, they can look at all their ListenLog and Emancipay activity.
The user can also set some settings:
- whether to broadcast her ListenLog activity in the Blippy-style live stream
- whether to broadcast Emancipay activity
UI
Third tab. ListenLog/Emacipay tab. Doc will do screen mockup. The pay button and the dollar picker and message field here.
First time the user taps this, dialogue putting user on notice that they're activity is being logged.
Anonymous broadcast. User can toggle this setting on the listen log tab page.
Beta test
Public beta test, possibly thousands of users. Release modified Public Radio Player in Apple App Store. Doc blogs about the experiment.
Doc will talk to Jake about how to make this all work out.
Things the first prototype won't implement
A distributed, peer-to-peer, secure datastore, This is ideal but too complicated to implement at this stage and will slow down progress on the prototype, which is a proof of concept.
The ability to opt in or opt out from having the client app (the modified Public Radio Player) log listening activity.
The ability to log to ListenLog from desktop browsers and other non-iPhone clients.
A real payment system. For the first prototype, we skip implementing a real payment system. Payments are just recorded and maybe broadcast blippy-style (see below) for demonstration purposes. Later, we should decide on the details of the Payment system: how recipients can claim payments, how to set up escrow, etc.
Twitter, Facebook Connect as additional broadcast channels.
Privacy
For prototype, we can allow the user to control the data in that she can delete her account and anonymize her data at any time. She can also download her data in CSV format at any time.