The Original Question
I have a friend in Real Life (who is also on Twitter as @practicalkatie) who tweeted me a perfectly reasonable question the other day:
hey – where do you find out the date you joined twitter? everyone is twittering about their anniversary dates, but I can’t even find mine!
and I realized I really wasn’t sure myself. So I went pawing around at the Twitter API Documentation site, and I came up with the RESTful method users/show, which uses a GET with a userID or screen name as data payload and returns extended information in JSON or XML form. So of course I tried it out in curl:
curl http://twitter.com/users/show/practicalkatie.xml
and lo and behold, there was an element returned called "created_at" to read. So I sent her the curl command-line. Then I thought about it some more, and I realized that was kind of a dumb thing for me to have sent her: how do I know she has curl installed? So I made up a little piece of code to provide that user-lookup service: twitterinfo 
Let Nothing Serve But One Purpose
As long as I was writing a Web-based user interface to a user info lookup sevice anyway, I figured I might as well use the opportunity to distribute the work (no API key or such to hide in the middleware) and let the client talk directly to Twitter. And hey, why not make it so it can "already be there" on a handheld device when it is needed? Why not move towards making it a WebApp? Let them load it once from the RIT server, and thereafter get it locally.
This, of course, is a security problem. Unless you are willing to be a little twisted in your code.
The Same-Origin Policy
Like the Applet security model, the JavaScript security model says it is only allowed to open sockets and make requests (and thus send data) back to where it originated. And this stuff was not going to be originating on the Twitter server, it was going to be originating at RIT.
And so I had an excuse to play with another idea: JSONP
jQuery Makes It Easy
JSONP works by injecting a callback function into the JavaScript acting on the DOM, after the page thinks it is done loading and coming from the remote server. Weird, huh? I really didn’t want to write that code right now, I just wanted to use that capability and refine it later by writing it myself. jQuery has some already-defined functionality to do just this, and I am basically lazy. So I used jQuery’s $.getJSON function. jQuery makes it easy to do this stuff; you simply pass the fully-made-up URI for the GET and a function prototype.
$.getJSON( fullUri,
function( data ) {
processJsonResults( data );
});
The fullUri parameter contains the request we saw in curl, with a minor twist to deal with naming the callback, and the data variable in the anonymous function used for the callback ends up containing the response. The only real problem is that there is squat for error-handling. Anything other than a successful request-response cycle is unthinkable to this little bugger… There are always trade-offs for initial laziness, and this is one of them: I’ll accept this first version being stoopid about users typing in non-existent user-names to look up, for the sake of not having to write this particular code myself.
The Data Display
I figured a simple list would do, there wasn’t much in the way of depth to the "extended" user data returned and simple displays are easy for user to understand quickly. I also figured the avatar-picture should actually show in the list, and that "Web Home" field should be clickable.
Mobile? Did I Hear Someone Say Mobile?
I figure it should be made to work on mobile devices as well, I mean I do run this little Center for the Handheld Web and it would be a bit embarrassing to not make it work okay on "reasonably smart" mobile devices . And by "reasonably smart", I mean handhelds with browsers supporting the basic Holy Trinity of XHTML, CSS, and JavaScript. So I made sure it worked small, I added a bit of meta-tag magic like this:
<meta name='viewport' content='width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;' />
and I added a little iPhone-specific JavaScript magic to make the address-bar roll up out of sight like this:
document.getElementById("toolbar").style.visibility = "visible";
window.scrollTo( 0, 1 ); // pan to the bottom, hides the location bar
and it was ready to go.
The structural markup was simple and should work on a small screen using gestures, the browser had been told not to mess with the fonts and such and to hide the address-bar, the sneaky JavaScript request/response code-injection was working, & the response-data node injection stuff was dealt with.
So What Next?
Simple things that do one thing nicely make me happy, but I can sometimes make things just a teenie bit "too simple". So I asked folks on Twitter what they would like to see as extended features for my little app. I figured there was no harm in asking, and the only responses I got involved seeing who someone was following and seeing who was following them. Followers and following, that is what folks wanted. And so that got me to thinking too, how about letting them "follow a trail"?
Wandering Through the Webs
Any list of followers or following users appears flat, but each entry in it is actually a node in a set of "interpenetrating webs of social affiliation" (as I have put it in other writing). Each person who follows me has in turn people who follow them and people who they follow. To each of us, we are at the root of a couple of webs. Looking at the larger picture, we are each embedded in interpenetrating webs (plural). If I get a list of the users following so-and-so, each of those entries should in turn be clickable so I can follow a path wanderting through the webs embodied in Twitter's persistence store.
Back to the API Docs
Of course, this meant I had to go back and look at the API documentation at Twitter. Was there any way for my WebApp to ask for user info on all the friends of someone with one call to the Twitter API? I wanted to be nice… sure enough, the REST API comes to the rescue with the method statuses/friends. So I tried that out in curl with
curl http://twitter.com/statuses/friends/jeffsonstein.xml
And it seems to work just fine. Perhaps I can add that functionality to the client and still not bang on the Twitter machines with too many API calls.
So That is Where We Are, Now
I have another week of classes, then exams to give and grade (ugh). Then I get to play with this some more. What do you think of it so far? Do you think I am going in the right direction with the follow-the-webs extension I am planning? Will it still be simple enough and work okay on a handheld device? Comments are very welcome.