Solving the TinyUrl centralization problem

Saturday, March 07, 2009 by Dave Winer.

Following up on an earlier bit about centralizing and TinyUrl, this is one of those vexing problems that actually has a solution!  

Every web app that produces long urls should provide a built-in url-shortening facility. The user interface would be similar to the one in Google Maps they call "Link To This Page." You click on it, and up pops a box containing an address you can use to point to the page. Screen shot. 

But look at the size of the url that Google gives you. It should be short. Why not something like: http://goog.us/8uj9oj. 

In other words, why doesn't Google have a built-in shortnener? 

When blogging software gives you a permalink, it should be short. It's okay to make the user ask for one, why clog up the system with shortened urls no one uses. 

Another key point, when they give you a shortened url, it should point back to the software that gave it to you, so the shortened link will be exactly as long-lived as the thing it's pointing to. In other words, the URL shortener wouldn't contribute any extra link rot, to use an old term coined (I believe) by Jakob Nielsen. 

It's a mistake, in hindsight, for Twitter to give us TinyUrl urls, because the link depends on two companies and two servers. It would be better if it just depended on one, less likely to break. 

Now that URL length has become an issue for users, it might be even better for designers to view URLs as part of site design. Look at the address for the page for the Wii at Amazon. Wouldn't it be easier to find if the address were: 

http://amazon.com/wii  

Try clicking on it -- it actually works!  

Why should a user ever see the longer crappy url? 

In other words, url-shortening isn't just for Twitter users, it's for everyone. Maybe most people don't look at the urls, but some do, and maybe more would if they made more sense? 

Note: This is a repeat of a piece I wrote in November 2007.