Here’s how it works. In the story above, the base URL is:
If you wanted to link to a specific paragraph, you’d simply add a “#” and the number of the paragraph, e.g.:
You can even go a step deeper and skip to a particular sentence, e.g.:
And here’s where it really gets cool, though. If you want to highlight that section, you simply switch the p to an h. I generated the highlighted text below with the following link:
To simplify things, if you hit your shift key twice on a Times story, small icons appear next to every paragraph. Click on one of them and it’ll place the paragraph linked URL up in the address bar of your browser.
After maintaining years of awkward, inconsistent URL shortening behavior because of some vague argument about SMS capabilities – Twitter has announced links passed through their service may or may not be shortened to t.co.
“A really long link such as http://www.amazon.com/Delivering-Happiness-Profits-Passion-Purpose/dp/0446563048 might be wrapped as http://t.co/DRo0trj for display on SMS, but it could be displayed to web or application users as amazon.com/Delivering- or as the whole URL or page title. Ultimately, we want to display links in a way that removes the obscurity of shortened link and lets you know where a link will take you.”
This is a win for the casual users of Twitter that still send & receive URLs through the service.
URL shorteners were all the rage in 2008 and 2009 – primarily due to the character constraints within the short messages service that was all the rage in 2008 and 2009 – Twitter.
URL shorteners take a long url, for example, this Google Map url:
and transform it into something like: http://tinyurl.com/y3lxdru
Every URL shortener uses their own magic sauce to create the short random string - i.e. the 'y3lxdru' part - and stores right next to the long URL. So if there's a tiny.cc/y3lxdru or a j.mp/y3lxdru - they probably don't point to the same Google Map. In fact, if I understand how bit.ly (aka j.mp) works - their shortened URLs only exist for a few months - and then are 'released' (that's how they're able to keep them short). I even created a automatically expiring URL shortener cause I thought it was funny.
When someone clicks on the short URL, the URL shortener (tinyurl.com in the example above) promises to look up the long URL stored next to the short random string - and promptly redirect you to the location of that Chinese restaurant for your lunch meeting. And not some place unseemly - which has happened, more than once.
There are lots of problems with URL shorteners. I feel qualified to say this because I build 3 of them in the past 2 years (Culld.us, RE07.US, and a native WordPress hack, none of which are currently active).
At best - they make less usable URLs - because both the URLs shorteners domain name and the random string are meaningless (not to mention hard to remember) to people.
At worst - this obfuscation means every short URL clicked is more of a potential computer security risk than normal clicking around the internet.
A 3rd party URL shortener shouldn't be necessary to make Google's Map URLs shareable. Same goes for any other website - URLs can and should be constructed to be reasonably short, human readable, guessable, and accountable. URL design is one of the most under-appreciated aspects of website usability (as is scrolling).
For the past 6 months or so - Twitter has been the only real reason to use a URL shortener. Facebook and other services are now doing a better job of handling long URLs. Many people and companies use URL shorteners as hack for not having a good web site statistics package. Additionally, Twitter has made noises like they're going to default to their own URL shortener in the near future - a move which will promptly shorten the already tiny lifespan of other URL shortening services.
“When you see a TinyURL, you have no idea what the link is going to point you to. Viruses, spyware, porn and all sorts of other unwanted or inappropriate stuff are just a click away. …what if you actually could trust a shortened URL?….The need for safety and security online will not go away. Don’t worry: Smart people like Garrick will be here to help.” – Mike Keliher
Culld.us is the URL shortening system powering grv.me & minnpo.st (and others). Drop me a line if you’d like to hear more about how it integrates with your existing online publications.
One of the biggest problems with URL shorteners – aside from being needed at all – is it’s not easy to move from one to another without breaking all the previous links.
Culld.us hopes to change all that.
Use Your Own Domain Name
At Culld.us, you get a subdomain – like grv.culld.us – and just point a CNAME record to it from your domain.
Use Your Own Web Analytics
Put the statistics on your short URLs in your existing web analytics package, whether it be Google Analytics or another package, just paste the tracking code in your subdomain’s settings.
.htaccess and archival feeds
If you want to leave Culld.us, you can take your redirects with you. Anytime you want – you can grab the .htaccess file, containing your shortened urls and the webpages they redirect to, and upload to your own server.
You can also grab the RSS or JSON feeds.
Fully Customized Stylesheet
Anything you can change in CSS can be changed in your Culld.us subdomain.
Anyone you authorize has access to add URLs to your Culld.us subdomain. Everyone gets their own login and API tokens.
We don’t shorten URLs just to shorten them.
We shorten them for the same reason big box retailers sell flat-pack furniture – greater confidence during transport.
With that in mind, I’ve completely rebuilt Cullect’s URL Shortener1 – http://culld.us
It’s still custom brand-able. In a way I’m much happier with than in the previous version – just point your domain at your Culld.us subdomain.
The part I’m very excited about – it flips shortening on it’s ear.
Sure – you can shorten a URL in Culld.us and share it with a comment in Twitter or email or wherever…or you can just leave it in Culld.us.
Think microblogging + url shortening.
1. This is the first step in a complete rebuild of Cullect as a whole.
Zack Seward from Harvard’s Neiman Journalism Lab and I talked about URL shorteners yesterday – and the responsibility of publishers to shorten themselves…
“The really, really big benefit in that case is that it’s no longer a redirect…”
…and the additional opportunity for a focused, curated, short URL service….
You could change the redirect to whatever is catching your interest at the moment or, say, randomly selected links from Andy Baio.
There’d be elements of mystery and serendipity, like flipping the pages of a great magazine, and devotion might center around the URL itself..”
Big thanks to Karl at MinnPost for connecting us.
I appreciate tr.im’s honesty.
From what I understand, tr.im’s business model was similar to bit.ly’s and – what increasingly feels like – Twitter’s business model: aggregate and sell statistics on how information is being shared on real-time basis.
Measuring word-of-mouse if you will.
Given how fleeting and how nascent the real-time stream is, it feels like trying to measure string pushing.
Sure there’s a result, but if
value = effect - effort then the real value (relevance, importance, and significance) – doesn’t unfold until the pushing stops.
To that end – I don’t see tr.im’s (or any other URL shortener’s) breaking the internet for more than 5 minutes.
If anything this shutdown is a reminder that URL shorteners are cheap hacks apologizing for poor content-management-systems, network security risks, and that publishers should be shortening themselves.
There’s lots of silly URL shorteners.
Some of my favorites – not just because of their silliness, but because they offer some interesting potential;
- GiantURL – takes a regular URL and transforms it into a multi-line, unreadable, hash. Potentially, the information you’re sharing could be encoded into the hash, rather than redirected. Hmmm. what’s the difference?
- Similarly, IWouldHaveBoughtYouThis.com. Which takes advantage of Cullect‘s custom domain URL shortener – again shows us that URL shortening is like packing peanuts for sending those special nothings.
- and of course Re07.us, still makes me smile – and still shows me that if you limit namespace, you can offer time.
Tonight the Wege added another non-URL shortener to the list.
DickinsURL takes your url and applies a sentence from one of Charles Dickins’ works as the key.
“Enter an ugly URL above and hit convert button. Soon you will be faced with beautiful words of Charles Dickens.”
Unfortunately – if you take a close look at the URLs it generates – the Dickin’s lines are optional!
@highwind – if you drop the numeric key, I’ll give you the #2 slot. 🙂
URLs are consistently the least usable aspect of our interaction with web-based information services – which is terribly unfortunate considering their prominence in how we access, share, and interact with these services.
With that in mind, let’s take a look at how Twitter’s URLs could be more usable – by either being more logical, more readable, more share-able, or a combination of all 3.
Here’s a standard Twitter URL:
Let’s break this apart:
The person’s Twitter account we’re interested in – very clear1.
I’m not sure what ‘status’ is – seems like a very system-centric term. For the sake of this conversation, let’s assume it’s a synonym for ‘note’, ‘message’, ‘news’, ‘memo’, or the collection of things I publish at Twitter.
This is the individual ‘status’ identifier. Presumably, it’s the primary key ID of this ‘status’ within all the ‘statuses’ in Twitter’s database – making this ‘status’ ID global – not nested within ‘garrickvanburen’. Again, very system-centric and kind of backwards – if we assume URLs should go from largest logical entity to smallest nested entity.
A RESTful URL structure would dictate the following:
/Plural Version of Resource Name
/Individual Resource Identifier
/Plural Version of Sub-Resource Name
/Individual Sub-Resource Identifier
If we mapped Twitter’s existing structure against this model we’d have:
We can see, Twitter’s URLS aren’t exactly RESTful, and since they’re not – let’s look at some ways to make them more logical.
Proposal 1: Logically Long
This is the most usable and readable for both people and machines. It has the huge benefit of having the entire message in the URL (the mind reels with possibilities). WordPress does a great of making legal URL strings out of a weblog post’s title.
Benefits: Highly-readable, logical nested structure, great for search engines
Detriments: Long (though Twitter’s built-in limits provide a maximum length)
Proposal 2: Globally Short
This is akin to my WordPress URL Shortening Hack
Detriments: Almost no information provided makes this the least usable and equivalent to the shortened URLs you find throughout Twitter.
Proposal 3: Personally Short
5954 is the number of the individual message in the pool of all my messages.
Benefits: Short, encourages numerically navigating through a person’s messages.
Detriments: Numbers are always less usable than words.
The great thing about these proposals is they’re not mutually exclusive. In fact – different URL structures bias different usages and contexts. In the same way different formats (HTML, RSS, XML, Text-only, etc) providing different presentations of the same webpage to different devices are more usable – different URL strings pointing to the same webpage are as well.
1. Identi.ca’s URL structure doesn’t include the person’s name [example]- making the number less confusing, but the URL itself less usable.