|
Well, you should have thought of that before you did such a piss poor design... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-----
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-----
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
I came to Windows from RISC OS, where OK was in the bottom right, two decades ago, and I still think that it's the correct layout.
If MS thinks it's right for the order to be OK - Cancel, why don't they use Next - Prev too?
|
|
|
|
|
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. 
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
|
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.
|
|
|
|
|
Exactly.
But your example is quite different from the subject.
|
|
|
|
|
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.
|
|
|
|
|
His reasoning is valid. It may not be sufficient to justify changing it, either because user annoyance more than counters it or simply because it's a reasonably large cost for a reasonably small gain, so he shouldn't keep pushing it if he's been rebuffed. But inconsistency with standard OS practices is a valid thing for a tester to complain about.
|
|
|
|
|
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.
|
|
|
|
|
>>new users would cancel rather than choosing the usual ok.
That's the point: <b>WHO in his right mind would DO some action that he is most likely GOING TO CANCEL??!</b>
|
|
|
|
|
I thought it worked like this:
Windows
OK Cancel
Mac
Cancel OK
Mobile
put the most likely button to be pressed closest to my right thumb, please!
(Especially important in landscape mode and as phone screens become larger)
I noticed that Rovio changed a few of its prompts between Angry Bird versions which my thumb appreciated.
In my brain it should follow the local reading order.
English L-R, OK/default Cancel.
Arabic R-L, Cancel OK/default
|
|
|
|
|
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
|
|
|
|
|
I would not only punch you in the face, I'd probably break skull of anyone who tries to make me "think RTL"! 
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. 
PS/2: I think I'll start saving money so I can travel to where GTK developers gather and start a massacre
|
|
|
|
|
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. 
|
|
|
|
|
So you don't use the "Default" MessageBoxes? Did you (your company) create special "MessageBoxes" with Cancel/OK too? 
If you did so - I hope you also created your own "MessageBoxButtons" enumeration (MessageBoxButtons.OKCancel MessageBoxButtons.CancelOK
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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 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 
|
|
|
|
|
In consistency with the OS, you should switch the buttons, in consistency with the current user base, you should punch his face... 
|
|
|
|
|
Ask him t present a full proposal, with costing.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
He should re-apply for a job as a product engineer instead of QA, then he can change it and answer to the customers who don't like the change.
"And when I have understanding of computers, I shall be the Supreme Being!"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
