User-Centered URL Design 41
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.
Tim Berners-Lee (Score:2, Interesting)
Re:Tim Berners-Lee (Score:2)
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 [robotwisdom.com] lunacy.
Brent Simmons' Law of CMS URLs (Score:4, Insightful)
The more expensive the Content Management System, the crappier the URLs. Compare, for instance, StoryServer's weird comma-delimited numeric URLs [vignette.com] 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 (Score:1)
Sorry for the
Re:Brent Simmons' Law of CMS URLs (Score:2)
Some tips for static urls (Score:3, Interesting)
- 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 (Score:2)
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 (Score:1)
Re:Some tips for static urls (Score:2)
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 (Score:2)
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 (Score:2)
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
It costs a few extra string operations, not an extra HTTP request
Re:Some tips for static urls (Score:2)
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 (Score:2)
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.
Um, why would it?
The rules are pretty simple; when you see a
Thousands of years in the future, archeologists and server admins will boggle at these mysterious requests that continue to hit their webservers
Your tips are incompatible with GeoCities (Score:1)
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/").
What if you don't control the namespace below "http://server/foo/"? For instance, what if your URL is http://server/~username/ as it is on fortunecity, geocities, or your university's web space?
never use client-side redirects
Unless your hosting service doesn't support server-side redirects.
Client-side redirects are a sure sign of someone who can't grok .htaccess.
"Someone" not always being the person responsible for the content.
Anyone else find it a bit ironic... (Score:4, Funny)
Mr. Garrett isn't alone in this. (Score:3, Informative)
Help me, I've gone link-mad! (But those are all good reads.)
URL's are for computers - not people (Score:2)
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 (Score:1)
The users care about:
Conclusion: URLs should be for people, not computers. People care what the URLs are, computers don't
Re:URL's are for computers - not people (Score:2)
Article Lacked Useful Tips or Code (Score:2, Interesting)
For instance, this thread in
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 (Score:1)
Re:Article Lacked Useful Tips or Code (Score:2)
Well, they're not great URL's either. Better would be something like: With this, you can add
I'd probably try to think where the best spot for developer is too; in front of the article number at the end? After
I just use mod_rewrite to pass the entire path to my scripts, ala: Although it's bit of an insult to mod_rewrite's capabilities, this approach is quite effective.
Re:Article Lacked Useful Tips or Code (Score:1)
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'm thinking, why should it be? It really doesn't matter. You would never type a slashdot url or any url that refers to a specific page under a site. That's what the bookmars are ment for.
Using page names like ".../User_Centered_URL_Design.html" only causes more work for the admin. If you say that you'll know then what it contains, try checking the titlebar.
Re:Article Lacked Useful Tips or Code (Score:1)
Using page names like ".../User_Centered_URL_Design.html" only causes more work for the admin. If you say that you'll know then what it contains, try checking the titlebar.
The subject of this discussion is making the life easier for the user, not the admin. If the admin have to write som code to let the user have the same URL (amlost) as the title, then so be it.
It's kind of useless to dictate the titlebar over the phone to someone if you want them to get to the same page.
Re:Article Lacked Useful Tips or Code (Score:1)
How will those "easier" urls benefit users?
It's kind of useless to dictate the titlebar over the phone to someone if you want them to get to the same page.Is it really useless to dictate the titlebar? You can always search using the titlebar. Do you usually dictate urls to dynamic page/other than main page by phone?
Re:Article Lacked Useful Tips or Code (Score:1)
How will those "easier" urls benefit users?
That's the subject of the article, try to read it.
An earlier article (Score:2, Insightful)
Make links shorter (Score:1)
TinyURL (Score:3, Interesting)
Really nifty utility for dealing with sites that choose the long obfuscated URL approach...
Re:TinyURL (Score:1)
This is cool, I admit. However, how long will these stored tiny URL's exist? For something like this I could email out to clients, and tell them that it would be valid for the next 90 days. This is assuming that tinyurl.com would not store my hundredline URL until the end of time.
Redirects are bad (Score:1)
Then what happens when your user bookmarks the result of the redirect and you want to change the server technology without your users noticing? ie say the original URL is:
http://myserver.xyz/myproduct
which redirects the user to:
http://myserver.xyz/stuff?things=blahblah&product
which the user bookmarks. Then you want to change your content management system. Do you support all the old links and all the redirects?
Forget about bookmarks, how about when google indexes your site? I think something like this happened to apple's support site a couple of months back. Suddenly all the hits to knowledge base articles started coming up with 404s.