I've Got a Key to Your API, Now What? (Joint PBS and NPR API Presentation Give at IMA Conference March 2012)


Published on

PBS’ Tom Crenshaw and NPR’s Javaun Moradi discuss the PBS and NPR APIs. Topics covered are radio, television and dual-licensee stations can leverage the PBS and NPR APIs to innovate and build audience on their websites, mobile devices, and beyond. Tom and Javaun discuss retrieving API content for use on station sites, putting station content into our APIs for reuse elsewhere, and finding station information based on location or call letters. They share their ideas on where the public media APIs are headed, and they look forward to hearing your questions, feedback, and pain points.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Tom 14 years development experience Lives and breaths core services such as APIs Product evangelism Little known fact: lived most of his 20s on a submarine Javaun Prior to NPR: Fortune 500 companies, dot-coms Developer, experimenter, tinkerer Watching/listening since the ‘ 70s: WTTW, WBEZ, WXXI, Michigan Radio, WABE, GPTV, WAMU, WETA, MPTV
  • Gnar! Dirt! Awesomeness!
  • at the end we will open discussion on any of the APIs but more importantly we want to discuss with you how we can help make your life easier through our API efforts
  • (CONSIDER GOING BACK TO JUST A FEW BULLETS ON THE NPR API, AND INSTEAD OF THIS SLIDE NAV TO SOME WEBSITES THAT USE GOOGLE MAPS API AS EXAMPLE) Who ’ s heard of the NPR api? Usually no one. What ’ s an API? No, we didn ’ t invent the term. Been around in software for over a decade. Nerdiest, sexiest thing that you ’ ve never heard about. API is not a platform. A radio, a TV, a pc, a phone are platforms. It ’ s a toolset. You build it because it allows you to create a lot of stuff over and over without reinventing the wheel each time. Also lets you use someone else ’ s tech w/o having to build or maintain. Simplest example is google maps. Who ’ s seen a real estate map w/ prices laid over geography? Show the Dr. Who map (good for a chuckle). This guy has the map on his blog. The embedded map is google ’ s, and he ’ s laid his data on top of it. Google developed maps at a huge cost ($$$$). They maintain it, improve it. When they shoot new satellite or streetview images, it automatically upgrades his Dr. Who map and he ’ s willfully ignorant of how it all works. Most APIs are tougher than this. It takes a programmer (less than 1% of the audience), but when those skilled people make good stuff, everyone can use it. So what is the NPR api? It ’ s a repository, a big bucket of all the digital content we have, easily accessible to anything that can connect to the internet. A pc, a phone, you name it. We ’ ve taken all of our content and sliced it up into pieces, so you can make requests by topic (give me environment, health, and business stories) by program (that appeared on ATC), by reporter (that are by Allison Aubry) by date, by series. Infinitely sliceable/diceable. Also, you can get whole stories are just the pieces. Give me text, photos, but not audio. Or just give me thumbnails and audio. Give me titles, links, and reporter names. The API is the big bucket of content at the center of all of our digital platforms. The website is one presentation of the API. An iPHone app is another. (will show a few more in the demos) Why is this good? We have the ultimate toolset. It means that everytime we want to put our content somewhere new, we never have to worry about how to get it there. We have everything in one place that everything can get to, and we can get it in whole or in pieces. (Sometimes I throw out examples, i.e. there ’ s a game called “ Grand Theft Auto ” where people steal cars. What if the game company came to us and said that when someone steals a car in the game, they want to be able to have the player turn on the dashboard radio and hear that day ’ s “ morning edition ” . We could do that tomorrow, the technology isn ’ t a problem because we already have this API that can put content anywhere that connects to the web – like an Xbox game console. So tech isn ’ t an issue, we ’ d ask “ is this an appropriate use of NPR content, is it the right opportunity, and how much will you pay us? ” Biggest user of the API is us. It let ’ s us create new stuff so quickly. In a way, the API makes us future proof. We don ’ t know what is coming next. We didn ’ t know we were going to make an iPhone app. Would ’ ve been so much harder and taken so much longer without the API. Second biggest user is our partners and our member stations who want better access to our stuff. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Here, I jump off to examples. Show “ Mix your own podcast ” . I make a podcast on the search term “ banjos ” . I explain that it ’ s calling to the API and saying “ get me all stories that have ‘ banjos ’ in them. But I just want to title of the story and the audio file, since that ’ s all I need for a podcast. I don ’ t need text or photos. ” In this way, my podcast is another presentation of the API. Everything is just another presentation. If there ’ s a reporter in the room, I make a podcast with their name (Howard Berkes, Karen Grigsby Bates) and ask them if it looks like the last few weeks of their life. Always a yes. I tell them to share it with their mom/stalker. If time, I may also show another use of the API, like the iGoogle Gadget. Depends on who is in the audience. Time to talk more iPHone…
  • Every where our content appears, it’s just another presentation of the same core stories. To make a web page, I need all the pieces at once. To make a podcast, I just need the story title and the audio link. An email newsletter needs title, teaser, and thumbnail photo, but not full text or audio. A mobile device needs all the pieces, but it calls them as it needs them. The first screen is just a news river with story titles and audio indicator icons. If you click through to a story, you see text and photos and can listen to audio.
  • We assumed that our audience would register and build things we never dreamed of.
  • The reality is that NPR, stations, and partners were almost all of the usage.
  • But the crowd did invent things. The first iPhone app was PRX. The second was written by Brad Bluebacher, a developer by day and NPR fan by night. This spawned the term “to be Fluebachered” in our department. It means that if throw disruptive tech out there and don’t act on it, someone will beat you to the punch. We reached out to Brad and gave him a thumbs up as we wrote our own app.
  • Our station app provides localization by city, state, zip, or lat/long.
  • A whole suite of new apps.
  • Stations are getting into the act too. Expect to see a lot more convergence using many data APIs
  • The cars app prompted us to rethink our APIs and add a few more for quality-checking streams.
  • And of course, the Infinite Player.
  • The interesting part about this graph is what’s not on it. We launched the API in summer 2008 but our usage (and resulting traffic) didn’t jump until a full year later when we launched the iPhone app. Disruption takes time.
  • This has been going on for almost a year. Asset gap analysis across all platforms. What goes where – and what doesn ’ t. Complicated and what appears to be a single issue (i.e. photos) may have many roots Photos – often rights issues. Getting AP solves a majority but not all of the issue Videos – Youtube is the biggest share. There are system & process reasons that other videos aren ’ t captured in our systems.
  • This is the most important slide in the deck. 150 stations by year end, ingesting into the NPR API. We’ll have the first news platform to cover world, national, and local news. This will be a great starting point for the Public Media Platform
  • Stations using stations’ content. This is crazy! The revolution is beginning!
  • Our library system’s search is run solely off the API, powered by Elastic Search
  • We’re about to begin quality checking our streams so that we can programmatically check formats and only deliver the streams that a device can actually play. We’ll also check to see if a stream is down and temporarily remove it to prevent serving a dead URL to our users.
  • We’re about a month away from launching our new documentation site.
  • . The API was originally centered around NPR systems because that ’ s the only way it could have ever existed.
  • We started by going through our mechanism, but you can see it looks complicated. The business reason has changed. We ’ re asking it to be something different, and that requires philosophical and architectural changes.
  • The API is the center of the system – everyone sends content in the same way (including NPR), and everyone pulls it out the same way. More flexibility to fit station data structures.
  • We ’ re asking our API to something beyond what was originally envsioned – the purpose is changing. A major refactor is underway. We ’ ve already rewritten Ingest from scratch. IT ’ s a very different API under the hood, and NPR Digital Services has done a lot of work to make audio ingest faster via core publisher. They now have the fastest station audio to CDN by a wide margin.
  • Who hear uses XML? JSON? Who loves XML? JSON? Proved my point
  • We ’ ll see a convergence of CMS. It ’ s getting harder and harder to go it alone. We ’ re building more APIs and constantly changing the ones we have. That means you not only have to upgrade your CMS, you also have to keep pace with API updates to ingest, retrieval. We ’ ll see a few key flavors of CMS. Not surprisingly, all of them are based on open source. We want something proven, but something that we know has a community dedicated to maintaining it. Drupal is a big one. NPR Digital Services ’ Core Publsher is a Drupal CMS. Other stations and some of the folks at MPR are using Drupal. WBUR and others, including StateImpact and ARgo are using WordPress OPB, WNYC, and others are using Django-based CMSs. Django is a framework that lends itself to reuse. There are full Django CMSs, including Armstrong (Knight) and Ellison). We need to share with each other. This is too hard and we should never reinvent the wheel. Doug Gaff told me there are some Open source Drupal modules in Beta.
  • We need to be open to new technologies that solve problems better and faster. We ’ ve used Elastic Search to great success on the Artemis Library project and giving us a powerful search engine in days, not weeks. You better believe we ’ ll keep experimenting.
  • We really need local, segmented audio. This was just an experiment, and we don ’ t know what it will look like as a grown-up product, but it will affect almost all of our platforms. We need segmented audio for mobile, for cars. I was really proud of this one, this was our first digital radio. An exec called it “ the most disruptive thing we ever created ” . We were like cool. Then holy crap. We did this in two weeks because we knew our APIs, systems, and the member station system. But someone else could ’ ve done it. Would ’ ve taken them longer. I ’ m glad we invented it. We have to remember what ’ s gone on with newspapers. Aggregators. They ’ re chasing everything. We have to own this, we have to control our destiny. Help us.
  • We all need to be willing to share more. More code, more content.
  • Not really sure when it launched Not really sure what the driving business need was other than drive the national PBS electronic program guide Not really sure if there were product requirements written up or if it was skunk works I am sure that I am in the process of rebuilding
  • Outages have been reduced The documentation has been improved Lived out its usefullness
  • WPT uses the TVSS API (or used to) but is able to punt on the channel/headend portion of EPG
  • Would not be possible without the API No native way to support the device
  • Migration path from application-centric web to API-centric web COVE 2.0 portal launched on COVE API Video portal driven by combination of COVE API and Merlin API
  • http://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png http://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png .resize.103x58.png
  • User enters ZIP code, chooses headend (provider) which may or may not be familiar to them depending on location and finally gets what’s on a particular station Flawed user experience that puts station first and user second
  • TV viewer really only cares about “What is on that I can watch” or “when is the next showing of my show on air” Overlap markets can play nicely together
  • double usage out of the imperial walker painted like mystery machine image By combing the COVE API with the updated TVSS API, we will be able to host previews and other interesting user experiences within the EPG
  • Multiple IDs on the internet that index and describe single entities whether they are programs or episodes Creating a single PBS ID and leveraging the power of the cloud, we can create a single ID that we can provide to the other content providers, both local and national
  • Remember when there was 1 way to watch a program and you had between 4-8 channels to choose from?
  • Connected TVs, programming on the web, station and national portals, iTunes, Hulu, Netflix are all providers of PBS content. Not just broadcast and EPGs
  • Let us know how we can help you. What are we doing right? What are we doing wrong?
  • I've Got a Key to Your API, Now What? (Joint PBS and NPR API Presentation Give at IMA Conference March 2012)

    1. 1. I’ve got a key to your API, now what?!?•Presented by:•Thomas Crenshaw – PBS (@justhomas)•Javaun Moradi – NPR (@javaun)
    2. 2. Who are these guys• Combined 30 years technical experience• Both straddle the line between technically focused and experience focused• Both work for 3 letter companies and won’t have to kill you for telling you that (inside the beltway joke)• Fun fact: both are mountain bikers
    3. 3. 3
    4. 4. Who are you? ( Who who who who )• Just Radio?• Just TV?• Joint licensee?• Digital folks?• Broadcast?• Developers (the software kind)?
    5. 5. Who we think you are• Some development experience in some development language (python, ruby, javascript)• Desire to extend your site/app/presence with additional content• May or may not be a joint licensee• Know that APIs rule the 2.0 world• May or may not know that APIs are actually web services
    6. 6. Now that introductions are out of the way let’s talk about APIs
    7. 7. We are going to go through this part of the presentation “Vin Diesel” style....
    8. 8. 9
    9. 9. think of this as API speed dating 10
    10. 10. Application Programming Interface (API)• A flexible toolset. Not a platform, a file format, or a type of content.• Reuse your own technology, or• Use someone else’s without building it yourself.• Skilled developers program new API applications, but everyone can use those new creations.
    11. 11. Where did NPR begin?
    12. 12. Create Once, Publish Everywhere (COPE) • A central content repository that feeds all NPR platforms, stations, and partners NPR.org Mobile NPR API Story Pieces: headline, text, photos, audio, video Email Story Attributes: Newsletters Date, byline, topic, program, series, artistPartner Apps
    13. 13. Vision: “Let a thousand flowers bloom…”
    14. 14. Reality: NPR + Stations + Partners
    15. 15. Rise of Mobile AppsPRX Brad Fluebacher’s basement NPR
    16. 16. Stations API
    17. 17. Stations API
    18. 18. APIs you didn’t know we had• Transcripts ROBERT SIEGEL, HOST: From NPR News, this is ALL THINGS CONSIDERED. Im Robert• User & Playlist Siegel. MELISSA BLOCK, HOST: And Im Melissa Block. Were marking the 50th anniversary of a childrens classic thats still devoured and puzzled over in reading nooks and classrooms. KEVIN THOMPSON: So we got Mrs. Whatsit, what about the 2nd character that we met? UNIDENTIFIED GROUP: Mrs. Who. THOMPSON: Mrs. Who, OK. What did we learn about Mrs. Who? UNIDENTIFIED CHILD #1: That her glasses are thick. THOMPSON: Yes, she has thick glasses. What kind of... UNIDENTIFIED CHILD #2: She has spectacles. THOMPSON: They call them spectacles, very good. What else is...
    19. 19. NPR Now…
    20. 20. NPR Mobile Today
    21. 21. Station & Show Apps!
    22. 22. Cars!
    23. 23. Experiments
    24. 24. NPR Doubled Page Views NPR Music NPR Facebook Integration iPhone app iPad app Relaunched NPR mobile siteAPI launched in 2008 Player 2.0 NPR News Android app NPR News NPR Music Homepage NPR Blogs iPhone app Remix Improvements Made API Friendly Story Page Improvements
    25. 25. Stations Doubling Traffic!
    26. 26. NPR API stuff in progress
    27. 27. Plugging Asset Gaps <externalAsset id="141487365" type="YouTube"> <url>http://www.youtube.com/watch?v=Ws6AAhTw7RA</url> <http://www.youtube.com/watch?v=Ws6AAhTw7RA%3C/url%3E> <oEmbed>http://www.youtube.com/oembed?url=http %3A//www.youtube.com/watch%3Fv%3DWs6AAhTw7RA </oEmbed> <externalId>Ws6AAhTw7RA</externalId> <credit/> <parameters/> <caption/> </externalAsset>
    28. 28. Station Ingest:150 by the end of 2012!
    29. 29. API-Centered Development• Rule 1: Everything is an API• Rule 2: Be RESTful• Rule 3: Drink Your Own...
    30. 30. Streams & Genres APIsGET:/genres/10003/streams/
    31. 31. 33
    32. 32. Artemis Library APIGET/stories/?names={"or":[{"name":"Newt%20Gingrich","role":"4"},{"name":"Newt%20Gingrich","role":"1"}]}
    33. 33. NPR what’s next? 47
    34. 34. Station Data Project (BUS)• Schedule information• Bridge existing information, including: – Station localization – Streams directories• Lots of bad puns
    35. 35. Stream Validation 
    36. 36. Update Our Old Documentation
    37. 37. Better Documentation and Support
    38. 38. The API in the beginning… 
    39. 39. Ingest is getting complicated
    40. 40. Where we’re headed 
    41. 41. An API for the System• Independent of any one CMS or data structure• More flexibility• Versioning• Rights/permissions
    42. 42. Trends
    43. 43. JSON APIs XML JSON<response> { <status> response: { <version>4.2</version> status: { <code>0</code> version: 4.2, <message>Success</message> code: 0, </status> message: Success <songs> }, <song> songs: [ <artist_id>ARH6W4X1187B99274F</artist_id> { <id>SOWKEUN12AF72AB837</id> artist_id: ARH6W4X1187B99274F, <artist_name>Radiohead</artist_name> id: SOWKEUN12AF72AB837, <title>Climbing Up The Walls</title> artist_name: Radiohead, </song> title: Climbing Up The Walls <song> }, <artist_id>ARH6W4X1187B99274F</artist_id> { <id>SOXZVWD1316771449E</id> artist_id: ARH6W4X1187B99274F, <artist_name>Radiohead</artist_name> id: SOXZVWD1316771449E, <title>Fake Plastic Trees</title> artist_name: Radiohead, </song> title: Fake Plastic Trees <song> }, <artist_id>ARH6W4X1187B99274F</artist_id> { <id>SOMLGKF12AB017DF3C</id> artist_id: ARH6W4X1187B99274F, <artist_name>Radiohead</artist_name> id: SOMLGKF12AB017DF3C, <title>Vegetable (Live)</title> artist_name: Radiohead, </song> title: Vegetable (Live) </songs> }</response> ] } }
    44. 44. Smaller, Simpler APIs GET/genres
    45. 45. CMS Convergence• Harder to go it alone• A few CMS/frameworks will dominate• Let’s share modules! Don’t reinvent the wheel• http://drupal.org/project/npr
    46. 46. Technology: Shiny new things!
    47. 47. We need local, segmented audio!
    48. 48. An ecosystem for sharing
    49. 49. NPR is hiring!http://www.npr.org/about/careers/Digital Media (Washington, D.C.)•Programmer III•News Apps Editor•Quality Assurance Engineer•Software Developer•Audio-Video Production Supervisor•Product Manager, Connected Cars•Lead User Experience ArchitectDigital Services (Boston)•Digital News Specialist•Project Coordinator•Programmer III•Web Application Developer IV•Client Services Manager•Client Services Associate
    50. 50. Hey what about PBS...we have APIs too...
    51. 51. TV SchedulesI couldn’t resist the image of an Imperial Walker painted like the Mystery Machine!although it really doesn’t have much to do with the TVSS API!Very little knowledge passed down through the PBS Interactive group aboutthe origins of the TVSS API(see “mystery” wrapping large cumbersome object....you get it now right?) 21
    52. 52. It works....• Although not without blemishes, it does work• Pass parameters into TVSS API• API returns TV schedule data back• Documentation greatly improved recently by WETA’s Jess Snyder• Built for single purpose, extended overtime to do handle other tasks that 22
    53. 53.  WPT Examplehttp://wptschedule.org/schedulenow.php 23
    54. 54. PBS Tune-in iOS App 24
    55. 55. COVE API• Request video object• Get video object• Pretty simple at its core• Manual key management at PBS• Public key available for POC 58
    56. 56.  WordPress PluginWNET built it and is using it in production code is public on GitHub 59
    57. 57. 60
    58. 58. Other APIs 61
    59. 59. Image Transformation Service (ITS)On-the-fly image resizing using URL decoratorshttp://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.pnghttp://image.pbs.org/ramp/programs/logos/NOVA_mezz_16x9.png.resize.103x58.png
    60. 60. Universal User Authentication (UUA) 63
    61. 61. Hey PBS ... what are you working on now?
    62. 62. Localization 65
    63. 63. Simplify the obviousPassed in parameters: ZIP, IP or CoordinatesReturn: Call signFilter and rank as necessary withadditional parameters 66
    64. 64. Document from the beginning, not as an afterthought 67
    65. 65. TV Schedules Rethunk 68
    66. 66. ~300 x 24 x 21 x 3 x 4 = ~1.8 million records(Actually closer to 2.629492 million records in PBS TV Schedules grid of information but who’s counting) 44
    67. 67. Not the best user experience 70
    68. 68. assume the role of a viewer 71
    69. 69. Build a robust API that fits the viewers needs and the user experiences will follow 72
    70. 70. MashupCOVE API + TVSSReloaded = EPG Nirvana 73
    71. 71. One ID to rule them all 74
    72. 72. Ask the questionwhere can I watch a PBS program? Yesterday 75
    73. 73. Today 76
    74. 74. Now that you know what we are doing... what can we do for you while we are doing what we are doing? open discussion begins..... now 77
    75. 75. API Reference• NPR • PBS – NPR API – TV Schedules – Transcripts – COVE – User – ITS – Playlist – UUA – Stations – Localization – Streams & Genres – TVSS Rethunk – Artemis – PBSGUIDPROJECT 78
    76. 76. PBS URLs• http://open.pbs.org - open PBS• http://answers.open.pbs.org - Q&A site• https://github.com/pbs - PBS github site• http://to.pbs.org/docs-api-cove• http://to.pbs.org/docs-api-tvss• http://to.pbs.org/docs-api-its• http://to.pbs.org/docs-api-uua 79
    77. 77. Questions?Tom Crenshawtwcrenshaw@pbs.org@justhomashttp://open.pbs.org/Javaun Moradijmoradi@npr.org@javaun 64