|
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.
|
|
|
|
|
Leslie K. wrote: Wow, I guess you just skipped over the whole section about Platform Consistency not being good enough:
Nope, I just don't agree with it.
Leslie K. wrote: 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.
You're absolutely correct, and ironically enough I don't always copy the herd, so go figure. However, 9 out of 10 times when I see UIs that swap the order, the UI has no thought, is ugly, etc. So, while I totally agree with this, in practice, I see it being wrong as the result of laziness.
But, I do respect anyone that puts thought into it, even if I don't agree with them.
Jeremy Falcon
|
|
|
|
|
From the article:
"...but you cannot ignore the fact that users will look at all of their options before they choose which action to take."
The article may be correct, but the author provides no proof. Was an eye tracking study done? I generally don't look at all the options if the first one I see is the correct one. And I'm guessing that OK and Cancel buttons result in very fast fixations because our brains are doing visual pattern matching against two very common and distinct options.
|
|
|
|
|
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!
|
|
|
|
|
Quote: I've studied UI, and the whole reasoning behind doing something like Cancel | OK is completely invalidated by never changing its order.
Really? You've "studied UI"?? Add to your studies that many if not most of these OK/Cancel buttons respond to Enter for OK and Escape for Cancel. Man does not compute by mouse alone, and neither should a UI expert. Talk about ivory towers...I've seen what you suggest in actual implementation for truly critical application paths, and it has its place there, but for general use in all applications your user base would rise up in arms and depose you for a less educated but more practical developer.
BTW, as part of my Master's Degree in Computer Science, I took the User Interface Seminar, so I'm familiar with the principles you expose. Many of them fail miserably in general practice because they interfere with getting things done as quickly as humanly posssible for the least cost, which are principles from another discipline entirely called BUSINESS.
"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
|
|
|
|
|
cpkilekofp wrote: I've seen what you suggest in actual implementation for truly critical application paths, and it has its place there, but for general use in all applications your user base would rise up in arms and depose you for a less educated but more practical developer.
If you're gonna argue, at least attempt to address the point I was making. You ain't. Thus, arguing with yourself you are.
cpkilekofp wrote: BTW, as part of my Master's Degree in Computer Science, I took the User Interface Seminar, so I'm familiar with the principles you expose. Many of them fail miserably in general practice because they interfere with getting things done as quickly as humanly posssible for the least cost, which are principles from another discipline entirely called BUSINESS.
Nice generic references there with no solidity. Btw, as part of my real life BUSINESS experience making multi-million dollar software instead of some intangible academia references where it's impossible to have 1,000s of users for your software, I disagree.
Please, continue spewing more generic fluff that sounds religious. Kids these days.
Jeremy Falcon
|
|
|
|
|
I've seen the point you're making numerous times. I've seen software successfully implement that idea. I didn't say it wasn't a good idea in many circumstances. When the decision to commit or cancel cannot be undone afterward, your assertion makes a great deal of sense. When the decision to commit or cancel can easily be undone, say, through an edit screen accessed later, it is far less critical, and when the goal of the interface is speedy manual input of large amounts of information, randomly changing the position of screen controls forces the operator to make time-wasting decisions. This is not acceptable in many business contexts.
Further, if you have two hundred items to change, that's two hundred points of failure you now have to test for, and that's a lot of man-hours you now have to pay for - and for what? Are you gaining in safety what you lose in time to change the code, time to test it, and time for your user base to get used to the new entry pattern?
Both of these points have to be addressed in order to justify to a business an extensive change like this. You justify the decision because the current control order "shows a complete lack of disregard (??) for standards and poor UI design" because "the whole reasoning behind Cancel | OK is completely invalidated by changing its order." How about some statistics? What is the level of acceptance or cancellation in error due to the fact that these buttons are in a particular order at all times in this application? In short, can you at least suggest a technique to prove or even support your assertion in a way that bears some resemblance to science and not doctrine?
Because that's what you are promoting - and yes, it does "sound religious", doesn't it? Nearly 30 years of development experience in businesses from four employee startups to 60,000 employee companies in the Fortune 100 has made me a development atheist - I don't believe it until I've tested it. Nor do I make decisions without considering the context in which the decision will be made and the cost of implementing that decision - I show a "complete lack of disregard" (that is to say, I place great regard) for the business consequences of a software doctrinal decision.
"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
|
|
|
|
|
I've lost interest. Chances of me actually reading this: 0.5%.
Jeremy Falcon
|
|
|
|
|
LMAO kids these days have no attention span whatsoever.
"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
|
|
|
|
|
I have a long one, I just don't value what you have to say. Ta ta.
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: Cancel | OK
Thanks Jeremy!!
I just finally understand what this 'OK | Cancel' order is about, after all those years! 
|
|
|
|
|
Will Rogers never met me.
|
|
|
|
|
|
He might annoy you and all the other devs, but he DOES have a point...
I've dealt with customers who wanted me to change my software because it was not compliant with the Microsoft standard (small things like the order of OK and Cancel, an icon etc.).
I'm now pretty keen on keeping things consistent with the OS I'm aiming at and, when there's no standard yet, keeping things consistent within my application.
Perhaps now your customers are used to it it's not a good idea to change it though... Although new customers may benefit from it.
It's an OO world.
public class SanderRossel : Lazy<Person>
{
public void DoWork()
{
throw new NotSupportedException();
}
}
|
|
|
|
|
Quote: Perhaps now your customers are used to it it's not a good idea to change it though... Although new customers may benefit from it.
Cost versus benefits...if your current user base is very small compared to the new user base, and your new user base is more likely to purchase your product if you change, then it may make sense.
These changes do not come for free.
"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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
