|
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.
|
|
|
|
|
I'd be all for leaving it as it is, with cancel selected as the default button.
My experience is that users really don't tend to like things moving around, unless they have asked for it.
That said don't sweat the small stuff - I know that's way easier said than done.
If someone is pushing in such a big way for what amounts to a small change and it does not make sense - make sure you email them explaining why you think it is not such a good idea and let them go ahead with it.
That way you have yourself covered if criticism comes your way for the change.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Don't worry, there has been copious* amounts of discussion on this subject. Everyone knows where everyone else stands on the matter. 
Also, I'm not even the dev that has to deal with making this change. I'm just the one that tends to get into the design debates with this tester. We have had quite a few battles with one another.
*Side note: I love using that word.
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
|
|
|
|
|
Depends on the structure of your code as to how much work it would be, but you could add a persistent option to the software that allow users to select which standard they want to use: the new and improved Microsoft standard, or the old default way that it has always been. Depending on the option selected, just switch the buttons appropriately. Now your tester is happy, and probably also a good portion of your users who are used to the Microsoft standard.
-NP
Never underestimate the creativity of the end-user.
|
|
|
|
|
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
|
|
|
|
|
It should be relatively easy to make a function that would to that automatically and just ensure that the function is called when the dialog is displayed.
If your code is object oriented, then you might essentially use a base dialog/form that will do it automatically and just update existing form to derive from that class instead of the original one.
This would really the best option and if the application is installed for the first time, it could use the new order by default and otherwise use the old order.
That way everyone is happy and the developer has some chalenge...
Philippe Mori
|
|
|
|
|
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.
|
|
|
|
|
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 QA
FTFY. 
|
|
|
|
|
What about letting users configure it themselves? A simple routine to set the button text and dialog return value for all OK/Cancel buttons would do the trick. That way older users could keep doing things the way they are comfortable with, while new users could do things the "Microsoft Way" if they want.
Or you might even get rid of the Cancel buttons. I never saw much use in them myself. The "X" in the upper right corner can be used for the same functionality. I suppose it might make some users more secure having a specific button for abandoning changes, though, just so they could be sure their exit is done in a controlled manner. Although you can code the X to do exactly the same as a Cancel button, it might seem more unsafe to users.
|
|
|
|
|
What kind of weird design decision was it to have it the opposite way round to, probably, 99% of every other application out there?
.-.
|o,o|
,| _\=/_ .-""-.
||/_/_\_\ /[] _ _\
|_/|(_)|\\ _|_o_LII|_
\._. |\_/|"` |_| ==== |_|
|_|_| ||" || ||
|-|-| ||LI o ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
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 
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
|
|
|
|
|
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
|
|
|
|
|
Mycroft Holmes wrote: I still use a DAL that pre dates Entity Framework by a decade
 As do I and probably most experienced practitioners.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Colin Mullikin wrote: (OK in bottom right corner, Cancel to the left of it)
Which is the sane way to do it. When I first started using Windows in the 3.1 days, I kept clicking on the the Cancel button by accident because that intuitively seemed to be the most logical place for "continue on to the next dialog." I've always that that the way Microsoft decided to do it was bassackwards. And no, I don't believe Microsoft "studied" the problem or knows anything more about good UI design than I do. Just look at W8 for proof.
Colin Mullikin wrote: The next time he brings it up I might punch him in the face.
Nah, swat him on the butt and ask him if you broke his nose. Obviously he's got his head where his arse is, just like his idea for where the OK and Cancel buttons should be.
Marc
|
|
|
|
|
Consistency is the key...
But I'm curious. Am I the only person who uses .net msgbox's and hence to achieve consistency you have to use OK-Cancel.
|
|
|
|
|
Simple solution is to have a OkayCancelButtons composite control that you can use a style setting to choose which way round they appear. Default is Cancel/Okay and QA mode is Okay/Cancel
|
|
|
|
|
Doing this is entirely situational, switching the OK/Cancel buttons on a few dialogue boxes now and then so that the end user actually has to pay attention as to what they are doing rather than just clicking OK on everything while being a zoned out drone. Alternately you can randomise the OK/Cancel button so that on some dialogue boxes they are switched and on others not, but when the program is used a second time, the OK/Cancel buttons may be in the reverse order.
But if you don't mind your users being zoned out drones then there is no legitimate reason to switch them.
|
|
|
|
|
Does seem kinda dumb to have them the wrong way around
Windows has had them the same way around for way more than a decade
|
|
|
|
|
Change all the 'OK' buttons to 'This is what I want to do'
and 'Cancel' to 'I do not wish to change my mind'
The advantage of this is that you will have no room for any other buttons,
so you can't change their test.!
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
