Tom Rispoli wrote:.....or what research was done to arrive at this rule?
Tom Rispoli wrote:The logic of these rules does make sense. If you remove controls that a user is used to having then they may find the application more frustrating.
At the same time, the application I work on does remove most of the browser controls. This was at the request of our client. It gives the application more of a client server feel and allows us to have more control over the flow. It also reduces our development and testing costs.
Tom Rispoli wrote:
To be honest, some users have complained about the loss of the back button, and the site does essentially have a captive audience, but there has never been a big push from the user comunity to get the browser controls back (perhaps becuase the application used to be client server).
Tom Rispoli wrote:
So the reason I'm being annoying about the source for that rule is that if there are some quantifiable impacts (or attempts at quantifying them) of doing this then I'd like to try to etermine if they are affecting my application and perhaps recomend to my client that we move away from this strategy of removing the browser controls.
I would offer Reshmi suggestions on how to do this (at least on IE), but if there is data showing that this is always a bad move then I'll keep it to my self and not incourrage others to to make the same mistakes that I have.
It is a web application, people expect web applications to look and feel a certain way.
I am not sure how it reduces development costs other than you are just ignoring work flows which can lead to major bugs in the code. Modern day browsers CAN allow a user to override toolbar settings. So you can hide them, but the browser may not allow it to happen.
I still can go back with a button on my mouse, alt arrow keys, right click, etc.
Just because no one speaks up does not mean that the users do not miss the functionality.
Tom Rispoli wrote:So we don't have to code/test for it, and if an issue occurs (which has been rare) its our client's responsibility to correct the data.
This seems like it would improve the user's experience rather than hurt it
Customer: "Ever since you installed this new CD changer in my car, the shifter doesn't work."
Mechanic: "Only a handful of customers have complained so it must be ok."
Sorry if I'm taking this wrong, but it sounds like "We can't be bothered to code our applications correctly, so screw our customers. It's up to them to make sure our systems don't screw them up."
In this, I feel that you are mistaken.
Any website that tries to prevent me using the back button, an act which most certainly does not improve my experience, is one I will never willingly visit again. Ever.
My compromise was to run the app in a newly opened window that didn't display the browser controls at all. At least that way, I wasn't screwing them over by trying to take over their original browser window.