Ever since Twitter switched over to using the official ‘t.co’ short linking it has become impossible to tell where a link is sending you before you tap it. This has always been true of other shortening services, of course, so we shouldn’t pick on t.co too much. The difference is that Twitter has given us a glimpse of how cool the t.co ‘wrapper’ can be on Twitter.com and in its official apps.
In any of those apps, the shortened t.co links are displayed as a plain-text preview that gives you the full URL, followed by an elipsis. This makes it easy to see where you’re going when you click on the link, before you click on it. It’s a cool way of handling the issue of conserving space, while still giving the user as much information as possible.
F**k it, we'll do it live!
Our biggest ever edition of TNW Conference is fast approaching! Join 10,000 tech leaders this May in Amsterdam.
You can see how it looks in action in the results of a search on Twitter.com here. Notice how the links are shortened to fit the length of the Tweets and apended with the elipsis when they run up against the character limit.
As you can see, the links either display the full URL of the site or, at the very least, the custom URL shortener that the site is using, which is normally easy to identify.
This is great, but unfortunately this does not work on searches in third-party clients because the search API that Twitter gives to developers to use doesn’t give them access to the ‘URL entities’ when producing search results for their users. So that means that you get results like the one below, where every link is a t.co shortened link instead of the much nicer long ones.
That should all start to change now though as Twitter announced today that it is giving developers of third-party applications the ability to access URL entities for themselves. This means that your favorite client, as long as they implement it, should be able to start delivering you the same easy-to-read results in their searches.
I talked to Paul Haddad of Tapbots, the makers of Tweetbot and said that this is a step towards bringing the search API in line with the rest of the Twitter API as the URL entity was one of the major omissions from it. He also said that it should be fairly simple for clients to modify their apps to handle the new option.
I’m happy to see this as I always prefer to see actual readable text rather than a blind shortlink before I click on it. I rarely use the Twitter website and use several clients on mobile devices to perform searches on topics, so this will make it easier to choose which links I tap on in searches and which ones I don’t.