You're right, I did mistake the web app. with a web site. I agree with you on the ui needing to be done well enough that the app. user doesn't have to use the browser controls much.
However, many organizations demand that all web apps follow the company look and feel leaving you at the mercy of the corporate web designers. So, it's easy to say that the ui should be well designed but you may not be able to for reasons outside your control. Dave >From: "Craig R. McClanahan" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: Struts Users Mailing List <[EMAIL PROTECTED]> >Subject: RE: Struts Tag Request >Date: Fri, 11 Oct 2002 11:41:35 -0700 (PDT) > > > >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. > >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. > > > 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]> _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
