That has a fix for ALL the problems, such as the actual url postback problem, the no events firing problem, etc???

Thats all I ask for! But it seems to not exist!? How is ASP.NET 2.0 going to be with URL rewriting?

eron19--

Regarding this...

eron19 wrote:

That has a fix for ALL the problems, such as the actual url postback problem, the no events firing problem, etc??? Thats all I ask for! But it seems to not exist!? How is ASP.NET 2.0 going to be with URL rewriting?

...my two cents is...

...it sounds to me like "URL Rewriting" is generally a bad idea...

...this is all just my opinion...

...I cannot think of one place where it is NECESSARY to do so...

...I file this sort of idea under the heading of "isn't programming simple, clear, working, maintainable, extensible code difficult enough?"...

...talk about "reaching behind the user's back"...

...whatever happened to establishing a sensible, logically-oriented, physical folder hierarchy???

no good place to use URL Rewriting??

how about rewriting a url like this http://mysite/blog/my_post_title.aspx to this http://mysite/blog/post.asp?id=23

Is making more friendly urls for your users not worth it?

crpietschmann---

Regarding this...

crpietschmann wrote:

....no good place to use URL Rewriting?? how about rewriting a url like this http://mysite/blog/my_post_title.aspx to this http://mysite/blog/post.asp?id=23 Is making more friendly urls for your users not worth it?

...note that I said that do not think I can find a case where it is NECESSARY...

...in your example above, I think this holds-- it is not necessary... that is, the application would be just fine if it were not done...

...I am not sure that it is "worth it" or not... and I would argue that it is NOT worth...

...also, I would argue that, in the example above, it would be just as easy to write the site to ACTUALLY write the URL the way that you want it, with the use a query string veriable, rather than "faking it"... in fact, it looks to me like it would, in fact, be EASIER to actually write the URL that way than to have to rewrite it as such...

...again, I would suggest that if VersionA were the actual URL and VersionB were the desired URL, then the fact that VersionB is not the actual URL is simply a by-product of a shaky design and refactoring would be in order...

...finally, I will say that aside from the starting page of a site, such as http://www.ASP.net , URLs should never be designed to be "user friendly".... we, as developers, pay much more attention to URLs than the common enduser... I think it is VERY bad practice to expect an enduser to know what a given URL or query string means... I think that endusers should never be expected to decipher or manipulate URLs directly... that is the job of navigation controls, menus, tabs, and the other UI elements... once a user gets to the starting page of an application, the enduser user should be able to navigate the site using just the provided navigation controls.... the URL should, generally, be ignored by the enduser...

Now, that is just MY opinion and I respect those of others... in fact, I do understand why people think URL rewriting is a good idea but I do disagree with such thinking...

IMHO.

Thank you.

I can find many cases where it is NECESSARY, the most important probably is: SEARCH ENGINES.

Why Search Engines?
Because they need the simple urls that many advanced applications can't (or is not built to) deliver in order to index the website correctly. This is a very important factor if you have a large corporate website with lots of information that you need people to find by searching on popular search engines.

And I think the ordinary Joe would remember www.mysite.com/thefolder/thepage.htm than www.mysite.com/load_doc.aspx?id=28181&fid=381 (as an example).

Cheers

phalange--

Regarding this...

phalange wrote:

...I can find many cases where it is NECESSARY, the most important probably is: SEARCH ENGINES...

...you are absolutely right and I am stand corrected. I did not think of that; but, I should have. Thank you pointing it out. I agree completely that it is important to make one's site "search engine friendly". That is a good point.

However, does this mean that URL rewriting is "necessary"? No, it does not.

Here is an interesting point. It is known that search engine crawlers have trouble with dynamic pages. Fine. However, this may actually imply that it is also true that search engine crawlers have trouble with dynamic URL generation.

The question becomes-- Do search engines "like" dynamic URL generation as done by URL rewriting?

I don't know if search engines "like" URL rewriting. AFAIK, it has not been shown that search engines "like" dynamic URL generation, as is done by URL rewriting.

I still believe better solutions exist. For example, one can avoid using the query string entirely, which is necessary (in fact) for all but optional/low-security data. Another approach is, as I have suggested, to devise a more sensible logical and physical layout of the site, along with a better mechanism for creating and serving dynamic pages. Lastly, and perhaps the best solution,(which is perhaps a candidate for widespread industry adoption), is to follow the leader and use Google SiteMaps , https://www.google.com/webmasters/sitemaps/ , which may very well obviate this entire matter and be the best way to go.

Regarding this...

phalange wrote:

...I think the ordinary Joe would remember [Example1] www.mysite.com/thefolder/thepage.htm than [Example2]  www.mysite.com/load_doc.aspx?id=28181&fid=381 (as an example)...

...I see your point. I agree that the Ordinary Enduser would probably remember Example1 more easily than Example2. However, my point is that a web developer should not hope/ask/require/suggest/plan that the Ordinary Enduser will remember any URL except that of the home page of a given site. Therefore, if the point is that "making a URL easier to remember is a reason that shows it is necessary to do use URL rewriting", I disagree.

Also, as a side-note from a security perspective, let's all remember that "security through obscurity" is NOT "security"; it is merely kidding oneself. (I don't make this point directly to you, phalange. I am just mentioning it in general because sometimes people suggest that security-through-obsucurity is a good idea. In fact, it is a false sense of help.)

Finally, I will point out that I have posed some alternative solutions to the URL-Rewriting solutions. These alternatives may or may not be "great"; but, they do exist. However, as the title of this thread suggests, it looks like there may be no real URL-Rewriting "solutions" at present, which, obviously, is yet another good reason not to implement URL-Rewriting.

Regardless, you make some good points and I appreciate the dialog.

Thank you.

mkamoski wrote:

...note that I said that do not think I can find a case where it is NECESSARY...

I cannot disagree with you more. Here is my blog on the subject "Well Designed URLs are Beautiful!" and a follow up of sorts "All I want for IIS7 is my mod_rewrite!"

mkamoski wrote:

The question becomes-- Do search engines "like" dynamic URL generation as done by URL rewriting? I don't know if search engines "like" URL rewriting. AFAIK, it has not been shown that search engines "like" dynamic URL generation, as is done by URL rewriting.

The answer is, search engines can't know when a URL is rewritten.  They find the URL on a page someone in the world wide web, it looks just like any URL to a static page, and when the crawler makes a request of the URL from the web server, the server returns an HTML page (or something else like a GIF, JPG, PDF, etc.) back to the crawler. In that context the web server is a black box; the fact the page or the url has been programatically composed is of no concern to any user agent including crawlers.

mkamoski wrote:

...I see your point. I agree that the Ordinary Enduser would probably remember Example1 more easily than Example2. However, my point is that a web developer should not hope/ask/require/suggest/plan that the Ordinary Enduser will remember any URL except that of the home page of a given site. Therefore, if the point is that "making a URL easier to remember is a reason that shows it is necessary to do use URL rewriting", I disagree.

Saying "easier to remember" does not really frame the issue as best it could.  Better to say "easier to discover."  For example, at my website I have the following URL where we have a Guide about .NET Obfuscators:
   
   http://www.howtoselectguides.com/dotnet/obfuscators/

If someone was on that page and wanted to see if we have a Guide for Build tools, Deployment tools, or Documention tools, they could "hack" my URLs and type the following (we don't yet have these Guides but will soon):

   http://www.howtoselectguides.com/dotnet/build/
   http://www.howtoselectguides.com/dotnet/deployment/
   http://www.howtoselectguides.com/dotnet/documentation/

Further, someone could hack my URLs by removing the subdirectory and find a list of Guides:

   http://www.howtoselectguides.com/dotnet/

OTOH, if my URLs looked like the following, there is no way they could "hack" the URLs and get where they want w/o having to click around to find in my menu system:

   http://www.howtoselectguides.com/gobbeldegook.aspx

Your argument that end users shouldn't wouldn't understand URLs anyway doesn't take into consideration that younger people are much more technically saavy than older people, and many web sites built today may still be around years from now. Today's younger people will grow to be an increasingly large percentage of the population, as is always the case when time passes.

Plus we've not even discussed the benefits of eliminating file extensions in URLs for futureproofing.

mkamoski wrote:

Finally, I will point out that I have posed some alternative solutions to the URL-Rewriting solutions. These alternatives may or may not be "great"; but, they do exist. However, as the title of this thread suggests, it looks like there may be no real URL-Rewriting "solutions" at present, which, obviously, is yet another good reason not to implement URL-Rewriting.

URL rewriting doesn't work if you have a CMS like DotNetNuke and don't want to "own the code" (i.e. modify the code and then be responsible for remodifying it after each upgrade).

BTW, I've started using ISAPI Rewrite (www.isapirewrite.com) and love it, though it probably does not address all the issues that eron19 was asking to be addressed.

MikeSchinkel--

Regarding this...

MikeSchinkel wrote:

... OTOH, if my URLs looked like the following, there is no way they could "hack" the URLs and get where they want w/o having to click around to find in my menu system: ... Your argument that end users shouldn't wouldn't understand URLs anyway doesn't take into consideration that younger people are much more technically saavy than older people, and many web sites built today may still be around years from now. Today's younger people will grow to be an increasingly large percentage of the population, as is always the case when time passes.

...I think we disagree, almost entirely on these points.

First, my point is I don't want users to "hack" my site at all. Not one bit. I don't want them to go anywhere they don't belong. And, I don't want them taking any paths that are not on the map. Sure, they can try it; but, if you start hacking a URL and all of sudden get nothing then, IMHO, that's great. That's exactly what I wanted you to get. Stick to the navigation and you are OK. Hack the URL and all bets are off. This is, I think, a simple application of the security principle of "least privilege" and it is a good one.

The analogies to the "stick to the navigation rule" are paramount everywhere and they generally work-- we build roads for this reason, we have flight-controllers for this reason, we put water-lane markers in harbors for this reason, we have lighthouses for this reason, we print maps for this reason, we have GPS for this reason, and so on. It is a nice ideal to hold saying "I want to go anywhere at any time in any way I want" but, aside from being somewhat childish, that is impractical and it shows lack of respect for those who have put order into the system-- order, without which, there would be a lot of wasted time.

A simple test proves this point. How many people would claim that a standard website eCommerce clothing site is successful if it provided no navigation at all? Suppose there was no map to know where anything was. Now, suppose another site has navigation, sizing-wizards, checkout controls, categorized menus, a site map, and all the rest. Would the average user claim that site A is better than site B? Another point-- does such a site, with no navigation, exist? I haven't seen one and, if there is one, I would be surprized if it was successful. Now, why don't we build such sites? Well, simply because they do not make sense. Therefore, logically extending the idea of freeform URL entry support does not seem to work; however, alternately, extending the idea of "good site navigation via web controls", for example, does makes sense, were we see vendor after vendor making great controls for doing just that, improving and improving their functionality.

When you note that the users will "have to click around" on the site, I say "excellent". That's the point. That's what navigation is. That's why it exists.

Regarding young people, or old people, or any people for that matter-- the same applies. The fact is that one can never anticipate all the permutations of URL entries. Therefore, one can only guess. However, with navigation, clear, well-defined workflows can be presented to make it easier for the user.

Regarding the point to "the young are more technically savvy today", I am suspect, although I hear this all the time. Have you ever seen one of these "savvy" folk try to count out change for a buck at a convenience store? Man, if the power ever goes out and the cash register stops working, we are sunk. Have you seen the crap that kids are learning in the schools today? Have you ever listened to the "youth activists" speeches? Have you ever walked around a mall on a Friday night? These are NOT the "savvy" folks that we hear about in the news. Sure, they can play Nintendo, but can they read a novel and analyze it? Can you do algebra? Can they problem solve beyond figuring out how to bypass the library's blocked sites list? Oh, and those blocked sites they are trying to access, what are they? Do you think they are accessing online resources on renewable energy sources? Do you think they are visiting the philosophy sites on Wittgenstein? Nope. I seriously doubt it. For a generation that idolizes Tony Hawk more than it does the Stephen Hawking, there is going to be a BIG need to show them where to click.

That's just my opinion.

HTH.

I haven't read all those long posts, so might be repeating something.

In many applications, there is a huge difference between the public API and the internal implementation.
Remapping urls is the same kind of indirection.

Often, the best answer will be a third party tool like www.isapirewrite.com that intercepts and translates urls with  ISAPI before they reach the web application, but even this can have issues depending on it's features and your implementation. MCMS remaps urls and then uses script or an HttpResponse.Filter to adjust the html form's action.

Here is an example of remapping urls with an HttpHandlerFactory: http://weblogs.asp.net/andrewseven/articles/UrlRewriting.aspx

mkamoski,

Sorry, I missed your reply and didn't see until I got a notice that another person posted.

mkamoski wrote:

First, my point is I don't want users to "hack" my site at all. Not one bit. I don't want them to go anywhere they don't belong. And, I don't want them taking any paths that are not on the map. Sure, they can try it; but, if you start hacking a URL and all of sudden get nothing then, IMHO, that's great. That's exactly what I wanted you to get. Stick to the navigation and you are OK. Hack the URL and all bets are off.

That tells me you feel what you want is far more important in your web design than how your user's may want to use your site.

One of my favorites from Jakob Nielsen's Alertbox states:

mkamoski wrote:

Jakob's Law of the Web User Experience states that "users spend most of their time on other websites."

By designing your website the way you want it and not the way your user's expect it you are doing a disservice to the users that must use your site, and the rest will go elsewhere as soon as they have a viable option. I don't mean this just about URLs but about the generally dissmissive attitude you seem to have toward what your users might want.  Please forgive me if I am overstating this.

mkamoski wrote:

This is, I think, a simple application of the security principle of "least privilege" and it is a good one.

You are mixing apples and breadboxes. This is so not an application of least security that I can't even see how it might apply. This is about designing the URL structure so it is logical, and about making sure there is a valid page that makes sense  when users remove portions of a URL or have to reconstruct a URL.

mkamoski wrote:

The analogies to the "stick to the navigation rule" are paramount everywhere and they generally work-- we build roads for this reason, we have flight-controllers for this reason, we put water-lane markers in harbors for this reason, we have lighthouses for this reason, we print maps for this reason, we have GPS for this reason, and so on. It is a nice ideal to hold saying "I want to go anywhere at any time in any way I want" but, aside from being somewhat childish, that is impractical and it shows lack of respect for those who have put order into the system-- order, without which, there would be a lot of wasted time.

Apples and breadboxes again. Order is put in place when order is needed. Order is only needed when reality requires it, and there is no reality requiring incomprehensive URLs, only pendantic web developers who want to control what their URLs do (or lazy ones who don't make the effort.)

In the virtual world, there is much less need for the type of order required by the physcical world; you are not going to crash into someone else and kill them if you drive your virtual car off road. Look at Second Life and similar for example; you can go virtually practically anywhere you want. Why? Because the rules of physics don't apply in the virtual world.

Let's use a different car analogy. Let's say you decided to design a car and you had the funds to build it. You decide to put the brake on a big button at center of the steering wheel. People tell you the design isn't usable in a panic situation because the driver will need to take a hand they need to steer off the wheel. But you say "I have created order by my design, and people should accept it and not whine about not having it in the normal position." You sell a few cars because of the novelty, but you don't sell many, and then some of your buyers get injured or killed in crashes that were totally preventable had you followed standard layout and human factors/usability requirements.

On a side note, I read about a political theory that applies one of the two labels "the strict father" or "the nurturing mother" to people. The former believes that people need to take responsibility and if they don't they need to be disciplined. It sounds like you might have a "strict father" mindset. Would you agree?

mkamoski wrote:

A simple test proves this point. How many people would claim that a standard website eCommerce clothing site is successful if it provided no navigation at all? Suppose there was no map to know where anything was. Now, suppose another site has navigation, sizing-wizards, checkout controls, categorized menus, a site map, and all the rest. Would the average user claim that site A is better than site B? Another point-- does such a site, with no navigation, exist? I haven't seen one and, if there is one, I would be surprized if it was successful. Now, why don't we build such sites? Well, simply because they do not make sense. Therefore, logically extending the idea of freeform URL entry support does not seem to work; however, alternately, extending the idea of "good site navigation via web controls", for example, does makes sense, were we see vendor after vendor making great controls for doing just that, improving and improving their functionality.

You use fallacious logic to support your argument. You presume one of the other but don't include the option of having both. That would be like saying "Which car would be successful. One with a brake on the steering wheel, or one with no brake at all?" I would reply "One with a brake in the floor."

I would take one site that has no URL design and then compare its traffic before and after an update that added an elegent and hackable URL design. We are both arguing opinion which we can't prove, but I suspect we'd find an non-insignificant uptick in traffic and also in purchases (assuming the site is used for selling), and also in repeat visitors.

Let's take a look at a few real examples. Many people hyperlink Google searches because it is easy to understand their URLs. Amazon could never have had so many people referring them customers if at least their base URLs were not logical.

Take a look at one of my URLS:

http://www.howtoselectguides.com/dotnet/charting/tables/

Hack it once and you get:

http://www.howtoselectguides.com/dotnet/charting/

Hack it again and you get:

http://www.howtoselectguides.com/dotnet/

Hack it once more and you get:

http://www.howtoselectguides.com/

Why wouldn't I my URLs to look this way?!? If one of my users wants to see the text of my Guide about Charting Components for .NET, they just remove "tables/."  If they want to see a list of my Component and Tool Guides for .NET Developers, they don't have to find the link, they just remove "charting/tables/". And if they want to get to the home page, they just remove  "dotnet/charting/tables/"  (at least you can't stop your users from hacking your URL to find the home page! :) 

Why the heck would I want this instead?:

http://www.howtoselectguides.com/tabid/41/default.aspx
http://www.howtoselectguides.com/tabid/37/default.aspx
http://www.howtoselectguides.com/tabid/23/default.aspx
http://www.howtoselectguides.com/

Or worse:

http://www.howtoselectguides.com/1034-9874-9183
http://www.howtoselectguides.com/7961-4257-8212
http://www.howtoselectguides.com/4324-7294-3319
http://www.howtoselectguides.com/

Another thing, hackable URLs can let the user reconstruct broken URL in an email. If someone emails someone else my longest URL above and the email client/server puts a linefeed between "charting/" and "tables/", my user can easily see what happened and reconstruct.

There as SO many reasons to have good URLs, these just being a few. You can find here: More Reasons for Well Designed URLs.

mkamoski wrote:

When you note that the users will "have to click around" on the site, I say "excellent". That's the point. That's what navigation is. That's why it exists.

So you want to ignore usability and force users to do it your way? Noted web usability expert Jakob Nielsen disagrees in Web Design vs. GUI Design:

The User Controls Navigation On the Web, the user fundamentally controls his or her navigation through the pages. Users can take paths that were never intended by the designer: for example, they can jump straight into the guts of a site from a search engine without ever going through the home page. Users also control their own bookmark menu and can use it to create a customized interface to a site.   Web designers need to accommodate and support user-controlled navigation. Sometimes you can force users through set paths and prevent people from linking to certain pages, but sites that do so feel harsh and dominating. It is better to design for freedom of movement and, for example, put a logo (linked to the home page) on every page to provide context and navigation for users who have gone straight to that page.

Remember that Jacob's comments are mostly based on his research, not so much on his opinions.

mkamoski wrote:

Regarding young people, or old people, or any people for that matter-- the same applies. The fact is that one can never anticipate all the permutations of URL entries. Therefore, one can only guess. However, with navigation, clear, well-defined workflows can be presented to make it easier for the user.

So how does one use the navigation and well-defined workflows when they received a broken URL in an email to a specific page on a site? Since users have access to URLs they can and do try to do things with them you've never considered. In many cases, those thing they do with them benefit you (or your client.) Why would you want to explicitly disallow those beneficial things such as sharing links?

Heck, I'd love to see WinForm developers start incorporating URLs (or LRLs for "Local Resource Locators") into their apps. I love the fact that you can get to the path in Windows Explorer!  Adding URLs to WinForm apps would have so many benefits; users could bookmark the part of the app they use frequently (I'd kill to be able to do that with SQL Enterprise manager), they could send to a helpdesk person to show an error, they could share with co-workers via email or via IM, etc. etc.  SO many benefits.

Look at it this way. Think of your website as a platform, your URLs as an API, and your users as your third party developers. If you make the API easy to use, they will use it. If not, they won't. That's one of the reasons there were so many more apps written for Windows Server than for the old Novell server. Or more Windows apps today than Mac apps (you could argue it is instead because of the Windows vs. Mac marketshare, but I would argue one begets the other.)

Also, it just occured to me that you might be talking about web applications that by nature must be stateful, not about websites on the web with stateless pages that people may visit and share with friends. Are we arguing apples and oranges?  I'd still argue web apps should have good URLs, but my justifications would be fewer.

mkamoski wrote:

Regarding the point to "the young are more technically savvy today", I am suspect, although I hear this all the time. Have you ever seen one of these "savvy" folk try to count out change for a buck at a convenience store? Man, if the power ever goes out and the cash register stops working, we are sunk.

Only a small percentage of people work at a convenience stores, and those that do are by-nature less skilled and less educated than most others, or they would be working where they can make more money and probably have more self esteem.

mkamoski wrote:

Have you seen the crap that kids are learning in the schools today? Have you ever listened to the "youth activists" speeches? Have you ever walked around a mall on a Friday night? These are NOT the "savvy" folks that we hear about in the news. Sure, they can play Nintendo, but can they read a novel and analyze it? Can you do algebra? Can they problem solve beyond figuring out how to bypass the library's blocked sites list? Oh, and those blocked sites they are trying to access, what are they? Do you think they are accessing online resources on renewable energy sources? Do you think they are visiting the philosophy sites on Wittgenstein? Nope. I seriously doubt it. For a generation that idolizes Tony Hawk more than it does the Stephen Hawking, there is going to be a BIG need to show them where to click.

You were once a kid, right?  I'm sure your elders felt the same.  But anyway, you are now going way off course, and that is a much bigger discussion. I said "technically saavy", I didn't say they had a well rounded education. We'd have to take this one to Free Republc or Daily Kos or similar if we are going to continue that discussion. :)

I'll close with a rant.

<rant>

It is completely fine with me when people have a restrictive world view as long at they don't (try to) impose that view on other people.  A web designer with a restrictive world view unfortunately imposes their views on other people; in many cases lots of other people.  When web designers diminish usability to control how their users use their site or because of a (IMO) misguided view of security, it really gets me steamed!  They are negatively affecting many more people than themselves. 

And don't even get me started on Flash-based websites...

</rant>

FWIW :-)

MikeSchinkel--

Your points are well taken; however, I am cetain that we disagree fundamentally.

Rather than rehash at length, I will just make a few observations and comments on your latest post.

Regarding this...

MikeSchinkel wrote:

...Let's use a different car analogy. Let's say you decided to design a car and you had the funds to build it. You decide to put the brake on a big button at center of the steering wheel. People tell you the design isn't usable in a panic situation because the driver will need to take a hand they need to steer off the wheel. But you say "I have created order by my design, and people should accept it and not whine about not having it in the normal position." You sell a few cars because of the novelty, but you don't sell many, and then some of your buyers get injured or killed in crashes that were totally preventable had you followed standard layout and human factors/usability requirements.nded by the designer: for example, they can jump straight into the guts of a site from a search engine without ever going through the home page. Users also control their own bookmark menu and can use it to create a customized interface to a site...

...it IS an interesting analogy. However, I contend that it proves MY point much more than proves yours. If you were right, and the application of "do whatever you want whenever you want and design the car at your carefree whimsy", then it would be very likely that we would, in fact, have cars with alternate locations for the brake in the USA. However, as it is, the brake location does NOT differ in commercial passenger vehicles. This is because there are rules, regulations, and laws that govern the location of the brake. Why? Because there should be no ambiguity when one wants to know something important, to brake. The result-- it is patently clear to anyone who drives where the brake will be in a standard passenger vehicle in the USA. This is a GOOD thing.

To look at the parallelism, we have the following. If one wants to do something in the car-world (brake) then one is given a prescribed way to do it (press the pedal on the left downward). Similarly, in the web-world, if one wants to do something (find main category X on eCommerce site) then one is (more often than not) given a prescribed way to do it (click a link in the main navigation OR use the site's search box). Why? Because there should be no ambiguity when one wants to know something important, to navigate.

I suppose that if one does want to brake in a car, one could "do whatever he wants" and simply stick and arm out and grab a tree. Or, alternately, one could open the door and put down one's foot. However, that is not going to work very well. So too in the web-world, where one can start typing in the address bar at will; but, that is generally not the prescribed way and the results are generally not very good.

Frankly, I like the travel-by-roads and navigation-via-NavigationControls analogy. If one stays on the road, then one is fine. If one strays from the road, one may go on unauthorized land, get stuck in a rut, fall off a cliff, or simply get lost. Driving on the road is encouraged and that is why we often have guard rails to enforce the matter. Furthermore, in some instances (such as a bridge or a tunnel) it is strictly a bad idea to navigate at will. For the same reasons, navigation exists in the web. Sure, the navigation should be easy to use, complete, clear, simple, and allow full access to the site; but, it should exist in order to help the endusers and the site managers to run things smoothly and keep everyone on-track.

Regarding this...

MikeSchinkel wrote:

"Web designers need to accommodate and support user-controlled navigation. Sometimes you can force users through set paths and prevent people from linking to certain pages, but sites that do so feel harsh and dominating. It is better to design for freedom of movement and, for example, put a logo (linked to the home page) on every page to provide context and navigation for users who have gone straight to that page"

...you have not shown that the author intended to say that "URL hacking is AOK", or anything like that. In fact and again, I think that this author's point underscore my argument moreso than yours. Note that I have argued for navigation. Note that the author does not explicitly talk about "anticipating that the user can type anything into the URL". He is talking about putting in navigational elements (a logo linked to the home page). That is a far cry from "typing at will".

Regarding this...

MikeSchinkel wrote:

...Heck, I'd love to see WinForm developers start incorporating URLs (or LRLs for "Local Resource Locators") into their apps. I love the fact that you can get to the path in Windows Explorer!  Adding URLs to WinForm apps would have so many benefits; users could bookmark the part of the app they use frequently (I'd kill to be able to do that with SQL Enterprise manager), they could send to a helpdesk person to show an error, they could share with co-workers via email or via IM, etc. etc.  SO many benefits...

...I must say that I expect this, (the inclusion of LRLs in standard business applications), is not likely to happen. Not likely at all. Applications will become more and more user-friendly and that certainly does not mean returning to the black-screen days of executing commands at a DOS prompt. If anything, I expect that the browser will be begin to hide more and more implementation details (such as the URL) if possible. In fact, some browser-style interfaces for applications already do this, (see McAffee's home-user anti-virus software for an example). Looking at another popular UI, note that the iPod does not have a standard keyboard and navigation is clearly not centered on the idea of typing in characters to get the machine to react. In short, people are lazy (or, in the best light, efficient) and as such they want to point-and-click to get what they want. If they can click once instead of twice, then that is good.

We are talking in this discussion, (at least I am), about the average work-a-day web user. We are NOT talking about computer programmers, web developers, and the like. For the common person, simple navigation controls, (simple from the enduser's perspective surely but not necessarily from the implementer's perspective), will continue to provide the essential mechanism for navigation in Windows Applications and Web Applications. One of the chief complaints from endusers is that programs are too complex to use; not that they need to become more complex to use. Phrases like "user-friendly", "point-and-click", "write once, run anywhere", "plug-and-play", and "UNIVERSAL serial bus", get tossed about by developers like candy; but, to a large degree, such "ideas" still remain in the ether and largely unrealized. Honest developers will admit these shortcomings. To a great deal, the programmers have done a great dis-service to endusers, forcing them to learn silly technical details like "RSS Feeds" and the like. Why? Because programmers want to do things their way rather than asking the common enduser.

Take a simple polls sometime. Which is prerferable, clicking a link on a website to go somewhere or typing into the URL? 

And so on.

That said, I will finally point out that it is rather conspicuous that the list of navigation controls for ASP.NET continues to grow (see the http://www.ASP.net control gallery) and the push to "navigate via the URL" seems, well, not so strong.

Well, that's all that I am adding right now. Feel free to respond, of course; but, since I am skeptical as to whether or not we will be able to cover any new ground, my responses may be somewhat terse. For now, I believe we have reached an impasse of sorts and time will mediate from here on, as usual.

Thank you.

mkamoski:

mkamoski wrote:

MikeSchinkel wrote: ...Let's use a different car analogy... ...it IS an interesting analogy. However, I contend that it proves MY point much more than proves yours. If you were right, and the application of "do whatever you want whenever you want and design the car at your carefree whimsy", then it would be very likely that we would, in fact, have cars with alternate locations for the brake in the USA. However, as it is, the brake location does NOT differ in commercial passenger vehicles. This is because there are rules, regulations, and laws that govern the location of the brake.

There are laws about brake location? When I Google this:

http://www.google.com/search?q=laws+governing+brake+location+in+automobile

I found nothing about any laws regarding brake location. Brake location is defacto standard, not legally enforced. As it should be.

Just like URL hackability should be.

Actually, if you do a little research you'll find that brake locations were not standard in early days, they only evolved to that. Why? Because it was a best practice related to human factors.

mkamoski wrote:

Why? Because there should be no ambiguity when one wants to know something important, to brake. The result-- it is patently clear to anyone who drives where the brake will be in a standard passenger vehicle in the USA. This is a GOOD thing. To look at the parallelism, we have the following. If one wants to do something in the car-world (brake) then one is given a prescribed way to do it (press the pedal on the left downward). Similarly, in the web-world, if one wants to do something (find main category X on eCommerce site) then one is (more often than not) given a prescribed way to do it (click a link in the main navigation OR use the site's search box). Why? Because there should be no ambiguity when one wants to know something important, to navigate. I suppose that if one does want to brake in a car, one could "do whatever he wants" and simply stick and arm out and grab a tree. Or, alternately, one could open the door and put down one's foot. However, that is not going to work very well. So too in the web-world, where one can start typing in the address bar at will; but, that is generally not the prescribed way and the results are generally not very good.

The irony of your "GOOD thing" comment is you argue for a common brake interface across all cars (to which I agree), and you argue for a consistent web interface. But the fact many websites provide hackable URLs (because many people view them as best practice) means your are not following what many others are doing, i.e. you are putting the brake pedal in a non-standard location.

Also, you haven't yet given a good reason why they shouldn't be hackable, you've only said that you don't want users to hack them. Let me ask this pointed question: Why can't you accomplish your other goals *AND* make your URLs hackable?

mkamoski wrote:

Frankly, I like the travel-by-roads and navigation-via-NavigationControls analogy. If one stays on the road, then one is fine. If one strays from the road, one may go on unauthorized land, get stuck in a rut, fall off a cliff, or simply get lost. Driving on the road is encouraged and that is why we often have guard rails to enforce the matter. Furthermore, in some instances (such as a bridge or a tunnel) it is strictly a bad idea to navigate at will.

Again, you are using an analogy from the physical world that doesn't apply in the virtual world. Again I ask WHY is it a bad idea to design your URLs so people can hack them? More specifically, what harm can befall you if you do? Rules and order don't have virtue unless they have value and I see no value in your rule.

mkamoski wrote:

For the same reasons, navigation exists in the web. Sure, the navigation should be easy to use, complete, clear, simple, and allow full access to the site; but, it should exist in order to help the endusers and the site managers to run things smoothly and keep everyone on-track.

Yes explicit navigation (i.e. links) should exist, but it's existence should not preclude hackable URLs.

In college I took a Human Factors in Software (1986; one of my favorite classes) and the instructor's pet issue was "transitionality in user interfaces." Basically his position was an user interface is better if it supports a novice user interface and an expert user interface, and it makes it easy for the user to learn (i.e. transition to) the expert user interface.

I even wrote a competitive feature evaluation for my employer at the time (IBM in 1984) between IBM Personal Decision Series, Lotus Symphony, Ashton-Tate's Framework, and the Smart Series. The latter product was an order of magnitude better (which proves building a better mousetrap is not enough.) One key feature was it's use of a menu structure that composed commands for you as you used the menu. It was similar to how MS-Office records macros, but Smart did it visibly on it's own command line. After using the Smart Series for a while, you learned you could just start typing the commands, which at times was a lot faster than having to go through the menus.

Websites with explicit navigation and hackable URLs are almost identical to the Smart Series in having transitionality.

mkamoski wrote:

...you have not shown that the author intended to say that "URL hacking is AOK", or anything like that. In fact and again, I think that this author's point underscore my argument moreso than yours. Note that I have argued for navigation.

Au Contraire! See: Jakob Nielsen's URL as UI. I didn't mention before because it was never directly supportive of any of my points, but it does now.

BTW, can you point me to any research that supports your opinions (seriously?) I'm always willing to learn and change my mind, but I really think you've got it way wrong on this one.

mkamoski wrote:

Note that the author does not explicitly talk about "anticipating that the user can type anything into the URL". He is talking about putting in navigational elements (a logo linked to the home page). That is a far cry from "typing at will".

Although Jakob doesn't explicitly say people type at will regarding URLs, he did say "people guess the domain name of sites they have not visited before"

which could imply they guess URLs too, although again, it's not stated explicitly.

But you are using one use-case to discredit whereas I presented many use-cases, such as:

• Reconstitute broken URLs from emails
• Hacking off the end of the URL to move up a directory, and
• Having URLs that help the user visualize site structure

Still, I would argue in some cases is make good sense to let them guess and type. Consider a site with this URL:

http://www.example.com/makes/honda/model/accord/ 

So why wouldn't it make sense to have an company overview of Honda and a list of cars with links here:

http://www.example.com/makes/honda/

Further, why shouldn't the user be able to type the following and get to a page about a Toyota Camry that is just like the page he/she viewed about the Honda Accord?:

http://www.example.com/makes/toyota/model/camry/

Please tell me explicitly (not by analogy to rules in the real world) why this is bad, and also please tell me why it's not desirable?

mkamoski wrote:

...I must say that I expect this, (the inclusion of LRLs in standard business applications), is not likely to happen. Not likely at all.

Sadly, I agree that it's not likely. It would require developers to program apps as a series of state transitions, which is an infinitely better approach, but most developers don't have the skill and/or the discipline.  <Sigh>

mkamoski wrote:

Applications will become more and more user-friendly and that certainly does not mean returning to the black-screen days of executing commands at a DOS prompt.

User friendly and expert user interfaces are not mutually exclusive, and stated ad-nauseum above.

mkamoski wrote:

If anything, I expect that the browser will be begin to hide more and more implementation details (such as the URL) if possible. In fact, some browser-style interfaces for applications already do this, (see McAffee's home-user anti-virus software for an example).

Sadly I agree that this might happen, but I don't agree it's a GOOD thing. Instead it is because of programmer's optimizing for themselves as opposed to for their users.

mkamoski wrote:

Looking at another popular UI, note that the iPod does not have a standard keyboard and navigation is clearly not centered on the idea of typing in characters to get the machine to react. In short, people are lazy (or, in the best light, efficient) and as such they want to point-and-click to get what they want. If they can click once instead of twice, then that is good.

How you can use the iPod as justification for keeping URLs non-hackable is beyond me. The iPod is a handheld device with a very limited feature set. If it agains a much larger feature set, you *will* see add-on keyboards for it as you currently see for PDAs.

Again, read my comments about transitionality. One of the big things Linux has over Windows Server is it is much easier for an expert to administer a Linux server than a Windows server because in the latter GUIs are often the only way to admin whereas the latter has full command line admin capability. Even if the Windows Server admin does the same work day in and day out, they still have to use the damn GUI in most cases.

Note I'll also add that Linux really needs a lot more GUI admin tools for the novice. Being only novice-friendly or only expert-friendly is never a good thing; we should have both.

BTW, and I am not being sarcastic, what are your credentials regarding human factors and user interface? Have you at least take human factors courses in college?

mkamoski wrote:

We are talking in this discussion, (at least I am). about the average work-a-day web user; we are NOT talking about computer programmers, web developers, and the like. For the common person, simple navigation controls (simple from the enduser's perspective, not from the implementer's perspective) will continue to provide the essential mechanism for navigation in Windows Applications and Web Applications.

Sounds like your world view is "black or white," and mine is "a continuous transition from black to white, i.e. shades of grey."

What you are discounting is the fact that everyone has the capacity to learn, and over time many more people that programmers would like be learn shortcuts.

mkamoski wrote:

One of the chief complains from endusers is that programs are too complex, not that they need to become more complex.

You are confusing complexity that is required to accomplish a task with optional interfaces. Both navigation and hackable URLs can and should be provided, but using the latter is *optional*!

Ironically, when users complain about complexity it is often because the navigation is too complex. Take a look at what Jakob says about Office 12's new user interface; they changed because their navigation was too complex.

mkamoski wrote:

To a great deal, the programmers have done a great dis-service to endusers, forcing them to learn silly technical details like "RSS Feeds" and the like. Why? Because programmers want to do things their way rather than asking the common enduser.

Further irony, I contend making your URLs non-hackable is you the programmer doing a disservice to your enduser!

mkamoski wrote:

Take a simple polls sometime. Which is prerferable, clicking a link on a website to go somewhere or typing into the URL?

You continue to miss the point!!! The point is that hackable URLs are an optional advanced user interface, not the only or the primary interface. Using your road analogy, that's like forcing someone to only drive backroads by giving them no access to the freeway when in fact both will get them there but the latter is faster!

mkamoski wrote:

That said, I will finally point out that it is rather conspicuous that the list of navigation controls for ASP.NET continues to grow (see the http://www.ASP.net control gallery) and the push to "navigate via the URL" seems, well, not so strong.

Yes, and I think it is one reason ASP.NET may eventually cave in under it's own weight. I love .NET as a platform, but honestly think that ASP.NET does a lot of things really badly (such as "__doPostBack()").

mkamoski wrote:

Well, that's all that I am adding right now. Feel free to respond, of course; but, since I am skeptical as to whether or not we will be able to cover any new ground, my responses may be somewhat terse. For now, I believe we have reached an impasse of sorts and time will mediate from here on, as usual.

I brought up a lot of points about why hackable URLs are good but you didn't address any of them, such as (and I repeat again):

• Reconstitute broken URLs from emails
• Hacking off the end of the URL to move up a directory, and
• Having URLs that help the user visualize site structure

If we are at an impasse, I can only feel sad for your users, hope that you influence as few websites as possible, and hope that those you do influence don't have many users. And I don't mean this in any way to be nasty, I just want to see as few people subjected to websites that deny them hackable URLs.

P.S. If you can't tell, this is an web design issue about which I feel extremely passionate.

Mike--

BTW, there is a practicality point and reasonableness of effort regarding making pretty URLs.

Sure, they are nice, when one has the time and requirement to do it.

However, when it comes to one or the other, (navigation controls VS typing in the URL by hand), it seems that navigation controls are a bit more practical.

What got me thinking about this is that I noticed your blog (which I will say has some great content) has the following URL...

http://blogs.xtras.net/mikes/CommentView,guid,34d8ff59-526b-4613-9734-c2321073da14.aspx

...and I am thinking how much you must hate that and also I am thinking about how much I do not care about that.

Anyway, there is one more thing to think about as we move along.

And, another thing to note that one of the most successful recent sites is http://www.Google.com and they have no compunctions about dishing out URLs such as this...

http://www.google.com/webhp?hl=en&tab=gw&q=GetOleDbSchemaTable%20determine%20if%20it%20is%20

Just a thought.

Thank you.

MikeSchinkel--

I read you most recent post and it is fine.

I do see your point; but, I disagree on some points.

While I have tried to give my reasons, (least-privilege, unnecessary complexity, need for simplicity, speed for the endsuer, not reaching behind the user's back, and so on). That one says, "that is so not a case of breaking least-privelege" is hardly a counter-argument. I take it that one may disagree; but, I submit to that no publically accessible web-server allows users to REALLY go anywhere they want. Sure, one can trick the user and make it look like they have full mobility; but, the fact is that one are not going to let them into "c:\Program Files\" and simply poke around to see what they can find. That's what virus crawlers do-- they look for holes. Need for simplicity? Are we really ready to say we have conquered the "user friendly" idea and we now have time to move on to "support for a command line interface for expert users"? The case for prioritization seems to answer this question. And so on.

Let's consider an example. AOL is successful because it provides a very simple setup and a standard usage pattern. Everyone laughed at AOL in the old days. Now, it is AOL who is laughing, all the way to the bank. I don't quite know their market share right now; but, I am certain that "silly browswer platform idea" of theirs, the idea that everyone joked about in the past, has knit more than a few golden parachutes.

The point about skills-transition is OK; but, there are limits. One certainly cannot expect everyone to have the time to be a computer expert. Nor should one want that. Why waste the time? A medical doctor wants to shop for a pair of socks. Are we going to want him to click >EddieBauer, >Mens, >Socks, >Checkout, or do we want him to learn object query language so he can manually query a web service? We want him to get the socks without being distracted from curing cancer. So, what do we do? We provide reasonable navigation and, OK, maybe a default document in every directory. That's fine.

Who do the hackable URLs really support but a bunch of typing tech geeks who want to go everywhere without a mouse. Sure, that's a fine idea if you are an expert keyboarder. In fact, I agree that it MAY be a requirement for an application that is designed for such users, (as I have noted before, these decisions are necessarily requirements driven). However, I am talking about run-of-the-mill websites for the 80% of users out there. Those sites that are used by the general public, not applications for some esoteric group that, (of course), is going to require an estoteric application.

BTW, we have somehow transitioned into talking about "hackable URLs". Let's refocus. My main point is that the URL should be ignored by the enduser and the enduser should be discouraged from typing anything beyond the start address, such as http://www.SomeSite.com , and after that point custom navigation should be used. If there is a default document in every directory, that's fine. Yes, it is good idea. I hardly call that "hacking a URL". Now, the idea of having an enduser guessing that there might be a directory http://www.SomeSite.com/ProtectedDataThatIWantToHackInto/ just to see if anyone left a door open, that is hacking and, yes, it is a bad idea to allow users to do such a thing, experts or otherwise.

URL rewriting is a trick. It is reaching behind the user's back. It is having the user believe that he or she is more free than he or she really is. It is a lie.

To continue the road analogy, what I am saying "use the roads when you need to get somewhere and only go off the road in special cases like 4-wheel drive ATV parks" and what the proponents of URL hacking seem to be saying is "everyone should be able to drive whereever they want and that means if you have a Hummer you can drive across anyone's lawn". I don't want any Hummers on my lawn.

That's the reality in the web world too. Sure one can "trick the eye" and make it look like the user can navigate anywhere; but, in fact, we lock down directories and other resources all the time. Not every user is allowed to go everywhere. Why? Because it is not secure.

You have quoted many sources; but, most of them seem to be from ivory-tower "experts". I know they have a lot to say; but, it seems to me that one ought to ask the enduser for comments. There are many examples of VERY simple and VERY well-received UIs (McAfee, iPod, Google, and the whole Mac OS for that matter) and all of these have very little to with typing in characters into a textbox. Why? Because people, in general, do not want to type; they want to push a button and go. I mean can we come up with an example of a more primitive UI than-- "type the name of the command 'goto home page' into the text box and press 'Enter' to navigate". Is that really a design goal?

Is it "nice" to have a site or a program that is "ready for the expert user"? Yes. However, what amount of users are experts? Less than half, one can safely guess. Who are we pleasing? The top 5%? The top 10%?

As for Linux, it appeals to tech-types and as long as it continues to do that it will remain distant from first place. Wait and see. They will develop their setup, GUI, and the rest of it to do what? To follow the lead of Windows and Apple. Why? Because that's what most people seem to like. Even now the Linux GUI has Windows and Mac look-alike skins. Why? Because those are better GUIs? Have you seen Sun's GUI OS? Ug.

Finally, let's extend the whole model and think about how people really want to use computers. What is next? What do people want? I expect that they want to talk to the computer. Yes, no typing. And what will we be saying? I expect that it will be more like "go to Google" than things like "delete all characters from the address line up to but excluding the right-most forward slash character and then execute the Enter command". Note that few, if any, can type as fast as they can talk. What is desired is to move as fast as people think. When the average Joe wants to find a pair of socks, I bet he is going to want to say something like "find me the best priced pair of black dress socks for under $10" rather than something like "select * from google where category=clothing and item=socks and color=black and price<10".

Sure, I grant that if everyone became expert typists, if we all switched to the Dvorak keyboard layout, and we smashed every mouse, then, yes, we might develop a UI that IS faster to navigate. However, I am trying to be practical here and to expect such a change is, in my opinion, impractial and not very probable.

Also, is there a law about the placement of the brake? I don't know for certain; but, I bet that there is one. Regardless and accepting that there not a law as such for the sake of argument, that the industry has standards IS very clear. Why? Because they industry wants to avoid ambiguity and strive for consistency. That's the point. That there is evolution on the matter underscores the point. They found what works. If the computer industry had half as much a sense for standards we would actually have the darn backspace key as the same size and in the same location on every keyboard. And so on.

While me may not have standards in navigation, we can see that it is usually topnav, rightnav, leftnav, and bottomnav. Breadcrumbs are also common, near the top of the page. with content in the middle. Now, there is still a lot of leeway; but, that pattern is pretty common. So, could a site put the navigation in the lower right-hand corner only at the very bottom of the page? Yes, that is possible; but, is it advisable? Not today it isn't. Might it be the best case for tomorrow; well, lets see what the customers are buying-- if they like it, then they will buy it. And so on.

What are my credentials? Who cares? I don't care what I think the enduser thinks. I care about what the enduser actually thinks. And, that's just the point-- there is not one single web developer who is not tainted beyond the point of return; developers cannot objectively judge user interface design because of their skills. (Myself included.) Why ask an "expert in the field of UI design"? So he or she can tell the enduser what is good or not so good? Why not go to the source? Why not ask the endusers? The questions should be asked of the people using the software and they will vote with their pocketbook and clicks.

BTW, here is another thought. This post editor has 2 modes, Design and HTML. Now, it would be VERY interesting to see the site here setup some metrics to see which is used more often. I would think the Design mode is more often used.

Anyway, as far as "influencing people", I don't want to do anything of the sort. Please do whatever you like. I am simply trying to comment on perceived trends as reported to be from my endusers.

Well, I think now I may be done with this topic. Maybe. I think that I want to say "I hope so". Stay in touch.

Stay in touch.

IMHO.