Sidebar to Jakob Nielsen 's column on URL as UI .
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.
http://isbn.nu/ISBNNUMBER redirects by default to Amazon.com via my affiliate code.
http://isbn.nu/ISBNNUMBER/price generates a price comparison
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:
- Many Americans are unaware of the hierarchical namespace, and consider the second level domain name sufficient and unique.
- If your business grows to accommodate foreign customers, a local OR .com is a sign of stability -- albeit in a perverse way. The guys at
www.solid.fi needed a .com address, but by the time they realized this, it was already too late.
- Many countries' administrars are much more strict about domain names and take longer, require more money and more documented proof of ownership of name. Thus getting a .com to start with enables a quick bootstrap with a planned switch to a future country domain.
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.
- Register domain aliases that abbreviate long domains, especially for brands often abbreviated. For instance, Barnes & Noble, in addition to
- Create aliases for typos since users often mistype URLs. I have seen users type
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:
- if there is only one likely interpretation, then simply act on that interpretation unless the consequences of making a mistake are very high
- if there are several likely interpretations, or if an error would be very costly, then present the most likely interpretations to the user and allow him or her to choose from the list (making a choice from a small list is much easier than having to specify something from scratch)
- if errors would be extremely costly, then present a confirmation dialog that rephrases the requested action and its outcome in different terms and asks the user to confirm it
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).
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.
Share :Twitter | LinkedIn | Google+ | Email