As a gateway to everything on the Web, URLs form an important part of the user experience. One of the many issues bandied about by Web developers is providing user-friendly URLs that are both friendly to the eyes and the fingers while typing. This article explores the issues surrounding this subject and some possible solutions. Why? The concept of providing user-friendly URLs has been around for quite some time, but some developers still seem to miss the point. The basic idea is to provide easier-to-understand Web addresses, which offer the following benefits: Easy to communicate and remember: Current or potential customers can easily remember the address for personal use or distributing via word of mouth, e-mail, and so forth. Short enough to be pasted: This is a facet of communication -- the address should be short enough to be pasted in an e-mail without wrapping. The address is often mangled when/if it wraps, leaving the user to reconstruct it. Easy to guess: Users should be able to discern an address (within reason) by what they are trying to do. A good example is the news section of the Google site; you can get to it by adding news to the Google address like this www.google.com/news. Along the same line, the book section of Amazon.com is easy to access with the address www.amazon.com/books. Presentable: The URLs should be short and legible enough to appear in company brochures and so forth. Easy to type: The address should be easy on the fingers when typing into the address area of a browser via a conventional keyboard or mobile device. The length of the address will be a major issue with mobile users who often work with limited input devices. It's simple to apply these guidelines to static page filenames that you can control via URL mapping, but it's a bit different handling dynamic pages. I'll examine URL mapping first. Mapping existing pages URL mapping allows site developers or administrators to create constant user-friendly URLs and map them to existing Web pages. Most Web platforms provide this functionality as a standard feature. Basically, you point a friendly URL to an existing site path. For example, you may map the following lengthy address: http://www.examplesite.com/main/shopping/products/books/sale This lengthy address may be mapped to a shorter, friendlier address like this: http://www.examplesite.com/books/sale This functionality is readily available in products like IBM WebSphere with its administration tool; ASP.NET 2.0 provides mapping functionality via configuration files; Apache provides URL redirection, and so forth. The trickier aspect of providing friendly URLs occurs when you're working with a dynamic address. Dealing with dynamic content Page generation is a common feature in today's Web, as sites often utilize backend databases to deliver content that is constantly changing. This is a necessity to give users timely and up-to-date information, but the addresses for the dynamic content is often overwhelming. A good example is the URLs spit out by Lotus Domino. The following URL points to a book on the IBM site (which is using Domino): http://publib-b.boulder.ibm.com/Redbooks.nsf/9445fa5b416f6e32852569ae006bb65f/7a98d2e4b033351c85256a50004af2fc?OpenDocument Do you want to try to remember that address? While it may not be necessary to provide a friendly URL for this address, there are often times when you want to shorten and decipher an address so it is friendly. These addresses are often called dirty URLs because they include data or commands that could be exploited. URL rewriting allows you to hide complex Web addresses. It is the process of intercepting an incoming Web request and redirecting the request to a different resource. A challenge with implementing URL rewriting is the amount of time it takes to do it right. You may develop and include rewrite functionality in your application or utilize existing solutions. The mod_rewrite module is available for Apache. It provides a rule-based engine to rewrite requested URLs on the fly. With ASP.NET, you may develop your own or use a third-party solution like ISAPI_Rewrite, IISRewrite, or PageXchanger. This is only a small sample of the current market of Web platforms. Using a service Another approach to simplifying Web addresses is using a third-party service such as TinyURL to shorten it for you. As an example, I entered the TechRepublic.com address on the site, and it provided this simplified URL for it: http://tinyurl.com/39ty44 http://snipr.com/1na6h It reduced the size from 28 characters to 24. It's not a big deal in this case, but it could be beneficial for more lengthy addresses. I dislike using this type of service because it introduces a dependency on a third-party service that could easily disappear in the future. Also, it could easily be compromised and send users to other destinations. Transparency On the other side of the fence are developers clamoring that URLs should not be hidden so users know exactly where they are going when selecting a link or entering an address. That is, friendly URLs often hide the ultimate destination from users. With third-party services, this can be exploited to send users to spam or malware sites. I tend to favor friendly URLs as long as they are implemented as part of the application via redirection or rewriting, but I stay away from third-party solutions. Where are we going? Web addresses are an important aspect of any business, just as important as a telephone number as people expect an easy way to retrieve more information online. One problem with these addresses is often their length and wording (or lack thereof), so friendlier URLs may be provided via redirection or rewriting to simplify the process for the user. Do you utilize friendly URLs in your applications? If so, how do you implement them? Share your thoughts on the forums.
