Who Cares How This Website Was Built?
Updated June 2007
An oddity of the web is that you can make nasty judgments about the whole culture of an
organization just by looking at a single URL. "Ha!", says the zealot. "All of their
web addresses end in .cfm. They are using ColdFusion, the poor fools."
Such little fringes are unintentional leaks in corporate secrecy. They show
commitment to a development platform, a particular off-the-shelf CMS product,
or demonstrate that some high-school kid made the site in FrontPage. We
elitists tend to pride ourselves on firing off such zingers.
Times have Changed
Before the dawn of the web, you couldn't really tell much about the internals of an
application based on its appearance. Thanks to application programmer interfaces
(APIs), the levers and conveyor belts that one software program exposes to another
to share data, programs could talk to each other behind-the-scenes without
bothering the user. Most importantly, programmers didn't have to reinvent the wheel all
the time, they could just use somebody else's API to get a whole host of useful things
done with minimal effort. Everyone was leveraging everyone else's software, and
the days were long and sweet.
Companies developed their entire strategy around providing a great API for their software,
from Microsoft and it's suite of operating systems to Oracle and its database. A whole
slice of the publishing industry created reference manuals and educational guides explaining
how one developer could leverage the work of another developer through the API. Programs
discussed among themselves, and we users didn't have to hear any of it.
Now, the ugly realities of inter-process communication are exposed for all to see. When
you visit a website, you bounce around using long, often weird addresses that stare back
at you via the address bar. You can check out the internals of any webpage any time
using the "View Source" option. The backdrop is lifted and you have no choice but to
watch the electronic stagehands each to the time you click. IT people take great
pleasure in this chaotic ballet. Somehow, we feel that our secret knowledge of the
hidden theater gives us power and insight incomprehensible non-techies, not just
about how the site was made, but the company who would select that kind of approach.
The Actual Problem
The basic structure of the web has just two types of communication: a REQUEST made by the
browser using a particular address, and the text, images, and media content that make up the
sever's RESPONSE. The original address, with the cryptic name of "Uniform Resource Locator"
(URL), is the cause of all of the snickering. Beyond the domain name part (www.whatever.com),
it's often a mess of symbols and strange acronyms sometimes stretching beyond the width of
your screen. This not only gives geeks fuel for religious rants, but makes the address
bar practically useless for managing addresses.
It's true that the URL is one of the basic foundations of the web, and a critical component
of the browser-server "API". But, it's also visible to the end user, and anything that
users can see we should try to make, you know, usable. That's why all of the addresses of
this website have human-readable, friendly names, as far as the standard will allow. Check take
a look at the address bar right now: you're on robbyslaughter.com, under the musings heading,
reading about "who-cares-how-this-website-was-built". This is clear to the computer and pretty easy
to understand for the user as well.
As with all technical systems, there are compromises. Spaces are not permitted in URLs, and
underscores are tough to read next to the underlines of hyperlinks, so I use hyphens to
separate words. There's no need for those pesky ".php" or ".html" or ".aspx" extensions,
so I leave them out. The key exception is downloadable content, such as images. Some
operating systems don't play well with hyphens, so these files are named using underscores.
Finally, because domain names are always in lower case letters, I keep every other part of the
address in lower case letters as well. You can tell a lot about what you are going to see before
you see it, even if you are coming from another website entirely.
How This Website Was Built
I am not going to tell you. Maybe it's a database-backed monstrosity running Oracle 9i and
Java Servlets. Maybe it's all Perl and flat-files. There could be an old Apple
Powerbook running WebObjects, or an ancient IBM PC Jr. with a custom-built HTTP server
creaking along in GW-BASIC. I swear I'll never reveal the secret.
The point is, it doesn't matter to you, the user of the site. You shouldn't need to concern
yourself with how any website was built unless you are building upon it directly. Other users should
not have to wade through extra junk in the address bar just because it makes the
web developer's life easier. The API should be hidden again, just like in the glory
days of old.
###
Further Reading
Readability, Uniqueness, Hackability and Meaning in URL Design. An article by
Andrew Ingram on URL design.
