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. If we're talking user friendliness and expectations, THIS is how it should be IMO. > So we have two pages and we can return from a login page to > welcome page using Back, and then to go again to login page using > Forward. I think it is logical, that we need to click Back *only once* > to return from login page to welcome page. And I would agree, if we really want to persue a fundamentally flawed site design :) > Now a user tries to login. He makes several attempts, say five. Should have been locked out at 3, but I digress... ;) > 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 :) > How many times is he supposed to click Back button? In most > applications, six times. Why? because browser recorded each login > attempt as a separate resource location. > > Therefore, a user actually *expects* to click Back only once to return > back, because login page is a second page. Instead, he is *forced* to > click six times. Do you really think that clicking Back six times is > logical and expected by a user? I do not thik so. Agreed. 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. If they wanted something more fat-client-like, then I would address the fundamentally bad design first. > 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. > 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? Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
