The Wayback Machine - https://web.archive.org/all/20060314210730/http://www.useit.com/alertbox/990321_comments.html
useit.com -> Alertbox -> Mar. 1999 URL as UI -> Reader comments

Readers' Comments on URL as UI

(Sidebar to Jakob Nielsen's column on URL as UI)

Linkable URLs

Glenn Fleishman writes:
Excellent set of points. As an intellectual experiment that's bringing in about $150 a week in affiliate fees, I set up ISBN.nu. The URL pattern operates the underlying redirect or price comparison engine. Other bookstores have "short codes" that can be used after an ISBN to redirect to their page. What's odd is that I've done this whole site with about 40 hours of programming, maintenance, and thinking (since about September). However, only Amazon.com makes it relatively easy to get to the single most widely known and only unique item on a book: the ISBN.

Barnes and Noble has ISBN.com registered, but hasn't deployed it yet.

Jakob's reply: This same principle applies to many other types of sites beyond bookstores: Make it easy to link to your site in systematic ways so that server-side programs on other sites can computationally generate links to specific services on your site. As another example, a map site should use a simple format for specifying an address in the URL to link to a page with a map showing that address.

Securing Double Domain Registrations

Petri Aukia writes:
An option you forgot to mention is that of registering both in the .com and the local foreign root. This has several advantages, and only a nominal added cost:

Jakob's reply: Excellent advice. In the beginning all the domains can be aliased to the same server, and once localized content is available in various countries, the appropriate domains can be switched to a local server.

Several readers commented on the strict (i.e., difficult) policies used to administer domain names in many countries. The bureaucracy makes it so difficult and time-consuming to register a country-specific domain that many people give up and go with .com instead. This observation should be a wake-up call to these countries: if you want to remain an equal part of the Internet, you need better customer service for domain registration. On the Internet, people can go anywhere they please, so local monopolies can't be too arrogant.

Elan Freydenson writes:

Two additional tips to increase usability of URLs.
  1. Register domain aliases that abbreviate long domains, especially for brands often abbreviated. For instance, Barnes & Noble, in addition to www.barnesandnoble.com has www.bn.com and www.barnesnoble.com.
  2. Create aliases for typos since users often mistype URLs. I have seen users type ww.useit.com and wwww.useit.com. Both URLs should take users to www.useit.com and maybe notify them of the redirect.

Jakob's reply: Wow, I can get to Barnes & Noble without having to type half a novel for the domain name. Maybe I will buy from them now that I can reach them with two keystrokes :-)

It is indeed a good idea to have domain aliases. But the example of Barnes & Noble also indicates the need to pick a single one and make it the primary one that is promoted and shown on the site. I simply think they picked the wrong one: nobody can spell www.barnesandnoble.com and it's awkward to type. By all means, keep the long domain alive, but start promoting www.bn.com as the "main" domain. A change in primary domain could be part of a makeover into a sleek and fast service (we can always hope).

Ambiguity Is Bad

Jay R. Ashworth writes:
You suggest that ambiguity is a Good Thing in addresses. I must disagree, I'm afraid. If it's ambiguous, it's no longer an address. Pretty much the entire point of an address is that it is not ambiguous. on a related point, you're invited to note that the domain name of a system is in fact not case sensitive, regardless of whether the web server on that system treats the remainder of the URL with case sensitivity or not.

Spelling checking webservers are a good idea, but only if the implementor of the spell-checking algorithm (or the designer of the website) have taken sufficient pains to minimize ambiguity in the namespace. This is especially true when the URL doesn't point to a page, but rather a program -- and the stakes are higher if you get it wrong.

This is akin to naming systems for, e.g., email accounts that use a first initial and a last name. I agree wholeheartedly with the person who noted somewhere that the best naming convention for email addresses is random.

That way, when I send a steamy love note to Jane Smith at borax.com, it doesn't accidentally end up in the mailbox of John Smith at borox.com, the company whose name I actually typed. Or at least, the odds are less. For that matter, what happens to Jane when BoraxCo hires John?

The point is, of course, that systematization can often cause as many -- or more -- problems as it solves, and deeper than normal analysis is very useful.

The fundamental underlying concept to my point of view is that there are engineering rules and reasons for the design of the domain name addressing system, and the fact that current browsers make it easy to flout those rules and treat addresses (which must be unique) as names (which commonly are not) is not remotely sufficient reason to break those rules.

Yes, search engines and directories, and whatever will supplant them, are excellent tools for finding things. But those search engines must return some address that the browser can use to find the desired page. If you introduce ambiguity into the addressing scheme itself, then what can that search engine return?

Jakob's reply: I agree that the machine-level addressing scheme has to use unique addresses for every accessible object. But I prefer separating the machine-level addresses from the human-level addresses. Humans are very good at tolerating and resolving ambiguity.

For example, terms like "Mother" and names like "Bob" are very useful and a much nicer way to refer to people than their Social Security Number or other unique identifier. Sometimes, the person you are talking to has to disambiguate a name by asking a question like "which Bob are you talking about?", but usually it is clear from the context. You don't need to consider all Bobs in the world, only the ones that you both know and who could have done the thing you are currently discussing.

Spelling checkers and mechanisms for resolving ambiguous names should both take proper precautions to reduce the consequences of making a mistake. Error-correcting dialogues are a classic topic in user interface design, and the traditional guidelines seem to apply well to the Internet:

In the email example, the cost of sending to the wrong person would be high, so the system should confirm the interpretation of the action and possibly show a photo of the recipient (thus using a different modality for the confirmation than the verbal input received from the user - of course, if the user had picked the recipient from an image, then the confirmation should display the person's name instead).

In contrast, going to the wrong Web page has a small cost since the user can always back out and ask the system to "show me the other possibilities instead." This approach is taken by the Google search engine with its "I Feel Lucky" button (which takes the user directly to the best search hit without showing the full results listing - if the user was "unlucky", then the only cost is the need to click the Back button and use the normal search command instead).

Case-Sensitive Cookies

Joshua Yeidel from Washington State University writes:
One quick point on case-sensitivity:

It turns out that cookie string-matching is case sensitive in the two major browsers. If the webserver is case-insensitive, a user who types in a mis-cased URL will get his page, all right -- and a new cookie (e.g., he is treated as a new user). If the case of links within the site is not uniform, he can be switched from cookie to cookie -- not what he (or the programmer) have in mind!

This is totally aside from the cookie/privacy runaround.

Jakob's reply: What stupidity. We don't need any more case-sensitive computers. It is now several decades since research on human errors proved the prevalence of description errors where people easily confuse two situations that are virtually identical except for a small difference. Early text editors were notorious for binding different commands to, say, u and U, and users frequently issued the wrong command because they confused the two.