Craig R. McClanahan wrote: > > On Fri, 11 Oct 2002, David Graham wrote: > > >>Date: Fri, 11 Oct 2002 11:15:06 -0600 >>From: David Graham <[EMAIL PROTECTED]> >>Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> >>To: [EMAIL PROTECTED] >>Subject: RE: Struts Tag Request >> >>I'm not sure I agree with training users that the url is meaningless. This >>goes against everything people know about browsing. They use urls for >>bookmarks, look at the list in there address bar for one they recognize, >>etc. You could train internal people but for internet sites this seems >>unreasonable. >> > > > A web application is *not* the same as a web site. The problem with > browsers as the delivery vehicle for both is that users get confused on > this issue. And developers who are confused on this issue don't help > matters any :-). > > Interactive applications in general (both web-based and rich client based, > as well as those built into hardware like the controls on your microwave > or VCR) should be modelled as a set of reactions to user gestures (button > clicks and so on). The set of possible gestures that are recognized at > any point in time *should* be limited to the set built in to the UI, > because the developer has provided reactors for those events, and only > those events.
I agree with your basic point -- a web app is an app and the UI should be self-contained -- but for browser-based apps targeting the public at large, you have to expect that users are going to use the back button and users are going to attempt to bookmark things. They have been *trained* to do so by their experience on the web. If my VCR works differently from others on the market, I need to anticipate that my "users" are going to do what they have done with other machines -- I better not, for example, chew tapes when users elect to use "eject" before "stop," regardless of how clearly my UI steers them toward the "correct" sequence. I need to either "disable" the eject button until stop has been hit or to handle the "exceptional" event. (see below) > > Imagine writing a Swing-based app where the user had some external > mechanism to cause *any* arbitrary event to happen, whenever they want. > That's essentially what the back button and bookmarks do to you. > This is not a good analogy, since we are not talking about "any" event here -- just a couple of events with high probability of ocurring. From my perspective, this is similar to exception management: the developer has a responsibility to identify and handle all exceptional conditions likely to interfere with the normal processing of an application. The tricky bit is defining the scope of these "exceptional conditions". I would consider use of the back button or bookmarking in a web app as within scope. (as would millions of web users :-) > >>I don't like the frames approach because then you can't bookmark any pages. >>This is really frustrating for people. >> >>Also, redirects aren't much slower than forwards so I use them when I want >>to make sure the user doesn't get confused and repost form data. This seems >>easier to me than training millions of people :-). >> > > > IMHO, if your users find that they can't use your webapp effectively based > on the UI controls you've built in to the user interface, without using > the browser facilities, that's a pretty good clue that your UI needs some > additional navigation controls and other similar features added to it. > > Sorry to sound so absolutist ... but this issue is critically important in > good user interface design for web-based applications. It's nearly > impossible to prevent users from using all the built-in functionality of > the browser (even if you don't show the back button, you still have to > worry abou the keyboard equivalents). Our mission needs to include > minimizing their desires to do so. > > >>Dave >> > > > Craig > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
