Cancel - OK
-
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
-
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 am referring to the fact that there was one from MS that stated (Cancel | OK) was the preferred method. I would have never noticed had it not "changed". Just another case of MS doing something different to be different. Of course, design guides and research documents going be different.
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
-
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
I have a long one, I just don't value what you have to say. Ta ta.
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 consistency with the OS, you should switch the buttons, in consistency with the current user base, you should punch his face... ;P
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
Colin Mullikin wrote:
We have been consistently doing it this way for over a decade.
I get it, but I don't believe there is every a valid reason for continuing to do something wrong. I realize you got users to deal with that may even not care as much as devs do, but I'd still fix it.
Jeremy Falcon
A few random thoughts come to my mind... I've always hated how WinZip randomly changes the buttons on their trial software when it first loads, tricking me into hitting the Buy button. If you write Windows software, you should stick with the conventions established by Windows. Major software vendors have made major changes (like swapping the buttons) when they have new major release of their software. Maybe that's the time to change button positions, if it's decided they need to be changed. I'm guessing many users will curse the first time they hit the wrong button, and maybe the second or third time. But after that they'll have learned the new positioning. They learned in the first time they used the software and had to realize it was opposite of how all their other software does it. People may be stupid, but they're usually not THAT stupid. I really hate keyboards that move around the Insert, Delete, and other keys found above the arrows. I'm really glad someone challenged the position of the starter on cars. I'd hate to have to stand in front of the car and crank a handle just because it was always done that way. And remember rotary telephones? :-) Things will forever evolve and we must regularly update things to keep up with the continual change. Case in point, if you want your application to work well on a touch device, you'll need to make things easier to tap with a finger (generally larger) and within reach of a thumb. And the interface usually needs to be simplified. Evolution.
-
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
It doesn't matter if he's right or not. He's supposed to be testing functionality, not commenting on UI style. If the OK or Cancel buttons don't perform the desired function, then and only then should he comment on the buttons, and ONLY if those buttons are broken. He's a tester, not a UI designer.
".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 -
Here is an article that better explains my reasoning: Clickety[^]
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
From the article: "...but you cannot ignore the fact that users will look at all of their options before they choose which action to take." The article may be correct, but the author provides no proof. Was an eye tracking study done? I generally don't look at all the options if the first one I see is the correct one. And I'm guessing that OK and Cancel buttons result in very fast fixations because our brains are doing visual pattern matching against two very common and distinct options.
-
It doesn't matter if he's right or not. He's supposed to be testing functionality, not commenting on UI style. If the OK or Cancel buttons don't perform the desired function, then and only then should he comment on the buttons, and ONLY if those buttons are broken. He's a tester, not a UI designer.
".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, 2013John Simmons / outlaw programmer wrote:
He's a tester, not a UI designer.
Most agile environments have requirements analysts who double up as first level QA. So if that's the case here, the tester is also the guy who can dictate specs.
Regards, Nish
Blog: voidnish.wordpress.com Latest article: C++ 11 features in Visual C++ 2013 Preview
-
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.
Poor OP. Came here for sympathy, and got just the opposite :-)
Regards, Nish
Blog: voidnish.wordpress.com Latest article: C++ 11 features in Visual C++ 2013 Preview
-
A few random thoughts come to my mind... I've always hated how WinZip randomly changes the buttons on their trial software when it first loads, tricking me into hitting the Buy button. If you write Windows software, you should stick with the conventions established by Windows. Major software vendors have made major changes (like swapping the buttons) when they have new major release of their software. Maybe that's the time to change button positions, if it's decided they need to be changed. I'm guessing many users will curse the first time they hit the wrong button, and maybe the second or third time. But after that they'll have learned the new positioning. They learned in the first time they used the software and had to realize it was opposite of how all their other software does it. People may be stupid, but they're usually not THAT stupid. I really hate keyboards that move around the Insert, Delete, and other keys found above the arrows. I'm really glad someone challenged the position of the starter on cars. I'd hate to have to stand in front of the car and crank a handle just because it was always done that way. And remember rotary telephones? :-) Things will forever evolve and we must regularly update things to keep up with the continual change. Case in point, if you want your application to work well on a touch device, you'll need to make things easier to tap with a finger (generally larger) and within reach of a thumb. And the interface usually needs to be simplified. Evolution.
You totally get where I'm coming from. If intelligent thought is the reason behind the change then I'm all for it. It's how we improve the world. If it's laziness or "just because" then I'm usually against it. In my experience, people that typically get the buttons backwards suck at UI design overall, as it's due to just not studying UI in the first place. It's like a shortcut I use to know if they have an idea of what they're doing or not.
Jeremy Falcon
-
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, 2013John Simmons / outlaw programmer wrote:
The tester should just STFU, especially if this issue has been previously marked as "not a bug"
Oh I agree with you there, especially if the original design pre dates the flavour of UI design. I just think the original design is flawed as I am pretty sure the dialog layout was set in the late 80s.
Never underestimate the power of human stupidity RAH
-
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
Ask him t present a full proposal, with costing.
I wanna be a eunuchs developer! Pass me a bread knife!
-
John Simmons / outlaw programmer wrote:
The tester should just STFU, especially if this issue has been previously marked as "not a bug"
Oh I agree with you there, especially if the original design pre dates the flavour of UI design. I just think the original design is flawed as I am pretty sure the dialog layout was set in the late 80s.
Never underestimate the power of human stupidity RAH
When you consider the intended role of the tester, and his operational charter, my point renders the question of button order irrelevant.
".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 -
John Simmons / outlaw programmer wrote:
He's a tester, not a UI designer.
Most agile environments have requirements analysts who double up as first level QA. So if that's the case here, the tester is also the guy who can dictate specs.
Regards, Nish
Blog: voidnish.wordpress.com Latest article: C++ 11 features in Visual C++ 2013 Preview
I've never participated in an environment where a *tester* was expected to dictate functional specs, and while testers may often question control layout, it's handled via email, and is NOT posted as a bug unless the control overlaps another control or inhibits other form functionality.
".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 -
In my opinion, this line of reasoning reinforces my point. A new user is going to look at the buttons regardless, so it doesn't matter what kind of system/other applications they are used to. An expert user, on the other hand, is relying on the OK button being in the corner. I would rather count on new users adapting to our standard than annoy every single existing customer by switching the placement.
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:
An expert user, on the other hand, is relying on the OK button being in the corner.
That however depends on the application. As I said a 'data entry' type application most users will not use the mouse. As a more specific example if the application is a call center app and the call center people are being monitored then how long it takes them to use the application goes into the per call time, and better times are better. Which means that the better ones will use the keyboard. And the ones that are not so good, probably should. But your application might not fall into that category.
