Limits of a URL Shortening Service

Apr1609Apr 16, 09

After creating in October of last year, I've been watching the service grow amidst a wealth of near-identical competitors. One of the ideas I originally had for a unique twist on URL shortening was to provide automatic tools for linked content. There are a number of reasons I never pursued this avenue, some obvious and some not-so. In order to provide a practical analysis of the problem and its potential solutions, I will use the example of linked images.

When someone dFL8's (shortens) a URL, there is an expectation that the service will provide only a simple redirect, and the final URL will be displayed after the two DNS records have been fetched. Interestingly, there has been no digression from this concept. One of the reasons is certainly the expectation users have formed about the simplicity of these services - a pre-conceived notion that they are extremely simple. In most cases, this is the truth. I set out to prove this point when creating by creating the entire service in a single evening. Although there were a few quick bug fixes and updates that needed to be done after a week, the point had been made.

Another expectation that has formed in the minds of Twitterers and location update junkies is the ability to use a shortened URL in place of the original for absolutely anything. This is logical - but is it effective? Coming to the example of linked images, many people used shortened URL's for image files when placing images on a web page (I am guilty of this). This might seem great, but it forces services like to remain within the confines of HTTP requests and redirects. It has always been my intent to expand URL shortening into something more usable and interactive, which would allow for things like AJAX document and image viewers, or (tasteful) custom toolbars.

Imagine for a moment that you have just found what you believe to be an excellent LOLcat picture not yet posted to ICanHasCheezburger (of all things!). You decide to shorten the URL of the image and post it to Twitter. Assuming you have a decent number of followers, a few people are going to see that link and open it up - just a plain old image in its own browser tab. This is not a very pleasant experience, and there is no convenient way to resize the image or pan around if it is very large. Wouldn't it be great if that URL shortening service had detected that you linked to an image and provided a more effective tool for viewing it? I think it so.

Unfortunately, this is not the easiest thing for a service like this to accomplish. Remember that the paradigm is such that the image you linked to should be usable in the src attribute of an image element on any web page. If the service were to automatically provide an image viewer for the link you shortened, using the shortened URL as in an HTML <img> tag would be impossible. That great, usable AJAX viewer would be interpreted as binary image data by the browser and the result would be a mess and ultimately no LOLcat (a terrible loss).

So you can see the problem. The same is quite true for all binary content, like non-HTML documents and audio files. I would love to provide such a handy service, but I am at a loss for a clean and universally compatible solution to the embedding problem. Perhaps the solution would be to enable the advanced functionality as an option when the URL is shortened.

Your thoughts?

About Jason Miller:

I am a JavaScript developer from Waterloo, Ontario, Canada. When I am not typing green code onto a black screen, you might find me at the nearest coffee pub checking out the brew. I run a internet firm called developIT and maintain blogs and web apps when I can.
What about the HTTP Accept: header?
I'll have to look into the differences between requests sent via the <img> tag and requests sent for the originating document, but I imagine that one will vary by browser. Thanks for the idea!
cheap jordans#
2018530 leilei3915
Leave a Comment

Post Comment