|
Colin Mullikin wrote: God among men
I think I worked with the same guy. The guy I used to work with would submit bug reports with really detailed information such as "The button text is wrong". Just figuring that we would know which button he was talking about and what text... 
|
|
|
|
|
Wes Aday wrote: "The button text is wrong". Just figuring that we would know which button he was talking about and what text.
Perhaps you misspelled "OK" on your dialog buttons?
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
RyanDev wrote: misspelled "OK"
Entirely possible. I thought he was talking about maybe "The" button text was wrong and I spent years going through the code looking for a button with "The" on it... 
|
|
|
|
|
Easy, close the ticket with the comment "unable to locate 'The' button". 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Wes Aday wrote: The guy I used to work with would submit bug reports with really detailed information such as "The button text is wrong". Just figuring that we would know which button he was talking about and what text...
Hahahaha, I used to work with a QA department that would frequently write, "I was doing something when the program crashed."
We were so happy when one of the programmers transferred to the QA department and could give us accurate, step by step instructions on how to duplicate a bug.
He really transferred because our manager would always harass him and he wanted to stick it to the manager by pointing out all the bugs she wanted swept under the rug. Her status reports always made it seem that everything was working perfectly, but he knew all the places he could lean on the code to make it fail and provided the documentation to prove he wasn't making them up.
He was out to get revenge on her, but he knew the documentation would help us at the same time.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
Don't they all? ...I was giving some customers training recently and I actually noticed that some of the screens in part of one of our systems have the OK/CANCEL in one order and others have it reversed. 
|
|
|
|
|
Quote: This particular tester seems to think that he is a God among men when it comes to interfaces...
I think I've met him...and her...many times in my career. I was that idiot, in fact, for the first couple of years of my career. Ask him how much of his pay he will donate to the costs of development and QA for this change.
"Seize the day" - Horace
"It's not what he doesn't know that scares me; it's what he knows for sure that just ain't so!" - Will Rogers, said by him about Herbert Hoover
|
|
|
|
|
Colin Mullikin wrote: That is his one and only reason.
And it's a valid reason.
Colin Mullikin wrote: He fails to acknowledge that switching it will annoy the hell out of every single person that uses our software (thousands of people).
It probably annoyed them when y'all did it backwards to start with. Can always annoy them again.
I've studied UI, and the whole reasoning behind doing something like Cancel | OK is completely invalidated by never changing its order. In fact, to be consistent with the premise of it, you should change it randomly (ie to force users to read the message). Otherwise it just shows a complete lack of disregard for standards and poor UI design.
Jeremy Falcon
|
|
|
|
|
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
|
|
|
|
|
Colin Mullikin wrote: A reason I have seen for Cancel | OK is ...
Good try but no I don't buy it.
There are two types of users, novice and expert.
A novice user fumbles about regardless.
An expert relies on patterns. They don't see anything they just know (this is the very people you otherwise argued would be ignored by the change.)
And if applicable in a standard data entry type application the placement should be irrelevant because a touch typist will use the keyboard and tab to get the ok rather than the mouse.
|
|
|
|
|
jschell wrote: Good try but no I don't buy it.
Agreed.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: jschell wrote: <layer>Good try but no I don't buy it.
Agreed.
Me too.
All are born right-handed. Only gifted few overcome it.
There's NO excuse for not commenting your code.
|
|
|
|
|
In my opinion, this line of reasoning reinforces my point. A new user is going to look at the buttons regardless, so it doesn't matter what kind of system/other applications they are used to.
An expert user, on the other hand, is relying on the OK button being in the corner.
I would rather count on new users adapting to our standard than annoy every single existing customer by switching the placement.
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: An expert user, on the other hand, is relying on the OK button being in the corner.
That however depends on the application.
As I said a 'data entry' type application most users will not use the mouse.
As a more specific example if the application is a call center app and the call center people are being monitored then how long it takes them to use the application goes into the per call time, and better times are better. Which means that the better ones will use the keyboard. And the ones that are not so good, probably should.
But your application might not fall into that category.
|
|
|
|
|
Colin Mullikin wrote: A reason I have seen for Cancel | OK is that if the user does read the buttons, it results in fewer visual fixations.
I don't see how that's humanly possible if they read the buttons. They still have to look at them.
Jeremy Falcon
|
|
|
|
|
Here is an article that better explains my reasoning: Clickety[^]
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: 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 > done makes more since than text > Cancel > Ok > done when 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
|
|
|
|
|
While I pretty much agree with everything you just said, the key is consistency. We have been consistently doing it this way for over a decade.
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 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... 
|
|
|
|
|
A few random thoughts come to my mind...
I've always hated how WinZip randomly changes the buttons on their trial software when it first loads, tricking me into hitting the Buy button.
If you write Windows software, you should stick with the conventions established by Windows.
Major software vendors have made major changes (like swapping the buttons) when they have new major release of their software. Maybe that's the time to change button positions, if it's decided they need to be changed.
I'm guessing many users will curse the first time they hit the wrong button, and maybe the second or third time. But after that they'll have learned the new positioning. They learned in the first time they used the software and had to realize it was opposite of how all their other software does it. People may be stupid, but they're usually not THAT stupid.
I really hate keyboards that move around the Insert, Delete, and other keys found above the arrows.
I'm really glad someone challenged the position of the starter on cars. I'd hate to have to stand in front of the car and crank a handle just because it was always done that way. And remember rotary telephones? 
Things will forever evolve and we must regularly update things to keep up with the continual change. Case in point, if you want your application to work well on a touch device, you'll need to make things easier to tap with a finger (generally larger) and within reach of a thumb. And the interface usually needs to be simplified. Evolution.
|
|
|
|
|
You totally get where I'm coming from. If intelligent thought is the reason behind the change then I'm all for it. It's how we improve the world. If it's laziness or "just because" then I'm usually against it. In my experience, people that typically get the buttons backwards suck at UI design overall, as it's due to just not studying UI in the first place. It's like a shortcut I use to know if they have an idea of what they're doing or not.
Jeremy Falcon
|
|
|
|
|
No way the "OK" button should always be the default button that gets an Enter/Return as a click !
Which is the clicked-if-enter/return should depend on context, where context includes the application, the particular circumstances/meaning of a specific dialog, whether or not "undo" is available, etc.
“I speak in a poem of the ancient food of heroes: humiliation, unhappiness, discord. Those things are given to us to transform, so that we may make from the miserable circumstances of our lives things that are eternal, or aspire to be so.” Jorge Luis Borges
|
|
|
|
|
BillWoodruff wrote: No way the "OK" button should always be the default button that gets an Enter/Return as a click !
I actually agree with you on that. Realistically though it is more than times than not.
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
