[catone]

I disagree with that statement. Even before the rise of microblogging, URL shorteners were helpful in certain situations.

Which URL would you rather paste in an email for readability's sake:

http://maps.google.com/maps?f=d&source=s_d&saddr=Oak...

or

http://tr.im/Gw8B

In context, the recipient should have no problem anticipating the URL's end point (i.e., you probably just wrote something like, "here are some directions to my house:"), but using the shortened URL makes the email much more readable and prevents any potential screwy scrolling issues that might be caused by an ultra unwieldy URL borking their email software.

That's just one non-microblogging use case for one site that spits out very long dynamic URLs -- there are many use cases for many sites.

TinyURL, et. al. certainly did (and continue to) solve a problem, imho. And they've become even more useful for microblogging sites like Twitter, on which character limit constraints (which essentially defines that type of service) require that URLs be shortened.

[EDIT: I know HN auto truncated that Google Maps URL, but it is a 355 characters long -- and most email software (my use case) wouldn't auto truncate the URL in the same way. So readability would be negatively affected for the recipient by using the long URL instead of the short one.]

[_dan]

The former. Even though it's 355 characters, at least it tells me it's a Google maps link. Which the shortened version doesn't.

There are some situations where URL shortening is arguably useful. But there's absolutely no reason why "microblogging" should be one of them.

[leonh]

You could use this bookmarklet which translates all short URL's in to long ones. But then again maybe you do not trust longurlplease.com.

  javascript:void(function(){if(typeof%20jQuery%20==%20'undefined'){var%20s=document.createElement('script');s.src='http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js;document.getElementsByTagName(head)[0].appendChild(s);}var%20l=document.createElement(script);l.src=http://www.longurlplease.com/js/jquery.longurlplease.js;document.getElementsByTagName(head)[0].appendChild(l);function%20runIfReady(){try{if($.longurlplease){%20$.longurlplease();%20clearInterval(interval);}}catch(e){alert(sadsda)}};%20var%20interval%20=%20window.setInterval(runIfReady,100);}())

[Skeuomorph]

That inline bookmarklet didn't work in Safari 4 (OSX 10.6), but the bookmarklet from http://www.longurlplease.com/ did--thank you for sharing it.

[andrewljohnson]

Spoken like a person without a Twitter account.

[bjelkeman-again]

Twitter should solve this problem, they should stick links separately to the 140 characters. Like they don't force you to encode the picture of the person in the 140 characters.

For SMS, well if the link goes beyond 140, send it in a separate SMS? Should SMS messaging compatibility for Twitter break the whole paradigm of transparency of addressing on the web?

Time to move on and create solutions looking forward, not backward.

[Pistos2]

FriendFeed FTW. You can attach photos [separately], and each FriendFeed post can have a comment thread.

[bkudria]

It's not like SMS is limited to 160 characters, anyway.

[Kadin]

That's a stupid design decision on the part of Twitter, which the rest of the Internet is paying for.

At the very least, Twitter could only shorten URLs when messages go out via the SMS gateway, and not universally. All they'd need to do is count any valid URL as 20 characters (length of a bit.ly shortened URL) for the purpose of the limit, while preserving the actual real URL up until that limit actually mattered.

The sad and ironic part is that the 140-character limit and the URL shorteners it spawned will probably stick around, due to Twitter, far longer than Twitter-via-SMS does. I don't know many people who even use Twitter via SMS anymore; it was a cool feature initially, but it's being quickly obsoleted by smartphones that can access Twitter via much more user-friendly interfaces via TCP/IP.

"140 characters" is likely to become the "4 feet, 8-1/2 inches" of the Internet. Totally arbitrary, far from ideal, nearly impossible to change.

[bumblebird]

eg most people.

[_dan]

You got me ;)

[boredguy8]

Yeah, I don't get why shorteners don't have the option to do something like http://tri.im/maps.google.com/8HkN - short but still insightful (way better than 'visit this preview page')

[Pistos2]

> it tells me it's a Google maps link. Which the shortened version doesn't

See http://twi.bz/ .

"twi.bz shortens web addresses without completely obscuring where the link ends up. By keeping part of the domain name in the twi.bz link it's possible to instantly see the site you'll end up on by clicking the link."

[dkersten]

The former. It shows the reader not only where I'm sending them, but even gives them an idea of what to expect, not to mention the whole dead links problem that will inevitably occur when these sights finally go down.

What I would normally do is something like this "<loads of text> Check out my map here [1] <more text>" and at the end put "[1] http...", that way a giant ten page url doesn't interfere with the message, yet I don't have to shorten it either. If I think the precipitant won't understand what I mean, I'd put more details in, eg [1 below]

The ONLY place where I'd consider using a url shortener is printed material, since its easier to type in by hand than a giant url, but this has the same dead link problem, especially if printed in magazines.

[catone]

I like your footnote idea, though I think it seems fairly unnatural for casual communication. To me, short URLs seem like the more user-friendly solution.

I'm also still not sold on the dead link problem for two reasons.

1. You're already relying on one site (in this case Google) not to go down or change its dynamic URL patterns. Certainly adding another layer increases the chances of a dead link, but any time you link to something on the web you're taking a risk of sending someone to an error page.

2. Most instances in which you'd use a short URL -- such as email -- are for instant communication in which the recipient is likely to visit that link in the next day or two. In other words, you wouldn't link to a short URL in the body of your web page or blog (something with more permanence on which you want to be sure the link works months or even years from now), but for email or Twitter messages, which are generally fleeting and timely, that matters less. As long as the link works right now then all is good. If the person visiting the links wants to save it for later, they'll more than likely bookmark it, cutting the shortener out of the loop anyway.

[dkersten]

Sure, but it doesn't change the "Oh, some random site, I have to click on it to see what it is" vs "oh, its google maps, and I can also see the street in the url, i'll save that for later" loss of information in shortened urls.

I dunno, you can use url shorteners if you want, but Im not convinced of their usefulness, thats all.

[bruceboughton]

1. The dead link problem is that Google, for example, can't control whether a bit.ly link will work but they can ensure maps.google.com links will always work if they want to. And they have a bigger incentive to ensure this than bit.ly do (since they consider their Maps service to be an important service).

2. True, but there is a vast amount of valuable information held in tweets (along with the noise), each with a permalink. A tweet's permalink is useless if it contains a shortened URL which no longer works. Do we really want this body of information to become useless at soon as URL-shortener-of-the-week loses funding and turns its servers off?

[bumblebird]

That problem should be solved in the 'reader'. If a url looks long, get your email client to show a small version of it. Get it to show the full URL when you hover over it. Whatever. Just do it in the client.

Even on twitter it's a stupid artificial restriction. It would be pretty trivial to show minified links for SMS alerts (Which is a tiny amount of twitter anyway now), and show full URLs for everyone else. Then clients could show the urls how they like.

[storborg]

Sure, since it's definitely easier to change thousands of different email clients, twitter clients, and cellphones in use around the world than it is to write a 10-line web app that wraps a key-value store.

[roc]

Exactly.

And while they're at it, they could emphasize the actual root domain when showing links.

The fact that scammer links with obfuscated URLs are still successful is shameful.

[symptic]

This tells me Google should consider providing shortened URLs. maps.google.com/a7sga would be great.

[jurjenh]

That could possibly be implemented as a hash of the included header/response terms.

A simple example could be http://www.google.com/search?hl=en&q=hacker+news+site:yc... -> http://www.google.com/search?#b9fh23

One downside would be that you can't see the query parameters and values in plaintext, but a browser extender / inspector could probably do this.

[ggrot]

You can make it much shorter without loss, unfortunately Google Maps doesn't do it for you:

http://maps.google.com/?saddr=Oak+Green+Way+33611&daddr=...

[rapind]

URL Shortener makes sense in this context for sure. I think providing your own friendly paths in web apps you build is a good idea too, so people don't feel the necessity to use a url shortener which is one more thing to do.

The maps URLs are ridiculous. Google should provide their own shortener for these imo. Then you get the best of both worlds, smaller more readable URLs and within a domain you recognize / trust.