Link shorteners hurt the user experience and destroy the Web(t37.net)
t37.net
Link shorteners hurt the user experience and destroy the Web
http://t37.net/why-link-shorteners-harm-your-readers-and-destroy-the-web.html
29 comments
I couldn't find a working Chrome extension so I created a basic one [1]
[1]: https://github.com/codrineugeniu/chrome-unshortener
[1]: https://github.com/codrineugeniu/chrome-unshortener
There's no real need for an API. Just do an HTTP HEAD request until you stop getting redirects (watch out for loops).
Some days, I go around internetting and it's like I'm lengthening URLs with that page every 5 clicks.
Not to mention it's a great way to spread other unwanted nasties.
> Link shorteners appeared as a consequence of the rise of Twitter. With a 140 characters limitation, sending full links over the micro blogging network was almost impossible.
No. The first extremely popular link shortener was TinyURL, and it launched in 2002, years before Twitter existed. Link shorteners became popular because URLs for some websites are extremely long and unweildy, and are thereby difficult to type; they also have tons of puncutation, and are at danger of being mangled by various transports due to line wrapping, escaping, and character mapping.
No. The first extremely popular link shortener was TinyURL, and it launched in 2002, years before Twitter existed. Link shorteners became popular because URLs for some websites are extremely long and unweildy, and are thereby difficult to type; they also have tons of puncutation, and are at danger of being mangled by various transports due to line wrapping, escaping, and character mapping.
Indeed. They became popular on Usenet because of the 80-character line width limit. Because of the way text is wrapped and quoted on Usenet, link-mangling was a common and pretty annoying problem.
IIRC, makeashorterlink.com was the first popular one, but for reasons that seem obvious and ironic now, tinyurl quickly supplanted it. Bit.ly was the first to really take domain name shortening to the extreme and was also the first to be popularised by Twitter.
IIRC, makeashorterlink.com was the first popular one, but for reasons that seem obvious and ironic now, tinyurl quickly supplanted it. Bit.ly was the first to really take domain name shortening to the extreme and was also the first to be popularised by Twitter.
What is the ironic reason that explains tinyurl supplanting makeashorterlink?
That makeashorterlink is unneccessarily long I guess.
I like my irony served with less inevitability.
[deleted]
Yeah. We used started using tinyurl on #haskell IRC by 2003 because long urls would break line wrapping, get mangled, not be typeable etc.
Please explain your "typeable" concern. I've been using IRC since the dawn of time and I could always copy and paste. Not to mention that links are recognized and you can click them.
Copy and paste didn't work too well on serial terminals. How far back was this 'dawn of time'?
Mid nineties.
I'm going to hazard a guess that you're a Windows or Mac user.
Well you can paste into irssi too.
Middle-click much?
i̶r̶s̶s̶i̶, or rather the terminal it's running in according to the person replying my comment, lets you click on links to open a browser too.
That's the terminal, not irssi.
Thank you for mentioning this, I'll correct the article accordingly.
[edit] Fixed
[edit] Fixed
they existed way before 2002. I used to use welcome.to/ back in 1997 or 1998 to give out a shorter URL to my very long geocities one
Good ol' geocities. Now that takes me back!
While not really a URL shortener in the tinyurl sense, cjb.net offered sub-domains for URL redirection that effectively shortened long URLs (ie: mysite.cjb.net) since the late-1990s; it was a pretty popular in the gaming community.
Also, many paper magazines had similar services (often called "quicklinks" or similar) for a long time where they would just print the URL or even just the ID of the link, for easy lookup on their website.
In college everyone used NNTP. Well, CS students used it anyway. But the proper netiquette was to used shortened URLs when possible with the goal to reduce typing all around.
This scripts [1] searchs for links in the user timeline and replaces shortned URLs with the original (stored in the data-expanded-url attribute).
[1] http://userscripts.org/scripts/show/186801
[1] http://userscripts.org/scripts/show/186801
Userscripts has been down for months, as far as I know.
It can still be accessed on port 8080:
http://userscripts.org:8080/scripts/show/186801
http://userscripts.org:8080/scripts/show/186801
Good to know, thanks. Sorry to see it go that spammy route.
> t.co -> j.mp -> pocket.co -> getpocket.com -> bit.ly -> $PROPER_URL
Wow, so many different people tracking a single link.
These are super annoying once they changed to storing the actual URL on the server. The old "redirect?to=http%3A%2F%2Fwww.example.com" style could be re-written on the client to remove the click-tracking, but by storing it on the server, you have to be tracked to get the URL. These seriously need to go away - that's way too many tracking databases just waiting to get a subpoena or "national security letter".
--
side note: The only time I ever used a url shortener was for a meme that unfortunately never went anywhere:
http://preview.tinyurl.com/feckless-imbroglio
edit: typo
Wow, so many different people tracking a single link.
These are super annoying once they changed to storing the actual URL on the server. The old "redirect?to=http%3A%2F%2Fwww.example.com" style could be re-written on the client to remove the click-tracking, but by storing it on the server, you have to be tracked to get the URL. These seriously need to go away - that's way too many tracking databases just waiting to get a subpoena or "national security letter".
--
side note: The only time I ever used a url shortener was for a meme that unfortunately never went anywhere:
http://preview.tinyurl.com/feckless-imbroglio
edit: typo
It seems really strange that the person would use this many link shortners, are you sure it wasn't a malicious link? Back when I used to clickjack we used to mask our website by using multiple link shortners and other tricks to hide the website from Twitters automated checker.
It's the Pocket to Buffer to Twitter workflow. Pocket adds getpocket.com and pocket.co, Buffer adds j.mp, Twitter adds t.co.
They don't use link shorteners, but Ars Technica has posted links with that many redirects on their "deals" page. I'm guessing it's a series of affiliate links or something. The "Logitech MK520" link on this page has 7 redirects. https://arstechnica.com/gadgets/2014/05/thursday-dealmaster-...
Not all link shorteners are evil and are destroying the web.
Here are some scenarios in which I like link shorteners:
1) Removal of the referrer (the anonymising redirect)
2) Redirects within a site when content moves, but the redirect service offers a permalink shortened URL. As only they can generate the URL you can trust that the destination is as safe as the source (the intra-site trusted redirect with vanity URLs)
3) Self-healing of the web, if a URL becomes broken the redirect service may be able to figure out or suggest a replacement, or offer a cached version of the destination or a link to the web archive (the self-healing redirect)
4) Protect users against malware and spam by cancelling a redirect if the URL is reported (the 'for the user' gateway redirect)
Not all redirects and shorteners are inherently bad. I suspect the author just dislikes the tracking side of things, but there's always http://unshort.me/
Here are some scenarios in which I like link shorteners:
1) Removal of the referrer (the anonymising redirect)
2) Redirects within a site when content moves, but the redirect service offers a permalink shortened URL. As only they can generate the URL you can trust that the destination is as safe as the source (the intra-site trusted redirect with vanity URLs)
3) Self-healing of the web, if a URL becomes broken the redirect service may be able to figure out or suggest a replacement, or offer a cached version of the destination or a link to the web archive (the self-healing redirect)
4) Protect users against malware and spam by cancelling a redirect if the URL is reported (the 'for the user' gateway redirect)
Not all redirects and shorteners are inherently bad. I suspect the author just dislikes the tracking side of things, but there's always http://unshort.me/
Have you ever seen cases 2, 3, or 4 happen?
2 - Why would a site use some sort of middle layer just to ensure that links remain permanent? They could just redirect old URLs to new ones.
3 - I am aware that the owner can change the URL behind a shortened one so if they needed to they could fix "links" to their site. I have never heard of a service which claims to find out where broken redirects should now be pointing.
4 - I think they make attacks more likely. Most people's browsers will automatically follow the redirect and not give them a change to say no if they don't like the look of the URL. Yes, in theory, a user could try to report a dangerous link but I would be surprised if anyone is available to listen at these services.
2 - Why would a site use some sort of middle layer just to ensure that links remain permanent? They could just redirect old URLs to new ones.
3 - I am aware that the owner can change the URL behind a shortened one so if they needed to they could fix "links" to their site. I have never heard of a service which claims to find out where broken redirects should now be pointing.
4 - I think they make attacks more likely. Most people's browsers will automatically follow the redirect and not give them a change to say no if they don't like the look of the URL. Yes, in theory, a user could try to report a dangerous link but I would be surprised if anyone is available to listen at these services.
> 1) Removal of the referrer (the anonymising redirect)
Should really done by a browser maybe like an attribute on a link but fair enough.
> 2) Redirects within a site when content moves, but the redirect service offers a permalink shortened URL. As only they can generate the URL you can trust that the destination is as safe as the source (the intra-site trusted redirect with vanity URLs)
Just make the original url not move...
> 3) Self-healing of the web, if a URL becomes broken the redirect service may be able to figure out or suggest a replacement, or offer a cached version of the destination or a link to the web archive (the self-healing redirect)
Ideally just better one on the browser and is done in say like chrome. I doubt there's any that were manually updated.
> 4) Protect users against malware and spam by cancelling a redirect if the URL is reported (the 'for the user' gateway redirect)
This is done in browsers anyway. And even if when would this work? Presumably they are getting this through some trusted medium otherwise what's to prevent them just getting a bad url? And if they are why not just check before?
Should really done by a browser maybe like an attribute on a link but fair enough.
> 2) Redirects within a site when content moves, but the redirect service offers a permalink shortened URL. As only they can generate the URL you can trust that the destination is as safe as the source (the intra-site trusted redirect with vanity URLs)
Just make the original url not move...
> 3) Self-healing of the web, if a URL becomes broken the redirect service may be able to figure out or suggest a replacement, or offer a cached version of the destination or a link to the web archive (the self-healing redirect)
Ideally just better one on the browser and is done in say like chrome. I doubt there's any that were manually updated.
> 4) Protect users against malware and spam by cancelling a redirect if the URL is reported (the 'for the user' gateway redirect)
This is done in browsers anyway. And even if when would this work? Presumably they are getting this through some trusted medium otherwise what's to prevent them just getting a bad url? And if they are why not just check before?
On your 1st point: the noreferrer attribute is indeed part of the HTML5 standard.
http://www.w3.org/TR/html5/links.html#link-type-noreferrer
http://www.w3.org/TR/html5/links.html#link-type-noreferrer
1) It can be done without shortening and obfuscating URL
2) Wouldn't call it link shortener, as redirector and target are in same administrative domain.
3) I doubt the possibility of meaningful automated fixing of arbitrary links, beyond redirecting to web archive. Which is not always best option and can be done manually or by browser addon
4) Or redirect 0.1% of traffic to attack page. This functionality should be in trusted location (browser or proxy). Screening as opt-in, especially by one providing link is useless
2) Wouldn't call it link shortener, as redirector and target are in same administrative domain.
3) I doubt the possibility of meaningful automated fixing of arbitrary links, beyond redirecting to web archive. Which is not always best option and can be done manually or by browser addon
4) Or redirect 0.1% of traffic to attack page. This functionality should be in trusted location (browser or proxy). Screening as opt-in, especially by one providing link is useless
1, 3 and 4 almost never happen in real life.
2 is the only thing remotely useful.
2 is the only thing remotely useful.
#1 is used by a lot of sites, mostly torrents and the like to protect their users and themselves from obvious liability. But I even built one to help a forum that discussed philosophy and politics to help them avoid being invaded by trolls just because they discussed (and linked to) content on far-right sites, etc.
#2 was the one I couldn't think of a great example for, but thought that maybe the BBC were doing this (I have no citable source for this hunch but recall a page discussing programme identifiers and moving all existing URLs to this new structure using redirects).
#3 I agree does not happen in real life. Which is a shame.
#4 Twitter claim to do this https://support.twitter.com//entries/109623 , and I believe Google are doing this.
Edit: Citable source for #3 http://www.bbc.co.uk/blogs/legacy/radiolabs/2007/11/urls.sht... . The BBC use a URL shortener in addition to the equivalent of mod_rewrite to normalise all of their content behind permalink short URLs.
#2 was the one I couldn't think of a great example for, but thought that maybe the BBC were doing this (I have no citable source for this hunch but recall a page discussing programme identifiers and moving all existing URLs to this new structure using redirects).
#3 I agree does not happen in real life. Which is a shame.
#4 Twitter claim to do this https://support.twitter.com//entries/109623 , and I believe Google are doing this.
Edit: Citable source for #3 http://www.bbc.co.uk/blogs/legacy/radiolabs/2007/11/urls.sht... . The BBC use a URL shortener in addition to the equivalent of mod_rewrite to normalise all of their content behind permalink short URLs.
#3 actually happens in reverse: link shortener dies or the shortened link expires, while the actual URL lives on. This way, shorteners are _accelerating_ link rot.
#1 is done by pretty much any site that lets you display "third party" content where said third-party is untrusted. Such as most webmail providers, when loading remote images, and often for links too.
(but there's no reason to do shortening)
(but there's no reason to do shortening)
1 happens all the time no reason to make it a "short" url though.
Wouldn't it be quite easy for a link shortener to find the final target url and just point to that instead of pointing to another shortener url? It could even heuristically try to search further if the pointed to url looks like an already shortened one (i.e. it's shorter than a treshold).
I also wondered this, and commented before I read your comment. The shortener can just follow the HTTP status chain until it gets a 200; no need for length heuristics.
The problem is not the link shorteners but the amount of (often slow) redirects that come with them.
Getting users to long URLs is a good thing if done directly.
Getting users to long URLs is a good thing if done directly.
Anything that silently sends informations about your users to a third party is nasty by nature, including google analytics, gravatar, disqus, +1/like buttons and many more. Please, web designers, think twice before selling all your users to gain little convenience.
Another evil that roams interwebs are "farewell" gates for outgoing links; eg dA [1].
Unlike URL shorteners which could be in rare cases useful [2] I see not a single benefit of this.
[1] http://www.deviantart.com/users/outgoing?http://www.devianta... [2] http://tinyurl.com/selfcontained-editable-datauri (yes, this one is a misuse, but whatewer)
Unlike URL shorteners which could be in rare cases useful [2] I see not a single benefit of this.
[1] http://www.deviantart.com/users/outgoing?http://www.devianta... [2] http://tinyurl.com/selfcontained-editable-datauri (yes, this one is a misuse, but whatewer)
What's bad about them? Blocks referer and warns of phishing.
1) Referrer obscuring: If I wanted not to enclose referrer, I'd have told my browser not to do it. (I don't want to disable this so I don't like some sites forces me to do something very similar by their design.)
1a) (Rhetorical question:) If you were site owner and were interested in incoming traffic, would you rather see 'someportal.com/outgoing?yoursite/page' or 'someportal.com/certainpage' referer header in access logs of yoursite/page?
2) Phishing protection: assuming such outgoing links are checked with Safe Browsing API or something similar (I doubt it), again, that's what my browser does by default. (Incidentally, sometimes I do not want my browser to do this either, so again I like to switch this off: things are a bit faster and free disk space bigger sometimes.) It might seem nice that some page makes this effort too, but again, I don't see a big deal in it.
2) Phishing protection: assuming such outgoing links are checked with Safe Browsing API or something similar (I doubt it), again, that's what my browser does by default. (Incidentally, sometimes I do not want my browser to do this either, so again I like to switch this off: things are a bit faster and free disk space bigger sometimes.) It might seem nice that some page makes this effort too, but again, I don't see a big deal in it.
In my experience, from working amongst marketeers, bit.ly is still used not because of its link-shortening abilities. It's used because of the analytics and insight it can provides.
Even on sites with comprehensive analytic packages integrated, bit.ly (and services like it) will be used because the people doing the "social media" work an the people responsible for the performance of the website online are sitting in different places and not talking to each other.
The result is this division of statistical data for each party to beat each other with.
Even on sites with comprehensive analytic packages integrated, bit.ly (and services like it) will be used because the people doing the "social media" work an the people responsible for the performance of the website online are sitting in different places and not talking to each other.
The result is this division of statistical data for each party to beat each other with.
It's even more annoying on mobile (I'm using Android).
If I click an Instagram link in a tweet (since Instagram images no longer show up inline on Twitter), it loads the t.co link in my web browser, and then launches the instagram app to show me the photo. If I then press my phone's "back" button, it takes me back to my web browser, and I have to press "back" again to get back to the Twitter app. It also leaves the t.co link in my web browser's list of active tabs, so the next time I open my web browser, it hijacks me and launches me back into Instagram. It would not be difficult for the Twitter app to resolve t.co links before launching anything, mitigating this issue entirely.
If I click an Instagram link in a tweet (since Instagram images no longer show up inline on Twitter), it loads the t.co link in my web browser, and then launches the instagram app to show me the photo. If I then press my phone's "back" button, it takes me back to my web browser, and I have to press "back" again to get back to the Twitter app. It also leaves the t.co link in my web browser's list of active tabs, so the next time I open my web browser, it hijacks me and launches me back into Instagram. It would not be difficult for the Twitter app to resolve t.co links before launching anything, mitigating this issue entirely.
The problem here is that Twitter has hijacked every URL posted on its service with the t.co redirector. Even if you post an already short link, it will be wrapped in a useless t.co, which causes problems like what you've described.
Here's one reason for me to use an URL shortener in my (German-language) newsletter: URL length. When you send out HTML + plain text emails, some URLs will break the text layout.
So I shorten them sparingly, for simple layout reasons. But I don't track the clicks or anything. I might be in the minority here, tho.
So I shorten them sparingly, for simple layout reasons. But I don't track the clicks or anything. I might be in the minority here, tho.
I have been in https://bg.wikipedia.org/wiki/%D0%9D%D0%B0%D1%86%D0%B8%D0%BE... and http://bg.wikipedia.org/wiki/%D0%91%D0%B0%D0%BD%D0%BA%D1%8F also I should note that I am https://bg.wikipedia.org/wiki/%D0%A2%D1%83%D1%80%D1%86%D0%B8...
Did you enjoy your stay in http://bg.wikipedia.org/wiki/Банкя ?
IRI FTW.
IRI FTW.
Yes, it had a pool with naked people. http://bg.wikipedia.org/wiki/Банкя
Edit: Oh, it needs some editing in the URL and done, cool.
Edit: Oh, it needs some editing in the URL and done, cool.
My favourite link shortener was mug.gd, which could also manipulate the page it was being sent. I remember seeing a version of a PG essay trumpeting the benefits of learning Visual Basic over Lisp :).
It's dead now, demonstrating another problem with URL shorteners.
It's dead now, demonstrating another problem with URL shorteners.
A problem with 3rd party URL shorteners.
If you use and host your own, you've got things covered for as long as you need.
If you use and host your own, you've got things covered for as long as you need.
Link shorteners fix one apparent problem with Microsoft Outlook: people sending text emails with long links will typically break them for the recipient and the common workaround, setting the line length setting very high, is terrible too.
They use a URL shortener to track trafic and « engagement » to their content: how much clicks were generated from Twitter, Facebook, Linkedin… without an access to the site’s Google analytics. That’s because figures are more important than people who read their content. In other words: spam.
Okay, I know that ranting content beats happy or deep-thought-out content, but we got into hand-waving territory a little early here and without, well, knowing what the hell we're talking about.
I use bit.ly, and gad, I hope I don't spam. There are a dozen good reasons. I just like knowing in real-time how many people are re-using the links I share online. Gives me some idea if anybody is paying attention. Over time, I can go back and look at all the links I've shared, from my own stuff to MSM material, and see what my friends liked and what they didn't. That's great feedback for me -- just like a "like" on Facebook, except it's entirely passive on the consumer's part.
I'm not saying there isn't a problem. The problem here is that everybody and their brother want as much data as possible from the user, so there's this cascading thing going on where you almost never click on a link that actually describes where you're going. Many times the redirect can be several deep, as the author points out.
So yes, there's a problem. But please don't jump from "there's a problem" to "Spam! Spam! It's all about spam!"
No, it's not. There can be a problem with something without there having to be an evil villain involved.
Okay, I know that ranting content beats happy or deep-thought-out content, but we got into hand-waving territory a little early here and without, well, knowing what the hell we're talking about.
I use bit.ly, and gad, I hope I don't spam. There are a dozen good reasons. I just like knowing in real-time how many people are re-using the links I share online. Gives me some idea if anybody is paying attention. Over time, I can go back and look at all the links I've shared, from my own stuff to MSM material, and see what my friends liked and what they didn't. That's great feedback for me -- just like a "like" on Facebook, except it's entirely passive on the consumer's part.
I'm not saying there isn't a problem. The problem here is that everybody and their brother want as much data as possible from the user, so there's this cascading thing going on where you almost never click on a link that actually describes where you're going. Many times the redirect can be several deep, as the author points out.
So yes, there's a problem. But please don't jump from "there's a problem" to "Spam! Spam! It's all about spam!"
No, it's not. There can be a problem with something without there having to be an evil villain involved.
Short URLs are not just for the web - they are incredibly useful for sending links via broadcast SMS.
It is true at least for me. I never click on a shortened URL, whatever it might be...
I tend not to trust it.
I tend not to trust it.
Why do you need to trust a website before clicking the link? If your computer has some vulnerability to virus/hack just by visiting a website then you need to upgrade!
Upgrade to what? If you're vulnerable to a 0-day exploit, you're screwed. If you're vulnerable to a known exploit that the vendor hasn't patched yet, you're screwed. If the page delivers a virus the vendors can't block[1], you're screwed. etc.etc.etc.
[1] http://krebsonsecurity.com/2014/05/antivirus-is-dead-long-li...
[1] http://krebsonsecurity.com/2014/05/antivirus-is-dead-long-li...
Why doesn't t.co (and, in fact, any URL shortener) follow the redirect chain first, before shortening the URL?
Because it's a semantic thing. If I tell Twitter that I want to link to a web page, they damn well better link me to that web page, and not what it redirects to, because I've asked them to link me to that web page. I could be using the link shorteners for analytics, all sorts. Maybe I'm targeting different URLs to different users.
Yes, for almost all users removing the shorteners is preferable, but the SEO people would be up in arms.
The real thing here is that modern browsers don't have problems with links - they don't need link shorteners. Twitter adding t.co to every link is unnecessary - they could just have a hyperlink etc.
Consider what happens when someone decides to give it a URL that redirects infinitely -- it is possible to make an infinite loop, as someone demonstrated 4 years ago while also complaining about URL shorteners:
http://breakingcode.wordpress.com/2010/01/11/having-fun-with...
(The infinite loop in that example unfortunately seems to have broken, illustrating another downside to URL shorteners - they can go away rather quickly.)
http://breakingcode.wordpress.com/2010/01/11/having-fun-with...
(The infinite loop in that example unfortunately seems to have broken, illustrating another downside to URL shorteners - they can go away rather quickly.)
Detect the loop and reject the URL. I'd rather twitter protect me from ever clicking on an infinitely-redirecting link, although browsers tend to handle that case fairly gracefully.
The only real complaint in the article seems to be the redirect chain and your suggestion would solve it. I'm working on a URL shortener (for universities) at the moment and I see no reason not to implement this.
This is the quickest route to solving the problem halfway and it's better than the crappy status of URL shorteners today.
Every URL shortener should follow redirect chain before shortening.
Every URL shortener should follow redirect chain before shortening.
I think you've forgotten that there are different types of redirect, with different permanency semantics.
potential side-effects, if you have a cookie set following the url might end at a different final URL than if you don't have any cookie set. e.g. login here
URL shorteners provide one of the two values.
- short link that is easier to share/doesn't break in the process (when you send it via email, need to copy-paste on your mobile or just want a cleaner FB message
- tracking that will give the poster insight on the number of clicks and other performance indicators of the message
No one in their right mind would use 302 redirect, because you then loose things like Twitter share counts, or card implementation.
There is an odd case of someone using the shortener for marketing purposes (I do it for my product), but it usually will be a by-product of something deeper that offers value to the user. And, as many of those services are free (as your referred Pocket), it's a small price to pay for an otherwise great product IMO.
- short link that is easier to share/doesn't break in the process (when you send it via email, need to copy-paste on your mobile or just want a cleaner FB message
- tracking that will give the poster insight on the number of clicks and other performance indicators of the message
No one in their right mind would use 302 redirect, because you then loose things like Twitter share counts, or card implementation.
There is an odd case of someone using the shortener for marketing purposes (I do it for my product), but it usually will be a by-product of something deeper that offers value to the user. And, as many of those services are free (as your referred Pocket), it's a small price to pay for an otherwise great product IMO.
I'm not quite sure it's a URL shortener but http://linkis.com shortens the URL anyway (as ln.is). I never click a ln.is url anymore. It takes you to an intermediary page that only worsens your^H^H^H^H my life.
PS: Can anyone see what's the point of this service?
PS: Can anyone see what's the point of this service?
Long URLs hurt the user experience and destroy the Web.
If I want to send you a link to a washingtonpost.com article the link looks like:http://www.washingtonpost.com/opinions/ej-dionne-jr-the-root...
The same url could just as easily be user readable, and something that I could tell me office-mate verbally from 10 feet away. Most people just expect bad URLs now and have given up trying to remember the name of the page they want to see. I used to love NBC.com because they would let me type things like nbc.com/parks to get to http://www.nbc.com/parks-and-recreation, but that is no longer true. Now everyone just assumes that they need to google something to find it, and they can't even imagine that apple.com/ipad would be the page they are looking for.
If I want to send you a link to a washingtonpost.com article the link looks like:http://www.washingtonpost.com/opinions/ej-dionne-jr-the-root...
The same url could just as easily be user readable, and something that I could tell me office-mate verbally from 10 feet away. Most people just expect bad URLs now and have given up trying to remember the name of the page they want to see. I used to love NBC.com because they would let me type things like nbc.com/parks to get to http://www.nbc.com/parks-and-recreation, but that is no longer true. Now everyone just assumes that they need to google something to find it, and they can't even imagine that apple.com/ipad would be the page they are looking for.
user readable and user typeable aren't the same thing. your WaPo url is perfectly readable - it includes the author, the source, the name of the article, and the date. if you click on it, it takes you where you want to go. if you see it in a context where you don't want to click on it but want to read the article later, you can still find the article because it gave you all the information you need to google for it. if for some reason the link breaks, you can use the information in the link to find an alternate source for the article.
apple.com/ipad is a good URL because it describes the destination. so is nbc.com/parks. but there is a practical limitation to that sort of url scheme - you only get a couple hundred pages max before you exhaust your namespace. you couldn't use a URL like that for every single article a newspaper writes without an absurd number of collisions. so you have to start using unique IDs. and if you only use the ID, you lose the memorable/describable aspect.
apple.com/ipad is a good URL because it describes the destination. so is nbc.com/parks. but there is a practical limitation to that sort of url scheme - you only get a couple hundred pages max before you exhaust your namespace. you couldn't use a URL like that for every single article a newspaper writes without an absurd number of collisions. so you have to start using unique IDs. and if you only use the ID, you lose the memorable/describable aspect.
How is your first URL not easily user readable? It clearly tells me that it is from the Washington Post, in the Opinions section, written by EJ Dion Jr, titled "the roots and lessons of memorial day," published May 25 2014, and then has a (presumably) uuid for the article.
Since when has verbal transmission been an important consideration for URLs?
Since when has verbal transmission been an important consideration for URLs?
If I have to repost content that contained shortened links, I always replace them with what they redirect to, and scrub out what's unneeded (e.g. session IDs, referer querystrings). I wish more people would do this, as it will help in reducing the amount of nested redirections. IMHO link shorteners are only for extremely space-constrained applications like Twitter.
As for some sites having extremely long required URLs: Sometimes they are necessary, e.g. parametric searches, but many other times they could've been better designed to be either shorter or more informative. Whatever the form, I don't think link shorteners should be used to hide them, if there is enough space available to hold the full URL.
As for some sites having extremely long required URLs: Sometimes they are necessary, e.g. parametric searches, but many other times they could've been better designed to be either shorter or more informative. Whatever the form, I don't think link shorteners should be used to hide them, if there is enough space available to hold the full URL.
Pet peeve: articles that start with the word “why” where “how” is what they meant.
Why link shorteners do this is a completely different question with completely different answers.
Why link shorteners do this is a completely different question with completely different answers.
thank you.
So literally scheduling the automated sharing of links from a "read it later" app is a common enough workflow, but simply using a link shortening service is automatically indicative of spam? Come on.
Another nit: j.mp and bit.ly are different domains for the same service. If you append a "+" to either URL you see how many times the destination has been shared, clicked, and by all shortened versions of the destination. So it's like both of those are the same link.
Final nit: The Internet was designed to survive nuclear war. The "X destroys the Web" trope is popular, but getting incredibly tired. That's not to say there aren't totally legitimate criticisms of URL shorteners - there are! - but their use clearly pre-dates Twitter and obviously has numerous legitimate use cases as lots of comments here attest to.
Another nit: j.mp and bit.ly are different domains for the same service. If you append a "+" to either URL you see how many times the destination has been shared, clicked, and by all shortened versions of the destination. So it's like both of those are the same link.
Final nit: The Internet was designed to survive nuclear war. The "X destroys the Web" trope is popular, but getting incredibly tired. That's not to say there aren't totally legitimate criticisms of URL shorteners - there are! - but their use clearly pre-dates Twitter and obviously has numerous legitimate use cases as lots of comments here attest to.
I was a bit confused about the spam thing too. Was the intended meaning that URL shorteners indicate the link is spam, or that trading off user experience for analytics makes it spam? (Or in the spirit of spam, or something.) I'd think they meant the second one, except that it doesn't actually make any sense.
I also got a really strong gut feeling of "spam" being used as a "boo!" sign, for some reason.
I also got a really strong gut feeling of "spam" being used as a "boo!" sign, for some reason.
There's a few more genuine use cases for shorteners, one of them is using links offline (e.g. print advertisements). I noticed my university does that and I kind of like it.
It definitely won't remember company.com/section/potentially_a_subsestion/page?someParamters=mayyybe if I see it somewhere. But I might remember bit.ly/CompanyCampaign.
Some might say that it's the developers/company fault, they should have made the URLs more friendly/configurable. Yeah maybe, but it's often easier just to use a shortener, let's be realistic.
I also use them when I know I will need to open some link directly (i.e. by typing in URL). For example, I prefer bit.ly/myPresentation to logging into google drive, getting 2FA text, finding the presentation...
So yeah, while they are evil in some cases, they have a bunch of genuine use cases.
It definitely won't remember company.com/section/potentially_a_subsestion/page?someParamters=mayyybe if I see it somewhere. But I might remember bit.ly/CompanyCampaign.
Some might say that it's the developers/company fault, they should have made the URLs more friendly/configurable. Yeah maybe, but it's often easier just to use a shortener, let's be realistic.
I also use them when I know I will need to open some link directly (i.e. by typing in URL). For example, I prefer bit.ly/myPresentation to logging into google drive, getting 2FA text, finding the presentation...
So yeah, while they are evil in some cases, they have a bunch of genuine use cases.
Bog standard permalinks to the rescue: company.com/some-promotion
Right. This is the correct way to do it, with natural language related to the ad.
Link shorteners are bad for usability, but they're also a potential attack vector for targeted attacks. A link might go to the right site 99.9% of the time, and redirect a user to a malicious site the rest of the time.
You can redirect based on the browser fingerprint, IP address, or any number of things.
I have a proof-of-concept of this at http://brokenthings.org/
It redirects to a "friendly" site for preview scanners, etc., and to a "bad" site (Youtube videos, with some stale ones) for users.
It's blocked by Facebook, but still works on G+.
You can redirect based on the browser fingerprint, IP address, or any number of things.
I have a proof-of-concept of this at http://brokenthings.org/
It redirects to a "friendly" site for preview scanners, etc., and to a "bad" site (Youtube videos, with some stale ones) for users.
It's blocked by Facebook, but still works on G+.
Amazing. Thanks for this.
Link shortners are useful. There is possibly one other simple way to avoid the latency. t.co can resolve the link all the way to the end at the time a tweet is posted (ie run through 1-5). The latency hit is taken once and and not on every access to the shortened link.
Paste in a shortened link and it will tell you the original URL, listing all the intermediate steps on the way. It also has an API.