|
Acknowledge it is a bug and resolve it as "won't fix".
|
|
|
|
|
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!
|
|
|
|
|
Quote: what Microsoft does throughout Windows(Cancel in bottom right corner, OK to the left of it). 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.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
This makes sense. Please make it happen.
|
|
|
|
|
This is another line of reasoning that I have seen before that I definitely agree with. Let me just get Uncle Bill on the phone and we can have this whole mess straightened out in no time.
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
|
|
|
|
|
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
|
|
|
|
|
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!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
It is just plain wrong. The dialog is shown for breaking the sequence, not for making it flow.
|
|
|
|
|
Order is important, as are expectations.
Always wipe, then pull up trousers.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The real problem occurs if you wipe, then pull up trousers, then wipe again...
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
|
|
|
|
|
That depends whether you wanted to get rid of the stain on the back of your pants, or the wipe is your trousers wiping your sht covered @rse.
And member rse just got an email...
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
The console is a black place [taken from Q&A]
How to ask a question
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|