|
Colin Mullikin wrote: that uses our software (thousands of people).
So say you have 10,000 users.
In 10 years how many of those same users will be using it?
How many new users will be using it?
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.
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.
|
|
|
|
|
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
modified 20-May-14 15:53pm.
|
|
|
|
|
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 
|
|
|
|
|
Remove the Cancel button. 
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!  Or may be a variant where OK and Cancel switch places when your mouse pointer gets near 
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
