I've been Twittered.

After working on the Tweetports component for Joomla! 1.5 I have become intimately familiar with the Twitter Search API and the power and limitations associated with it.  More importantly I learned there is the still untapped power in tweets and tweeting, twittering, oh heck who knows what to call it. Twitter has largley been defined by its use and users and has become a powerful communciation tool but also provides the capability for people to talk about every inane thing they do during the day.  Trust me; there is such a thing as TMI (Too Much Information) and the fact that you clipped your toenails or just added salt to your pot of chili fits squarely in that category.  That is the simple beauty of Twitter - use it for what you want.

But with all of the static that is Twitter there is hidden gold in them there hills.  Check out this interesting read from the BBC, Twitter used to predict box office hits, correlating tweet frequency to the prediction of box office results.  Through the process of developing Tweetports I looked at a bunch of Twitter and Google Maps mashups.  Maps that showed where the latest tweets were appearing from around the world geo-located on a Google Map - midly interesting but not of real use.

The power of Twitter for EO MediaWorks is the ability to provide an easy micro-blogging architecture that's free to our customers.  An architecture that supports third-party applications for smartphones such as the iPhone, Android, Blackberry as well as text-capable phones that support SMS without having to incur development costs.

Companies are starting to use Twitter effectively as an opt-in method for clients to stay abreast of company related activities, agencies are beginning to leverage the platform for effective marketing.  We wrote Tweetports as a platform to provide an open reporting arcitecture that leverages Twitter's emerging geo-targetting capability.  During development it became clear that trying to leverage the geo-targetting capability was powerful but has a couple major shortcomings.

Geo proximity was a major factor, how to correlate a location with a tweet if the tweet is created after the fact and the device you are entering the tweet provides the geographic location.  Let's say you want to provide a tweetport for a specific location but dont have an opportunity to do so until you're half way home (please dont tweet while driving).  If you tweet from your geo-capable mobile device the report will be targeted on your current GPS location and not the location you are trying to report on.  This geo proximity issue makes the report practically useless if the goal is to use a technology Google Maps to provide a map-based interface to access those reports. 

To overcome this we found it necessary to support another Twitter technique in the form of hashtagging.  The # symbol, also called hash, coupled with a geogrpahic location are combined to provide a exact location for the tweetport.  We didn't create hashtagging and neither did Twitter, it was a technique that was adopted by it's user base organically.  Let me give you an example of typical use of hashtagging.

Hashtags are used to allow people to more easily search for something within the Twitter universe.  Tweetports build a correlation between a given hashtag, #grandhaven, and a longitue/latitude location used for locating the postiton on a map.  Ofcourse using hashtags is only one part of the Tweetport solution because a generalized hashtag like #grandhaven is likely to be used by any number of people outside of your Joomla users.  Tweetport allows Joomla users to register their twittername and then only that subset of tweets are searched.  This had two benefits in our design as it reduced our search queries to a focused subset and also eliminated the noise and possible spamming of certain hashtags.

In the first itteration of Tweetports we tried to do real-time search queries of Twitter but after early load testing this proved to be overly ambitious as the performnace of twitters search engine left much to be desired.  Given this limitation we decided to implement a cached based strategy where we query tweets for registered users and then cache those results.  We maintain the latest unique message ID for each registered user and then use Twitter's Search API to return results newer then that id (since_id parameter).  We then created a cron job (timed self executing program) to run these queries asynchronously of what user are viewing.  While this is not real-time based on thefrequency of the cron job it can be close and in the case of Tweetports real-time has only marginal benefit.

In the latest itteration of Tweetports the user experience has been significantly imrpoved through the elimination of reliance on Twitter performance and will allow for greater interactivity.  Additionally, we now maintain a internal history of all Tweetports so that we can do any post processing we see fit at anytime without relying on very complicated and large queries against the search API.

We are still in pre-release stages at version 0.95 but are projecting a May 1st launch of Tweetports to the general market.