Jon's recent piece, "Web namespace design: de facto standards" really resonated with me, and I can almost completely blame it on work. Two separate and very different events transpired recently and both proved his point quite nicely. They're both related to a couple of Yahoo's most popular properties (that's the lingo we use to refer to something.yahoo.com, where "something" is a property like news, sports, mail, finance, and so on.)
Yahoo News
Like many tech companies before us, we have an internal mailing list that most of our engineers use for marginally work-related discussion. Most of the traffic, however, is generated by rants.
That's healthy. We all have complaints we like to get of our collective chests once in a while. Recently, in a discussion on the quality of the HTML we generate at Yahoo, someone brought up a related issue: our URLs. Why are some of them so long and ugly? Sure, some of them are short and sweet, but others are long and ugly. Very few of them are guessable URLs.
As most of our debates do, it raged for a bit and then degraded. But during the course of discussion, a few important points came up in favor of short, simple, guessable URLs:
- Short URLs mail better. They don't wrap and break.
- Short URLs are easy to read over the phone.
- Short URLs can be memorized when used often enough.
- Guessable URLs keep the hackers and geeks happy without affecting the 99.9% of normal users at all.
Sure, there are arguments against simple URLs, too. URLs are clicked, not typed. Most users don't care. It's not worth the extra engineering effort to make them short (whatever that means). And so on. But I personally find them all rather weak. They sound like justifications for being lazy.
Yahoo Finance
As you may be aware, we've been talking about changing some of our technology in Yahoo! Finance and using some new-fangled stuff.
In a recent meeting, we got to talking about how some of our URLs will be impacted by these changes. Obviously, we don't want to break URLs, but we may want to phase them out in favor of new ones--kind of like what we've been doing for quote.yahoo.com (much to my chagrin).
We eventually realized that we were contemplating a change to the single most important URLs in the entire world of on-line Finance! Seriously. Everyone in the world (who cares) knows that if you need a sock quote for a ticker, like YHOO, you just need to visit http://finance.yahoo.com/q?s=YHOO and you're there.
Sure, most people just click and type YHOO in the search box on finance.yahoo.com or quote.yahoo.com :-)
But changing it is still a very big deal. Many, many other web sites link to their own financial information on Yahoo! Finance. Search engines like Google will take you there if you search for a ticker. Desktop applications do it too.
As you'd expect, we're not changing it. Ever. It'd be stupid. There's no reason at all to do it. It's too easy to have our servers honor that URL for eternity.
But the larger discussion around this change dealt with an attempt to better structure the less popular URLs on our site. Many of us were arguing to make the URLs just a bit longer (one character, in most cases) to introduce a bit of a namespace where there isn't an obvious one today. (There is one, but it's not at all obvious unless you know way too much about the folks who run Yahoo Finance.)
The bulk of the argument boiled down to roughly something like this:
1. http://finance.yahoo.com/xp?YHOO
Or...
2. http://finance.yahoo.com/x/p?YHOO
Or...
3. http://finance.yahoo.com/x/p/YHOO
That's right. We spent a long, long time arguing about the difference between a slash ('/'), or question mark ('?'). And we argued passionately for our favorites.
#1 is "traditional" Yahoo Finance. Notice many of our links look like that. #2 is "traditional" with an added slash to make it look like there's some semblance of a namespace at work. And #3 is a carry-over from the pages hosted on biz.yahoo.com, like this one.
The Decision
I'm not going to say. Yet. It'll become obvious in the not-too-distant future. But what I'd like to know to satisfy my own curiosity is this: Which one do you prefer? And why?
Later I'll explain my bias and rationale. :-)
Posted by jzawodn at November 07, 2002 10:50 PM
First impression off the top of my head: my preference is 3:
http://finance.yahoo.com/x/p/YHOO
... It's mostly based on gut feel, but "instinctively" this URL gives off the impression of being longer-lasting than a URL with a ? in it (which instinctively gives off the impression of being dynamically generated; which both of them obviously are anyway, but we're digressing)...
There seems to be anecdotal evidence that some search engines also doesn't search URLs with ? but for Yahoo this isn't much of a big deal I suppose :-)
I've always been a sucker for slashes - question marks are just ugly :) Out of that lot I'd go for 3, but I would prefer this:
4. http://finance.yahoo.com/xp/YHOO
Since 1 didn't have a slash between the x and the p, is there any reason for 3 to have one?
Or even better, how about the system used on php.net so going to finance.yahoo.com/YHOO identifies the URL as containing a ticker symbol and redirects the user straight to the relevant page?
Of course, the very best thing would be to have finance.yahoo.com/YHOO :)
Hm, I'm probably the only one who will say this, but I'd vote for #1.. There's been a certain standard established for passing variables in url.. and like it or not, the question mark is it. Slashes are used by many sites but I think it's counterintuitive for passing variables. Mixing slashes and question marks is just confusing.
I like the 4. http://finance.yahoo.com/xp/YHOO , because it's almost as simple as it gets.
Regarding kasia's point about it being counterintuitive to pass variables by '/', I think 99.99% of the users of the site doesn't know or care if they are passing a variable. They just want to type in a url, and adding question marks to it makes it more confusing for users. Usually, they don't have to type urls that pass variables.
Slashes are easier to communicate to a non technical user than a question mark. People are used to them now.
The other problem is that Yahoo Finance has a really sucky 404 page (I accidently clicked on one of the links mentioned). If it could be made more user friendly this would help, especially if it could be "clever" enough to suggest a correct url.
What I'd like would be:
http://finance.yahoo.com/xp/YHOO
Or even better:
http://finance.yahoo.com/stock/YHOO
Or:
See, this is exactly why programmers should never design user interfaces.. we just don't think like the normal users :)
If you do not need an HTML form to submit a GET request, I would suggest http://finance.yahoo.com/x/p/YHOO or something
shorter. how about http://ticker.yahoo.com/YHOO?
The ticker YHOO is just a piece of info that is more specific. It has nothing to do with it being a variable or not.
If you do not need an HTML form to submit a GET request, I would suggest http://finance.yahoo.com/x/p/YHOO or something
shorter. how about http://ticker.yahoo.com/YHOO?
The ticker YHOO is just a piece of info that is more specific. It has nothing to do with it being a variable or not. I will be debating this heavily at ApacheCon (http://www.apachecon.com/) in Las Vegas during "Link Rot: How to sustain the dynamic web".
I'd like to just think inside my head, "Hmm...I wonder how much a share of Yahoo is going for?" And then a semi-tranluscent panel, which is visible to me, but mostly invisible to onlookers, will appear in my field of vision telling me the current stock price, with an ad directing me to where I can go to buy a share or 100 of YHOO.
The panel would disappear as my attention shifted.
You boys have anything like that in the works? If you do I'll be the first subscriber to Yahoo premium.
I certainly prefer #3
(1) YHOO is only a param because we say it is a param. Params are am implementation detail. The act of viewing YHOO stock details as a discrete browsing target validates the existance of a canonical URL.
In fact I'd argue that it is incorrect for a user to think of YHOO as a param at all, it is actually the target of the request. Additional params to tweak the output are in a separate class, but the YHOO is what we are there for.
(2) The simplest solution is usually the right one: option 3 is the simplest metaphor. It contains the fewest discrete path components to understand; protocol (http://), host (finance), domain (yahoo.com), path (/x/p/), file (all may perhaps be metaphorically speaking, since "host" may be 80 servers, "domain" may be geographically redundant data centers, "path" may be a regex trigger for a Model 2 controller, and "file" may be an indicator of a param for a controller method. Thankfully http may really just be http ;)
(3) Don't understimate the value of simple hierarchies when analysing logs. This adds value to every link in the business analyst chain.
(4) The concept of device "files" in UNIX (/dev/null, etc) is very similar to the concept of using a YHOO "file" as a source of power and light. This is powerful, simple, tried, and longlasting.
However...after all that, *please* drop the "/x/p/", "/stock/" will do just nicely.
http://finance.yahoo.com/stockquote/YHOO
use a human language fer goodness' sake! what the heck do the X and P stand for ? No wait.. I don't care! I want my quote dammit! ;)
(get my point?)
