Applicability of InterfaceDesignersRule1

[Tom Rispoli]

[Devaka] Originally posted on : this topic

---

Can I ask what the source of InterfaceDesignersRule1 is, or what research was done to arrive at this rule?

Thanks

[Devaka Cooray]

Tom Rispoli wrote:.....or what research was done to arrive at this rule?

Does it that require to have academic researches done for every little thing that we can think of?
That's NOT a formal or legal rule you must follow - it's just a rule that defines what the best practices are. If you read the content under "What I (meaning the end user) expect" of that page, it has a good explanation from the end-user's viewpoint.

[Tom Rispoli]

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.

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).

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.

[Eric Pascarello]

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.

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.

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).

I still can go back with a button on my mouse, alt arrow keys, right click, etc. You just removed one of many ways of doing an action. In most cases users of applications are FORCED to do something and are afraid to speak up and say things. Just because no one speaks up does not mean that the users do not miss the functionality.

Removing the back button is like opening up a window with a hammer. Yeah the window is pen, but you can not go back and close it.

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.

There are no numbers that you can find. The only real way to see how the application is used and what bad habits are is to hire someone to do a study on the usability of the site. We have two full time guys here at our place that do these types of studies. They sit and watch people use the site and give them tasks. They see what is broken and how to improve the performance.

IMHO: Web applications that work like a client app is because the developers who designed it only understood how client apps work and think that is the way all applications work. This thinking is how we have companies stuck using IE only intranets and so on.

Eric

[Bear Bibeault]

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."

Web applications should not try to change anything about the environment in which they operate, including browser settings and controls. It doesn't take studies or numbers to know that ticking off customers is never a good business strategy.

[Tom Rispoli]

It is a web application, people expect web applications to look and feel a certain way.

I agree, this is a cost of this method. Opening an application through a web browser does create certain expectations for may users and taking away browser controls may dissapoint them.

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.

It reduces costs because the browser specifications we require, prevent (I hope) the user from having access to those controls. 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.

I still can go back with a button on my mouse, alt arrow keys, right click, etc.

We block these through javascript as well.

Just because no one speaks up does not mean that the users do not miss the functionality.

Its true, I do not have any good data on what our user community thinks of this. Just the occaisonal complaint that someone would like to use the back button. I'm pretty sure that if I were to tell my client I could give them the browser controlls back but it would mean an increase in thier costs that they would scoff at the idea. The majority of the changes I hear about being requested by the user community are to ask for additional functionality.

I feel that the controls that have been removed prevent (or at least make it more difficult) for the users to use the application in unintended ways. This seems like it would improve the user's experience rather than hurt it. In the absense of any broad data (if somebody's got some I'd be very interested to see it) to show how browser controls effect user acceptance and user productivity, it seems reasonable that there are some situations where an application would be enhanced by the removal of controls, and if thats true, then blanketly recomending against removing browser controls might might not always be the best advice.

It could be that my current scenario of a captive audience with largely homogenous client environments is a bit of a novelty, and maybe thats what is driving my point of view here.

[Bear Bibeault]

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.

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."

This seems like it would improve the user's experience rather than hurt it

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.

You may be in a position to have a captive audience that just has to take it, but even in this case, ticking off the users is never a good idea. As soon as they have a choice, they will not forget who had the "screw them" attitude.

[Bear Bibeault]

P.S. I once did work on a web app that required that I impose these sort of limitations -- clueless product management and all. 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.

[Tom Rispoli]

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."

I agree, if I went to google or wikipedia and they took away my browser controls I would be very frustrated. However, consider this scenario.

City Bus Driver: "Ever since you got buses with automatic transmissions, there is no clutch for me to step on"

City Purchasing Official: "I know you are used to stepping on the clutch, but adding a clutch for you to step on that won't do any damage to the transmission will cost money that could go to other things, like more pay for you. Since the clutch isn't neccessary, we won't put it in for the small number of drivers that are complaining about it. When you drive home in your standard car, feel free to hit the clutch as often as you want."

I agree, requiring users to get used to a web app that doesn't have a back button will not serve to make them happy, but if you take the benefits into account you may get a better application overall.

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."

I'm sorry if thats how it came off, its not how I intended it. The idea is we (the vendor) will limit user ability as much as possible to use browser controls, this will reduce development/maintenance/testing costs and there by I allow you (the client) to have additional resources to invest in the system or other things. The draw back is that you (the client) will need to work to control the settings of the user community to prevent them from using the browser controls. As this is your (the client's) responsibility, we (the vendor) will help you correct problems that arise from this but are not obligated to.

In this, I feel that you are mistaken.

I may be mistaken, all I have to go on is the feedback (which does not come from a broad subset of the user community) I get. What I hear doesn't rank browser controls as a high level issue. This is the best indicator I can come up with to show me where development time is best spent.

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.

I guess I tend to think that my user community isn't as firm in thier belief on this as you are. As they use it frequently I assume they start to see it more like a client server application that is launched by a browser, rather than as an application that hijacked thier browser. It is possible that I am unaware of the frustration that this is causing, but I'd like to think that after 5 years of use I would have an idea if that was the casee.

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.

Interesting, you think its more user friendly to pop a new window rather than to hijack the current browser? Its not a bad idea, I'll float it to my client to see if they think it will make the users happier. Thanks for the idea.

[Bear Bibeault]

My pleasure.

My compromise made users happy, as well as product management. Me, not so much. But it wasn't me I was trying to please.