Expanding URLs in Dabr / Twitter
bit.ly dabr longurlplease twitter url · 7 comments · 500 words · read ~493 times.
I hate shortened URLs with a passion. It makes it hard to see what a link is and whether I've visited it before. If they fail - like tr.im threatened to do - you lose your links with no way to see where they once went.
So, hurrah for LongURLPlease - a service which takes those horrid little links and turns them in to full sized URLs.
Here's the basic code in PHP to use the service.
function long_url($shortURL)
{
//Use the LongURLPlease API
$url = "http://www.longurlplease.com/api/v1.1?q=" . $shortURL;
//Set up CURL
$curl_handle=curl_init();
curl_setopt($curl_handle,CURLOPT_RETURNTRANSFER,1);
curl_setopt($curl_handle,CURLOPT_URL,$url);
//Get the JSON response
$url_json = curl_exec($curl_handle);
//Close the connection
curl_close($curl_handle);
//Decode the JSON
$url_array = json_decode($url_json,true);
//Get the Long URL out of the array
$url_long = $url_array["$shortURL"];
if ($url_long == null) //The service couldn't find a long URL
{
return $shortURL;
}
return $url_long;
}
So, how should this be displayed to the user in Dabr?
There are three possibilities.
Display
<a href="short.url/foo">VeryVeryLong.Url/Bar</a>
This keeps the redirect, but it displays the full URL for the user.
Pros.
- Get to see what the content is.
- Allows the short URL service to record hits etc.
Cons.
- Won't highlight if you've already visited it.
- May cause problems if the VeryLong.Url is too long for the screen.
All Change
<a href="VeryVeryLong.Url/Bar">VeryVeryLong.Url/Bar</a> This completely replaces the short URL.
Pros.
- Hurrah! No more silly URLs.
- Will highlight if you've already visited it.
- You can seen what you're about to click on.
Cons.
- Breaks any statistics management the short URL service was performing (is this a con? Surely the receiving website should be recording such details?)
- May cause problems if the VeryLong.Url is too long for the screen.
Background
<a href="VeryVeryLong.Url/Bar">short.url/foo</a>
Pros.
- Will highlight if you've already visited it.
- You can seen what you're about to click on if you hover over the URL.
- Won't cause problems if the URL is too long for the screen.
Cons.
- Breaks any statistics management the short URL service was performing (is this a con? Surely the receiving website should be recording such details?)
- User can't immediately see what they're about to click on.
Conclusions
I prefer replacing the URL completely. I see no value in the various short URL services. The stats that they gather don't seem any better that those your webserver can provide.
However, long URLs can be messy - especially on small screened devices.
Long URLs on a BlackBerry
So, which do you prefer?
function theme_external_link($url, $content = null) { //Long URL functionality. Also uncomment function long_url($shortURL) if (!$content) { $longurl = long_url($url); $domain = parse_url(long_url($url)); if (setting_fetch('gwt') == 'on') { $encoded = urlencode($longurl); $longurl = "http://google.com/gwt/n?u=$encoded"; } return "<a href='$longurl' target='_blank'>[".$domain["host"]."]</a>"; } else { return "<a href='$url' target='_blank'>$content</a>"; } }I also moved the GWT modifications there since it doesn't handle all shortened urls well, plus I still wanted to get more URL context via the full link if I mousedover it hope the code pastes in here correctly