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.
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.
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.
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.
> 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.
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.
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:
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.
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.
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?
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.
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.
28 comments
[ 2.6 ms ] story [ 63.4 ms ] threade.g. 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.
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.
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.
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.
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.
https://dev.twitter.com/discussions/1062
Sounds like a bug.
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.
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.
if(strShortenedURL.Length > strURL.Length) { //Handle this case //donot use shortened version, use original URL }
So a tweet that says:
Would be posted as: 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?As long as it doesn't slow down the user experience much, adding in the additional layer, I think it'd be fine.