User-Centered URL Design

Adaptive Path has this interesting essay by Jesse James Garrett on user friendly URL design. When websites were just static files, they were often named in a friendly way, just to make it easier for the designer. But today, many dynamic web sites and CMS's are based around extremely long and complicated URLs that are difficult to work with (ever try to read one to someone over the phone?). This essay explores the way some websites use redirects and smart naming schemes to keep URL's easy and friendly.

Comments

Tim Berners-Lee

[queh]

A good basic guide from the founder of the web is at http://www.w3.org/DesignIssues/Axioms.html. (Note that URI doesn't follow its own advice, heh)

Re:Tim Berners-Lee

[RobotWisdom]

"A good basic guide from the founder of the web is at http://www.w3.org/DesignIssues/Axioms.html (Note that URI doesn't follow its own advice, heh)"

What's more, his 'good basic guide' is written by a PhD who's completely lost touch with the 99.999% of web-authors who don't have PhDs in compsci or physics or anything. The W3C has become a big irrelevant exercise in intellectual masturbation, and responsible web-authors ought to secede from its pseudo-AI lunacy.

Brent Simmons' Law of CMS URLs

[cpeterso]

Brent Simmons' Law of CMS URLs:

The more expensive the Content Management System, the crappier the URLs. Compare, for instance, StoryServer's weird comma-delimited numeric URLs to Radio UserLand's human-readable (and guessable) URLs. Then compare the prices--orders of magnitudes of difference. So, at least in this respect, there's an inverse relationship between price and quality.

Re:Brent Simmons' Law of CMS URLs

[PD]

Interesting! To compare, my site has a free content management system I wrote myself in Python. The URL's are not too bad, except for the ones that my digital camera made up in the photo album.

Some tips for static urls

[RobotWisdom]

My site is 100% static HTML, but my rules of thumb for URLs include:

- never more than 80 chars, so they can be emailed
without wrapping

- no uppercase, ever (otherwise you'll forget where
the caps were)

- never more than two directories deep (I sometimes
break this due to bad planning)

- if a new page seems likely to grow into many
pages, it should be created as foo/index.html
instead of foo.html (Someone emailed me this
brilliant tip, I forget who though.)

But the bottom line is to arrange directories
and files (and their names) so that you can
remember them without having to doublecheck.

Re:Some tips for static urls

[Permission Denied]

I take this even one step further: I make every page into a directory. Thus, you would never see "/foo.html" or "/foo/index.html", but just simply "/foo/". The final slash is optional, but what happens when a user doesn't include a final slash is that the browser asks for "/foo" and the server responds with a redirect to "/foo/" and the browser then proceeds to ask for and download "/foo/" (so always specifying a final slash never hurts).

The advantage is that this makes it easier to move between content management systems without breaking links or maintaining loads of redirects. Eg, if my site goes from php to zope, I don't need to change any links or create any redirects for outside people that linked to us or users that bookmarked a page. This also means that if you adopt this scheme for your 100% static html pages and then decide to go to php (or whatever) you don't need to make page redirects, symlinks, permanent redirects, etc.

I also only specify absolute URLs that don't include the server name (not sure of the correct terminology, but I mean "/foo/bar/" instead of "../bar/" or "http://server/foo/bar/"). This makes it easy to mirror a set of pages on a different server (for instance, if you have a database app that you MUST run on a specific server but you want to make it look like it's running on your main front-end server). I've tried working with non-absolute URLs ("../foo/"), and this made it very easy to move entire sets of pages to different directory hierarchies or different servers, but it's quite a PITA to actually write pages like that (and it also creates a redirect, like not including the final slash). Anyway, the point is that you should always be aware of the issue when writing pages as consistency saves time in the long run.

Anyway, these two things have come in quite handy in a number of situations.

Final pet peeve: never use client-side redirects, always use server-side permanent redirects. Client-side redirects break the "back" button. Client-side redirects are a sure sign of someone who can't grok .htaccess.

Re:Some tips for static urls

[Permission Denied]

I'm not certain about that. I thought it was actually the other way around. Quoting RFC 2616:

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

(301 is the permanent redirect I was talking about and is what apache generates on "redirect permanent" statements.)

I recall doing some tests with a few browsers a couple years ago, and I actually noted that none of them update their bookmarks no matter what you do. Situation may have improved in the meantime.

When you do this:

< META HTTP-EQUIV="refresh" CONTENT="N;URL=http://www.foo.com/foo.html">

(which is what I mean by "client-side redirect") I would say it's a very bad idea for a user agent to update a bookmark since that is used for a number of other things (eg, auto-refreshing pages like a webcam, etc.).

Re:Some tips for static urls

[Fweeky]

I'm not certain about that. I thought it was actually the other way around.

Yes; there are several different redirect schemes in HTTP (permanent, temporary, see other, etc), and a couple of other response codes that can edit bookmarks.

410 Gone, for instance, should be used instead of 404 if a resource used to be there but has been removed. While 404's might disappear later, 410's are explicit "this is gone, it's not coming back" notices.

Re:Some tips for static urls

[Fweeky]

and it also creates a redirect, like not including the final slash

Uhm, no it doesn't.

The UA does not request "../foo/" from the server; it looks at the current URL and strips off the last directory and appends /foo/ to it, resulting in exactly the same URL you would have got using absolute links.

It costs a few extra string operations, not an extra HTTP request :)

Re:Some tips for static urls

[Permission Denied]

Actually, I just tested this, and we're both wrong. I haven't found a browser that does that string manipulation, and I also haven't found a server that does a redirect.

Type in http://server.com/somedir/../ into a Netscape and the browser sends a request for exactly that, and apache and thttpd respond with exactly that directory (eg, equivalent to the web root, assuming "somedir" exists). Test it with a sniffer if you don't believe me (I'm using Netscape 4.x for Unix (please, no comments) - perhaps other browsers actually do the string manipulation, but if Netscape 4.x sends that out, I'm sure all servers deal with it). I'm certain apache must be doing some sort of string manipulation internally since it has to figure out whether or not you're requesting something in its web space (eg, to prevent fetching /../../../etc/passwd). I'm not sure how well this works, because such string manipulation would become more difficult with UTF-8 and URI-encoding (where there's more than one representation for a character).

Actually, now that I think of it, this is probably what these things are trying to exploit:

GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+ dir HTTP/0.9

Looking through one page of a server's logs, I see three different variants of the above request, from three different IPs, all within an hour :)

Re:Some tips for static urls

[Fweeky]

Actually, I just tested this, and we're both wrong. I haven't found a browser that does that string manipulation, and I also haven't found a server that does a redirect.

You can't have looked very hard. Both Opera, IE6 and Mozilla normalise the URL before sending; even wget does. curl was the only client I use which doesn't.

If NS4 doesn't, fine, more fool it. Several months ago my copy started coredumping every time I tried to run it, so it no longer gets tested :)

No need to packet sniff, anyway; server logs work just as well.

I'm not sure how well this works, because such string manipulation would become more difficult with UTF-8 and URI-encoding (where there's more than one representation for a character).

Um, why would it?

The rules are pretty simple; when you see a .., back up to the next / and try again. How would UTF or URL encoding make this more difficult?

Actually, now that I think of it, this is probably what these things are trying to exploit:

GET /scripts/..%255c%255c../winnt/system32/cmd.exe?/c+ dir HTTP/0.9

Thousands of years in the future, archeologists and server admins will boggle at these mysterious requests that continue to hit their webservers ;)

Anyone else find it a bit ironic...

[NickV]

Anyone else find it a bit ironic that an article that is offering suggestions for cleaner URLs and undoing the damage of CMS naming conventions is named "000058.php" ?

Mr. Garrett isn't alone in this.

[Louis_Wu]

Well, this was also written up at A List Apart, which is directed by Jeffrey Zeldman, who did an interview for Slashdot in May of 2000, and was a recent subject of controversy here and elsewhere, as he chronicled on his website.

Help me, I've gone link-mad! (But those are all good reads.)

URL's are for computers - not people

[funkman]

Users do not care about urls. They care about the following:

How to get to the site

How to navigate to the place they want - and get out as quick as possible

Bookmark their fav spot - to get in/out quick

Short URLS should be provided to redirect users to redirect to the intended result site. Such as advertising.

Re:URL's are for computers - not people

[Ed Avis]

Damn right. Have whatever URLs you want, just make sure that *the same URL gives the same page* (without weird hidden POST parameters or other crap). Then users can bookmark the pages or link to them. Maybe some small customization with cookies is okay, as long as the page content remains the same.

Article Lacked Useful Tips or Code

[herderofcats]

I agree with the general premise of the article, but unfortunately it was vary light on any useful tips or code.

For instance, this thread in /. is http://developers.slashdot.org/article.pl?sid=02/1 0/02/1946224&mode=flat&tid=95 -- why couldn't it just be http://developers.slashdot.org/thread/02-10-02/194 6224.html ? Or even http://slashdot.org/developers/02-10-02/User_Cente red_URL_Design.html ?

I'd love to have some tips from various folk on how to use Perl and PHP with Apache in fancy ways to simplify and avoid these clunky URLs.

-- Herder Of Cats

Re:Article Lacked Useful Tips or Code

[Fweeky]

For instance, this thread in /. is http://developers.slashdot.org/article.pl?sid=02/1 0/02/ 1946224&mode=flat&tid=95 -- why couldn't it just be http://developers.slashdot.org/thread/02-10- 02/194 6224.html ? Or even http://slashdot.org/developers/02-10-02/User_Cente red_URL_Design.html ?

Well, they're not great URL's either. Better would be something like:

http://developers.slashdot.org/article/2002/10/02/ 1946224

With this, you can add ../ to the right most side of the URL and get listings for the day/month/year/forever, and you can guess it'll be the same for /poll/, etc. The ID number might be frowned upon somewhat; you could shorten it to just the article number for the day, or even further categorise by time. You might try something like user_centered_url_design, but that takes a bit more work to generate and map to a database.

I'd probably try to think where the best spot for developer is too; in front of the article number at the end? After /article? Before? :)

I'd love to have some tips from various folk on how to use Perl and PHP with Apache in fancy ways to simplify and avoid these clunky URLs.

I just use mod_rewrite to pass the entire path to my scripts, ala:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*) /index.php?p=$1

Although it's bit of an insult to mod_rewrite's capabilities, this approach is quite effective.

An earlier article

[skware]

I read a better article quite some time ago by Tim Berners Lee, entitled Cool URIs don't change, in which he discusses the designing urls properly ie. what to leave out of a url (things like .cgi, cgiexec, access details - members / non ...). The things he suggests are easily implementable in .htaccess for apache using mod_rewrite for php / cgi things.

TinyURL

[Bishop923]

<shameless_plug>

TinyURL
Really nifty utility for dealing with sites that choose the long obfuscated URL approach...

</shameless_plug>