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:
http://twitter.com/garrickvanburen/status/161277022
Let’s break this apart:
/garrickvanburen
The person’s Twitter account we’re interested in – very clear1.
/status
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.
/161277022
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
/(et. al.)
If we mapped Twitter’s existing structure against this model we’d have:
http://twitter.com/people/garrickvanburen/statuses/161277022
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
http://twitter.com/garrickvanburen/twitter-suggestion-put-the text-of-the-tweet-in-the-tweets-permalink.
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
http://twitter.com/1612770222
This is akin to my WordPress URL Shortening Hack
Benefits: Short
Detriments: Almost no information provided makes this the least usable and equivalent to the shortened URLs you find throughout Twitter.
Proposal 3: Personally Short
http://twitter.com/garrickvanburen/5954
Where 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.
You’ve got some very good points, and although I’m totally unimpressed with the full REST version (I fail to see what’s gained), the shorter versions would definitely be nice. Unfortunately, the global id version — http://twitter.com/1612770222 — might be confused with the home page for a user of the name 1612770222.
Less relevant but still notable: maintaining a global id, a user-centric id, and the chatty full-message id version is going to put additional load on Twitter, which they’re demonstrably not in a position to handle.
Robert, thanks for the comment.
You’re absolutely right about the full REST version. I included it to illustrate the clarity of logically sequenced URL structure.
I’m less concerned about the confusion around global ID vs. persons-name issue. We have issues today with pages like /about, /tos, /privacy, /jobs, etc – all information systems have reserved words.
Regarding Twitter’s ability to handle the load of this feature: hasn’t stopped them before 😉
I don’t think there’s an easy way to get around the use of a numeric for an individual sub resource. “Status” was what Jack Dorsey originally conceived Twitter being, a simple “I am ____ [fill in the blank]” state of being (sleeping, eating, etc.). They (Jack, Evan and Biz) could not envisioned that they would spawn a micro-blogging platform but your point is clear that scalability is hindered without proper nesting. It may explain the many Twitter outages as they have tried to scale the platform.
Wonderful post about this often overlooked aspect of web design.
When developing giftag.com I insisted on this kind of RESTful and human readable URL. In fact, we found it so useful, we ended up adding a framework for creating these kinds of URLs to our open-source Google App Engine utility project, Gaegene (http://www.gumption.com/blog/gaegene/ — it’s in the “slug” sub-project).
An example giftag.com URL would look like this:
http://www.giftag.com/thomas/items/shelter-architecture-remodel/
We let the user control both their username (e.g. “thomas”) and the “slug” of the item (e.g. “shelter-architecture-remodel”). The item slugs are unique per user, so different users can have an item with the same slug.
We think this kind of readability helps our users as they post their URLs around the web. With a single glance you can see that you’re posting the correct link.
By the way, Tim Berners-Lee totally agrees with you (http://www.w3.org/DesignIssues/Axioms.html).