« Internet Security | Main | Wireless Airport »

March 26, 2003

URLs continued

I've gotten a few emails (and one comment) about my post on Web URLs. As such I'd like to clarify this a bit with commentary back to Joshua Kaufman whom I think has too narrow a scope on the idea as a whole. Not to single Joshua out, other emails revolved around the same sentiments, but were (unfortunately) sent in a non-public forum.

Think of it more like this:

http://www.deadmime.org/~dank/archive/Web%20URLs.html

Where the archive script will pull out of the database all entries that have started with the topic of Web URLs. There is essentially no need for the date, as multiple entries (if they do exist) can be retrieved. Although the inclusion of the date can narrow one's results to a more specific entry, this will introduce another problem in realm of formating of course.

The practical benefit of the (debatable) "longer" URL though can be found in the ease of use. It's much easier for people to remember word phrases and patterns then a series of semi-random non-meaningful text. This can already be seen through the use of the Domain Name System rather than the underlying IP address method of connections found on the Internet. The reason I call a URL semi-random and non-meaningful is simple; to those who do not develop the system, each keyword means nothing. Take for example the opening page for amazon.com I just received:

http://www.amazon.com/exec/obidos/subst/home/
home.html/002-3796724-4042416

While I know that exec stands for execute, and obidos is a type of database connection, there is no real way I could tell you what subst or home are for. Nor am I likely to remember these much longer than 10 minutes after finalizing this post. Why do I, as an end user, know what these stand for now? Most likely due to prior involvement with such systems, or possibly (but unlikely) due to repeated use of a web page.

The beauty of this, though, is that I really don't have to memorize it. That the web-server already takes care of all these headaches (and many others) for me. The downside to this of course is, how do I share this amazing book I've found online? It will be near impossible for me to remember that URL, let alone conveying that information to someone in passing. I could say for example:

http://www.amazon.com/exec/obidos/tg/detail/-/006092988X/
qid=1048703149/sr=8-1/ref=sr_8_1/002-3796724-
4042416?v=glance&s=books&n=507846

or

http://www.amazon.com/book/title/A%20Tree%20Grows%20In
%20Brooklyn

The biggest problem with this idea is the need to HTML encode bits. It won't be until such necessity is gone, that the idea of short URLs can truly take form.

The follow up to this can seen in a need for format standards. For example, take the a hardware manufacturer website like HP's. They could have a URL that looks like so:

http://www.hp.com/products/printers/deskjet3500
http://www.hp.com/printer/deskjet3500

Both are means of describing the DeskJet 3500 printer, but which one would be the proper format? Or what about this case:

http://www.hp.com/drivers/deskjet3500
http://www.hp.com/products/drivers/deskjet3500

Which format should be the suggested means for access for downloading your drivers? While it is possible for a web designer to create a means to handle most URL formats, it adds in new levels of background complexity to the site. Yet on the front end, the end user will never notice this and be provided a much easier means to help themselves and their friends. More importantly it provides a more natural flow for a user, resulting in a more pleasant experience. The easier it is for a user to find something and share this knowledge, the more likely they are to return (with friends). This is after all what most commercial web sites aim to accomplish, right?

The background complexity issue is one that I, as an end user, care little about.

Posted by Dan at March 26, 2003 10:43 AM

Comments

Thanks for the clarification, Dan. You're right, it does make a lot of sense, and I plan to change my archive URL format to something more like yours.

Posted by: Joshua Kaufman at March 26, 2003 12:40 PM

In regards to Amazon, part of the information passed in the url is a session id (passing it in the url is an alternative to storing the url in a non-persistant cookie, which some users find annoying). I am unclear how a session id could be passed via url without "semi-random non-meaningful text". Even if it is a part of the url that is unnecessary to give to someone to reach a particular page in a site.

Posted by: L Matey at March 27, 2003 07:32 AM

Please read the following:

http://www.w3.org/TR/2003/NOTE-chips-20030128

(Section 3.2 most specifically)
You will find this isn't a recommended method by the W3C.

Posted by: dk at March 31, 2003 06:46 AM