time-shifted Twitter - re-create the experience of watching events live with their time-synchronized Twitter streams

Live events are nice to participate in live, when they happen. But sometimes that doesn't work out. For whatever reason, we can't be there to watch the Emmy Awards live or a baseball game, Nascar race, or whatever.

When we watch a live event time-shifted after the fact, it would be nice to still have the Twitter social media buzz for that event. That's what my friend, from early EarthLink days, Brian Ladner @mysterylectric thought. Brian wanted a "Twitter DVR," a way to play back his Twitter stream synchronized with a pre-recorded live event he was watching on his TV. I thought it was a pretty cool idea too. So I threw together a quick implementation in Javascript:

twitterDVR

These are relatively simple client-side Javascript tools that work with the Twitter API and a modern browser, like Firefox, Chrome, or Safari.  They probably don't work in IE, but I will leave that as an exercise for the reader. Since they are purely client-side (in-browser) apps, they have limitations. I'll describe that more below.

There are two versions:

  • listplayback.html - Playback from a Twitter list. This version accepts a Twitter list and a start-date as input and then starts playing back the tweets from that list.
  • queryplayback.html - Playback a stream of Tweets based on a Twitter search query, such as by hashtag or other identifier associated with the live event

The Twitter List version is for those cases where you have a specific list of people that you want to monitor for their commentary of the event, when you only want to see the tweets from those specific people and not the entire Twitter-sphere. This will typically be a more precise and personalized set of tweets, and probably less voluminous.

The Query version is for typical events indicated by a hashtag or other searchable term or terms, such as SFGiants or  #BONES etc.

In all cases, once you provide input and say GO and the app collects the tweets, playback is the same. In the upper right, the state of the playback is shown, including the current time of the stream, the state of the playback (paused, normal speed, or one of three possible fast-forward speeds), and the "time cursor" or the relative position into the stream from the beginning.

Below that are some simple controls: PAUSE, PLAY, and FAST-FORWARD. There are three fast-forward speeds. Clicking FAST-FORWARD once gives you the slowest fast-forward. Click again to go faster and a third time to skip through the stream even faster. Click PLAY or PAUSE to stop fast-forwarding.

Tweets will appear in synchronized time in the main column. The app plays a sound when a new tweet comes in. You can turn that off by clicking the Sound ON/OFF toggle. The sound might not work in all browsers.

Using the Apps

These don't have very sophisticated user interfaces and they have no input validation, so you need to enter correct information in the proper format or they won't work.

For the Twitter List version, you must provide the Twitter username and the list name. For example, say you wanted to see what the tech. journalists were saying about some event based on the HuffPostTech/tech-journalists list, you would enter 'HuffPostTech' for the Screen-name and 'tech-journalists' for the list name.

The starting date is anything Javascript recognizes. To keep it simple, I suggest the following form, e.g.: "April 12, 2012 2:30 pm" or "April 12, 2012 14:30"

Press GO and the app will begin scanning backwards through the Twitter List or Twitter Search for the start-date. In the right-hand column you'll see a stream of progress as the app works. Then, if all goes properly, you will see the following in the right column: Done. nn Tweets. click to begin playback

If you don't see that message in the right column, then something has gone wrong. Check your inputs. Also, after the word 'Done' it will display the total number of tweets it has collected. If that number is zero, something went wrong.

Limitations

There is no official way that I know of to authenticate and access the home_timeline API using just Javascript to look back in your normal Twitter timeline. That's why this implementation works with a Twitter List instead.

There is no authentication, so all the Twitter API calls are considered "anonymous" and therefore are subject to tighter rate-limiting.

The Twitter List has to be a Public list.

Since there is no backend capturing Tweets and these apps rely entirely on Twitter histories and API limits, you cannot go back very far in time. This more or less means about 3000 tweets maximum. As a result, it is basically limited to playback of an event within a 24-48 hour window, such as later the same day or the next day.  In some cases, for an event with a large number of tweets, you might not even be able to easily go back that far.

Of course one could build this as a real service with a back-end. Who knows, I may do that at some point. But the nice thing about these Javascript implementations is that they are stand-alone and don't require any back-end database, PHP, or any other server-side infrastructure or code. However, it also results in limitations, as noted above.

All that said, I used it watching the crazy Giants vs. Colorado baseball game last night time-shifted by a few hours and it really gave a new life to the experience. 

UPDATE 2012-04-14: I started a Google Code open-source project for TwitterDVR: here. Anyone that wants to contribute, just send me your Google Account email and I'll add you so that you can update the code in SVN.

UPDATE 2013-06-11: With the final retirement of the V1.0 Twitter API Twitter no longer supports JSONP and therefore this kind of serverless hack no longer works. To implement the TwitterDVR concept now, in an API 1.1 world, would require a backend service (and servers cost $$$ to deploy and operate)

7 thoughts on “time-shifted Twitter - re-create the experience of watching events live with their time-synchronized Twitter streams

  1. Work with using both for various events over the weekend
    #twitterDVR hasn't yet created the buzz expected, but a bit. My main problem was actually using lists with this implementation, as you mention above. I have now downloaded the code and am learning it as well. I created "pre-taped" versions for "TxMotorSpeedway" for the NASCAR Cup race (http://t.co/k7JvUMuD), one for the Long Beach Grand Prix with tag "#TGPLB" (http://t.co/4AWMZOtD) and one for the @AshleyJudd show Missing "#Missing" (http://t.co/jWyjVcOS). Each starts at the appropriate time and so far I can go back three, four days no problem with queryplayback, but do run into limits. Good start on what many think is a cool idea but most don't know quite what to do with it yet. I have many ideas for enhancements, but need to learn how it does what it does first. Very cool.
  2. #twitterDVR off to a ... start!
    #twitterDVR hasn't yet created the buzz expected, but a bit. Check out http://goo.gl/info/dGAKx to see some response to the "pre-prepared" Indy race "replay" I put together and published on Sunday. My main problem was actually using lists with this implementation, as you mention above. I have now downloaded the code and am learning it as well. I created "pre-taped" versions for "TxMotorSpeedway" for the NASCAR Cup race (http://goo.gl/Dhg6r), one for the Long Beach Grand Prix with tag "#TGPLB" (http://goo.gl/dGAKx) and one for the @AshleyJudd show Missing "#Missing" (http://goo.gl/6OMtc). Each starts at the appropriate time and so far I can go back three, four days no problem with queryplayback, but do run into limits. Good start on what many think is a cool idea but most don't know quite what to do with it yet. I have many ideas for enhancements, but need to learn how it does what it does first. Very cool.
  3. the problems with lists
    the main one, especially compared to using queries, was that anytime i used a list and that functionality, if i added people to the list (while building it up), then went to retry a link i had created for that list at a specific time, it would drop off from hundreds of tweets found to 1, then slowly build back up. it also seemed like those fell out of range more quickly as you stated in the description above. i didn't have such problems (at least not so far) with the pre-generated urls for the nascar and indy races (or even the tv show) over the past few days.
  4. Twitter Lists
    Right, based on what you've mentioned it sounds like when you change the list membership, Twitter has to reindex the list in some way and that takes some time to stabilize. I hadn't heard about this issue before on the Twitter Dev forums, but suspect it's just something else we have to live with when it comes to the API and its issues/limits. There is this issue: https://dev.twitter.com/issues/123 and it claims "This should now be resolved" but perhaps that's not quite 100% accurate. :) I can't see how it could have anything to do with the list being a pre-generated url or not -- I think it's just a mater of giving Twitter some time to re-built the list timeline.
  5. Pre-generated URLs and lists
    It didn't directly have anything to do with the pre-generated URLs, other than the fact that I might distribute one, then add someone to the list used in generating that URL. In that case, what was bringing back a nice chunk of tweets for someone to follow was suddenly bringing back 2, then 5, then 12. i stopped promoting that way, at least while i was adding people to the list. ;-D
  6. Pre-generated URLs and lists
    It didn't directly have anything to do with the pre-generated URLs, other than the fact that I might distribute one, then add someone to the list used in generating that URL. In that case, what was bringing back a nice chunk of tweets for someone to follow was suddenly bringing back 2, then 5, then 12. i stopped promoting that way, at least while i was adding people to the list. ;-D

Leave a Reply