The Power and Confusion of the Permalink

I’m an avid consumer of online media (blogs, magazines, Twitter, et al) and I’ve been watching with interest recently how the URL continues to be a problem for users (whether they know it or not) as more and more people interact with it directly (instead of passively, by clicking on links).

Thanks to Twitter and Facebook, the number of people creating and sharing online content is going up (and up and up), which naturally means that the relative technical sophistication of the general population of contributors is going down. But the one thing you absolutely need to provide every time you share a piece of online content is the URL — a fairly technical piece of text that tells a web browser where to find the piece of content you’re sharing.

I would hazard to guess that most people who consider themselves savvy web users know what a URL is, and might even be able to tell you what it stands for (Uniform Resource Locator). We also probably know that a URL is what’s displayed in the address bar of our browser (whether we ever actually enter a URL in the field manually or not).

The less savvy users among us often aren’t aware of the address bar at all — or, to be fair, they can probably see the field, but they don’t know what the text in it means, much less how it can be manipulated to take them to sites they want to visit.

Counterintuitively, the problems that arise when sharing URLs usually don’t come up when dealing with less-savvy users. There’s a pretty simple reason for this: The less-savvy users aren’t using the address bar. They are using tools that have been provided expressly for the function of sharing content.

Stated another way: The users who use the tools designed expressly for the task of sharing content aren’t causing as many problems as the users who know how (and like) to do it themselves.

So, what’s the issue with savvy users? My guess is that the biggest problem is we move too fast, and we forget that the URL we’re copying and pasting from the address bar may very well not reflect the state of the page as we’d actually like to share it.

Here are a few sample cases I’ve identified:

(For the record, I’ve seen mistakes like these made on many different kinds of sites, from high-profile news sites, to commercial blogs, to popular web communities of long-standing.)

1. Inadvertent Deep-Linking

You’re reading an article about YouTube’s legal problems on Slate, and you decide to share it. You copy and paste the URL from the address bar and write a fantastic blog post about it:

http://www.slate.com/id/2249124/pagenum/2

The problem?

The URL you just shared reflects the fact that you just finished reading the article, and anyone who follows it will be taken to the last page. Sure, it doesn’t take much effort to find the article’s navigation and head to the first page, but it sometimes causes a moment of confusion as the reader realizes they’ve entered an article through the wrong door. (Or, even more annoyingly, they might not notice at all, and miss the fact that they’ve only read part of the article.)

The giveaway?

If the URL makes reference to a page number somehow, chances are very good you won’t be linking to the first page.

The fix?

You can either head back to the first page and copy the correct URL, or, more simply, you can edit the URL you already have by removing the pagenum/2 (or similar) portion of the URL. In most cases you could probably just change the 2 to a 1, but sometimes sites start counting their page numbers at 0, so you aren’t guaranteed to get the result you’re looking for.

2. The Accidental Anchor

You’re reading about the Large Hadron Collider on ScienceBlogs and you click through to read the comments on the post. It’s a great post, so you hit your is.gd or bit.ly bookmarklet and shoot it out to the Twitter-sphere:

http://scienceblogs.com/startswithabang/2010/02/looking_for_new_laws_of_nature.php#comments

The problem?

The URL as sent will automatically jump the reader down to the comments portion of the page, requiring whoever clicks it to scroll back up to the top of the page if they want to read the post. (Or, worse, they will already have started reading the blog post before the page fully loads, and then the browser jumps down, totally interrupting their reading experience.)

The giveaway?

If the URL you’re sharing has a hashmark in it (#) it’s very possible you’re linking to an anchor point that will jump the reader farther down the page than you’d prefer.

The fix?

Eliminate everything after the hash mark and you’re good to go.

The caveat:

It’s becoming more and more common to use information after the hash mark for other purposes, for example, a photo gallery’s main page may be located at this URL:

http://thefarmonadderley.com/index.php/galleries/gallery/type/the-farm/

… but since the gallery is powered by javascript, it uses the information after the hashmark to indicate which photo to load first:

http://thefarmonadderley.com/index.php/galleries/gallery/type/the-farm/#4

If your intent is to link to a specific photo, you obviously need to keep the hash mark, but it’s something you need to consider before quickly dashing off your Tweet: Should the information after the hash mark be there?

3. The Session- or Context-Specific Link

Some web sites or applications pass information to themselves via the URL, including a very popular one. Say you simply must share the latest Danielle Steele novel with your book club pals. If you found the page via Amazon’s own home page, the URL you end up sharing may look something like this:

http://www.amazon.com/gp/product/0385343183/ref=s9_simh_gw_p14_i1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-2&pf_rd_r=05THFNDRZ3KKPBVZ518Q&pf_rd_t=101&pf_rd_p=470938631&pf_rd_i=507846

The problem?

For our purposes there is a ton of unnecessary information in that URL, information that is only useful to the web server and not at all useful to the visitor. As we like to say, the URL isn’t very human-readable.

The fix?

It will be different for every site, but in Amazon’s case everything from /ref onward is unneeded by us and can be eliminated, leaving you with this:

http://www.amazon.com/gp/product/0385343183

Which, admittedly, isn’t a very human-readable URL. Fortunately, Amazon does something smart. If you search Google for the title of the book, you are directed to this URL:

http://www.amazon.com/Big-Girl-Novel-Danielle-Steel/dp/0385343183

… which, while it still has numbers that mean nothing to you and I, it also has the title and author’s name of the book. Much friendlier.


Anyway. That’s my little rant about URL sharing. Was it worth a thousand words? I’m not sure — but I feel better. :)

Comments

4 Comments so far. Comments are closed.
  1. Don’t forget about “utm” crap appended to every link being tracked by Feedburner and/or Google Analytics. Usually it goes like this:

    http://techcrunch.com/2010/04/01/gowalla-adobe-chipotle/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Techcrunch+%28TechCrunch%29

    I can’t stand when people give me links like this.

  2. Well, it seems you’re actually advocating that we put in time and effort to make already unreadable, overlong, unwieldy URLs marginally less so. I do agree with the #comments example, certainly, but really: Why not provide the shortest Amazon URL, and why link to anything at all that breaks up a single article into pageview-inflating chunks?

  3. You’re right — bothering with “human readable” URLs isn’t all that compelling, given how many URLs are compressed (and therefore obfuscated) via URL shorteners.

  4. I have got to agree with you here, this is a growing problem. It is, as a result, something I always try avoid screwing up on my sites by using properly structured permalinks.

    Nice articles ;)