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
-
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:
That is his one and only reason
Unfortunately it is a good reason. One thing I learned is that users complain a lot, but very often they adapt within a few hours of the rollout. Those that can't adapt are those that couldn't work with it in the first place. Besides 200 dialogs is not thát much. Yes it is a bloody annoying and tedious job. it will keep you busy for the better part of the day, but that's about it. But I can imagine it's not much fun to be told to do something when you did it differently for so long.
V.
(MQOTD rules and previous solutions) -
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
I agree. But unfortunatly this is the ideal and not the reality in the world. I've seen many applications where the developers thought it good to make the Cancel button default, not providing hot keys, even providing wonderful names for there buttons like proceed etc. Although the reasoning behind it may be to force the user to read the screen, I think the rest of the argument should keep in mind that a user who is familiar with a system would like to rely on automatics for the obvious tasks, and have a consistent experience across different applications. Well, one can only hope... :^)
-
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
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 -
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 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?
-
In my expert opinion :), the Cancel button should ALWAYS be on the right, and here's why... Your app undoubtedly has many dialogs, and not all of them have OK and Cancel. I have been writing enterprise apps going on 30 years. The set of dialogs I use contain some of these... - Yes & Cancel - Yes, No, Cancel. - Select & Cancel - Login & Cancel. - Save & Cancel. - Proceed & Cancel. - Connect & Cancel - Rotate, Align, Cancel - Ignore QA & Cancel ... and there are more. See the pattern? Cancel is ALWAYS last. Send your God this book[^]. It was written in book form by MS many moons ago, but the principals still apply. Book form is here[^] Then have him see this[^].
If it's not broken, fix it until it is
Kevin Marois wrote:
- Cancel & Yes
- Cancel, No, Yes.
- Cancel & Select
- Cancel & Login.
- Cancel & Save.
- Cancel & Proceed.
- Cancel & Connect
- Cancel, Rotate, Align
- Cancel & Ignore QAFTFY. ;)
-
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 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).
-
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
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.
-
As a side note, I should mention that the initial design decision was made over a decade ago. Switching now benefits no one. A reason I have seen for Cancel | OK is that if the user does read the buttons, it results in fewer visual fixations. If they want to click OK, the result is two visual fixations: Cancel, OK, click. If the buttons are switched, the result is three visual fixations: OK, Cancel, OK, click.
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
Just a thought: you seem to assume that every user always clicks buttons. Depending on your application, and considering the fact that some users are really good at the keyboard and may prefer not having to resort to the mouse, how many of your users, do you think, may be using the keyboard instead, and may be annoyed by the fact that for your - and only your - application they need to type [tab]-[tab}-[return] rather than just [tab]-return]? As a software devolper, I see that a lot of functionality in software development tools are mouse-oriented. Yet these functions are all also available via keyboard shortcuts or keyboard navigation! There are plenty of professionals who almost never use the mouse at all, simply because it slows them down. And I'm sure they would be less than happy if any of their tools would favor Cancel/OK over OK/Cancel!
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[^]
-
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
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.
-
We switched the order internally for one day, and every single person that used it clicked Cancel at least a dozen times when they meant to hit OK, including the tester that wants it switched. So, despite knowing about the change and being a regular user of other applications with the OK | Cancel standard, I had to consciously make sure I clicked the correct button, rather than using my "muscle memory" of clicking on the bottom right corner.
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
If Microsoft worked by that logic we'd still be using MS-DOS. Change takes getting used to. That doesn't mean it's bad.
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[^]
-
jschell wrote:
If say 9,000 of 11,000 total users will still be using it have 10 years then I can see your argument.
However if after 10 years there will be 5,000 original users and 95,000 new users then the other person has a valid argument.We are growing, but no where near at that rate. I'm just spitballing numbers here, but I would guess we have roughly 15000-20000 users currently and gain a little less than 1000/year at our current pace.
jschell wrote:
But other than that this is a requirement/improvement and not a bug so a QA role shouldn't be driving that sort of change anyways so their view is irrelevant and ignorable.
We are a fairly small development team (~15 devs, 4 QA), so as much as I would like to agree with you, everyone kinda has their hands in everything.
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
At that rate (of new users coming in) I'm inclined to agree that changing any parts of the UI should better be based on a strong argument/benefit. If your numbers are halfway accurate, I'd not disregard this request entirely, but postpone it unto a time when you incorporate a major overhaul of the UI, or at least the dialog structure. Such redesigns are really helpful to keep up to date with modern UI standards, and to adapt to new OS versions - unless your company is SAP, of course ;P
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[^]
-
Remove the Cancel button. :-D Or how about one of those apps where the button moves whenever the mouse gets near it?
You'll never get very far if all you do is follow instructions.
I prefer the latter! :laugh: Or may be a variant where OK and Cancel switch places when your mouse pointer gets near ;)
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[^]
-
Colin Mullikin wrote:
Here is an article that better explains my reasoning: Clickety[^]
I see the point you were trying to make now. Keep in mind that only really applies to when learning the software. All of what we're talking about does of course. Anyway... Here's the thing the article does not account for, platform consistency. The whole visual fixation thing only really applies to when the user is first learning the software and also assuming your app is the only one one the planet for the OS installed, which it's not. The eyes and brain will make shortcuts depending on, you guess it, consistency as the user gets used to the computer. In Windows I just know which button is which without even looking for that very reason. Now, here's my take on it in regards to what the guy was trying to say about workflow. Considering the OK button is the button that's used the most, and meant to confirm the whole intent of the dialog even existing in the first place, it should be the focal point of a dialog's action buttons, that's why it's the default with the thick border. The user does not have to worry about Cancel unless something went wrong, which the majority of the time shouldn't happen. Cancel is the bastard stepchild nobody loves. Boo hoo for Cancel, but get out the way because we have work to do. So in regards to workflow only, which the article speaks of,
text > Ok > donemakes more since thantext > Cancel > Ok > donewhen considering the purpose of what the button is even there for. Consistency man. Who cares about what what some guy wrote on his blog.Jeremy Falcon
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.
-
Alternatively, you could acknowledge that this has been raised as a defect and put a ticket in your bug tracking system. Now, don't just treat this as meaning you've finished with your responsibility. The action to come out of this is to investigate the impact of reversing the change - and this means talking to your customers. I pretty much guarantee you that this is a feature that would be greeted with joy by them. Do the maths, and see what the cost of making the change would be. Finally, someone in authority needs to decide whether the cost of the change is worth it. If the answer is no, then you have the ticket to smack the tester with.
In my experience the customers rarely know whats good for them. Microsoft realized that a long time ago and keeps pushing changes that many beta testers vocally argued against. Sometimes the beta testers turn out to be right. But just as often they're wrong. In the end, it probably doesn't matter all that much which way you go - just don't waste too much time discussing it. The worst decision is always no decision!
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[^]
-
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
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.
-
Forogar wrote:
Is just plain wrong. The OK or "moving forward" button should be at the bottom right. The Cancel or "give up and go back" button should be to the left of it similar in action and placement to Forward and Back buttons on browsers - except they are at the top.
And people should fish with a rifle instead of a fishing pole. It's fish hunting season. Point being, just because something is done one way in a different environment doesn't mean it should be done that way everywhere.
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[^]
-
Colin Mullikin wrote:
That is his one and only reason
Unfortunately it is a good reason. One thing I learned is that users complain a lot, but very often they adapt within a few hours of the rollout. Those that can't adapt are those that couldn't work with it in the first place. Besides 200 dialogs is not thát much. Yes it is a bloody annoying and tedious job. it will keep you busy for the better part of the day, but that's about it. But I can imagine it's not much fun to be told to do something when you did it differently for so long.
V.
(MQOTD rules and previous solutions)But before they adapt, your highest paying customer forces the account manager to tell you to put it back as it was in the first place. Mean while, the lowest paying customers have already adapted to the change and complain when you change it back.
-
While I would love for this to be an option, it would require some work. We don't really have an ancestor form with the OK and Cancel that all other forms inherit from. If we did, it would be a nice easy switch, but as it is, the placement of the OK and Cancel buttons has to be switched in roughly 200 forms. We could potentially add a bit of code into each form that would dynamically change the position as you suggest, but I'm not sure it would be worth the work. Also, it would just spawn a new debate of what should be the default setting: the new way or the old way...
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:
We don't really have an ancestor form
If you don't already have one, consider introducing it, and think about other functionality that you then could easily implement for all the forms combined, with relatively low effort! I once worked on such an application (only about 35 forms IIRC, but then we were only a team of two), and got a request to introduce a feature that would affect most of these forms. Due to the number of forms and required amount of change, the request was never fulfilled. Much later we finally decided we couldn't go on without a common base form and just implemented it. Then I stumbled upon the old request and realized it could now be done with just a few hours of work... I should add that these forms were derived from system classes, so we had to actually slip our own common base class in-between the existing class hierarchy.
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[^]