Hacker News Reader

Comment by bumblebird | Hacker News Reader

The fascination with url shorteners is really worrying and useless. Can we get past this fad?

Indeed. They're a solution to a problem that doesn't exist.

And a problem to a solution that does.

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...

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.]

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.

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.

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.

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?

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.

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.

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.

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.

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);}())

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.

Spoken like a person without a Twitter account.

eg most people.

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.

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

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

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.

You got me ;)

> 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."

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')

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.

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

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.

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=...

a solution to a problem that doesn't exist

I do not use them, but long URLs are a pain in many contexts, and it's not always possible to [link]wrap a tag around it[/link]. Server > client communication has gotten incredibly flexible, but client > server or client > peer communication is still mostly text-driven, and many URLs are not text-friendly or human-friendly.

The widespread use of these shorteners strongly argues that they do solve a problem, just not one that matters to you as a programmer.

If the problem doesn't exist, why do so many people find them useful?

death to tiny urls! I want context back!

I was against shorteners for a long while, but you can't argue against the fact that it lets you fit more in your message when you have a character limit to deal with, such as with Twitter, identica, FriendFeed, etc. I try to restrict my use of shorteners to microblogging. When following shortened links, I just use common sense and take into account how much I trust the source of the shortened URL. In practice, this has worked very well for me.

What if Tweeter and other places that have message length limit ignore the length of the URL in you post?

They can't do that due to text-message length restrictions

They should have their own url shortner.

Every major website should have their own URL shorter. People would be more willing and trusting to click a random link found on Twitter if it's from Gizmodo's short URL rather than bit.ly.

Then again, people shouldn't click random links.

"Then again, people shouldn't click random links."

What does this even mean? The web's primary use case is clicking random links as defined in some context. Shortened links rarely show up in a tweet without any defining context.

No need to build a new one every time; services like http://totally.awe.sm let you set up a URL shortener on any domain. (Disclaimer: the founder is a friend of mine)

And before you say "it's trivial, I could build that in a weekend" I suggest you try it; there is a lot of hidden complexity in something so simple, especially at any kind of scale.

I understand, from looking at this when I first came across twitter, that there is a well established protocol for using multiple text messages to send a single message.

Couldn't they in any case have a convention of putting a hash mark (#) for the URL when texting and then sending URLs in subsequent messages, each message being serially (by time of sending) matched with a # mark?

The concern for me is that they disguise the original URL and if the shortner ever ceases to exist the context of a lot of microblogging posts will be lost for ever.

who cares if the content is lost forever? It's ephemeral data anyway. The emphasis is real-time not all-time.

The stats that you can get out of something like bit.ly are quite useful. Or at least ego-strokingly hypnotic.

I'd say they were largely unuseful and inaccurate :/

I use an extension, like many others, that automatically "follows" every url shortener url on a page. Your stats are likely skewed.

In an ideal world the extension would only be making HEAD requests and the analytics system would only count GETs, right?

In an ideal world, HEAD and GET probably wouldn't exist.

But we're here. The question is, does the analytics system work that way?

Reply on news.ycombinator.com