Cancel - OK
-
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people). The next time he brings it up I might punch him in the face. :mad:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
Colin Mullikin wrote:
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people).
Testers don't write specs or or code. They test. That is all they do. As long as the interface adheres to the functional specs, the testers shouldn't even be talking about it. It wastes the team's time during the bug triage process. If the testers don't have functional specs to work from, that the Business Analyst's fault.
Colin Mullikin wrote:
The next time he brings it up I might punch him in the face.
Ahhhhh, the Outlaw Programmer's favorite conflict resolution methodology. I like it. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people). The next time he brings it up I might punch him in the face. :mad:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
I would not only punch you in the face, I'd probably break skull of anyone who tries to make me "think RTL"! :mad: Try asking your friends "Do you not need coffe?", "Are you not going home already?". After twenty or so times they'll stop talking to you or beat the [random code] out of you. PS: is't not that tester's fault that he got dragged into gay community. :rolleyes: PS/2: I think I'll start saving money so I can travel to where GTK developers gather and start a massacre :)
-
You're not getting much joy from this one are you! I'm afraid I disagree with your stand on this one as well, standards and consistency are what make a user experience easy. Having said that I can sympathise with you when YOUR standard pre-dates Microsofts latest set of decisions. I still use a DAL that pre dates Entity Framework by a decade :sigh:
Never underestimate the power of human stupidity RAH
Standards and consistency should be handled in the design phase - NOT the test phase. The tester should just STFU, especially if this issue has been previously marked as "not a bug", or moved to the product backlog.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
The period in my life when I had my highest frequency of swearing loudly at my office desk was when we used an editor that at exit might display a warning (this was before the mouse was common, so you responded through the keyboard: "You have not saved the last modifications to the file. Do you want to save it before exiting? (Y/N)" Of course you would immediately hit the "Y" key. Then we switched to another editor that had very much of the same style user interface, but it would give the warning: "You have not saved the last modifications to the file. Do you really want to exit without saving? (Y/N)" Obviously, from old habit, you hit the "Y" key. Then you would swear loudly and be grumpy for the rest of the day. Moral: Don't play games with the user's old habits.
-
It's guaranteed that most of your customers will complain if you change it since they will need to retrain all their users for that minor change. No doubt the original decision to place the buttons in the order you prefer was so the new users would cancel rather than choosing the usual ok.
-
Oh sure - there is no need to repeat exactly the same example. I certainly would insist that it is not very different; it has to do with old habits. The CUA prescribed that the button to click to termminate a dialog normally should be the bottom rightmost one, and in the old days, all applications followed that recommendation. Then some software turned up where following the habit of clicking the bottom right button would NOT confirm all your entries, but cancel them. That is very much the same as following your old habit of responding "Y" to a yes/no question, without reading the label. You loose your modifications is both cases.
-
Microsoft published a design guide, in the before the before, that suggested putting the OK button on the right was correct and that most user expected that. Then when Microsoft switched to placing OK buttons on the left, the guide mysteriously disappeared. It was a well written research article, to this day I wish I had printed it. My personal opinion is that the confirmation should be in the same location every time and should not float. Placing it on the left makes it float. For example on an OK only dialog the OK button will be in a different place from the OK Button in an OK Cancel Dialog. Long story short, just because Microsoft does something doesn't make it correct. More importantly I agree with your button placement, and furthermore I like using the word furthermore.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
Ennis Ray Lynch, Jr. wrote:
just because Microsoft does something doesn't make it correct
Hear hear!
You'll never get very far if all you do is follow instructions.
-
You're not getting much joy from this one are you! I'm afraid I disagree with your stand on this one as well, standards and consistency are what make a user experience easy. Having said that I can sympathise with you when YOUR standard pre-dates Microsofts latest set of decisions. I still use a DAL that pre dates Entity Framework by a decade :sigh:
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
I still use a DAL that pre dates Entity Framework by a decade
:thumbsup: As do I and probably most experienced practitioners.
You'll never get very far if all you do is follow instructions.
-
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people). The next time he brings it up I might punch him in the face. :mad:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
I agree that it should have been standardized to match the platform (Windows) your software runs on. Changing it now would be an annoyance to your users initially, but they'd get used to that. That said, is it worth the time to do it? Well, you'd have to determine that. That said, the appropriate thing to do is use your time machine to go back and tell your designers to do it "right " the first time. ;)
-
Way back, in the old days when MS and IBM were friends, was developed a standard called the Common User Access, CUA, giving the common guidelines for Windows, OS/2 and Motif user interfaces. The CUA was published as an IBM document, but was endorsed by MS (and I believe several other companies). Windows 3 was developed in close to 100% adherence to the CUA rules. The CUA stated clearly that normal completion of a dialog is done by clicking the button in the lower right corner. In other words, OK to the right. The first CUA rule (at least among the essential ones) were the location of the Help menu: CUA requires it to be pushed to the very right on the menu line. I don't remember when MS decided to move it together with the other pulldown menus; that could be in Win 3.11. We started out with consistency where you by instinct clicked the bottom right button to complete normally, to a transition period where an increaing fraction of the applications made you follow your instincts, swear, and redo the entire dialog, this time reading the button texts closely, to the current situation where everything is so inconsistent and free of rules that you cannot rely on instincts but must read all the buttons anyway. ("But OUR software is consistent" - sure, the good thing about standards is that there are so many to choose from. Most customers buy software from several different vendors.) Whenever I make user interfaces, I follow the CUA rule of normal termination being the bottom right button. Nowadays, all user must read the button labels anyway, so this is as good a choice as any other. Or even better, since I can justify my choice by referring to a user interface standard document. (True enough: It was published more than 25 years ago, but it is far better than nothing).
Member 7989122 wrote:
that could be in Win 3.11
No, Win 3.11 was still good.
Member 7989122 wrote:
the location of the Help menu: CUA requires it to be pushed to the very right on the menu line
I remember that and I wish I could still put it there, but WinForms doesn't seem to allow it. :mad: :thumbsup:
You'll never get very far if all you do is follow instructions.
-
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people). The next time he brings it up I might punch him in the face. :mad:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
So you don't use the "Default" MessageBoxes? Did you (your company) create special "MessageBoxes" with Cancel/OK too? :omg: If you did so - I hope you also created your own "MessageBoxButtons" enumeration ;-) (MessageBoxButtons.OKCancel MessageBoxButtons.CancelOK
-
Jeremy Falcon wrote:
Here's the thing the article does not account for, platform consistency.
Jeremy Falcon wrote:
Consistency man. Who cares about what what some guy wrote on his blog.
Wow, I guess you just skipped over the whole section about Platform Consistency not being good enough:
Quote:
It’s also a popular excuse to use to not think deeply about the design problems users face. What’s the benefit of following a design convention, if one doesn’t know why it exists, or if it’s right for users in the first place?
If consistency becomes your sole argument, then there is no need to refute anything else. You have chosen the point that no design rationale is important because all that matters is what everyone else does. Okay, I do not want to get into a big argument, but my observation is that there is no real consistency in the wide world of UI. I have seen places where Cancel | OK is used instead of OK | Cancel and that means that everyone always has to read the screen carefully. Inconsistency is consistent.
Leslie K. wrote:
Wow, I guess you just skipped over the whole section about Platform Consistency not being good enough:
Nope, I just don't agree with it.
Leslie K. wrote:
If consistency becomes your sole argument, then there is no need to refute anything else. You have chosen the point that no design rationale is important because all that matters is what everyone else does.
You're absolutely correct, and ironically enough I don't always copy the herd, so go figure. However, 9 out of 10 times when I see UIs that swap the order, the UI has no thought, is ugly, etc. So, while I totally agree with this, in practice, I see it being wrong as the result of laziness. But, I do respect anyone that puts thought into it, even if I don't agree with them.
Jeremy Falcon
-
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people). The next time he brings it up I might punch him in the face. :mad:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
I agree with him. You should always try and follow what the OS does. And since your app's a Windows app, you need to do what Windows does, which is always OK on the left and Cancel to the right. It'll make it way way easier for your users when your app starts behaving like the rest of the OS.
Regards, Nish
Blog: voidnish.wordpress.com Latest article: C++ 11 features in Visual C++ 2013 Preview
-
Quote:
just because something is done one way in a different environment doesn't mean it should be done that way everywhere
It does if I say so! ;P
- I would love to change the world, but they won’t give me the source code.
Ha!
Jeremy Falcon
-
Not a bad idea at all: you bind the fishing line to the end of the rifle, and when you get bored you shoot the competition :cool:
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto) Point in case: http://www.infoq.com/news/2014/02/apple_gotofail_lessons[^]
Stefan_Lang wrote:
Not a bad idea at all: you bind the fishing line to the end of the rifle, and when you get bored you shoot the competition
Now if we just toss a boomerang on the end of the line, we'll never have to go get our food again!
Jeremy Falcon
-
For several months now, one of our testers has been pushing to get the OK and Cancel buttons switched in every single dialog in our application (roughly 200 dialogs). His only reasoning for this is that the way we do it (OK in bottom right corner, Cancel to the left of it) is the opposite of what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). That is his one and only reason. He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people). The next time he brings it up I might punch him in the face. :mad:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
In every other application it is the reverse OK on left cancel on right, so I agree with him. I think users will inevitable hit Cancel when they mean OK on your app. If they are using your app more than other apps, then they will accidentally hit Cancel on the other apps when they mean OK. So this is a valid and a smart reasoning.
-
cpkilekofp wrote:
I've seen what you suggest in actual implementation for truly critical application paths, and it has its place there, but for general use in all applications your user base would rise up in arms and depose you for a less educated but more practical developer.
If you're gonna argue, at least attempt to address the point I was making. You ain't. Thus, arguing with yourself you are.
cpkilekofp wrote:
BTW, as part of my Master's Degree in Computer Science, I took the User Interface Seminar, so I'm familiar with the principles you expose. Many of them fail miserably in general practice because they interfere with getting things done as quickly as humanly posssible for the least cost, which are principles from another discipline entirely called BUSINESS.
Nice generic references there with no solidity. Btw, as part of my real life BUSINESS experience making multi-million dollar software instead of some intangible academia references where it's impossible to have 1,000s of users for your software, I disagree. Please, continue spewing more generic fluff that sounds religious. Kids these days.
Jeremy Falcon
I've seen the point you're making numerous times. I've seen software successfully implement that idea. I didn't say it wasn't a good idea in many circumstances. When the decision to commit or cancel cannot be undone afterward, your assertion makes a great deal of sense. When the decision to commit or cancel can easily be undone, say, through an edit screen accessed later, it is far less critical, and when the goal of the interface is speedy manual input of large amounts of information, randomly changing the position of screen controls forces the operator to make time-wasting decisions. This is not acceptable in many business contexts. Further, if you have two hundred items to change, that's two hundred points of failure you now have to test for, and that's a lot of man-hours you now have to pay for - and for what? Are you gaining in safety what you lose in time to change the code, time to test it, and time for your user base to get used to the new entry pattern? Both of these points have to be addressed in order to justify to a business an extensive change like this. You justify the decision because the current control order "shows a complete lack of disregard (??) for standards and poor UI design" because "the whole reasoning behind Cancel | OK is completely invalidated by changing its order." How about some statistics? What is the level of acceptance or cancellation in error due to the fact that these buttons are in a particular order at all times in this application? In short, can you at least suggest a technique to prove or even support your assertion in a way that bears some resemblance to science and not doctrine? Because that's what you are promoting - and yes, it does "sound religious", doesn't it? Nearly 30 years of development experience in businesses from four employee startups to 60,000 employee companies in the Fortune 100 has made me a development atheist - I don't believe it until I've tested it. Nor do I make decisions without considering the context in which the decision will be made and the cost of implementing that decision - I show a "complete lack of disregard" (that is to say, I place great regard) for the business consequences of a software doctrinal decision.
"Seize the day" - Horace "It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
-
I've seen the point you're making numerous times. I've seen software successfully implement that idea. I didn't say it wasn't a good idea in many circumstances. When the decision to commit or cancel cannot be undone afterward, your assertion makes a great deal of sense. When the decision to commit or cancel can easily be undone, say, through an edit screen accessed later, it is far less critical, and when the goal of the interface is speedy manual input of large amounts of information, randomly changing the position of screen controls forces the operator to make time-wasting decisions. This is not acceptable in many business contexts. Further, if you have two hundred items to change, that's two hundred points of failure you now have to test for, and that's a lot of man-hours you now have to pay for - and for what? Are you gaining in safety what you lose in time to change the code, time to test it, and time for your user base to get used to the new entry pattern? Both of these points have to be addressed in order to justify to a business an extensive change like this. You justify the decision because the current control order "shows a complete lack of disregard (??) for standards and poor UI design" because "the whole reasoning behind Cancel | OK is completely invalidated by changing its order." How about some statistics? What is the level of acceptance or cancellation in error due to the fact that these buttons are in a particular order at all times in this application? In short, can you at least suggest a technique to prove or even support your assertion in a way that bears some resemblance to science and not doctrine? Because that's what you are promoting - and yes, it does "sound religious", doesn't it? Nearly 30 years of development experience in businesses from four employee startups to 60,000 employee companies in the Fortune 100 has made me a development atheist - I don't believe it until I've tested it. Nor do I make decisions without considering the context in which the decision will be made and the cost of implementing that decision - I show a "complete lack of disregard" (that is to say, I place great regard) for the business consequences of a software doctrinal decision.
"Seize the day" - Horace "It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
I've lost interest. Chances of me actually reading this: 0.5%.
Jeremy Falcon
-
Microsoft published a design guide, in the before the before, that suggested putting the OK button on the right was correct and that most user expected that. Then when Microsoft switched to placing OK buttons on the left, the guide mysteriously disappeared. It was a well written research article, to this day I wish I had printed it. My personal opinion is that the confirmation should be in the same location every time and should not float. Placing it on the left makes it float. For example on an OK only dialog the OK button will be in a different place from the OK Button in an OK Cancel Dialog. Long story short, just because Microsoft does something doesn't make it correct. More importantly I agree with your button placement, and furthermore I like using the word furthermore.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
The “design guide” did not disappear; for my copy it morphed into the Windows “User Experience Interaction Guidelines for Windows 7 and Windows Vista”; an 882 page tome that I found quite useful when I designed and documented my most recent Windows apps (e.g. does one “click the xxx button” or just “click xxx”?). And it’s still (OK, Cancel); (Yes, No) …. From page 503 of the “new” MS design guide: Present the commit buttons in the following order: OK/[Do it]/Yes [Don't do it]/No Cancel Apply (if present) Help (if present) (Some of my apps are used by "farm boys" and "old-timers"; they've had no complaints when I followed the MS "standard").
-
I've lost interest. Chances of me actually reading this: 0.5%.
Jeremy Falcon
LMAO kids these days have no attention span whatsoever.
"Seize the day" - Horace "It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover