Radio Schedules 2.0 at Startup Weekend San Francisco 2009
Posted by shannonclark on April 4, 2009
Back in Dec I posted about Radio Stations 2.0, an idea I had for a return of great radio schedules, updated and enhanced for the 21st century. My post attracted some great feedback and some comments as well as backchannel reactions. I placed my ideas out in public under a bit of a CC license and encouraged anyone to implement them (though I requested at least some attribution).
Friday night after the fantastic Web 2.0 Expo I arrived late to Startup Weekend San Francisco which this time is organized by many fantistic people (and friends of mine). As people went around the room offering up their pitches to the crowd (and to the panel of VC/angel investors who were offering feedback on the form of the pitches) I decided that I would offer a pitch myself.
So I remembered my Radio Stations 2.0 idea, since it is an idea I have already shared publicly, I don’t mind sharing it again, and there is the chance that by doing so at Startup Weekend (and of course following up with a great deal of work most likely) I may be able to inspire enough help from others to make it a reality!
I’ve updated my original post with some more analysis of the competitive landscape (in the comments). In the rest of this post I will set out our goals, targets and next steps for this weekend. Hopefully we will be able to cobble together something working by Sunday evening (and continue to refine it further after that).
Finding radio content whether in a rental car in a new city, on a mobile device or at your desktop is frustrating. Radio Schedules 2.0 is a simple, lightweight, API driven directory of terrestrial, satellite and Internet radio shows. The API will allow for both write & read functionality and likely will be combined with a wiki(like) set of data (station ranges & descriptions, show descriptions etc)
Since RadioTime does exist (and is a commerical entity already) we are going to look carefully at what we can (and should) do to be different, lightweight, and add real value as a competitor (in some ways) or perhpas even as a complementary service in other ways.
Other competition includes PublicRadioFan.com which lists most public radio stations from around the world (with Internet presenses) and a project started in 2003 (and put on hold in 2003) do something similar.
Steps for the weekend
- Define a simple data structure(s) to store the data we gather. Of particular note this will likely include a geographic focused set of data – station data driven by actual tower locations & signal reach. Potentially this could include variations by time of day & date especially the case for AM radio in the Midwestern US. It will also include a temporal set of data – shows on a given station aired (or scheduled to be aired) at specific times.
- Design our data to build up over time – i.e. not just “what is on now” or “what is scheduled to air next” but also “what just aired” or “What was on this morning during my commute…”
- From the beginning expect to build & deploy on servers located in the Cloud. This means evaluating Rackspace, GoGrid, Amazon’s Web Services as well as others.
- Design for a data-driven business model. Perhaps surprisingly a great deal of this design will be involved in streamlining and simplifying what data we need to collect & store from people. But by design this will include storing a great deal of log data & anticipating using such data extensively.
- Stay and work openly. I will likely update my blog with one or more posts of our progress as it happens this weekend – probably including some calls for help in specific areas.
Current design thoughts (very early, very rough)
- Stations – are associated with One or more “dial” positions For terrestrial radio this is the dial number (or numbers in cases of stations with multiple towers). Have a related schedule (or schedules in a few rare cases). Associated with a bunch of data about the station (probably in a wikilike manner that allows for versions)
- Schedules – related to a station (rarely but occasionally multiple different stations). Composed of many “shows” and a true temporal dataset (with start & end times, times normalized to a single timezone) may occasionally also have further details in a wiki (but less often, though “source of data” will be tracked – could be API calls, could be web crawl)
- Shows – A unit of a schedule, but shows can have a meaning by themselves (syndication). May have further data in the wiki.
When a request comes into the system that request MAY have the following:
- a geographic location (which in turn implies an likely interest in Terrestrial radio schedules)
- a range of time (blank may imply “right now”)
At some future point the system may do more with who makes the request (individual web user, individual web user w/tracking cookies, API called etc.). The system may also do some matching/recommendations (using Last.fm profile info or the like as a starting point) but that’s probably not in the first release.
- Start with standards – ideally calendar data will be available in an iCalendar form, via standard means of access. Where microformats make sense we should use them to semantically market up pages we generate (ideally this happens in the background so if a given page is editable ala a wiki the microformats are applied on top of that where they apply)
- Design for API use – ideally this means even for our own interfaces we use the SAME API’s we make available for third-party use. This then forces us to make the API’s simple and as stable as possible (we may of course use white-lists in the future to rate throttle some API access). It should also facilitate the use of other web standards – for example since we are starting from the beginning there is no reason we shouldn’t start using OpenID/OAuth instead of implementing our own Identity systems.
- Focus on simplicity – there are many directions we could go and we will want to explore how best to compete (or not) with RadioTime. Almost certainly our best approach is to keep it simple, do something exceptionally well and iterate.