However, this causes some problems when trying to copy/paste a tweet. See the screenshot of this tweet.

If you try to copy/paste that Tweet you’ll end up getting an unusable URL. Perhaps Twitter should throw the 140 character limit out of the window on the tweet permalinks to make the full URL visible. This would make it easier to copy/paste but also simple to see whether or not the URL you are clicking on will lead to a Web page, a PDF file, an MP3 file, etc.

For an example of what the DiggBar looks like, here is an example of a page here on First initial, last name that has been getting a few hundred views per day with the DiggBar.

But wait, there’s more. The DiggBar, as you can see from the example URL I gave, also acts as a way to shorten a URL. You can read some of my general thoughts about URL shorteners here. This makes it easy for people to share these DiggBar-wrapped URLs on sites like Twitter (I’m cdevroe, btw).

Why block the DiggBar?

Because the DiggBar is the devil!! No, not really. But there are some legitimate reasons to block, or boycott, the DiggBar in favor of the team at Digg changing the way it is implemented. You see, the same caveats that apply to other URL shortening services also apply to Digg. Such as link rot (or links expiring). On top of those reasons, though, is the fact that they are wrapping the Dugg URL with the DiggBar. Some may not like that. Worse, however, is that the location in the browser does not change as it would with traditional URL shortening services. This is bad practice for a number of reasons. First, although Digg would argue that they’ve “taken this into consideration”, is the way search engines index the URL. If the URL for these indexed pages all resulted in having Digg.com/* in them, Digg would be getting a lot of “Google juice” that really wasn’t meant for them. That credit should be going to the original URL but instead it’d be going to Digg. Digg says that they’ve addressed this problem but, as some have pointed out, they didn’t do this correctly.

The URL not changing also has an affect on the human interface. When people browse the Web they generally believe that the address in the location bar on their browser is the location that they are currently browsing on the Internet. If my browser says I’m browsing Amazon.com then I’m probably browsing Amazon.com. The DiggBar goes directly against this convention. Even though your browser reads digg.com/whatever it does not mean that you are on Digg.com. To make matters worse, if you’re going through your browser’s history – you know, to get back to that tutorial that you read earlier today about how to soften butter correctly – you will be presented with a Digg URL rather than the canonical URL (or, the established URL for a piece of content, the real one). This is just bad form. Other URL shortening services do not even show up in my browser’s history.

In other words, the current implementation of the DiggBar brings with it a whole new set of problems that adversely affects both the sites that Digg links to and the people that are browsing those sites.

Why I’m not blocking the DiggBar

With all of this hoopla about how bad the DiggBar’s implementation is you might think that I’d be one of the first people to block it. John Gruber, who is kicking and screaming about the DiggBar as much as anyone, has chronicled the goings-on with the DiggBar over the last week. Searching through his coverage, which is sort of hard since his search results are a bit odd, will reveal a wide array of ways to block the DiggBar fairly easily. But I think I’ll wait on blocking the DiggBar just yet, and here is why.

I’ve met Kevin (who founded Digg and is the lead guy behind many of their products), know some of the people at Digg (or did, not sure if they are still there), and am generally a fan of what Digg is trying to do as a site and with the DiggBar. John’s all out assault on Digg’s audience, in my opinion, isn’t really fair. I’m just as much against trolls on Digg as anyone but not everyone that uses Digg is a douche. I also do not believe that Digg’s intentions were all bad when they released the DiggBar. Could they have done a better job? Yes. Could they have leaked it out to more testers that are more sensitive to the adverse affects it may cause? Yes. But Digg has misstepped before and, as far as I’ve seen, done a fairly good job of listening to community feedback and adjusting. I hope they do the same thing with the DiggBar.

If they don’t, then I’ll block it.

Update: It looks like the first wave of changes to the DiggBar are planned and being released this week. Digg will allow members to opt out while non-members, or those not currently logged in, won’t see it at all. A fantastic first step in my opinion.

These facts are nothing new and, I’ll bet, do not allude those that built these services. But, they see a general use and purpose for these services and decided to provide their own solution to the problem.

The problem is that, in some cases, you need a shorter URL than the one provided by a particular Web site. Web sites with incredibly long URLs (like Amazon, Google Maps, or search results on a site) can be cumbersome to deal with in situations like writing email, Twittering (I’m cdevroe by the way), and sending SMS messages. URL shorteners attempt to solve this problem by creating links to these pages much easier by providing a significantly shorter URL that simply redirects to the URL that you chose.

Seems innocent enough. Seems simple enough. However, by creating a shorter URL that represents a longer one you’re, as Joshua states, adding unneeded layers that could potentially fail overtime. If the URL shortening service manages 1,000,000 redirects, and suddenly goes down, those redirects no longer work. This is a big problem.

For services like Twitter, which benefit greatly from these URL shortening services due to their short message limit, they stand to have millions and millions of dead links. Right now, by default, Twitter uses TinyURL to automatically shorten URLs to help them fit into the 140 character limit for SMS messages. Jason Kottke suggested that Twitter create its own URL shortening service so that they can guarantee it be around forever and to replace all of the short URLs it had created in the past. I’m going to go one step further and suggest that they buy Bit.ly.

While Twitter has chosen to use TinyURL I believe this was because Bit.ly wasn’t around when they added the TinyURL functionality. Bit.ly is more on par with Twitter’s real-time efforts. Twitter would immediately get their own URL shortening service that has, on top of it, a very good statistics package to show how those links are being used, where they are clicked on from, how many people clicked them, and a service that has a good API.