Archive for June, 2012

Google’s Redirect URLs are a Pain

I’m a big believer in keeping the Web as simple as possible. Things that complicate the experience but don’t add any real value tend to annoy me. Not only are they (by definition) unnecessary, but they tend to have unwanted side effects.

One such annoyance is Google’s habit of displaying links on its search results page that lead, not to the actual result, but to a redirect script that forwards you to the result.

Among the (presumably) unintended side effects are various privacy and security issues, but I think Google’s privacy problems are well-covered enough that I don’t need to dwell on them here. If you’re interested, you might start with Lorelle VanFossen’s post (on Google+, incidentally), Google URL Redirect Issues in Google Search Results, Privacy, Security, and Ewe.

The problems I want to highlight have more to do with usability.

To illustrate, let’s try a little experiment. First, look up something on Wikipedia. For example, antelope. Next, try searching for it on Google. In the antelope example, the Wikipedia article should be the first result. (There’s no guarantee, of course.) Finally, try the same search on Bing. Again, for antelope, the Wikipedia article is first. (If you don’t like antelope, just use both search engines to look for any page you know you’ve already visited.)

Screenshot of a Google Search for "antelope"

Screenshot of a Bing search for "antelope" with the first result (the Wikipedia article) displayed in a different color

Notice a difference?

The first thing I want to point out, and the reason I posted these screenshots, is that the link in the Google results isn’t purple. When a link points to a URL the user has already visited, the browser usually displays it in a different color. Users depend on link color to navigate the Web. If a link ultimately leads to the same place the user has been but is directly pointing to a URL the user hasn’t visited yet, then it won’t be colored.

Another problem, which was brought up in one of the posts linked by VanFossen, is that the correct URL is no longer displayed in the status bar when the user hovers over or focuses on the link. Looking at the status bar to see where a link goes is a deeply-ingrained habit among users–so much so that browsers still display URLs in that area despite not even having status bars anymore. Google’s redirects break this not only by providing a different URL, but by making it so long and full of gobbledygook that the browser cuts it off. Thanks to that, even advanced users who know to look for the encoded original URL can’t see it. (Admittedly, Google displays the URL in plain text next to each result, but unfortunately, long URLs have the middles cut out of them.)

I should point out that these first two complaints aren’t quite true–at least not usually. Google uses some JavaScript that changes the link’s href attribute to point to the correct location when the page loads, but the onmousedown event changes it back to the redirect URL as soon as you try to click on it. This means that the browser renders the link in the right color and puts the right address in the status bar. Users with JavaScript disabled are out of luck, though.

Moreover, the JavaScript may help users viewing a Google results page, but it doesn’t stop the redirects from breaking copy-paste. It’s not uncommon for users to right-click a result in order to copy the URL. There is no onmouseup script that restores the correct URL, and even if there were, it wouldn’t work for users who navigate context menus by right-click-and-dragging to the desired option. This means that the redirect URL, and not the URL of the actual result, gets copied and pasted into blog posts, E-Mails, and forum posts.

It would seem to me that, in addition to breaking UI all across the Web, this would also work against what I assume is the whole point of the redirects in the first place: If Google is trying to track which search results people click, wouldn’t having them click the same links from completely different Web sites result in a bunch of false positives? They must be using referer headers or some other means to strip those out, since they wouldn’t be redirecting if it weren’t benefiting them. Maybe they’re gathering data on who’s copy-pasting from Google results.

Finally, the redirect script is another request that the user’s browser has to make. On modern, high-speed connections, this isn’t a big delay, but it is still noticeable. There are still dialup users out there, however, and things like this can be a major inconvenience for them.

The most annoying thing, I think, is that Google could solve many of these problems by using JavaScript to track outbound links instead of making users go through the redirect. Admittedly, sending the information back to the server is still another request, but it would fix the UI problems. I suppose Google just didn’t want to give up the data from users with JavaScript disabled. They get more information, and we get a less-usable Web. It just doesn’t sound like a fair trade-off to me.

Categories: Web usability Tags: ,