http://to/ World's Shortest URL Shortener
to.
to.
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...
or
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.]
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'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.
I dunno, you can use url shorteners if you want, but Im not convinced of their usefulness, thats all.
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?
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.
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.
There are some situations where URL shortening is arguably useful. But there's absolutely no reason why "microblogging" should be one of them.
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);}())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.
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.
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."
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.
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.
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.
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.
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.
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?
But we're here. The question is, does the analytics system work that way?
http://milkandcookies.net/2008/07/12/?lang=en_US&cntry=US&source=http%3A%2F%2Fwww.google.com%2Fsearch%3Fq%3D123%26lang%3Den-US&geoloc=-45.001,-53.175
2- The real domain we're looking at: "to" -- no "suffix" attached (TLD: top-level domain)
3- The .to registry added an A-record for the "to" domain, which resolves correctly.
[Edit: Looks like .cm does this too:
;; ANSWER SECTION:
cm. 86400 IN A 195.24.205.60]
But yeah, they then proceeded to put everything under .com.com, so they had news.com.com, cnet.com.com etc. It was painfully stupid.
So if your ISP is AOL, you might have a search path of aol.com so looking up "to" will first try to.aol.com if that exists it will go there. Putting a "." at the end will let it go straight there.
This isn't normally a problem because it's not like aol is going to set up google.com.aol.com. But really everyone should have periods at the end of domains.
And for the record, chrome and ie no worky for me either. Firefox does though.
'THINK ABOUT IT: If your grandmother sees this link: http://bit.ly/zPWG6 she'll think, "Hmm, does someone want me to fly to Lithuania to get my teeth fixed?"'
#!/usr/bin/perl
#
use WWW::Mechanize;
die "usage: $0 <url>" unless @ARGV;
$name = 'a';
$m = WWW::Mechanize->new;
while (1) {
print "Trying http://to./$name\n";
$m->post('http://to./', {
url => $ARGV[0],
name => $name,
'Witz that URL!' => 'Witz that URL!'
});
unless ($m->content =~ /sorry/) {
print "You got http://to./$name\n";
exit(0);
}
$name++;
}Succeeded, but sadly http://to./ rewrote it to http://index.php instead.
This could partially be based on all file-extensions being in the file-data rather than in the name and all folders having an "index" file that represented them (which could, then, be any type of file). I'd like to have an explanation for down-votes, please.
Not the world's best URL shortener...
This is blindingly obvious. A few characters shorter just doesn't matter.
I also like to know where people are sending me, but that is a secondary concern.
:)
This: http://to./z0ba1
Not this: http://to/z0ba1
With the dot it works, but then the browser fixes up the url, and removes the dot - so all subsequent requests don't work.
(This is for me, using firefox on linux.)
edited for spelling mistake
(edit: turns out it's actually run by the ISP who operates the .to TLD)
I remember when that deal was announced, during the first bubble. Everyone thought it was foolish, now it seems genius.
Not to mention the manner in which they sold them is unique. With most TLDs, all domains cost the same price, and its first come, first served. With .tv, the domains were priced according to their value, with many costing $25,000 or more per year. So for instance I have no idea what mlb.tv cost Major League Baseball, but it was a lot more than $49/year.
Now that .tv seems to have hit its tipping point, $50 million over 12 years is a bargain.
Very well structured deal for both sides.
like me...
They do it better though http://tk./abcde is http://abcde.tk which is even on character shorter ;)
I hope this helps you :)