DIGG IT! I view the URL/URI to be one of the most essential but often overlooked aspect of a website. I wanted to look at the good/bad uses of URLs within web pages and web applications. Let's take a look at a few:
Readable - I really like it when a URL is readable and easy to understand. When I read a URL I want to be able to guess at what the page will contain. .
CNET: Does a great job organizing content into directories.
http://reviews.cnet.com/
http://reviews.cnet.com/camcorders/
http://reviews.cnet.com/laptops/
News/Blogs: These sites have clean URLs with hints about the content
http://www.techcrunch.com/2007/11/28/google-earth-heading-towards-extinction/
http://machinist.salon.com/feature/2007/11/28/kindle_review/
http://blogs.moneycentral.msn.com/topstocks/archive/2007/11/26/how-a-little-laptop-is-changing-an-industry.aspx
http://www.businessweek.com/the_thread/techbeat/archives/2007/11/roll_over_beeth.html
I would also bet that SEO crawlers leverage keywords within the URL itself. If I were a robot, I would rank the words within the URLs above higher in my search listings than those below.
These URLs leave a bit to be desired.
http://www.news.com/2300-1041_3-6220161.html
http://www.abcnews.go.com/Technology/story?id=3922038&page=1
http://www.tgdaily.com/content/view/35022/118/
http://www.nytimes.com/2007/11/28/us/28hoax.html?em&ex=1196398800&en=b1408a7356b77eef&ei=5087%0A
State - I like it when the URL stays in sync with the state of the page/application. I think Picnik.com does a great job of this. The site is an RIA and the URL is in constant sync with the application. It leverages the anchor # symbol yet provides clean URL paths. You can bookmark any part of the site and return to the state of the application/site at any time. Although this looks easy, it is really hard to do well.
http://www.picnik.com/app#/home/welcome
http://www.picnik.com/app#/edit
http://www.picnik.com/app#/create/effects
http://www.picnik.com/app#/in/flickrsearch
http://www.picnik.com/app#/out/facebook
Programmatic - I really like it when the developer takes the time to make the URL programatic. It is very subtle but I often return when I can go directly to things via the URL.
http://www.flickr.com/photos/{FlickrID}
http://www.flickr.com/photos/diverted
http://del.icio.us/tag/{tag}
http://del.icio.us/tag/flex
http://del.icio.us/{del.icio.us ID}
http://del.icio.us/sfegette
http://{LANGUAGE}.wikipedia.org/wiki/{WikiName}
http://fr.wikipedia.org/wiki/Ted_Williams
I really dislike query string variables in a URL. In many ways it provides a poor interface to a website and adds a ton of gunk to what could be a clean programmatic URL.
Here are a few URLs that could be improved:
BEFORE - http://www.google.com/search?q=Adobe%20Flex
AFTER - http://www.google.com/search/Adobe%20Flex
BEFORE - http://www.amazon.com/s/ref=nb_ss_gw/104-0679262-3347908?url=search-alias%3Daps&field-keywords=wii&x=0&y=0
AFTER - http://www.amazon.com/search/wii
//Grip - I look up stocks all the time. Yahoo and Google make the URL easy to change directly.
BEFORE - http://finance.google.com/finance?q=adbe
AFTER - http://finance.google.com/adbe
AFTER - http://finance.google.com/nasdaq/adbe
BEFORE - http://finance.yahoo.com/q?s=ADBE
AFTER - http://finance.yahoo.com/adbe
AFTER - http://finance.yahoo.com/nasdaq/adbe
I am also a fan of organizing APIs using method+arguments syntax. It makes it easy to see what you are calling as a developer and to allow others to integrate against the API by discovery. Here is an example:
http://ifbin.onflex.org/api/3/search/resultByKeyword/Flex/Adobe/AMF
Essentially this would call a method like so: (the 3 is the API version#)
search.resultByKeyword( 'Flex' , 'Adobe' , 'AMF' );
Short - The shorter the URL the better in my book. I am always amazed at how long URLs can get. I view shorter URLs are just plain better. It almost makes sense for every site to have a tinyurl service within them so that each complex URL can be made simple. At Adobe the go URLs have been very popular as they allow a short programmatic URLs to various parts of the Adobe.com site.
http://adobe.com/go/flex/
http://adobe.com/go/flash/
http://adobe.com/go/amp
http://adobe.com/go/tryconnect
http://adobe.com/go/max
Technology Neutral - I prefer when developers hide the technology in use. Long term this provides the ability to switch between technologies on the server-side. The end user doesn't care what technology you use, so why let anyone know? In this case I think less is more. If the URL is free of technology, I think it elevates the service in my eyes. Hide the technology you use, it will make you look smart and provide you greater range of options long term. Also once you get into search engines, the URLs are there to stay and you will need to support the URLs presented to your servers.
Outside of Apache/mod_rewrite and Tomcat, there are very few options for simplifying the URL's a server presents. I have standardized on using Apache/mod_rewrite because it works well and is simple to implement. I would encourage you to take a look at mode_rewrite to simplify the URLs within your application. I need to make better use of this on my site and eliminate the php from my URLs site wide.
Cheers,
Ted :)
cool post Ted, I've been thinking a lot about this lately too. I've been using SWFAddress quite extensively on the Flash projects I do and I'm currently working on an e-com RIA that will use clean URLs all the way down to the dynamic content. A little confusing to put together, but definitely reproducible. If I ever get the time I'll blog about it....
looks like picnik needs to update their SWFAddress/SWFObject code with the latest versions.... (there's a bug that shows up with Safari 3.0 when clicking a link after entering the site... the page reloads (bad) and a '?' is put next to the '#' in the URL)
Great post, and timely too. In Buzzword Preview 6, released yesterday, we just added the #anchor support for Buzzword URLs, so you can bookmark individual documents, or the document organizer.
I agree. I find typing http://www.adobe.com/products/coldfusion/ or http://www.adobe.com/go/coldfusion/
easier than trying to navigate the web site.
I don't want to start a flame war of x is better than y but one of the things I like about rails is it's ease to modify route (urls) and I don't have to deal with the mod_rewrite.
True, Mongrel/Rails provides a simplified URL routing model. I wish it was easier to route urls on any server. It seems to be a missing element from most CMS systems and something that should be job 1, not an add-on.
The URL is the key, the server language used is secondary.
My 2 cents,
Ted :)
Nice sneaky IFBIN hint you slipped in there. ;)
I would love to see a post on how to leverage url's in flex. Like how to change the url in the address bar when you go to different areas (states?) of a flex application, and that combined with mod_rewrite to allow urls that do just that. For instance a flex application that is a user management thing, when you click on a user to manage them you see a url like: www.address.com/usermanagement/user/rguill
I'd like to double up on what Ryan said. I'm finding the history management in Flex 3 to be less extensible than I'd like. It's nice out of the box but more and more I find myself creating custom components or hacking existing ones to be used differently than the use cases they were tailored for. Doing that usually breaks the built-in history management.
A really good url/deep-linking library or api in Flex 3 would be da bomb. I'd be glad to participate if anyone knows of something already in the works. If not I'm sure myself or one of our engineers at StudioNorth will start one soon.
-Andy
Couldn't agree more! Sometimes there is discussion of deep linking in RIAs which overlooks the "readable" factor. I tried to find a post to link to at http://blog.centraldesktop.com/ but couldn't, so maybe it was over lunch, but Isaac Garcia used the phrase "hackable URLs" as a sign of a good web app. (I'm sure Isaac purloined the phrase from someone else, just as I have purloined it from him!)
I emailed my colleagues at Soliant a link to this post, and sure enough, Josh Smith found a 1999 reference to hackable urls. Here is his reply:
Jacob Nielson has some stuff to say about this, too.
Berners-Lee weighs in (and references JN).
Lastly, those wild webers at Adaptive Path said (and they quote Tufte, so they get a special place in my heart):
-jbs
(ironic aside: Just prior to emailing this link, I sent links about the good and the bad in email as a collaboration tool; dude, next time just comment the blog!)
to Ryan and others: Check out this link to see how to leverage deep linking in flex:
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Deep_Linking