api

Entries tagged with “api”.


Daniel Sandler is experimenting with using twitter for comments, and makes some very good points about comments on the web in the process. Essentially, he pulls in the content of any tweet that references his post’s full URL, TinyURL, or even just the TinyURL hash. This has the very nice effect of forcing people who want to comment on his post to own their words. Their comments will be public to their own audience, and so are more likely to be constructive and civil.

Twitter comments on Daniel’s website.

Tying your tweet to a particular page online is awkward though, due to Twitter’s 140-character limit. URLs were designed to be expressive, but not necessarily space-efficient (compare them to DOI or ISBN codes). Twitter’s recent rise has driven the increased use of URL-shortening services like TinyURL and bit.ly, which were originally designed because of the limitations of email clients that weren’t able to correctly break up an URL that was wider than the 80-character wide text columns used at the time.

We seem to have replaced one limitation with another though. By feeding all URLs through minimisation services, readers lose all context about the page they are about to open — is it a video? What domain is it on? Have I visited it before? There are some links that I would be disinclined to click on when using my iPhone, but with minimised URLs, you don’t know what you’ve got until it begins to load in. Plus, there’s the nightmare scenario that the URL service dies, and since their databases are kept private, all that information is lost.

I think URL shortening services could be obviated if Twitter started treating URLs a little differently. There are two main audiences for twitter tweets: mobile phone users who receive tweets as SMS messages (this is the original reason why twitter has 140-character limits), and users who visit the twitter website, or use one of the myriad desktop and smartphone applications to keep up with tweets. These users are not concerned about the character limit in the same way. I would expect this group of people to be growing faster than those who get tweets via SMS.

Ideally, Twitter would disregard URL content as part of the character limit. If you think about it, the URL http://tinyurl.com/cxt59m (this page) conveys almost no information whatsoever. It could as easily be replaced with some single-character replacement in SMS messages (whose users are much less likely to actually follow links than web/applications users anyway). [On further reflection, it is clear that this wouldn't work as I imagined, as the target URL for these single character links would still need to be encoded somewhere as part of the message.]

On the web, and in applications, URLs shouldn’t need to be minimised at all. Twitter clients could truncate URLs for display, but all the URL content should stay available to be used by those clients that want it.

Twitter has really taken off in the last few weeks. If you haven’t signed up yet, and are sick of hearing about it, I sympathise. I didn’t understand what the point was at all until I signed up, originally just so that I could follow a few interesting people better than I could using RSS. Eventually, you’ll see a conversation going on and want to join in.

From a web architecture point of view, Twitter is particularly interesting because it is, to my memory, the first web 2.0-ey application that doesn’t really need a website. They’ve done such a great job with their API and backend that there are dozens of excellent applications and plugins for just about every publishing platform. I read and post from a bunch of applications — Tweetie on my iPhone, and Lounge and Tweetdeck on my laptop — and very rarely actually visit the Twitter website.

I guess this is a matter of partly good timing (now that smartphones are common), and partly that tweets are perfect iPhone-sized data.

Recent bookmarks tagged with “api”.