Tag: url shortening

URL shortening has been the subject of [much][josh] [discussion][scripting] recently, and there is one big reason: Twitter. Twitter has exploded in usage in the last 6 months, and with that has come a sharp increase in both the number of and use of third-party URL redirection services. [Bit.ly][bitly], [TinyURL][tinyurl], [Twitpic][twitpic], and the rest, are just some of the major players in the space. All of them provide similar functions but suffer from the same problems, some of which are outlined below.

[josh]: http://joshua.schachter.org/2009/04/on-url-shorteners.html “Joshua Schachter: On URL Shorteners”
[scripting]: http://www.scripting.com/stories/2009/03/07/solvingTheTinyurlCentraliz.html “Dave Winer: Solving the TinyUrl centralization problem”
[bitly]: http://bit.ly “Bit.ly”
[tinyurl]: http://tinyurl.com “TinyURL”
[twitpic]: http://twitpic.com/ “Twitpic”

The purpose of this isn’t to indict these services, all of which grew out of the need for something very much like what they are. I think that by outlining the issues and benefits, we can gain a better understanding of why we need URL shortening / redirection, and what can be done to improve the practice.

## Problems that URL Shorteners Solve

This is what they’re good for.

### The Problem of Memorability.

`http://example.com/~username/directory/this_page.html`

becomes

`http://go.to/thispage`

The removal of many “slash”es and a “tilde” makes this URL much more accessible. When spoken aloud, the URL is easy to keep in mind. “go to this page.”

### The Problem of Awkward or Ugly

`http://www.amazon.com/gp/product/020530902X/ref=s9_sdps_c2_s1_p14_i4?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-2&pf_rd_r=1QBB624XETXRNEPDHV6V&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846`

becomes

`http://tinyurl.com/c82sr4`

The link is now more aesthetically pleasing, won’t be as confusing to the tech-unsavvy, and won’t give most URL formatting scripts headaches.

### The Problem of Length

`http://daringfireball.net/2009/01/applescripts_targetting_safari_or_webkit`

becomes

`http://bit.ly/BDN6`

It’s now shorter, and affords the writer more space on Twitter or in an SMS to comment on the link. The Amazon link in the second example, with a total of 181 characters, wouldn’t even fit in an SMS, or Twitter message.

These are legitimate problems, and each pops up in different circumstances. Memorability is primarily an issue when using free webhosts that do not provide each user a unique domain name, with sensible URLs. Awkward/ugly is an issue with many online shopping services that collect tons of referral and other link data. Length becomes an issue when using a micro-blogging or SMS service, like Twitter. These problems often “stack”, and co-exist.

## Problems That URL Shorteners Create

### Reliance On A Third-Party

What happens if your URL shortener of choice goes out of business, or changes their URL format some day? It is not out of the realm of possabiltiy that TinyURL, Bit.ly or any of the major players in URL reduction could go the way of 1000s of other web companies. As of today, TinyURL.com claims to have created over 200 million shortened URLs. 200 million is a lot of dead links that could be avoided. Even if the service goes down for a short time, these are visitors and readers and customers that need not be lost.

### Obfuscation

One of their prime drawbacks of URL shorteners, this is used for comedic effects by some. The spread of the Rick Roll might not have gone so well if not for the semi-anonimity created by these services. In recent years some (TinyURL, for one) have provided a “preview” mode to guard against obscene or otherwise untoward usage. This is fine, but it isn’t a solution to the real problem. Without context, a URL that starts with http://tinyurl.com/ could literally go ANYWHERE on the internet. Even with a custom name (e.g. http://go.to/thispage) there simply isn’t enough context to know what kind of thing you’re clicking on.

### Unnecessary Strain On Networks

This is one is a bit less of an issue right now, but it is gaining steam: The dozens of free, url redirection services are causing network congestion by adding an extra HTTP request to every URL that is processed by them. One by one these are not problems, but by the millions they can make a notable dent in networking throughput, strain on hardware, and eventually, increased costs of keeping networking hardware healthy. Compounding this problem is the recent trend of Twitter clients to “expand” shortened URLs and provide the user with the destination URL, which creates even more unnecessary networking overhead.

## My Solution To Some of The Problems Presented Above

Obviously, I can’t just say “stop using URL shorteners”. Nobody would listen, and besides, sometimes URL shortening is necessary or  just convenient. What I’m proposing is that you **provide your own shortened URLs**.

Use my WordPress plugin [la petite url][petite], or another [short URL plugin][short]. There’s a [Django app][django], too. Providing a Twitter/SMS-friendly URL format for your visitors and users gives context to your links that would otherwise be lost. The URL `http://extrafuture.com/msfxe` is not as context-rich as `http://extrafuture.com/2009/04/08/on-url-shortening/` but it is markedly better than `http://tinyurl.com/ck9df4` or even `http://tinyurl.com/onurlshortening`. At least the user an idea about where the link they’re seeing might take them.

[petite]: http://wordpress.org/extend/plugins/le-petite-url/ “la petite url”
[django]: http://github.com/jacobian/django-shorturls/tree/master “Django-shorturls”

[short]: http://wordpress.org/extend/plugins/short-url-plugin/ “Harley’s short URL plugin”

This is not a perfect solution, and I’m aware of that. If your web site’s URL is especially long, then serving shortened URLs from it will not be useful. In most other cases, serving your own shortened URLs is an option can solve the problems of third-party reliance, length, and obfuscation quite nicely.