Well, for the URL design bit, I wrote a page about it a while ago, and
this is the condensed version.

Aside from URLs I think there's a convention that clicking on the logo
of a site goes to the homepage. And it's popular to use an accesskey of
"?" to go to the search engine. Nothing else comes to mind though.

//

Designing URLs
URLs should be simple, concise, and designed to last forever -
reflecting the page's content and hiding the implementation. The days of
an URL mapping directly to a file are gone. Instead people treat the URL
like a command line - passing variables to a script that assembles a
page - ending up with a bloated, confusing, and forgettable URL like
http://somesite.com/book/9/index.php?anidifranco=neato&jeffk=hacker&slashdot=funny&point=taken

Filename extensions
As browsers ignore filename extensions (.php, .jsp, .asp) it is
unnecessary and detrimental to use them on the web (instead use MIME
types). The URL becomes a legacy to uphold when users and search engines
expect to find pages at that URL - especially when the URL is bound to a
piece of software that may no longer be in use (such as .php3, .asp, or
even .html). Changing the backend system now involves breaking the
legacy or making a convoluted redirection scheme... to the new
technology that - in the future - you'll have to redirect from again. A
good URL, I think, should abstract from technical implementation.

That said, browsers don't often reattach file extensions if they weren't
given them in the first place so if the file is for download (rather
than in-browser viewing) it's probably ok. Also, IE sometimes ignores
mimetypes <
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp


*>. So it's usually more practical to remove file extensions only for
html. Certainly .asp should never appear in the URL.

Apache's mod_rewrite URL Rewriting Engine can map external URLs to a
different internal file (/about/tauranga to /about/tauranga.html). This
allows you to hide the file extension. In three years XHTML will be much
more popular but i'm sure that will eventually have a successor too - so
serving .html is really missing the point. The technology has nothing to
do with the content so remove it from the URL.

K.I.S.S.
A simple url is better than a verbose one, so choose your words
carefully. A popular example is to use /job over /employment... /cv over
/resume. Domain names are chosen to be brief, perhaps an acronym - but
often people feel more comfortable choosing ludicrously long filenames
like 0092115-The_Movie_Troll_ Character_Harry_Potter.html.

Expressing Hierarchy
Parent/child relationships are typically expressed by /'s (slashes).
Using the URL as a command line has lessened this elegant simplicity.
There are URLs that are /?year=2001&month=3&day=12&pid=162340 when
/2001/3/12/[pid] has the same information. Or take a link to a page that
exposes internal logic, /?op=special;page=irc when /irc is enough of a
unique identifier. It's more readable and far easier to remember and it
doesn't become less flexible.
When content varies by date a useful structure is
year/month/day/ItemOfTheDay. With this, a user should be able to edit an
URL to /2001/5/1, or perhaps just the month (/2001/5) and receive a list
of all stories posted that month. In this way an URL becomes a hackable
interface. Most programmers already do this. When getting a 404 they'll
chop off the end to see if any parent pages remain.


* IE seems to follow this scheme in deciding filetype, -- If the server returns a content-type, IE will remember that. -- However, IE also runs the beginning of the stream through a 'buffer check' to verify whether the data actually looks like the content-type being passed to it. If IE thinks the content-type is invalid, it'll just ignore it and do whatever else it can to parse the data, including falling back on the extension of the URL given.


.Matthew Cruickshank http://holloway.co.nz/


****************************************************** The discussion list for http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
******************************************************



Reply via email to