On 7/25/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > On Mon, July 25, 2005 3:11 pm, Michael Jouravlev said: > > Ok, I will use the same use case I used during last weeks :) a login > > form. Say, you have a welcome page on a website, which directs a user > > to a login page. How many pages do you have? I hope your answer is > > two. > > I would have said one... why would I force a user to click a button to GET > to the logon page in the first place? Why isn't the logon page and > welcome page the same thing? This is the case in my apps. Therefore, > when a logon failure occurs, they are on the logon/welcome page, with a > message telling them about the failure, and they can try again.
Oh gosh, Frank, can you think more abstractively (is this a proper adjective?) It does not really matter, why login page follows welcome page, this is merely an *example*. Ok, consider that welcome page *is* a login page, but a user came from another site and after unsuccessful login attempt wants to return back to the previous site. Better? > > It did > > not work, and a login page is redisplayed with error (is not this the > > same login page, logically?) The user wants to return to welcome > > page. > > Why? They are already where they need to be. If they really want to go > back, let'em hit back 6 times :) Why??? They want to return from "login page" to whatever "previous page". I see only two pages here, why should they hit back 6 times??? > But again, what was the original expectation by the client? Is > this a web app? Then guess what? That's the way it works. Deal with it. They expect a webapp, which navigates from page one to page two. Therefore, it should be possible to navigate from page two to page one in one click. Is not this logical? *That* is the way it should work. Instead, users have to deal with raw implementation of HTTP POST. They don't care about HTTP, they just want to go back from page two to page one. > > Having one address for login page, and redirecting to it after > > submitting the data, we ensure (for most browsers) that browser > > history contains only one entry of our logical page. Which is exactly > > what a user expects. > > It's that "for most browsers" part that bugs me... If you code to > standards, in theory at least, things work across all browsers (of a > reasonable vintage anyway)... even if we agree that its better to not have > the 6 browser history items, why should I put something in place to defeat > it that isn't even entirely cross-browser? That seems to me to be > exacerbating an already bad situation. Actually, vintage browsers work great. It is the Opera which is a black sheep. Umm... should HD television be broadcasted? It is used by what? 1%, 3% of subscribers. Those who do not use it, get the same show with lower quality, that is it. Conversely to HD TV, Opera is used by only about 2% of users, and most of them use Opera specifically because it caches every page. These users like exactly this behavior and *they* expect that. So it is OK for them if they had to click Back six times. Normal... hm... users expect just to return from page two to page one. If they use browser other than Opera, they get exactly what should happen, return from page two to page one. If they use the application on Opera, they have to click back six times, just like in most other applications, but application does not break because of this. Hell, fill it up with 89 instead of Sunoco 94, it will still be driveable, not that fast though :) > > Right, clients don't know the details of tecnhology. We as developers > > should offer them the best we can do (in reasonable time, of course). > > On the other hand, do your clients really care about what happens when > > a user clicks Refresh button? I would say, they ask for certain pages > > to be bookmarkable. And oh, make it in blue, not in yellow ;) > > Perhaps... but are they going to be happy when you tell them it might not > work in browser A and B but is OK in C and D? What "it"? Application works either way, only on non-Opera browsers it works nicer, that is it. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
