Skip to content

Instantly share code, notes, and snippets.

@devongovett

devongovett/gist:1176791

Created August 28, 2011 15:30
Show Gist options
  • Save devongovett/1176791 to your computer and use it in GitHub Desktop.
Save devongovett/1176791 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
gistfile1.md
@getify
Copy link

getify commented Aug 29, 2011

@antimatter15

thoughtful post, appreciate it. a few responses:

I would think that funnycatvideo.youtube.fi.gd/j2xn would be better

That's certainly one approach to take, and I can recognize how some people might tend to prefer that. I don't, but then again, that's why opinions are the way they are.

One thing I'll point out is, I really was building off the precedent that bitly (and others) set for vanity URLs (because I think that precedent makes sense), which is to put the useful alias descriptive vanity part as the first part of the path, immediately after the domain.

http://bit.ly/some-awesome-vanity-url

I'm not sure if bitly ever thought about

http://some-aweomse-vanity-url.bit.ly/

But they certainly don't have that as their approach right now. @goLookAt merely extends and tries to improve upon the idea that the content-path portion of the URL is the right place (and most semantic place) to describe what kind of content the URL will point to. I'm not a huge fan of ugly/non-sense looking sub-domains, BUT I think it's better than ugly/non-sense URLs which have no useful descriptive info.

That having been said, I'd encourage other experimentation in this area. Build a shortener that puts the vanity stuff into the sub-domain. That's fine by me.

The description of the content should be what the rest of the post is for

I disagree. I think that having descriptive text surrounding a link in a tweet, facebook/g+ post, etc is an excuse and fallback for having a crappy URL that doesn't speak for itself. The spirit of my experiment with @goLookAt is to make URLs which speak for themselves, so that you have less "noise" in the tweet, and more link. "/funny/cats/video" is shorter and more effective to describe the link that "this funny video about cats", because it removes the unnecessary grammatical structures, punctuation, etc.

if a user is going ot type it or share it with someone else, having a long URL isn't good

Again, I disagree. Having a longer URL is not necessarily bad. Most URLs are not re-typed. Even short URLs. Honestly, how many times have you seen a bit.ly URL like http://bit.ly/ab34ds3 and gone and re-typed that yourself? At worst, most people do copy-n-paste of such URLs to make sure they don't typo. And in better cases, such as how sharing happens on facebook, or native retweets in twitter, the "sharing" is completely digital and requires no textual interaction on your part at all. In all those cases, length of URL is much less relevant.

Besides the incredibly niche case of manually re-typing URLs, the only place where length of URL is relevant is if it busts your 140 characters in twitter. Luckily, twitter's mandatory t.co wrapping of all URLs means that no matter how long you make a @goLookAt URL, it only costs you 21 characters in your tweet.

Moreover, I've already shown how descriptive keywords in the URL lengthen the URL but actually shorten the overall tweet. And btw, I don't recommend people creating vanity URLs that are excessively long (the usefulness factor doesn't extend forever to the right in a URL). I recommend 2-3 short, desciptive keywords on the end of the URL, at most. Most of these URLs then end up being about 35-40 characters in length. That's certainly well within the limits of almost all mediums in which URLs are displayed and communicated.

A url should be to some extent bidirectionally unique

There's a whole industry of people who create unique URLs to the same content, for A/B testing, SEO, marketing campaigns, etc. I see nothing that suggests that we have to stay in an old-world mindset which restricts one-URL-one-resource. If 10 different people describe a site in 10 different ways, I actually think it's quite healthy to have the different links, with different meta data, as this feeds into the larger body of knowledge (meta-data) about a page, and it's gathered virally and crowd-sourced rather than automated via soul-less algorithms.

@auroranockert
Copy link

I prefer the real URL, #1

  1. Showing the real URL is important for the user, for 'security' reasons etc.
  2. I care more about the domain than the path.
  3. Being short is irrelevant for mum printing flyers, being typeable and obvious where it goes is relevant.
  4. One URL per resource please, most people don't A/B test their links.

How often do you ignore links because they use an URL shortener? I know I do, all the time, I simply assume that people using them on anything but twitter are hiding something, play with open cards if you want people to click. You cannot really provide both the shortened URL and the actual URL, since they can diverge after you present it, or due to more malicious issues, like someone presenting a link to hacker news to the client, and on the actual click provide goatse.cx, not very nice.

The domain is much more important than the path, it is verified to some extent, I know youtube is youtube, anyone can fake anything in the path without any technical knowledge.

Mum printing flyers might want a short url, but bit.ly/98af79 is not as typeable as mums-cookies.com/special-deal, even though it is much shorter. People might even remember it! Use nice URLs to begin with, don't try to get them via a shortener.

If you are A/B testing links to some third party, you are probably caring a bit too much about something that hardly matters. Try to improve your own pages instead of your links to someone elses.

@nddrylliog
Copy link

nddrylliog commented Aug 29, 2011 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment