I hate TinyURL’s
You’ve probably seen these things… Instead of some ugly 5 long line link to an article that you have to cut and paste out of an email in 3 separate steps, you get something clean like http://tinyurl.com/9lcad.
Nice idea, bad execution. The problem of course, is that when I get one of these links I have absolutely no idea where I’m going to end up when I click on it. None. That’s a problem.
I want to know if I’m clicking on a link to a pdf or if I’m going to http://iloveraunchysex.com/fatties/. I want to know if I’m going to a site I trust, or something I’ve never seen before. I want to know if I’m wasting my time or not. With a tinyurl (or snipurl, or makeashorterlink, or shorl), I get none of these things. It’s a brick wall of obscurity hiding information from me.
I propose that they add the domain and possibly file type to the now-slightly-less-tiny url. So, it would look like http://tinyurl.com/nytimes/64lib or http://tinyurl.com/iloveraunchysex/avi/34dd.
A little bit of extra information goes a long way.
Update: In a bizarre occurrence of synchronicity, it turns out that someone else decided to implement this exact idea yesterday. Crazy. I hope he goes ahead and adds the file type suggestion too.
Update 2: In addition to Andrew’s nice burl site, another Yahoo! has taken my suggestions as well as some neat parsing of the page title and built http://www.url.vg.
Update 3: 1/3/2006 Looks like a friend of a Yahoo! has built http://urlx.org/. Probably the nicest implementation yet. No one has yet implemented my file extension idea though…
Update 4: 1/14/2007 I like this approach much more: http://giganticurl.com
October 26th, 2005 at 5:24 am
http://tinyurl.com/2oovs
October 26th, 2005 at 6:24 am
Exactly.
October 26th, 2005 at 9:34 am
I spent the better part of today thinking about your suggestion and the different aspect surrounding the implementation. Here’s the problem I came up with. The point of adding the file extension is to identify what is on the other end. However, there is no way to reliably determine what is at the other end. If someone links to an image, they could link directly to that image, or they could link to a page that has the image in it. Adding the file extension to the link only helps in one of those cases even though they both produce the same result, for the most part.
Hopefully this makes some sense. I will keep the idea in the back of my mind though. And if you have any more ideas, please feel more than welcome to pass them on!
October 26th, 2005 at 11:37 am
Hey Andrew, thanks for commenting. Even if it only helps in one of those cases, is that not still more helpful than doing nothing? I think the filetype is pretty much the only other useful piece of metadata that you can get from a url. With the domain and filetype in hand, you know quite a bit about what you might be getting yourself into. The idea being that it’s really annoying to unexpectedly open a pdf or movie file because it leads to other programs opening and all that. It would be nice to know a bit more beforehand. Just my 2 cents, but thanks for writing burl, you beat me by one day, hehe.
October 29th, 2005 at 12:10 pm
Here’s the thing though: if you start putting in filetype data, then you’ve set a precedent. If I give you a link to http://burl.fergcorp.com/microsoft/38jf9 and it takes you took a web page, then you would expect that links similar to that one would provide similar type of data. This is reinforced by the fact that I send you another link to, say, http://burl.fergcorp.com/msn/jpeg/dj3k0. This time it’s a picture. You would expect that links that follow that format will take you to some sort of picture. So when I send you to http://burl.fergcorp.com/google/dkj39 and it links to Google Image search for something just God aweful, you are suprised because there wasn’t a jpeg in the URL. Trust is loss and the system is broken.
I know that’s not the best example, but it’s the best I could come up with.
The other issue is implementation. How do you determine what the true filetype is? Many programs/browsers ignore filetypes and depend on MIME types instead. So the link I create could point to a URL that ends in a .jpg, even though it’s a PDF file. So now to prevent abuse, you have to load each file and determine its MIME type. Bandwidth is now soaring through the roof.
In other news, I’ve released the BURL source code under a GNU GPL License. So feel free to go download and tweak it to your hearts desire. If you need any help, let me know!
October 29th, 2005 at 11:21 pm
I think you’re overthinking this Andrew. If I get a regular link with a file extension in it, it still has all these issues that you’re describing. But, I’m used to that already and removing the extension simply means less information for me to work with.
November 20th, 2007 at 3:52 am
FWIW, I’ll vote with Udi. But, instead of a path, just echo the URL’s extension in the not-quite-so-tiny URL, e.g. http://burl.fergcorp.com/msn/dj3k0.jpg
The URL service doesn’t promise anything except that it shrunk the URL and preserved the extension (if any).
November 20th, 2007 at 1:29 pm
I realize you wrote this 2 years ago, but just for people who arrive here in the future, I’d like to point out that adding the “preview” subdomain in front of the tinyurl will reveal the full url that you’ll be forwarded to. Using your example, this would look like http://preview.tinyurl.com/9lcad
Optionally, you can have TinyURL set a cookie that will always take you to one of these preview pages first.
November 20th, 2007 at 10:23 pm
The preview is a nice feature, but having to go through an intermediary page is still very cumbersome. I still see no reason why we can’t still put the domain and extension into the short url.
November 21st, 2007 at 4:07 am
try http://decenturl.com
November 21st, 2007 at 9:47 pm
The Problem with Permalinks…
I’ve been thinking for quite some time about changing the URL structure at Mostly Muppet Dot Com to be a little more human-friendly. You know, taking out all the “archives” and date-string bullshit and just getting to domain-slash-po…
February 28th, 2008 at 4:05 pm
I found that http://www.redirectrevealer.com can unmask these urls and return the final destination url so you see exactly where you are going before you click the link.
July 13th, 2008 at 5:56 pm
[…] tell us they may report your activity to some “agencies” … In addition to the reasons why Udi hates TinyURLs, I wonder how is stored your URLs. Well, it’s not exactly “how?” but “with […]
July 19th, 2008 at 12:31 am
[…] next step would be an implementation of some “intelligence” in these short URLs (see Udi’s post). And since I never have time (or less and less), I’m a bit sad not to have that time to code […]
September 12th, 2008 at 7:10 am
i had also been facing problem with tinyurl.com. So i was looking for an alternative. I found this one – http://turl.us . turl.us is much better than tinyurl.com. I now use http://turl.us. It provides complete stats and bulk submission and lots more
September 10th, 2010 at 4:54 am
I just hate the word ‘URL’ and can’t stand the use, utterance or propagation of such a nerdy acronym – Universal Resource Locater. The words site, address, or simply website is far more intuitive and a MUCH better way of communicating. Earl – give me a fucking break!