Help Expose the URLs that Suck!

Something that would be fun would be to see a list of the top 10 worst designed URLs on the web, a.k.a. URLs that Suck! You know the type, you cringe when you see ‘em, especially if you frequently use their site.

So I’m calling on you to help in this quest. If you see a really bad URL, either place a comment on this page, or better yet, tag it with the following on del.icio.us:

urls-that-suck

If you want to tag a specific URL, please do that. But if you want to indicate the entire site’s URLs suck then tag their home page as well! Tag as many of a site’s different types of URLs that suck , but be fair to the site and only tag one of each type as we don’t want to overrepresent the suckiness of a site’s URLs.

And what’s more, tell your friends about it. It’d be great to get an army of URLians to keep an eye out for those really horrific URLs. Together we can shine a light on these abominations and give their owners a reason to bow their head in shame! ;-)

As soon as I get a statistically significant sampling[1] of sucky URLs, I’ll announce my pick for the Top 10 “URLs that Suck” Awards; probably at the end of 2007, but maybe sooner. I’ll also honor the top ten contributors and as well showcase anything or anyone that’s a standout for any reason. And if anyone is so inclined, talk to me about sponsoring these awards; you know you wanna!

If you are onboard for this, please leave a comment letting us know you plan to be on the lookout. And to kickstart this, I will nominate the very first site that has some truly awful URLs that Suck!:

Amazon.com

P.S. And if they are any excellent graphic designers out there who would like to help out with the cause, how about designing some badges that bloggers could post on their website linking to this post with a catchy slogan, something like “Help Stamp Out URLs that Suck!” or “Expose Sucky URLs”, or better; you get the idea!

  1. What is a “statistically significant sampling?” I don’t know yet, but I’ll know it when I see it. ;-)

 

Posted in Call to Action, Everyone, Tagging, URLs that Suck | 5 Comments

Lessons Learned from Delicious Praise

I learned an interesting lesson about URLs and social software; change your article’s URL or publish it under multiple cases, even with 301 redirects, and you’ll end up with fragmented references.

Back in August 2005 I published the article Well Designed URLs are Beautiful on my personal blog and have since had well over 400 people tag it on del.icio.us. Unfortunately during that same time, I’d changed my blog configuration twice to improve its URLs with one more change planned. Of course for each change I made sure the old URLs were redirected with a 301. Unfortunately, these chances resulted in my article being tagged from three different URLs, and hence splitting up it’s ranking on del.icio.us three ways!

So, when changing URLs, be careful. You could harm yourself in the process.

P.S. As an aside, this speaks sadly to ones ability to reorganize a poorly organized website, notwithstanding the fact that Cool URIs (aren’t supposed to) change. I can understand why del.icio.us and others don’t automatically test their links for 301s on an ongoing basis because of the resources required, but delicious and others could offer a “check me” test for links. This would even give them a legitimate reason to periodically email their users and say “Hey, here are all the links that moved!” That email could even ask “Should we keep the changes?” to guard against spammers, though I don’t think this would be a big issue. It is hard enough to get delicious links, how would spammers get them to begin with?

Anyway, I hope to see things evolve in the future where changing links won’t be such a big issue. And yes, sometime in the reasonably near future I plan to be an advocate for some specific plans to enable this.

Posted in Call to Action, Internet Professionals, Warnings, Website Owners | 1 Comment

Proposing URI Templates for WebForms 2.0

I recently had an off-list email conversation with Ian Hickson, the editor of the Web Application Hypertext Technology Working Group specifications (i.e. HTML5 and WebForms 2.0). I was proposing to him that the current WebForms 2.0 be draft specification be amended to include a URI Template in the “action” attribute of the FORM element. Because I believe so strongly in the benefit of this proposal and because such things are inline with the Well Designed URLs Initiatitve was envisioned to advocate for, I decided to publish it to our blog and reference it in the WHATWG blog. The following is what I sent to Ian in email:

I really want to see WHATWG incorporate URI Templates for Web Form actions[1]. i.e.:

<form
action="http://foo.com/{make}/{model}/"
method="get">
<input type="text" name="make" />
<input type="text" name="mode" />
<input type="submit" />
</form>

If I type “Honda” and “Civic”, it will do a get to:

http://foo.com/Honda/Civic/

Instead of the only current possibility being something like:

<form
method="get"
action="http://foo.com/cars.php">
<input type="text" name="make" />
<input type="text" name="mode" />
<input type="submit" />
</form>

Which would produce the following for “Honda” and “Civic”:

http://foo.com/cars.php?make=Honda&model=Civic

To which Ian replied in two parts. Here is the first part:

“Why not just write a server-side redirector? That’s a trivial one to write. Four lines of code, maybe 10 if you make the recommended security checks first. You could also do it with a little bit of JavaScript.”

Unfortunately, a server-side redirector is not an appropriate solution in one case for the use-cases this proposal would address and doesn’t work for two others:

  1. Server-side redirection requires two round trips instead of one. I don’t believe any reasonably competent web architect for a high traffic site would allow a redirect for a high-traffic site. Consider any search engine such as the flagship offering for Ian’s employer; is Google likely to implement a redirect on every search request? Not likely. Server-side redirection reduces response time (by half?) and increases (doubles?) the number of concurrent requests that servers must handle. Using server-side redirection would probably also increase bandwidth requirements a measurable amount.
  2. It is not possible via HTTP to redirect the body of a POST. Consequently, the following use-case cannot be duplicated with a server-side redirect:

    <form
    action="http://www.myblog.com/{topic}/"
    method="post">
    <select name="topic">
    <option value="first">My 1st Post</option>
    <option value="second">My 2nd Post</option>
    <option value="third">My 3d Post</option>
    </select>
    <input type="text" name="comment">
    <input type="submit">
    </form>

  3. For those wanting to create a form to direct to a website they do not control, a server-side redirect is absolutely not an option. For example, assume that I wanted to run a page on my website that lets people navigate to the topics on the WHATWG blog using a FORM with a SELECT? It’s simply not possible as WebForms 2.0 is currently specified without Javascript (addressed in a moment), but would be easily possible using a template (note I left off the closing “</option>” tags for formatting reasons):

    <form
    action="http://blog.whatwg.org/{topic}"
    method="post">
    <select name="topic">
    <option value="feed-autodiscovery">
    Feed Autodiscovery
    </option>
    <option
    value="text-content-checking">
    textContent Checking
    </option>
    <option value="checker-bug-fixes">
    Bug Fixes
    </option>
    <option
    value="significant-inline-checking">
    Significant Inline Checking
    </option>
    <option value="charmod-norm-checking">
    Charmod Norm Checking
    </option>
    <option
    value="proposing-features">
    Proposing features
    </option>
    </select>
    <input type="submit">
    </form>

  4. My belief is having this capability would encourage a lot more linking of this type between pages on the web.

So yes, server-side redirection is possible in some cases but by no means all, and for those cases where it’s possible it is not optimal.

Moving on the Ian’s suggestion to use “a little bit of JavaScript” to meet this use-case, I will admit it is possible to use JavaScript but these are the drawbacks in viewing JavaScript as the solution for this use-case:

  1. JavaScript is simply not allowed in a wide variety of web applications such as wikis, forums, and other sites that solicit community content although many of these do allow HTML elements such as FORM.
  2. Some users disable scripting on certain sites, often by decree of their employers.
  3. Javascript’s cross-browser compatibility issues make it less reliable and people are far less likely to depend on it when money is at stake, and forms are frequently used in those contexts.
  4. “User agents with no scripting support” from Section 1.3 Conformance Requirements of the Web Applications 1.0 Working Draft (HTML5) that incorporates WebForms 2.0. Need I say more?
  5. Declarative code is far easier to debug than procedural code.
  6. Far more people know HTML than JavasScript given the much greater skill required to master the latter, and that is unlikely to change.

It’s interesting to note that in the preface to the introduction for Section 3 of the WebForms 2.0 Working Draft of 12 October 2006, the following note is made about how everything that repeating form controls offers can already be done in JavaScript and the DOM. The mere fact that they went to the trouble to include something as complex as repeating controls into HTML5 when it can be done with JavaScript and the DOM implies that well-known patterns in web architecture are better implemented declaratively instead of via JavaScript and the DOM:

Occasionally forms contain repeating sections. For example, an order form could have one row per item, with product, quantity, and subtotal controls. The repeating form controls model defines how such a form can be described without resorting to scripting.

Note: The entire model can be emulated purely using JavaScript and the DOM. With such a library, this model could be used and down-level clients could be supported before user agents implemented it ubiquitously. Creating such a library is left as an exercise for the reader.

So yes it is possible to use JavaScript in many cases, but it no where near optimal. Javascript should not be considered the solution for as well-defined and obvious patterns such as submitting to a clean URL.

To further drive home the value of this proposal, anyone monitoring the REST-discuss list for any length of time will see that most REST experts tend toward using (what I call :) well-designed URLs, i.e. URLs where the resource is identified by path instead of query string. With WebForm 2.0′s pending support of PUT and DELETE, it would be just short of a crime not to include support for posting to clean URLs in WebForms 2.0.

Since having this discussion with Ian via email it was since pointed out to me on rest-discuss by Mark Baker that my proposal as written would break the existing web so was a non-starter. For some reason I wasn’t thinking about that, probably because I was more concerned about getting Ian (who I like to call: Mr. “No :) to agree that URI Templates were needed. Still, the solution would be simple.

What follows are my examples from above recast using an optional template attribute that would override the action attribute for WebForms 2.0 compliant browsers. This would of course require the server to accept both query string parameters and clean URLs (and hopefully do a server redirect from the former to the latter), or the submit could be implemented using Javascript for older browsers when applicable. Note that I didn’t show an example using JavaScript but, as the WebForm 2.0 spec says(that) is left as an exercise for the reader”:

  1. <form
    action="http://foo.com/model"
    template="http://foo.com/{make}/{model}/"
    method="get">
    <input type="text" name="make" />
    <input type="text" name="mode" />
    <input type="submit" />
    </form>

  2. <form
    action="http://www.myblog.com/topic"
    template="http://www.myblog.com/{topic}/"
    method="post">
    <select name="topic">
    <option value="first">My 1st Post</option>
    <option value="second">My 2nd Post</option>
    <option value="third">My 3d Post</option>
    </select>
    <input type="text" name="comment">
    <input type="submit">
    </form>

  3. <form
    action="http://blog.whatwg.org/topic"
    template="http://blog.whatwg.org/{topic}"
    method="post">
    <select name="topic">
    <option value="feed-autodiscovery">
    Feed Autodiscovery
    </option>
    <option
    value="text-content-checking">
    textContent Checking
    </option>
    <option value="checker-bug-fixes">
    Bug Fixes
    </option>
    <option
    value="significant-inline-checking">
    Significant Inline Checking
    </option>
    <option value="charmod-norm-checking">
    Charmod Norm Checking
    </option>
    <option
    value="proposing-features">
    Proposing features
    </option>
    </select>
    <input type="submit">
    </form>

So in summary I really hope that Ian, who definitely seems to be the gatekeeper for what goes into HTML5 and what doesn’t go into HTML5, can see his way clear to add this feature to WebForms 2.0. If his main issue with it is needing to have it written up for inclusion in the spec, I’m more than happy to help.

Posted in Call to Action, Framework Developers, Open-Source Participants, Potential, SoapBox, Software Vendors, Standards Participants, URI Templates, Web App Providers, Web Developers, Web Forms | 8 Comments

Intro, Part 15: About URLQuiz

As a way to gather a broad spectrum of opinion and engage the community on many different URL-related topics, we’ll be offering a URLQuiz from time to time. Inspired by and patterned after Dan Cederholm‘s very well received SimpleQuiz series, we’ll take a simple URL Design question, present a few different alternate approaches, and ask readers to weigh in on which they believe to be the best and why.

Dan proved that his SimpleQuiz was very effective at quickly emerging a consensus for a best practice when a consensus was possible. Building on Dan’s pioneering efforts, we hope to leverage his technique to address the constantly debated issues in URL Design and hopefully arrive at some consensuses of opinion on URL-relates issues ourselves.

So look for the first URLQuiz, part of an ongoing series, here at the Well Designed URLs Initiative blog in the near future.

Posted in Internet Professionals, Introduction, URLQuiz, Website Owners | 1 Comment

Intro, Part 14: About our URL Structure

 

For our web applications — our website, wiki, blog, and future forums — we chose to segment each by sub-domain; “wiki.”, “blog.”, and “forums.”, respectively. Rather than having subdirectories underneath the root of our www domain such as “/wiki/”, “/blog/”, and “/forums/”, we chose to use sub-domains to allow flexibility and maybe even scalability in the future.

Having the each application on a domain that is different from the blog and forums mean we can host on different machines and at different locations, as appropriate. However as I write this I realize that this rationale violates probably one of the most important best practices for URL Design; don’t allow your backend implementation dictate your URL structure!

It also means our URLs will be by 4 characters shorter[1] and since we chose a long domain name, that’s important. Still, there are pros and cons to both approaches and my gut tells me we’ll uncover further considerations as we continue researching this topic.

Related to this topic, we’ll discuss the URL Structure patterns for websites, wikis, blogs, forums, and other web apps in future posts.

  1. Assuming we were to continue using “www.” as a sub-domain for our main site, which itself is another topic for us to address in the future.
Posted in Everyone, Introduction | Leave a comment

Intro, Part 13: The Web Apps We Use

Here’s a run down of the web application software we are using or planning to use for the Well Designed URLs Initiative:

Blog
At “blog.” is running WordPress using Linux, Apache, MySQL, and PHP. We have direct experience with WordPress, Typepad, dasBlog, and Community Server, and among these options WordPress is definitely the best blog software for the URL Aficionado.
Wiki
At “wiki.” runs Mediawiki, also on using Linux, Apache, MySQL, and PHP, and is the same software used by as Wikipedia. Although setting up clean URLs can be a real pain on Mediawiki if you are not a regular expressions wizard, we think Mediawiki is the most mature wiki software, and nobody can debate that it has the best known user-interface.
Forums
To be at “forums.” will almost certainly run on vBulletin which also runs on Linux, Apache, MySQL, and PHP. Even though vBulletin isn’t open-source and costs US$85/year to lease[1], as users we have used practically every forum in existence and in our opinion nothing comes close to the usability and performance of vBulletin. We only wish that the vendor of vBulletin could envision a business model leveraging open-source so those who for whatever reason won’t use commercial software would be able to consider vBulletin; we think that would make the forum world a nicer place. Well that, and changing their default template; the visual layout as shipped is horrible!
CMS
To be at “www.“; we’ll probably use Drupal, Django, or similar when we get to installing and configuring it. In other words, when we really need the features of a CMS, we’ll add one. ;-)

The all the web applications we mentioned are great, and we can highly recommend them to almost anyone. The downside of using them though is being separate apps they are not well integrated. But, we’ll see what we can do about that in the future. Hopefully someone will see what a huge need and certain demand for integrating open-source web apps based on MySQL and they will solve this problem just as the WSGI team seems to be solving a similar problem in the Python web app world.

  1. Or you can purchase vBulletin for US$160 with one year of updates.
Posted in Everyone, Introduction | Leave a comment

Intro, Part 12: Major Topics from Different Angles

One of our plans is look at major topics from many different angles. Though this will allow us to revisit an issue numerous times, our main reason for covering topics in this manner is that making sure our coverage is complete and includes all references is really difficult. And we (well at least, I) have a tendency to postpone writing on a topic until I’m sure my research is exhaustive. Unfortunately, that often leads to me writing about something long after it’s relevant!

So rather then delay an important or timely topic, the plan is to both write about them numerous times with each time taking a slightly perspective and references different resources. And we plan to publish those multiple angles in the chronological of our normal blog publishing cycle.

But we also plan to maintain a section of Major URL-related Topics by consolidating the content from our numerous chronological posts on a topic and often augmenting with additional content not published during our normal blog cycle. You’ll find those pages at the following URL:

http://blog.welldesignedurls.org/major-topics/

Unlike our category pages that are generated by a SQL query from our prior posts by WordPress, we’ll actually be hand writing the content for these major topic pages. And we’ll do our best to keep those pages updated to cover our most recent research and views on the subject. In addition, we’ll reference any of our related posts and also provide quotes and links from related conversations on the Internet including those from other bloggers, mailing list archives, and online magazines.

Our goal is to make these major URL-related topic pages your most thorough, up-to-date, and hopefully concise resource on the subject. And we hope you’ll link to them if you need to reference one of our major URL-related topics when writing an article or posts for your own blog.

Posted in Everyone, Introduction | Leave a comment

About URI Templates

Probably one of the most interesting projects related to URL Design on which anyone is currently working is the URI Templates project spearheaded by Joe Gregorio of IBM. While not sexy and not something most end users will ever see, infrastructure developers writing blogs, wikis, forums, content management systems, and ideally even web servers, proxies, and routers will be able to utilize URI Templates for configuration and more. Well, once URI Templates are finalized and made an IETF standard that is.

Examples uses could include URL Rewriting Rules, URL Virtualization Configuration, REST’s Hypermedia Requirement, within future HTTP Headers and HTML LINK Elements, and even for Sitemaps (in a hopeful revision to Sitemap.org’s Sitemap protocol.) URI Templates will provide Internet professionals far more flexibility in dealing with URLs such as making it possible to employ URL Construction in a controlled manner without violating that nastly little URI Opacity Axiom.

Unlike most URL Rewriting Tools, URI Templates are very easy to use and, with the possible exception of certain esoteric edge cases that are still being finalized, accessible to mere mortals. URI Templates are certainly nowhere near as difficult as the requirement to master regular expressions and their complex interations when using Apache’s mod_rewrite and IIS’ (3rd Party) ISAPI Rewrite. Almost certainly anyone who has managed to language their own website will have no trouble at all mastering the most common use-cases for URI Templates.

URI Templates use a simple syntax where braces denote variables to be replaced when the templates are converted to actual URLs. For example, if this blog were using URI Templates to configure this page, the URI Template would most certainly look like this:

http://blog.welldesignedurls.org/{year}/{month}/{day}/{post-slug}/

When the template variables have the following values (as they do for this post):

year: 2007
month: 01
day: 03
post-slug: introducing-uri-templates

The resultant URL upon conversion will be:

http://blog.welldesignedurls.org/2007/01/03/introducing-uri-templates/

Pretty simple, huh?

However, be aware that before URI Templates can become an IETF standard there needs to be at least two interoperable implementations, if not a lot more. Mark Nottingham of Yahoo has implemented a URI Template parser in Javascript, but I don’t know for certain if that one will qualify for the purposes of standardization. Whatever the case, if you are working on any projects or products that could benefit from URI Templates I encourage you to participate in the URI working group via their mailing list and then implement the specification in your software projects or products.

Although it may appear to be a boring subject from the outside looking in, the standardization of URI Templates will be probably the most positive thing to happen for URL Design in over a decade.

Posted in Internet Professionals, Proposals, REST, Sitemaps, SoapBox, Software Vendors, URI Templates, URL Rewriters, URL Virtualization | 2 Comments

Introducing URI Templates

I decided to rename this post About URI Templates. Follow the link to see the post.

Posted in Redirects | Comments Off

Intro, Part 1a: The Unsung URL

NOTE: To see why this is labeled “Part 1a” see [1].

Although many people view the URL to be a rather obscure little creature, the URL is the arguably the most important of the web’s three essential legs; the “First Consul” of the triumvirate of web technologies; the truly unsung hero of the web.

When Tim Berners-Lee originally designed the Web, he did so by creating three core independently-specified yet inter-related technologies on top of the existing TCP/IP-based Internet. Used together, those three technologies leveraged each other to create spectacular value for the world.

The first of those three technologies, HTML, has been broadly appreciated by web developers and even lately a tremendous number of end-users for allowing them to layout text and graphics how they prefer them to be display[2]. The second, HTTP, is intimately familiar to most web users, but only as the prefix they see in countless television ads, on business cards and billboards[3], and in their web browser’s URL field as they use hypertext to navigate the web.

But whereas both HTML and HTTP are independent of the other, both rely heavily on the URL. Without the URL, HTML would have no Hypertext and HTTP could neither retrieve documents[4] from websites nor issue redirects when documents move. Berners-Lee even “canonized” the URL[5] in his 1999 Wired Interview:

“Well, the most important thing that was new was the idea of URI — or URL [it was UDI back then, universal document identifier]. The idea that any piece of information anywhere should have an identifier, which will not only identify it, but allow you to get hold of it. That idea was the basic clue to the universality of the Web. That was the only thing I insisted upon.”

But like the man behind the curtain to whom we are told to pay no attention in the Wizard of Oz, many web technologists have mistakenly promoted the notion that the URL should only be used for behind-the-scenes plumbing and thus hidden from view. Sadly, these technologists rationalize their stand by stating that mere-mortals couldn’t possibly understand URLs anyway, but nothing could be further from the truth. For this reason and more, URLs true potential has gone unfulfilled as they have been woefully under-appreciated in comparison to the power and benefits they can provide both the average web user and the web at large.

The URL, a.k.a. the URI, is more than just some behind-the-scenes, don’t-speak-until-spoken to technology. URLs provide a means to identify both concepts and tangible things and then allow related documents to be retrieved that can provide more information and/or further reference URLs. While most people think in terms of how they personally use URLs, they rarely envision the orders of magnitude of serendipitous uses by others of the URLs they assign and then publish.

It’s often said that what you don’t know can’t hurt you, but unfortunately this lack of understanding the power of the URL creates huge missed opportunity for most people. Just one simple example should illustrate this and that is the value of Google’s search engine indexer; without URLs there is no chance Google will send anyone to learn more about a concept or tangible thing that could have been made accessible by URL but wasn’t. Seeing how much money Google makes from advertisers seeking traffic to their website, it’s amazing that more people don’t realize the value of the indexable URL. But Google’s use of URLs is the mere tip of the iceberg when compared to all the serendipitous use one can receive by assigning and publishing Well Designed URLs for everything they view should be notable to others.

Tim Berners-Lee has been quoted as saying “Everything of importance deserves a URL[6] and it is our opinion that is probably his most profound statement ever. So one of the key goals of the Well Designed URLs Initiative is to right the wrong of past technologists who have been hiding URLs from the average user’s view. By elevating URL’s the significance in the minds of both Internet professionals and the masses we hope to be the catalyst for the positive change that the recognition of URL’s value will bring.

  1. This part of our introduction was published out of order hence it’s designation as “1a” instead of as “2.” During the process of writing it became clear that this needed to be said but unfortunately we had already published numerous posts that would have obviously come after this one. Ah well, that’s what happens when you start publishing before you finalize the outline. :-)
  2. Graphic designers would argue this point, but that would be nit picking for the purposes of this blog post.
  3. Albeit the trend is toward omitting and hence assuming the “http” written and spoken communication.
  4. The Weborati would correct me and say that HTTP retrieves “resources“, but why quibble over common use when this post is non-normative?
  5. My use of the term “canonized” is obviously just a bit of “dramatic license.”
  6. Actually Tim uses URI instead of URL which is his preference vs. mine. Go here to read about URL vs. URI here.
Posted in Everyone, Introduction | Comments Off

Happy New Year!

I’m taking the day off but wanted to wish everyone a Happy New Year hoping 2007 will be everyone own best year yet!

Posted in Everyone, Miscellaneous | Leave a comment

Ben Coffey and his eBook “Useful URLs”

In the hustle and bustle of these holidays, I didn’t manage to churn out all of my planned posts for our introduction series. So with nothing else to publish today it seems only fitting I introduce you to the works of someone I met recently. His name is Ben Coffey and he’s an absolutely brillant kid[1] from the U.K. who shares my passion for User-Centric User Design.

His work that I spoke of is his ebook entitled “Useful URLs” It is available for download at his website inelegant.org in both HTML and PDF formats. Further kudos to Ben for he licensed Useful URLs using a Creative Commonsby-nc-sa“ license meaning you’re free to copy and distribute it as long as you attribute him as author, you don’t use for commercial purposes, and you share any of your own modifications or additions with the same license.  Ben says that Useful URLs is a work-in-progress so he plans on updating it continuously. I’ll be sure to make mention here when he updates it, especially if he adds new chapters.

That said, Useful URLs is both a quick read and also:

Highly Recommended!

  • Sorry for calling Ben a kid, but at 23 he’s barely more than half my age, and I still feel relatively young! But the more I talk to him, the more I think I barely know half what he does, at least with respect to programming and the Internet! I’m actually afraid to talk to him about anything else for fear I’ll learn that I barely know half as much on those topics as well!
Posted in Champions, Everyone, Publications | 2 Comments

Intro, Part 11: Each Post will Identify Audience

Here at the Well Designed URLs Initiative we plan to address a wide audience and cover a plethora of URL-related topics. If it wasn’t obvious from yesterday’s post we plan to publish content for a variety of roles so we will categorize all our posts by the audience we are targeting.

Using our audience categories you can subscribe to our RSS feed then configure your feed reader to filter out all but those topics which are likely to appeal to you so as not to be overwhelmed by the rest. Some of our audience categories encompass other categories such as Everyone and Internet Professionals so we’ll plan to tag only the highest level category that applies to avoid duplication. For example, if you are a web developer you might want to filter out all but the Everyone and Internet Professionals, and Web Developers categories. Of course, if that’s too much trouble just subscribe to our entire feed and just ignore those posts that don’t interest you.

The following is the list of categories we’ve set up by audience role:

NOTE: If you read this post shortly after it is published, most of those links above will just redisplay this post. Let me explain. Because of the way our WordPress blog software works, those links would have displayed a 404 Not Found error if no posts existed for the given category. To avoid that I’ve tagged this post with all audience categories contradicting what I said above; that we would only put a post in its highest level category. Moving forward we shouldn’t need to do this again.

Posted in Conference Promoters, Everyone, Framework Developers, Hosting Providers, Infrastructure Providers, Internet Professionals, Introduction, Leading Companies, Open-Source Participants, Publishers, SEO Consultants, Software Vendors, Standards Participants, Teachers, Web App Providers, Web Designers, Web Developers, Website Owners | Comments Off

Intro, Part 10: Expect URL Design Advocacy

We’ve already said that we plan to question the status quo, but we want to make that point even stronger; we plan to advocate for positive change.

At least one person has already suggested that our activities would be best accepted if we, like the microformat initiative aimed to merely “uncover what already works” on the web and then dispassionately documented it for discussion. Although we do plan to research and then explain current patterns and best practices we don’t plan to make those our only activities; we didn’t pursue this merely to be the scribes of current behavior.

Instead, we are promoting this initiative because we envision specific solutions to current URL usage problems, and we believe those solutions will significantly improve both the web’s accessibility and user’s experience with the web. It is this vision that motivates us to pursue this path even if it means that at times it might be an uphill battle.

But what specifically do we plan to advocate? To give you an idea I prepared the following chart, organized by who will be the target of our advocacy:

To Whom? Plans for Advocacy
End Users
Web Developers,
SEO Consultants,
Web Designers
All Internet Professionals
  • Educate users on URL concepts
  • Promote User-Centered URL Design
  • Recommend URL Virtualization technologies
  • Promote strategies for avoiding and resolving Broken URLs a.k.a Link Rot
  • Advocate use of new URL-related Metadata in web pages
  • Always using Resolvable URIs a.k.a. URLs whenever URIs are needed
  • Utilize Web Request Containers where applicable
  • Recommned URL Interfaces for Sitempas, URL Rewriting and REST Service Discovery
  • Think in terms of providing everything a Permalink URL
  • Envision the URL as the Universal Identifier
  • Follow all REST Principles where appropriate
Website Owners
  • Expose users to URLs directly and indirectly
  • Adopt User-Centered URLs
  • Deprecate use of non-user friendly URLs
  • Use URL Virtualization technologies
  • Incorporate Web Request Containers into your website
  • Ensure your web pages incorporate new URL-related Metadata
  • Adopt strategies for avoiding and resolving Broken URLs a.k.a Link Rot
  • Make all HTML elements with ids addressable using URL Fragments
  • Deploy URL Interfaces for Sitemaps, URL Rewriting, and REST Service Discovery
  • Design your URLs to be Universal Identifiers
  • Ensure all Indivisible Content is an Addressable Resource
  • Provide Permalink URLs for all resources
  • Expose information and do so via RESTful interfaces
Web-app Software Providers,
Framework Developers,
Infrastructure Developers
  • Adopt URI Templates for URL configuration
  • Promote User-Centered URL Design
  • Deprecate use of non-user friendly URLs
  • Develop URL Virtualization technologies
  • Leverage new URL-related Metadata
  • Implement URLs as Universal Identifiers
  • Adopt strategies for avoiding and resolving Broken URLs a.k.a. Link Rot
  • Incorporate Web Request Containers into your software
  • Ensure all URIs used are Resolvable URIs a.k.a URLs
  • Leverage URL Interfaces for URL Rewriting and REST Service Discovery
  • Make Permalink URLs for every indivisible content element
  • Provide technology for simplifying RESTful development
Hosting Providers
  • Promote User-Centered URL Design to Customers
  • Provide URL Rewriting functionality on all the platforms offered
  • Use URL Interfaces for URL Virtualization and offer URL Virtualization services
  • Offer services for RESTful hosting
Web Browsers
  • Expose users to URLs directly and indirectly
  • Support URI Templates where applicable
  • Expose all content ids as addressable via URL fragments
  • Think of URLs as Universal Identifiers, implement accordingly
  • Incorporate technologies for resolving Broken URLs a.k.a. Link Rot
  • Expose new URL-related Metadata via “View Source“-like features
  • Implement usable interfaces for Web Request Containers
  • Provide support for URL Interfaces
  • Present user interfaces for calling RESTful services
  • Provide a “View Source” for User-Centered RESTful Services Discovery
Standards Participants
  • Promote User-Centered URL Design
  • Incorporate URI Templates into Standards
  • Advocate use of URL Virtualization
  • Accept and standardize Web Request Containers
  • Promote strategies for resolving Broken URLs a.k.a. Link Rot
  • Accept and standardize new URL-related Metadata
  • Promote URLs as Universal Identifiers,
  • Specify all URIs should be Resolvable URIs a.k.a URLs
  • Recommend URL Interfaces as the solution for Sitemaps
Leading Companies
  • Set a good example regarding User-Centered URL Design
  • Promote User-Centered URL Design
  • Deprecate use of non-user friendly URLs
  • Adopt strategies for resolving broken URLs
  • Publish URL-related Metadata about your pages
  • Consider your URLs to be Universal Identifiers
  • Incorporate use of Web Request Containers, where applicable
  • Make all HTML elements with ids addressable using URL Fragments
  • Expose and Document URL Structure, where applicable
  • Publish URL Interfaces for REST Service Discovery and Sitemaps
  • Make Permalink URLs for every indivisible content element
  • Expose information and do so via RESTful interfaces
Conference Promoters,
Educators
  • Promote User-Centered URL Design
  • Incorporate User-Centered URL Design into curriculum
  • Teach the concept of URLs as Universal Identifier
  • Provide education on User-Centered URL implementation
  • Teach URL Virtualization concepts and URL Rewriting
  • Educate about Broken URL a.k.a. Link Rot resolution strategies
  • Advocate use of new URL-related Metadata and URL Interfaces
  • Educate on the use of Web Request Containers
  • Teach people the concept and use of Permalink URLs
  • Advocate teaching as part of Web Science
  • Teach URL Design as a critical component of Web Design
  • Promote implementation of properly RESTful interfaces
Content Publishers
  • Publish on all User-Centered URL Design and related topics
  • Promote the use of properly RESTful services

Although this list of objectives is significant, it doesn’t represent the entirety of what we hope to accomplish via this initiative. Stay tuned.

Posted in Everyone, Introduction | Comments Off

Merry Christmas and Happy Holidays

I’m taking the day off to observe the holiday that millions of people observe worldwide. Whether you celebrate Christmas or observe some other holiday, it’s my hope that you and your loved ones are happy and healthy this holiday season. See you tomorrow.

Posted in Everyone, Miscellaneous | Comments Off

Intro, Part 9: Questioning the Web’s Status Quo

Yesterday we said we plan to make recommendations. That may have concerned some, especially those who are involved in the standards process. But don’t worry, we won’t make them in a vacuum; we intend to engage everyone interested to participate and influence the creation of the recommendations, especially the leading experts in the field of web architecture. We pledge to evaluate everyone’s input objectively, and incorporate input without prejudice.

What’s more, we aim to respect all the standards created by recognized standard’s bodies such as the Internet Engineering Task Force and the World Wide Web Consortium. Further, we plan to respect the spirit of all standards and acknowledged axioms.

Though we did expose a long list of agenda items, some of those may fall by the wayside once we engage the community. Those were our ideas but as we are not perfect some of them may not be either. Our goal is to make things better, not worse, and intellectual honesty is our only ally in addressing reality.

But that doesn’t mean we intend to always be non-controversial. No, we intend to push the envelope and lead some people out of their comfort zone. Like a child constantly asking “Why?” we plan to challenge conventional wisdom. We want to ensure that the axioms and standards defining web architecture are still based on actual requirements. We don’t want to see progress impeded simply because the framers of the web shared the universal human trait of being usable to foresee all future innovations and their requirements.

Though potentially disruptive, we think our willingness to question prior assumptions will ultimately lead to a better web for all.

Posted in Everyone, Introduction | Comments Off

Intro, Part 8: Expect to see Recommendations

One of our main goals is to publish an evolving list of URL Design and related recommendations that the world of web architects, website administrators and web developers will respect and embrace. Our recommendations will include advocacy for, but not limited to the following:

So you see, we’re planning to bite off an awful lot here but we think by doing so we’ll benefit all web users. Didn’t realize that URLs had so much to room for improvement? Stay tuned…

Posted in Everyone, Introduction | Comments Off

Intro, Part 7: Conventions, not Constraining Requirements

There is a belief among the people who guide the web’s technical architecture, people I like to call the “Weborati“, that as few constraints as possible should be placed on web publishers and web users. This is referred to as the Principle of Minimal Constraint. An example of such a constraint is the Robots Exclusion Standard that uses the “robots.txt” filename to inform search engines of pages to avoid. Because of this robots.txt “standard”, a web publisher can’t use a file named robots.txt in the root of their website for any other purpose besides the Robots Exclusion Standard without disabling their ability to inform web robots which files to ignore.

Although using the Well-known Name “robots.txt” was justified by Roy T. Fielding, use of well-known names such as those required by P3P and Favicon continue to be a sore point among the Weborati. However, contrary to some initial concerns, we here at the Well Designed URLs Initiative agree that using well-known names is A Bad Thing(tm) in Web Architecture. So let me state for the record: It is not our intention to encourage any new well-known names.

On the other hand, we do intend to recommend convention. Good conventions can increase productivity immensely by eliminating the need to evaluate alternate yet arbitrary choices. One such convention is the multi-column web page layout complete with a menu along either the top or one of the side columns. Prior to that established layout, right for many websites but not all, web designers spent considerable time evaluating different layouts. I, for one, am glad to have gotten past that stage.

Good conventions can aid common understanding if those conventions are widely used. For example the Internet sub-domain naming convention of “www” has helped many non-technical people recognize a web address on a business card, a TV advertisement, and on the side of a bus.

And good conventions can spawn an entire industry segment, unleashing a completely new layer of value. When Jesse James Garrett published his now well-known essay entitled “Ajax: A New Approach to Web Applications,” he recognized a design pattern that many people had been using in obscurity, and that recognition catalyzed a mega-million dollar segment of the web development industry.

Though we could only hope our efforts have the same effect, we do hope to influence how people perceive and use the lowly URL. For example via research and a consensus of opinion, it would be greeat to establish a widely used convention for how multi-lingual websites design their URLs.

Although conventions can be constraining, conventions are not in and of themselves requirements. Just as it is well known that “www” probably means “website”, it is not a requirements and the fact many websites use alternate sub-domain names prove it. For example, “newyork,” “london,” and “paris” could all easily be used as sub-domain names for relevant websites. Or a website can easily use no sub-domain at all!

So it is our hope we can get people from the Weborati down to the non-technical website owners to appreciate and embrace numerous new URL conventions in the future.

Posted in Everyone, Introduction | Comments Off

Intro, Part 6: What makes us URL Design Experts?

So what makes us “the” expert on URL Design as we are not (yet?) associated with any standards body like the W3C or the IETF? Nothing really, other than we have a keen interest in the URL Design and its ramifications, and are proactively devoting time to this initiative.

For me personally, I’ve spent lots of time spent studying any and every bit of writing I could find regarding URL Design, and even more time spent pondering the subject and writing about it. Lastly, it was my writing about “Well Designed URLs” and other’s subsequent interest that lead me to start this initiative.

Plainly put, I and the others involved are the first to take significant initiative to study and then advocate for User-Centered URL Design. We feel so strongly about this that we believe it should be taught in universities as part of the new field of “Web Science.”

As with any body of wisdom it has to start somewhere, and because no one else was focusing on URL Design, we decided we would start I here; it’s that simple.

That said, if you feel that you have something significant to contribute to URL Design then by all means join us and become one of the experts yourself. And if we do a good job, we may become recognized by the W3C and/or the IETF, and that will make us the experts. :)

Posted in Everyone, Introduction | Comments Off

Intro, Part 5: Who is “we?”

To this point, I have mostly written in the collective as opposed to the personal; “we” instead of “I.” However, right now “we” is officially “me.” Several others have signing on to indicate they believe in our mission, and I’ve discussed concepts directly with at least one other person, but at the moment no one has “officially” joined me in this initiative.

However, I hope to revise the situation in the near future so that “we” is officially many people. I’d love to have some company here; I didn’t start this project to be “all about me.” Instead I hope to leverage the research and experience of the many smart people who have contributed to the web in one form or another over the more than a decade of its existence. If all goes well, there will be more than just me blogging here about URL design before long.

So I write in the collective because I expect that like-minded people will join me in this initiative, and by self-selection they will identify with what I’ve published thus far. Since I expect this introduction to live on for a long time, ultimately “we” will refer in a retroactive sense to all of those involved, not just me.  That’s my hope, at least. :)

Posted in Everyone, Introduction | Comments Off