When is a URL shortener not a URL shortener? | Hacker News Reader

When is a URL shortener not a URL shortener?

qntm.org

87 pointspavel_lishin27 comments

> Once it's fixed (I'll let them know about it tomorrow and I expect it'll be rectified in a day or two) I'll update this page, but until that time, try it for yourself.

Sadly, it will never be fixed. This is not a bug to them. They are forcing every url on twitter to go through t.co for click tracking. It is no longer possible to put a url into a tweet without going through t.co, unless you leave off the http, which makes it unclickable in a lot of clients.

Twitter's description says wrapping only applies to links of 19 characters or longer.

https://dev.twitter.com/discussions/1062

Sounds like a bug.

Might be a bug, but the posting API has also been updated to allow developers to flag that all URLs to be wrapped, no matter the length. And it looks like the plan in the long run is to wrap all links.

"Eventually, all URLs will be wrapped regardless of length; we'll let you know more details on those dates well in advance."

This doesn't just bug me for URLs that are shorter than the t.co URL, but also when I'm posting a link to a website and I want people to see the full URL.

e.g. It is often sufficiently descriptive to tweet "This is a great site: http://actionfiguresridingkittens.tumbly.mil

Twitter has implemented a decent solution for that, which most clients (including the website) respect - it includes a display_url parameter along with the shortened URL in tweets fetched via the API.

But the displayed URL is truncated with an ellipsis at the end. The OPs URL is likely long enough to trigger that. Sometimes a long URL is all you want to share, but that is now impossible to do. A tweet saying "http://hotchickswithstubbedtoesmakingsexfaces.com/ exists" is a decent tweet, but a tweet saying "http://hotchickswit... exists" isn't as good. And sure, you can mouseover to see the full link, but that's balls.

"It is often sufficiently descriptive to tweet "This is a great site: http://actionfiguresridingkittens.tumbly.mil

You disappointed me when I clicked that link and found it didn't exist.

There's no preview for this, so you find out too late.

I think a proper short URL looks neater too: "http://t.co/x812ks1 A site about action figures" "http://action.figures.com/rid... A site about action figures"

The short URL may not look pretty, but at least regular Twitter users will quickly learn to process it as "some URL". The longer abbreviated one breaks that convention and by including some actual meaning, it gets in the way.

Agreed. I find short urls to be irritating when I want to share a link. REST makes it so links can be descriptive without visiting the link. I remember sending a link to a friend by DM and having them think it was spam since Twitter shortened it.

A solution to this would be for Twitter to post the t.co URL if the original URL is longer than the t.co URL or if the original URL is too long to fit in the tweet. Else, it would display the original URL but direct it to the t.co URL for tracking.

So a tweet that says:

    Check it out: http://zombo.com

Would be posted as:

    Check it out: <a href="http://t.co/whatever">http://zombo.com</a>

This would preserve Twitter's tracking while maximizing the amount of information in the displayed URL as well as meeting the user's expectations, intent, and needs. Thoughts?

I was in the middle of writing a response say that would be "bait-and-switchy" until I remember we're already talking about URL redirection.

As long as it doesn't slow down the user experience much, adding in the additional layer, I think it'd be fine.

That's what they already do through their web interface. And for any apps/whatever using the API, they give both version of the URL so that developers can do the same thing.

There are pigeonhole principle issues with the concept of url shortening - the same that apply to data compression in general.

With regards to urls that are a bit of ways down the tree (http://www.foo.com/bar/baz/whatever), this isn't really an issue, as generally within a domain, the url-friendliness comes at an expense of a great deal of length, and you can do something like:

shortened url := http://short.nr/shorten(domain)shorten(tail)

and end up with something shorter.

When trying to shorten already-short urls, though, characters will not necessarily be gained.

From Twitter's perspective, the ideal solution might be to count "urls" as a fixed length, or an attachment, with respect to the length of a tweet so as to sidestep this issue entirely.

If all you want is shortening, then there shouldn't be a problem: if the t.co link is longer, just don't use it. This is different from data compression because "pointers are automatically dereferenced": there's no functional difference between t.co/foo sending you to google.com and t.co/bar sending you to t.co/foo. (If I'm wrong about this, then it's still possible to not-make-longer everything that isn't a t.co link.)

A similar case with data compression would be if you can guarantee that the decompressed data is never a valid compressed file. In this case, compress something iff that makes it shorter, and decompress something iff it's compressed.

t.co isn’t just shortening—it’s also click tracking.

That's pretty much an assumed feature of any URL shortener these days. Many folks use them precisely for that sort of analytics.

>it's also click tracking

My understanding is they don't do this (at least publicly) yet (http://www.dnxpert.com/2011/06/08/twitter-officially-launche...)

I recently found a t.co link in my server logs but thankfully was able to track statistics by looking at information provided by the bitly URL it forwarded to.

So.. it's click tracking. Big deal. The magic of HTML is that the link that's displayed (the original if shorter?) doesn't have to match the actual href.

To use the zombo.com example above, why can't Twitter use the "shortener" to track redirects in the link and display the actual? <a href="http://t.co/?r=zombo.com>http://zombo.com</a>;

They're already doing something similar with elided URLs, why not with short ones?

I'm not familiar with the API--this of course assumes are tweets returned as html, not text.

this 'feature' works even with http://bit.ly or http://t.co, lol

It's surprising that URL shorteners are so central to how Twitter works, but they only recently built it into their own UI. I've been using the website interface lately and find myself having to shorten externally and paste it into Twitter, as the 120 default is sometimes too short.

Well, regardless what their policy says, it's been buggy this way since they introduced it, and they've thus far ignored the many, many bug reports they've gotten about it. If yours gets through to them that would be wonderful, but I'm not holding my breath.

Cannot believe that developer forgot to include this at the end of shortening process:

if(strShortenedURL.Length > strURL.Length) { //Handle this case //donot use shortened version, use original URL }

It's not in their interest to do so, as it would leave already short links without them being able to track them

When it's ajar?

link wrapper != link shortener

totally agree, some "shortening" services simply give you some value add services like - http://sclst.mp , http//su.pr etc.

Reply on news.ycombinator.com